TinyCore RedPill Loader Build Support Tool ( M-Shell )

[gericb]

20 hours ago, djvas335 said:

SSH was already enabled before this update so no need to change anything for now.

 

 

Hehehe, we'll I tried your tip, rebuilding the loader, to the previous version.  Interestingly, the system comes up, but can't login at this time.  It doesn't indicated the username/password is invalid. Possible the failed upgrades filled some critical space, and now can't even process the login. It's seeming like I am going to have to take the drive out, attach it to another system, clean out those failed uploads, that you mentioned before.  Hopefully that is pretty straight forward. 

Edited August 29 by gericb

[gericb]

4 hours ago, gericb said:

Hehehe, we'll I tried your tip, rebuilding the loader, to the previous version.  Interestingly, the system comes up, but can't login at this time.  It doesn't indicated the username/password is invalid. Possible the failed upgrades filled some critical space, and now can't even process the login. It's seeming like I am going to have to take the drive out, attach it to another system, clean out those failed uploads, that you mentioned before.  Hopefully that is pretty straight forward. 

So it looks like it was busy doing something in the background, maybe some rudimentary cleaning.  Now I am largely in line with @djvas335 and can get logged in, but aside from the Control Panel not launching, 10 installed Apps are stopped and reporting they need to be "Repaired".  I'm following KISS, so only have a simple EXT4 RAID1, I should be able to pull each drive and delete the same things to free up the space on both.  My primary target will be /upd@te but likely also  /var/spool and /var/log which will hopefully get me to the point where things are more "normal" again.  Possible I'll find more eligible directories or files that are purgeable. 

[Peter Suh]

On 8/29/2024 at 6:58 AM, gericb said:

Curious?  Is there no way to mount/access this /dev/md0 location from the Bootloader configuration tools, and delete all the files, like a Terminal? 🤔

 

I have experience mounting /dev/md0 via autorecover addon.
Please refer to the script below to find the location that needs to be organized.

 

At the stage where DSM can be installed,
You can access TTYD 7681 port instead of 5000 port through a web browser.

 

http://192.168.x.y(Your IP):7681

 

In there, please try the following.

 

cd /
mkdir /tmpR
mount /dev/md0 /tmpR
cd /tmpR

 

https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/autorecover/src/install.sh#L32C5-L32C16

Edited August 30 by Peter Suh

[djvas335]

Hi @Peter Suh can you confirm if the loader is working ? I have tried to build again for DS3622xs with JOT and it still gives me file is corrupt when installing latest DSM

Thanks

 

 

[Peter Suh]

14 hours ago, djvas335 said:

Hi @Peter Suh can you confirm if the loader is working ? I have tried to build again for DS3622xs with JOT and it still gives me file is corrupt when installing latest DSM

Thanks

 

 

 

Have you tried DSM 7.2.2? It's not a phenomenon that occurs for all users,

but the cause of the file corruption message appears to be different from the previous versions (error code 21),

so I've been checking with rr developer @wjz304 since yesterday.
Please stabilize it with DSM 7.2.1 and wait for the results.

[Peter Suh]

On 8/31/2024 at 12:00 AM, djvas335 said:

Hi @Peter Suh can you confirm if the loader is working ? I have tried to build again for DS3622xs with JOT and it still gives me file is corrupt when installing latest DSM

Thanks

 

 

 

Today I checked Jot Mod again.
Which type of loader did you use, USB/SATA?
From what I tested, the kernel panic kept occurring in the case of SATA type loader.
So, since it seems meaningless to distinguish between USB/SATA types now, I integrated the menu so that USB type and SATA type can be used together.
The integrated menu did not cause kernel panic.
As you can see in the capture,
It was reflected in version 1.0.4.3.

 

 

[midiman007]

@Peter Suh

Is there any maintenance we need to be doing on the boot USB drive.

The reason I am asking is that I have noticed that after reboots the boot loader is getting auto updated.

 

[Peter Suh]

4 minutes ago, midiman007 said:

@Peter Suh

Is there any maintenance we need to be doing on the boot USB drive.

The reason I am asking is that I have noticed that after reboots the boot loader is getting auto updated.

 

 

You can use the new version that is automatically updated.
The latest version after 1.0.4.2 is the required version for using DSM 7.2.2.

[djvas335]

I did not have any kernel panic and I use usb loader, my issue is that after rebuilding the loader I was getting the file is corrupt message, I will try again and inform of the result

 

3 hours ago, Peter Suh said:

 

Today I checked Jot Mod again.
Which type of loader did you use, USB/SATA?
From what I tested, the kernel panic kept occurring in the case of SATA type loader.
So, since it seems meaningless to distinguish between USB/SATA types now, I integrated the menu so that USB type and SATA type can be used together.
The integrated menu did not cause kernel panic.
As you can see in the capture,
It was reflected in version 1.0.4.3.

 

 

 

[djvas335]

I traced the problem to insufficient space on the system partition, you need to have at least 760mb for the update to complete sucessfully, in some systems coming from dsm6 the system partition is about 2.2gb compared to systems built directly on dsm7 which reserves about 7.6gb. So as soon as I freed space on the system partition, the update went through.

