TinyCore RedPill Loader Build Support Tool ( M-Shell )

[Peter Suh]

2 hours ago, Tibag said:

Thanks, I closed the PR. 

 

Yeah I am on ESXI using SATA controller... I can't really move to Proxmox as I have various other VMs running on my ESXI. 

 

Do you know any workaround?

 

 

I tried building the DS3622xs+ loader in SATA mode on my ESXI 7.0 Update 3 system.

I expected a 10 second timeout from my boot-wait and automount addons, but that wasn't the case.

The loader's three FAT partitions were successfully mounted on time.

 

The log below is part of Junior's linuxrc.syno.log.

 

Ran "boot-wait.sh" for thethorgroup.boot-wait->on_boot->modules - exit=0
:: Executing "on_boot" custom scripts ... [  OK  ]
...
:: Executing "on_patches" "patches" custom scripts ...
Running "install.sh" for automount->on_patches->patches
Found synoboot / synoboot1 / synoboot2
Ran "install.sh" for automount->on_patches->patches - exit=0
Running "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches
Ran "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches - exit=0
:: Executing "on_patches" custom scripts ... [  OK  ]

 

The cause seems to lie elsewhere.

Is it possible to access port 7681 through a web browser?

This method is called a TTYD connection.

Log in as root without a password.

 

If connection to Junior is successful, can you send me the command log as below?

