Script improvement thread for TG's boot-wait.sh module

[Peter Suh]

There is a script called redpill-boot-wait that TG, the founder of redpill in the TTG group, developed from the beginning of redpill.

https://github.com/RedPill-TTG/redpill-boot-wait

Why does the 55% file corruption message occur?

/dev/synoboot, /dev/synoboot1, /dev/synoboot2, /dev/synoboot3, which are essential for the DSM installation process

These four nodes should be automatically recognized and uploaded within seconds.

There are cases where it doesn't come up for some reason.

 

So I wait up to 30 seconds for these 4 nodes to appear.

If node recognition fails, eventually at the 55% point in the middle of DSM installation, with no nodes present, DSM will send a message that the files are corrupted.

Actually, this DSM PAT file is not corrupted.

One of the most common known reasons is that the VID / PID of the USB memory is written incorrectly.

In my M SHELL for TCRP, this VID / PID part is automatically processed, so the probability of this happening is 0%.

 

However, in cases where VID / PID is not required, such as MSATA, SATA, and VM, this phenomenon may occur for unknown reasons.

 

So far, when this has happened, you can switch the loader between TCRP FRIEND / TCRP JOT / ARPL to build the loader, or

I have been guiding you to install a USB memory with a version of 3.0 or higher into a 3.0 or higher port.

If this is not possible, it is impossible to install Red Fill on the PC.

 

However, by adding a little trick, I skipped this part and completed the implementation a little while ago to enable DSM installation.

This is a modified version only in M SHELL for TCRP.

I supplemented TG's boot-wait.sh script,

 

Anyway, if these 4 nodes don't come up within seconds, they will never come out even if you wait 30 seconds.

So I reduced the 30 second wait to 10 seconds,

If no response is received within 10 seconds, the above 4 nodes are forcibly created with the script below.

 

mknod /dev/synoboot b 8 1
mknod /dev/synoboot1 b 8 1
mknod /dev/synoboot2 b 8 1
mknod /dev/synoboot3 b 8 1

 

https://github.com/RedPill-TTG/redpill-boot-wait/blob/master/src/boot-wait.sh

 

https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/boot-wait/src/boot-wait.sh

 

As a result of installing DSM in this state, it was installed normally because the above 4 nodes required by Synology exist.

With this improvement, we have implemented a new DSM installation without a 55% file corruption message.

To use this function, you need to rebuild the M SHELL loader.

[Peter Suh]

For those who can read the junior log, we will inform you of log changes.

 

[force make synoboot node]

SynologyNAS> mknod /dev/synoboot b 8 1
SynologyNAS> mknod /dev/synoboot1 b 8 1
SynologyNAS> mknod /dev/synoboot2 b 8 1
SynologyNAS> mknod /dev/synoboot3 b 8 1
SynologyNAS> ll /dev/syno*
crw-r--r-- 1 root root 201, 0 Mar 16 11:55 /dev/synobios
brw------ 1 root root 8, 1 Mar 16 12:12 /dev/synoboot
brw------ 1 root root 8, 1 Mar 16 12:12 /dev/synoboot1
brw------ 1 root root 8, 1 Mar 16 12:12 /dev/synoboot2
brw------ 1 root root 8, 1 Mar 16 12:12 /dev/synoboot3


[junior log]

Running "boot-wait.sh" for thethorgroup.boot-wait->on_boot
Still waiting for boot device (waited 1 of 10 seconds)
Still waiting for boot device (waited 2 of 10 seconds)
Still waiting for boot device (waited 3 of 10 seconds)
Still waiting for boot device (waited 4 of 10 seconds)
Still waiting for boot device (waited 5 of 10 seconds)
Still waiting for boot device (waited 6 of 10 seconds)
Still waiting for boot device (waited 7 of 10 seconds)
Still waiting for boot device (waited 8 of 10 seconds)
Still waiting for boot device (waited 9 of 10 seconds)
Still waiting for boot device (waited 10 of 10 seconds)
ERROR: Timeout waiting for /dev/synoboot device to appear.
Most likely your vid/pid configuration is not correct, or you don't have drivers needed for your USB/SATA controller

========== BEGIN DUMP OF ALL PARTITIONS DETECTED ===========
/dev/sda1 2048 147455 145408 83
/dev/sda2 147456 301055 153600 83
/dev/sda3 301056 2097151 1796096 83


/dev/sdg1 8192 16785407 16777216 fd
/dev/sdg2 16785408 20979711 4194304 fd
/dev/sdg3 21241856 3906824351 3885582496 fd


========== END OF DUMP OF ALL PARTITIONS DETECTED ==========
Force the creation of synoboot , synoboot1 , synoboot2 and synoboot3 nodes...
Confirmed a valid-looking /dev/synoboot device

 

[Peter Suh]

The solution was courtesy of chatGPT.

 

Question: How do I make the /dev/synoboot device visible?

 

The /dev/synoboot device represents the boot partition on Synology NAS. If this device is not present, your Synology NAS may not boot.

Normally, the /dev/synoboot device on Synology NAS is created automatically when the system boots up. However, sometimes you may encounter a problem where this device is not created.

 

In this case, you can try one of the methods below.

 

You can try to rebuild the boot partition by pressing C key during boot to access boot menu, select "repair" option and click "rebuild".

Shut down your Synology NAS and unplug it, then plug it back in and try turning on the NAS.

You can manually create the /dev/synoboot device using the mknod command. Try using the following command:

 

sudo mknod /dev/synoboot b 8 1

 

The above command creates a block device (b), and creates a /dev/synoboot device with a major number (8) and a minor number (1). This method may vary depending on the Linux kernel version and device file system used by your Synology NAS. Therefore, this method may fail. Try other methods first before trying this one.