Edited September 1 by djvas335

[shibby]

in a few days i will change cpu from current i7-7700T to i5-13500T. Will M-Shell has working drivers for iGPU of 13gen CPU?

[gericb]

12 hours ago, djvas335 said:

I traced the problem to insufficient space on the system partition, you need to have at least 760mb for the update to complete sucessfully, in some systems coming from dsm6 the system partition is about 2.2gb compared to systems built directly on dsm7 which reserves about 7.6gb. So as soon as I freed space on the system partition, the update went through.

So that naturally begs the question, given the double+ increase in system space size, is this something we can increase after the fact? What do you think @Peter Suh?  Even then, any routines to initiate automatic purging of things in this space, at some interval? 🤔

[djvas335]

This space issue is actually a DSM thing, so to have a 7.2gb system partition you must erase your nas, recreate the loader and reinstall the DSM and it will create the new partition layout for you

 

8 hours ago, gericb said:

So that naturally begs the question, given the double+ increase in system space size, is this something we can increase after the fact? What do you think @Peter Suh?  Even then, any routines to initiate automatic purging of things in this space, at some interval? 🤔

 

[shibby]

@Peter Suh strange situation... I`m on DS423+ and i tried switch to SA6400. So i recompile TCRP using M-Shell (selected the same DSM version) After compilation and reboot i didn`t have even ping to my NAS. So i re-compile TCRP once again to DS423+ and... the same... no ping.

 

Lucky i had a backup. After restore VM (sata0 drive) my Xpenology booted and i have back connection.

[Peter Suh]

20 hours ago, gericb said:

So that naturally begs the question, given the double+ increase in system space size, is this something we can increase after the fact? What do you think @Peter Suh?  Even then, any routines to initiate automatic purging of things in this space, at some interval? 🤔

 

I have looked into the /dev/md0 structure while applying the automatic patch of the ramdisk in the recently applied autorecover addon mentioned above.
I have never seen a case where unnecessary contents are placed unnecessarily for actual updates, so I am not sure if it is possible to implement it.
I think you have already cleaned up /dev/md0,
Can you list for me what contents (mainly related to updates) are placed in the mounted /dev/md0?

[Peter Suh]

3 hours ago, shibby said:

@Peter Suh strange situation... I`m on DS423+ and i tried switch to SA6400. So i recompile TCRP using M-Shell (selected the same DSM version) After compilation and reboot i didn`t have even ping to my NAS. So i re-compile TCRP once again to DS423+ and... the same... no ping.

 

Lucky i had a backup. After restore VM (sata0 drive) my Xpenology booted and i have back connection.

 

Are you running Intel 13th gen + Proxmox + SA6400 (Sata bootloader)?
If it is not bare metal but Proxmox, I don't know if there is any advantage to moving to another model.
Especially SA6400 is unstable with Sata bootloader.
Please describe your XPE environment again and I will reply again.

 

 

I don't think it needs any description. I think it can be inferred from the situation mentioned above and your profile.
It seems that the purpose is to enable transcoding on SA6400 by passing through Intel 13th gen iGPU on Proxmox. Please change the bootloader of SA6400 from SATA to USB. Then it will work stably.

You can easily check if SA6400 is going into kernel panic by checking the serial log with Proxmox's xterm.js.

 

SA6400 supports Intel 13th generation iGPU acceleration for transcoding.
I do not have an Intel 11th generation or later CPU including iGPU, so I know it is possible only theoretically and based on user experience.
Passthrough iGPU acceleration in Proxmox may be possible, but I have not personally seen many reviews.

Edited September 2 by Peter Suh

[Trabalhador Anonimo]

12 hours ago, djvas335 said:

This space issue is actually a DSM thing, so to have a 7.2gb system partition you must erase your nas, recreate the loader and reinstall the DSM and it will create the new partition layout for you

 

 

Erase the NAS is something very radical. I have a 414J (original from Synology) and it came with DSM 6.0. I manage to upgrate to 7.1.1 following Synology upgrade order (see bellow). I do not know if system partition was resize, but I do not lost any data or had to erase it.

Edited September 2 by Trabalhador Anonimo

[shibby]

3 hours ago, Peter Suh said:

Are you running Intel 13th gen + Proxmox + SA6400 (Sata bootloader)?

at the moment i`m still on 7700T under Proxmox and yes, i`m using Sata bootloader. Change was as preparation to migrate on 13gen with iGPu support.

Strange was why i could not return to previous synology model (ds423+)?

 

3 hours ago, Peter Suh said:

Please change the bootloader of SA6400 from SATA to USB. Then it will work stably.

 

ah ok, i will change bootloader and try again.

Edited September 2 by shibby

[djvas335]

@Trabalhador Anonimo You can check the system partition size, which is /dev/md0, by ssh into your NAS as root and then issuing the command

df -h

 

Below see different partition layouts from my old and new built nas

 

Old NAS

 

 

New NAS

 

Edited September 2 by djvas335

[gericb]

13 hours ago, Peter Suh said:

 