cat /var/log/*rc*

Edited January 11 by Peter Suh

[Orphée]

May I ask how the IMG was built for ESXi ?

 

While I was still using ESXI, I personnally always took default IMG and used V2V starwind converter to convert it to FLAT ESXi VMDK file.

Never had any issues with loaders on ESXi with this method.

[Tibag]

21 minutes ago, Peter Suh said:

 

 

I tried building the DS3622xs+ loader in SATA mode on my ESXI 7.0 Update 3 system.

I expected a 10 second timeout from my boot-wait and automount addons, but that wasn't the case.

The loader's three FAT partitions were successfully mounted on time.

 

The log below is part of Junior's linuxrc.syno.log.

 

Ran "boot-wait.sh" for thethorgroup.boot-wait->on_boot->modules - exit=0
:: Executing "on_boot" custom scripts ... [  OK  ]
...
:: Executing "on_patches" "patches" custom scripts ...
Running "install.sh" for automount->on_patches->patches
Found synoboot / synoboot1 / synoboot2
Ran "install.sh" for automount->on_patches->patches - exit=0
Running "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches
Ran "boot-wait.sh" for thethorgroup.boot-wait->on_patches->patches - exit=0
:: Executing "on_patches" custom scripts ... [  OK  ]

 

The cause seems to lie elsewhere.

Is it possible to access port 7681 through a web browser?

This method is called a TTYD connection.

Log in as root without a password.

 

If connection to Junior is successful, can you send me the command log as below?

cat /var/log/*rc*

Yes I could connect to TTYD yesterday when it was failing - I am only at home later tonight so I will post the cat output later. 

 

Am I right in thinking that Junior should only kick in for a new installation? Like if my disks have a previous DSM version installed it shouldn't use Junior? 

 

14 minutes ago, Orphée said:

May I ask how the IMG was built for ESXi ?

 

While I was still using ESXI, I personnally always took default IMG and used V2V starwind converter to convert it to FLAT ESXi VMDK file.

Never had any issues with loaders on ESXi with this method.

I used the vmdk from Peter's repo and cloned it with vmkfstools on ESXI. Could that be the problem? It's a method I used before, I think! 

[Peter Suh]

1 hour ago, Tibag said:

Am I right in thinking that Junior should only kick in for a new installation? Like if my disks have a previous DSM version installed it shouldn't use Junior? 

 

Junior is used for both new installations and migrations.
Junior determines whether a new installation or migration is possible by comparing the DSM version installed on the disk system partition with the DSM version to be installed.

[Peter Suh]

3 hours ago, Tibag said:

May I ask how the IMG was built for ESXi ?

 

While I was still using ESXI, I personnally always took default IMG and used V2V starwind converter to convert it to FLAT ESXi VMDK file.

Never had any issues with loaders on ESXi with this method.

 

3 hours ago, Tibag said:

I used the vmdk from Peter's repo and cloned it with vmkfstools on ESXI. Could that be the problem? It's a method I used before, I think! 

 

 

My thoughts are a bit different.

proxmox uses img directly as a loader, but creates it as a Sata disk as if using SATA dom. Here, TCRP's ATA mode operates.
Synology's original bootloader is known to be SATA DOM, not USB.

I am not directly involved in the TTG group, so I do not know the exact mechanism of redpill.ko.

However, based on the results of analysis and experience so far, it seems that the part that activates this SATA DOM in redpill is still unstable.
Rather, USB mode shows more stability as a result.

I don't know if USB mode is also internally connected to SATA DOM emulation again.
Currently, TTG members are not active.
Is there anyone who can explain this part clearly?

Edited January 11 by Peter Suh

[Tibag]

9 hours ago, Peter Suh said:

If connection to Junior is successful, can you send me the command log as below?

cat /var/log/*rc*

There we go, find attached. Does that help @Peter Suh?

junior.log

[Peter Suh]

On 1/11/2024 at 7:27 AM, Tibag said:

So I forked the repo and managed to build - the above PR will fix it. 

 

So I am now on my next challenge. After the build it starts and suggests to migrate my disks. I upload my pat and during the process it fails with a corruption message. I check my logs and see:

 

There is a few posts about that but none makes sense. Any idea?

 

Assemble args: -u 0074c5b5:808d4c6e:3017a5a8:c86610be /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/md0 has been started with 3 drives (out of 12).
Partition Version=8
Checking ext4 rootfs on /dev/md0
return value: 0
sdc, part of md0, has obsolete partition layout 8.
Detected data partition on sda. Must not be fresh installation.
ForceNewestLayout: Skipped
Mounting /dev/md0 /tmpRoot

 

I saw the log you provided.
Are there only 4 discs in total?

It is also strange that disk mdadm started on only 3 of the 12 disks.
The sdc that is part of md0 has the deprecated partition layout 8.
Data partition detected by SDA. Do not do a fresh install.

 

It looks like the system partitions between disks are mixed up.
If DS3622xs+ does not recognize all disks
In order to recognize all disks, it would be a good idea to first complete the DSM version upgrade to the Device-Tree-based DS920+.
After the system partition's mdadm is stabilized, it would not be a bad idea to change the model again and migrate.

 

[Tibag]

6 minutes ago, Peter Suh said:

 

Assemble args: -u 0074c5b5:808d4c6e:3017a5a8:c86610be /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/md0 has been started with 3 drives (out of 12).
Partition Version=8
Checking ext4 rootfs on /dev/md0
return value: 0
sdc, part of md0, has obsolete partition layout 8.
Detected data partition on sda. Must not be fresh installation.
ForceNewestLayout: Skipped
Mounting /dev/md0 /tmpRoot

 

I saw the log you provided.
Are there only 4 discs in total?

It is also strange that disk mdadm started on only 3 of the 12 disks.
The sdc that is part of md0 has the deprecated partition layout 8.
Data partition detected by SDA. Do not do a fresh install.

 

It looks like the system partitions between disks are mixed up.
If DS3622xs+ does not recognize all disks
In order to recognize all disks, it would be a good idea to first complete the DSM version upgrade to the Device-Tree-based DS920+.
After the system partition's mdadm is stabilized, it would not be a bad idea to change the model again and migrate.

 

 

Yes 4 disks in total: 

 

Essentially I had disk as 1 volume and the other 3 as another. 

 

Could it be the face that I have no disks on SATA controller 1:1 as it does 1:0 -> 1:2 -> 1:3 -> 1:4?

 

Also, do you think trying a different loader like arpl-rr has chances of working better? 

[Peter Suh]

11 minutes ago, Tibag said:

 

Yes 4 disks in total: 

 

Essentially I had disk as 1 volume and the other 3 as another. 

 

Could it be the face that I have no disks on SATA controller 1:1 as it does 1:0 -> 1:2 -> 1:3 -> 1:4?

 

Also, do you think trying a different loader like arpl-rr has chances of working better? 

 

Without proper mapping, the disk may disappear and become invisible, especially on Non Device-Tree based models such as DS3622xs+.
However, since you can see all disks, I think your settings are fine.

 

I know that rr is handled using a slightly different disk mapping method, but I don't know the details.
I'm not sure exactly how rr can help since all disks are already well recognized.

[Tibag]

@Peter Suh I tried to use DS920+, find attached logs, and this time I am getting another error bout some missing disk space:

 

I start to wonder if my data is recoverable at all! 

 

 

junior_920.log

[Peter Suh]

35 minutes ago, Tibag said:

@Peter Suh I tried to use DS920+, find attached logs, and this time I am getting another error bout some missing disk space:

 

I start to wonder if my data is recoverable at all! 

 

 

junior_920.log 16.2 kB · 0 downloads

 

There is no need to despair too much.
Your data disk is still safe.
Are there separate backups?

This is a message I also experienced some time ago.
This was a case where there were too many files in the /root path of the already installed DSM system partition.
When updating DSM, use this /root path.

You need to access the /root path of the system partition and organize its contents.
Of your two volumes, which disk is /root located on?
I think you need to try installing the two groups of volumes separately.
The remaining groups will be automatically migrated even if they are equipped later.

Would you like to try this method?

[Tibag]

8 minutes ago, Peter Suh said:

 

There is no need to despair too much.
Your data disk is still safe.
Are there separate backups?

This is a message I also experienced some time ago.
This was a case where there were too many files in the /root path of the already installed DSM system partition.
When updating DSM, use this /root path.

You need to access the /root path of the system partition and organize its contents.
Of your two volumes, which disk is /root located on?
I think you need to try installing the two groups of volumes separately.
The remaining groups will be automatically migrated even if they are equipped later.

Would you like to try this method?

 

Well, thanks for still helping! 

 

If my memory doesn't fail me it's:

* volume1, made of the 2.73TB disk. It was the first installed so I am thinking this is where the /root is 

* volume2 is a RAID of the other 3 disks 

 

How can I access the data on the volume to clean them? 

 

Quote

I think you need to try installing the two groups of volumes separately.
The remaining groups will be automatically migrated even if they are equipped later.

Would you like to try this method?

 

Yes something I can try, I guess I run the loader with only my 2.73 disk (volume1) in? And hopefully the upgrade passes and I can add back the other three? 

[Peter Suh]

6 minutes ago, Tibag said:

 

Well, thanks for still helping! 

 

If my memory doesn't fail me it's:

* volume1, made of the 2.73TB disk. It was the first installed so I am thinking this is where the /root is 

* volume2 is a RAID of the other 3 disks 

 

How can I access the data on the volume to clean them? 

 

 

Yes something I can try, I guess I run the loader with only my 2.73 disk (volume1) in? And hopefully the upgrade passes and I can add back the other three? 

 

Currently, only Junior is available, so there doesn't seem to be a way to clean up /root directly.

 

I think you should follow the latter method by dividing the group into groups and trying to upgrade with only one volume.

 

However, migration should be possible with only sata1. Never attempt NEW Install. Installed packages will be corrupted.

Edited January 12 by Peter Suh

[Tibag]

14 minutes ago, Peter Suh said:

 

Currently, only Junior is available, so there doesn't seem to be a way to clean up /root directly.

 

I think you should follow the latter method by dividing the group into groups and trying to upgrade with only one volume.

 

So I tried to load volume by volume... 

1. tried with my volume1 disk only: stopped at the 55% mark with the "file is probably corrupted"
2. tried with my volume2 3 disks: stopped at 0% with the system space error 

I am not sure what other options I now have! 🤔

[Tibag]

I also tried ARPL just in case. Same error about disk space with all drives in, then with a single drive I get a new one (yay!):

 

Also tried ARC, same result. 

 

 

[Tibag]

Well, I think my DSM is now properly destroyed. I attempted to mount my disk on Magic Parted to try to explain the disk space problem, to no avail. Then, after starting again TCRP it's now not finding my disk anymore. So... the disk is probably unusable anymore. I can't tell anymore what's caused the whole thing but if I could drop myself a message 1 week ago I would convince myself to never upgrade anymore! I strongly suspect that when there is an error during the upgrade DSM keeps uploaded file on the system partition. So actually if you try multiple times you get closer to a fully bricked system. 

 

Current status for reference:

 

Quote

Exit on error [1] DISK NOT INSTALLED...
Fri Jan 12 23:55:52 UTC 2024
:: Loading kernel modules from extensions ...
:: Loading kernel modules from extensions ... [  OK  ]
:: Executing "on_jrExit" "jrExit" custom scripts ...
:: Executing "on_jrExit" custom scripts ... [  OK  ]
Extensions processed
none /sys/kernel/debug debugfs rw,relatime 0 0

 

I suppose the next option is to start an install from scratch and try to add my disks back if DSM can restore them? 

[dj_nsk]

1 час назад, Tibag сказал:

but if I could drop myself a message 1 week ago I would convince myself to never upgrade anymore! I strongly suspect that when there is an error during the upgrade DSM keeps uploaded file on the system partition. So actually if you try multiple times you get closer to a fully bricked system.

1 час назад, Tibag сказал:

I suppose the next option is to start an install from scratch and try to add my disks back if DSM can restore them?

No, you're wrong. Updating versions of DSM 7 in modern bootloaders usually goes without problems in both the baremetal and ESXi versions. Most likely, you have done some wrong actions yourself. Under ESXi, you still have the opportunity to test the upgrade process on a test DSM. But it is really required to use the correct iso image of the bootloader.

 

[Peter Suh]

6 hours ago, Tibag said:

Well, I think my DSM is now properly destroyed. I attempted to mount my disk on Magic Parted to try to explain the disk space problem, to no avail. Then, after starting again TCRP it's now not finding my disk anymore. So... the disk is probably unusable anymore. I can't tell anymore what's caused the whole thing but if I could drop myself a message 1 week ago I would convince myself to never upgrade anymore! I strongly suspect that when there is an error during the upgrade DSM keeps uploaded file on the system partition. So actually if you try multiple times you get closer to a fully bricked system. 

 

Current status for reference:

 

 

I suppose the next option is to start an install from scratch and try to add my disks back if DSM can restore them? 

 

Although no work was done on the first volume disk, it is a little strange that the disk is not visible.
Is the number of disks displayed as ll /sys/block in tinycore linux always 4?

If you don't see 4, you may need to recheck the cable connection.

 

The last method I would like to suggest is
DS3622xs+ is going back to DSM 7.2.0-64570.
Do you keep the original loader separately?
If not, you can rebuild it.

 

I think it would be a good idea to go back to the original version, 64570, correct the problems, and try upgrading again.

If you rebuild the loader, recovery may be requested due to a smallfixversion mismatch, but this process is normal.
It should only be requested once.

[Tibag]

11 hours ago, dj_nsk said:

No, you're wrong. Updating versions of DSM 7 in modern bootloaders usually goes without problems in both the baremetal and ESXi versions. Most likely, you have done some wrong actions yourself. Under ESXi, you still have the opportunity to test the upgrade process on a test DSM. But it is really required to use the correct iso image of the bootloader.

 

 

Oh that I am 100% sure, I did something wrong at some point. I am always lost in the few options at our hands when it comes to upgrade. Last time I did jump to 7.1 I also spent hours to get it back to normal. 

 

7 hours ago, Peter Suh said:

 

Although no work was done on the first volume disk, it is a little strange that the disk is not visible.
Is the number of disks displayed as ll /sys/block in tinycore linux always 4?

If you don't see 4, you may need to recheck the cable connection.

 

The last method I would like to suggest is
DS3622xs+ is going back to DSM 7.2.0-64570.
Do you keep the original loader separately?
If not, you can rebuild it.

 

I think it would be a good idea to go back to the original version, 64570, correct the problems, and try upgrading again.

If you rebuild the loader, recovery may be requested due to a smallfixversion mismatch, but this process is normal.
It should only be requested once.

 

Yes I still my old TCRP and I just tried it. I built DSM 7.2.0-64570 with all the disk in and it detected it as recoverable. The recovery process just started, let's see. 🤞

 

If it does recover, what do you suggest to move to 69057? 

[Peter Suh]

5 minutes ago, Tibag said:

 

Oh that I am 100% sure, I did something wrong at some point. I am always lost in the few options at our hands when it comes to upgrade. Last time I did jump to 7.1 I also spent hours to get it back to normal. 

 

 

Yes I still my old TCRP and I just tried it. I built DSM 7.2.0-64570 with all the disk in and it detected it as recoverable. The recovery process just started, let's see. 🤞

 

If it does recover, what do you suggest to move to 69057? 

 

 

Please check the parts that were problematic yesterday.
Is the /root directory really full?

And above all, back up your DSM settings separately.
If full backup is not possible, at least perform a selective backup of only packages using hyperbackup.
I make these backups every day on Google Drive.

It can be used for recovery if the DSM of the system partition is initialized due to an unexpected accident.
I think you should focus more on preparing in advance rather than upgrading.

Edited January 13 by Peter Suh

[Tibag]

1 minute ago, Peter Suh said:

 

 

Please check the parts that were problematic yesterday.
Is the /root directory really full?

And above all, back up your DSM settings separately.
If full backup is not possible, at least perform a selective backup of only packages using hyperbackup.
I make these backups every day on Google Drive.

It can be used for recovery if the DSM of the system partition is initialized due to an unexpected accident.
I think you should focus more on preparing in advance rather than upgrading.

 

Thanks, will do. Regarding backups I have cloud backup of the data, settings too, so no risk here (apart from more time wasted). 

 

Actually the recovery doesn't work, oddly. I get that screen:

 

Then after the restart (I can see it reboots) then nothing happens. 

 

Any idea why? 

[Peter Suh]

3 minutes ago, Tibag said:

 

Thanks, will do. Regarding backups I have cloud backup of the data, settings too, so no risk here (apart from more time wasted). 

 

Actually the recovery doesn't work, oddly. I get that screen:

 

Then after the restart (I can see it reboots) then nothing happens. 

 

Any idea why? 

 

 

In a recovery action, essentially nothing happens.
Does the recovery happen over and over again?

If so, please upload the junior log like you did yesterday.

[Tibag]

2 hours ago, Peter Suh said:

 

 

In a recovery action, essentially nothing happens.
Does the recovery happen over and over again?

If so, please upload the junior log like you did yesterday.

 

Yes it does always bring the recovery when it comes back. 

 

Find attached the logs, hopefully it shows something useful! 

 

Oddly, on the find synology I get: 

junior_1301.log

[Peter Suh]

12 minutes ago, Tibag said:

 
Yes it does always bring the recovery when it comes back. 
 
Find attached the logs, hopefully it shows something useful! 
 
Oddly, on the find synology I get: 

junior_1301.log

At the very end of this log, you can see that a smallfixnumber mismatch has been detected. This is a completely normal detection. Now, normal ramdisk patching should proceed on the Friend kernel. It appears in yellow letters. Can you take a screenshot of this screen and show me?


Sent from my iPhone using Tapatalk

Edited January 13 by Peter Suh

[Tibag]

5 minutes ago, Peter Suh said:

At the very end of this log, you can see that a smallfixnumber mismatch has been detected. This is a completely normal detection. Now, normal ramdisk patching should proceed on the Friend kernel. It appears in yellow letters. Can you take a screenshot of this screen and show me?


Sent from my iPhone using Tapatalk

Well, because I am back to my previous loader it's the old one (Version : 0.10.0.0) not using your own build. So Friend doesn't load automatically, I think? 

 

Do I need to do a postupdate maybe? Or use the Friend entry from my Grub? 

 

Thanks for keeping up the help!