Help needed for DSM 7.2.1 install process

[smileyworld]

I installed DSM on multiple system and didn't encouter this problem before BUT after updating my DS3622xs+ from 7.2-64570 to 7.2.1-69057-5 I had issues.

 

Update was done in DSM control panel.

 

Now i am at a point where i can't even get a fresh install working.

 

I was using @Peter Suh m-shell loader which i prefer instead of original tcrp.

 

But even original tcrp isn't possbile to boot.

 

My steps to make the installation more simple:

 

Unplug my HBAs and my 10G NIC.

Also i unplugged every HDD and SSD except one.

 

1. Download tinycore-redpill.v1.0.4.0.m-shell.img.gz from https://github.com/PeterSuh-Q3/tinycore-redpill/releases
2. Unpack it and use rufus to make image bootable from USB
3. Boot with USB on NAS (CSM not UEFI)
4. Build loader (I tried many variations but none worked and i am pretty sure it has to be a mistake on my end.)

 

 

 

 

The issue i get is either install runs to 100% and the system reboots.

After this are two options:

1. Boot from Juns loader -> results in reboot as soon as i enter http://ip:5000
2. Boot from Friend update -> results in this

 

If i use original TCRP i can't install DSM since it won't let me delete my SSD (the installer is asking me to delete more partitions than the one of the inserted SSD)

 

There is another thing i don't understand.

 

The current TCRP loader doesn't support 7.2.1-69057-5. How is it possible @Peter Suh got it working before "original" tcrp or am i missing something?

If you need more information pls tell me.

[Peter Suh]

You didn't mention yesterday's PM that the starting point is 7.2-64570.
In the case of mshell, if the DSM Major version changes, the loader needs to be rebuilt from scratch.
The current loader for 7.2-64570
should be rebuilt as the 7.2.1-69057 loader.

 

By default, mshell builds the loader as 7.2.1-69057 Update 0 version when building the loader.
The bootloader compares the version installed on the system partition of the DSM disk and proceeds with the patch.

 

First, please check if you can access the junior log while building the loader for version 7.2.1-69057.
How to check the junior log has been mentioned hundreds of times in this forum, so you should be able to find out the method just by searching.

 

Please capture how the DSM version is compared at the very last part of the log.

[smileyworld]

@Peter Suh

Quote

You didn't mention yesterday's PM that the starting point is 7.2-64570.
In the case of mshell, if the DSM Major version changes, the loader needs to be rebuilt from scratch.
The current loader for 7.2-64570
should be rebuilt as the 7.2.1-69057 loader.

True. Didn't know that.

 

Quote

By default, mshell builds the loader as 7.2.1-69057 Update 0 version when building the loader.
The bootloader compares the version installed on the system partition of the DSM disk and proceeds with the patch.

Thanks for clarification.

 

Quote

First, please check if you can access the junior log while building the loader for version 7.2.1-69057.
How to check the junior log has been mentioned hundreds of times in this forum, so you should be able to find out the method just by searching.

 

If I understand you correctly I should:

1. Format my USB and build the loader from scratch
2. Install DSM on empty SSD
3. use TTYD web console to poste content of the log file by
   1. connecting via http://youripaddress:7681 (user "root" pw "")
   2. get content of log by cat /var/log/*rc*

It is possible to connect to my NAS with ttyd for about 15 seconds: (I hope this is everything you need from the log file)

------------upgrade
Begin upgrade procedure
Failed to found any patch
No upgrade file found
End upgrade procedure
============upgrade
------------bootup-smallupdate
Failed to AssertFileKeyValueEqual
  value1: /etc.defaults/VERSION:smallfixnumber -> 0
  value2: /tmpRoot/.syno/patch/VERSION:smallfixnumber => 4
Skip bootup smallupdate, because root is not matched to junior
============bootup-smallupdate
Failed to AssertFileKeyValueEqual
  value1: /etc.defaults/VERSION:smallfixnumber -> 0
  value2: /tmpRoot/.syno/patch/VERSION:smallfixnumber => 4
Exit on error [7] root not matched with junior...
Tue Aug  6 21:49:12 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
/dev/md0 /tmpRoot ext4 rw,noatime,prjquota,rootprjquota,data=ordered 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0

 

If you need anything else, please let me know how I can help you.

[Peter Suh]

------------bootup-smallupdate
Failed to AssertFileKeyValueEqual
  value1: /etc.defaults/VERSION:smallfixnumber -> 0
  value2: /tmpRoot/.syno/patch/VERSION:smallfixnumber => 4
Skip bootup smallupdate, because root is not matched to junior

 

You brought exactly the log I expected.
As expected, smallfixnumber showed a difference,
and usually, when connecting to port 5000 in this state, it requests recovery to raise the smallfixnumber version of the bootloader to 4.
You can recover manually, but the latest function of mshell automatically recovers. For this, one reboot is automatically performed.

[smileyworld]

How can there be a difference in smallfixnumber when i choose the DSM version before building the loader?

 

I am not sure what you mean or rather how i can prevent my endless boot loop.

 

When i choose Ramdisk in grubs bootloader i can't boot.

When i choose USB verbose bootloader my NAS restarts endlessly. (Same if i choose SATA)

 

What do i have to do? (Sorry for asking like a noob 😅)

[smileyworld]

@Peter Suh

I know now, that I can set the smallfixnumber in the user_config.json.

 

I tried building the loader with

smallfixnumber "4" and

friendautoupdate "false"

but l still get the same smallfixnumber mismatch.

 

Also as far as I can remember the postupdate in the grub loader worked every time but this time it somehow fails, no matter which DSM version I choose.

[Peter Suh]

The smallfixnumber of user_config.json is not something that the user can modify directly.
It is a part that the loader records for reference.

 

The mechanism of TCRP always uses Update 0 (smallfixnumber 0) as the condition for creating a RAM disk by disassembling DSM when selecting a DSM version and building a loader.

The smallfixnumber that exists in the system partition of the disk is the final version of the DSM Update that the user actually used until the end.

The smallfixnumber of the loader and the system partition must always match for the bootloader to proceed with the kernel boot.

If the smallfixnumber of the system partition is higher than that of the bootloader, a RAM disk patch is required, but in the past, TCRP performed this RAM disk patch through PostUpdate.

 

My MSHELL has developed it a bit further and performs automatic PostUpdate instead of manual PostUpdate.

I think it may be that the DSM version was not used from the beginning and that is preventing the automatic PostUpdate of mshell.

In this case, it seems that you have no choice but to handle the manual PostUpdate as before.

Edited August 10, 2024 by Peter Suh

[smileyworld]

@Peter Suh unfortunately I didn't get the postupdate working with m-shell

 

I tried building the bootloader again with pocopico's trcp and got it working.

 

Nevertheless thanks for your support.