I have looked into the /dev/md0 structure while applying the automatic patch of the ramdisk in the recently applied autorecover addon mentioned above.
I have never seen a case where unnecessary contents are placed unnecessarily for actual updates, so I am not sure if it is possible to implement it.
I think you have already cleaned up /dev/md0,
Can you list for me what contents (mainly related to updates) are placed in the mounted /dev/md0?

Most appreciated that you looked into this and created this additional feature/functionality.  I just got back from spending several days in Mexico City on holiday, so I just left things the way they were, only looking into the issue of what was safely purgeable, but taking no action.  Interestingly enough, when I left, there were 10 installed apps that presented themselves as needing to be "repaired" (after I had reverted the loader back from 7.2.2 back to 7.2.1) and when I tried to do that to any/all of they, it always failed and the error indicator remained...yet when I just signed-in a few moments ago, they all seem to have automatically resolved while I was gone! Interesting to be sure!

 

Indeed, per @djvas335 my scenario was indeed having had DSM 6.x originally installed, and actually after you allayed my fears about upgrading to DSM 7.x, did exactly that with confidence.   So I assume to have the much smaller 2GB System Partition.

 

I will certainly provide you with any additional into regarding my pruning exercise.

 

As always, I am forever thankful for your intellectual drive, creativity, flexibility, technical prowess and making all of this magic happen!

Edited September 3 by gericb

[shibby]

20 hours ago, shibby said:

23 hours ago, Peter Suh said:

Please change the bootloader of SA6400 from SATA to USB. Then it will work stably.

 

ah ok, i will change bootloader and try again.

 

Well... i messed up and now i have a huge problem. Yesterday i moved to Arc Next loader and migrated DS423+ (7.2.1) to SA6400 7.2.2 (sata mode). All worked fine and i was happy to be prepare to change hardware to 13gen. Morning my NAS was dead - i had kernel panic and one drive got "critical" state - it was fine in proxmox. My biggest mistake was try back to DS423+... After migration i cannot run few services: san manager, container manager and file manager wont repair. I tried move to other models like ds923+, dva3221, even once again sa6400. Every time is the same problem with those packages.

 

But there is more: i cannot back to M-Shell loader. Every time i`ve got lernel panic. I tried lots of model and always is the same. Here for example DS423+

 

 

 

On RR and Arc i can run Xpenology but with packages issue.

 

Is there any possibility back to 7.2.1??
😕

 

 

[asaf]

44 minutes ago, shibby said:

 

Well... i messed up and now i have a huge problem. Yesterday i moved to Arc Next loader and migrated DS423+ (7.2.1) to SA6400 7.2.2 (sata mode). All worked fine and i was happy to be prepare to change hardware to 13gen. Morning my NAS was dead - i had kernel panic and one drive got "critical" state - it was fine in proxmox. My biggest mistake was try back to DS423+... After migration i cannot run few services: san manager, container manager and file manager wont repair. I tried move to other models like ds923+, dva3221, even once again sa6400. Every time is the same problem with those packages.

 

But there is more: i cannot back to M-Shell loader. Every time i`ve got lernel panic. I tried lots of model and always is the same. Here for example DS423+

 

 

 

On RR and Arc i can run Xpenology but with packages issue.

 

Is there any possibility back to 7.2.1??
😕

 

 

Yes there is.

ARC has an inbuilt option to downgrade you can choose.

AFAIK 7.2.2 has some big changes.

Please review it or at least watch the SpaceRex video on the topic before jumping on it.

[shibby]

I came to terms with the thought that I have to install Synology again. Now the questions are:

- use M-shell, RR or Arc as loader? I propably leave iGPU for now to SA6400 is not a priority. Must be 100% stable

- 7.2.1 or 7.2.2?

 

 

[asaf]

57 minutes ago, shibby said:

I came to terms with the thought that I have to install Synology again. Now the questions are:

- use M-shell, RR or Arc as loader? I propably leave iGPU for now to SA6400 is not a priority. Must be 100% stable

- 7.2.1 or 7.2.2?

 

 

7.2.1 is the stable one at the moment.

I would not use anything else than ARC loader anytime soon but that's just me.

You have to decide by yourself.

[gericb]

On 8/30/2024 at 12:21 AM, Peter Suh said:

 

I have experience mounting /dev/md0 via autorecover addon.
Please refer to the script below to find the location that needs to be organized.

 

At the stage where DSM can be installed,
You can access TTYD 7681 port instead of 5000 port through a web browser.

 

http://192.168.x.y(Your IP):7681

 

In there, please try the following.

 

cd /
mkdir /tmpR
mount /dev/md0 /tmpR
cd /tmpR

 

https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/autorecover/src/install.sh#L32C5-L32C16

Hey there @Peter Suh when you are saying "At the stage where DSM can be installed, you can access TTYD 7681 port instead of 5000 port through a web browser." are you referring to this boot-up screen?  I have tried a few times via my browser to go to this address (as seeing the image), while I see this screen, but there is never a response.  Is this accessibility persistent, or only for a short duration?

 

Since you guys are leveraging off one another, do you think it would be possible for you to add this additional functionality shown on option Z, "Force Enable Telnet & SSH"?

 

Thank You