how to undo a unfinished update 6.2.3 to 6.2.4 (no boot after 1st step of update)

[IG-88]

this is kind of work in progress and not perfect for all scenarios but as synology now offers 6.2.4 in the DSM GUI as update (instead of 6.2.3 U3) more people might have that problem, some people tested that already here (https://xpenology.com/forum/topic/41473-dsm-624-25554-install-experience/) but i wanted to continue in a easier to find area and try to sort out problems and fine tune here in the tutorial and guides section

 

there is the more complicated way of going back to 6.2.3, keeping all settings and data, that needs some experience in general and some linux skills and a easier way where you keep your data but loose the settings (user, shares, ...), the skills needed for this is more or less the same what you need to install xpenology, a link to the less complex way is added down below as a PS

 

 

download a rescue/live linux like system rescue cd (i used a "older" version 6.0.3, mdadm and lvm worked ootb, any newer should be fine too), transfer it to a usb (not your dsm boot usb) to boot from it

assemble your raid1 system partition like here (1st partitions of all disks as /dev/md0)

skip anything about swap or volume1 data partition, we only need access to the dsm system partition
https://xpenology.com/forum/topic/7004-tutorial-how-to-access-dsms-data-system-partitions/

 

mount the assembled raid1 to /mnt with this

mount /dev/md0 /mnt

 

then remove some files with this

rm -rf /mnt/SynoUpgradePackages
rm -f /mnt/SynoUpgrade.tar
rm -f /mnt/SynoUpgradeindex.txz
rm -f /mnt/SynoUpgradeSynohdpackImg.txz
rm -f /mnt/checksum.syno
rm -f /mnt/.syno/patch/*

 

also check the files containing the DSM Version

cat /etc/VERSION
cat /etc.defaults/VERSION

if the one in /etc shows 6.2.3 and the one in /etc.defaults shows 6.2.4 delete or rename one with 6.2.4 and copy the one with 6.2.3 to that place (a version file with slightly more content is also in the *.pat file that can be opened with 7zip, that can be used for comparison too)

report say's its working too if you just delete both VERSION files

 

shutdown the rescue linux

shutdown -h now

 

now you will have to restore the kernel files on your boot usb to 6.2.3 (the update also replace files on the loaders 2nd partition)

win10 can have some difficulties with mounting the 2nd partitions of the loader, so look here
https://xpenology.com/forum/topic/29872-tutorial-mount-boot-stick-partitions-in-windows-edit-grubcfg-add-extralzma/

(it can also be done with linux but i have not tried what other tools will extract the kernel files but if you are familiar with linux you will find out

https://xpenology.com/forum/topic/25833-tutorial-use-linux-to-create-bootable-xpenology-usb/)

 

on 2nd partition delete all files except extra.lzma and extra2.lzma (if its 3615/3617 then its just extra.lzma)
use 7zip to open "DSM_xxxxx_25426.pat" (dsm 6.2.3 install file, depends on you dsm type 3615/3617/918+)

 extract "rd.gz" and "zImage" and copy it to the 2nd partition of your xpenology usb

 

 

the assumption here is you already had 6.2.3 before the 6.2.4 update try, if not you would use the kernel files from the *.pat of the 6.2.x you had installed

as a example what could go wrong: if you had 6.2.2 and did 6.2.4 your extra/extra2.lzma on the loader where usually replaced with special ones made for 6.2.2, if you add 6.2.3 kernel files to the 6.2.2 extra/extra2 (drivers) then most of the drivers will not work as of the incompatibility with 6.2.1/6.2.2 with 6.2.0/6.2.3

if you are unsure about the extra/extra2 or you dsm version then use the original extra/extra2 from jun's loader (img file can be opened with 7zip, loaders kernel files and drivers in its extra/extra2 are 6.2.0 level) or use a extended version of the extra/extra2 made for 6.2.3 and use the kernel files of 6.2.3 if you had a older 6.2.x that would do a update to 6.2.3

 

 

put back your usb to the xpenology system, boot up, find it in network (i used synology assistant) and "migrate" to version 6.2.3 (keeps data and settings) - dont try internet that will do 6.2.4 again, use manual install and give it the 6.2.3 *.pat file (you already have as you needed it to restore the kernel files on the loader)
it will boot two times, one for 6.2.3, 2nd for 6.2.3_U3 (it will be downloaded automatically if internet connection is present)

 

everything should be back to normal except patches like nvme ssd patch (or other stuff you patched after installing 6.2.3 that is not dsm update resistant)

 

oh and one more thing - check your update settings, it should look like this

 

please comment on how to make it easier to follow, its just a short version i tried once

 

PS:

if that sounds all to complicated then its still possible to use the other downgrade method (but you will loose all settings and end with a factory default DSM - but you data volume(s) would still be unchanged)

https://xpenology.com/forum/topic/12778-tutorial-how-to-downgrade-from-62-to-61-recovering-a-bricked-system/

 

Edited April 9, 2021 by IG-88

[use-nas]

To return to 6.2.3 you need: Replace zImage (kernel) from version 6.2.3 on the flash (it is located on the 2nd section, you can take it from the installation package 6.2.3). The crap boot into the network will be visible, but not everything works ... Further, according to the instructions, change the version in (/ etc /etc.defaults), restore the crap All packages and data will be in place ... checked ASRock J3455-ITX

 

Edited April 9, 2021 by use-nas

[IG-88]

15 hours ago, use-nas said:

To return to 6.2.3 you need: Replace zImage (kernel) from version 6.2.3 on the flash (it is located on the 2nd section, you can take it from the installation package 6.2.3). The crap boot into the network will be visible, but not everything works ... Further, according to the instructions, change the version in (/ etc /etc.defaults), restore the crap All packages and data will be in place ... checked ASRock J3455-ITX

 

if thats a suggestion of improving the way from above then i don't get it, as it seem to be mangled in translation (i guess)

 

[TiagoGB]

Ty very much!

Just to mount system partition from livecd (pepermintos) i needed to use 'mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1'

The -U options didnt worked for me, i got "mdadm: No super block found on /dev/sda1 (Expected magic..."

 

Anyway.. Fixed now! TY AGAIN

[use-nas]

After updating to 6.2.4, you can replace zImage with flash with version from 6.2.3, then the system will boot - that's the idea.

[peppi01]

@HI  IG-88

 

perfect instruction ! How to downgrade from 6.2.4 to 6.2.3

 

I have done like the descripted procedure and i have recovered all my files und datas !

Many Many Thanx - 

 

- Outcome of the update: SUCCESSFULL SuSUCCESSFULL !! after 1 day 

- DSM version prior update: DSM 6.2.3_25432

- Loader version and model: JUN'S LOADER v1.03b - DS3615xs

- Using custom extra.lzma: NO

- Installation type: QNAP-TS-269_PRO - NIC: Intel Atom(TM) CPU D2701 @ 2,13GHz (2 Kerne, 4 Threads)

- Additional comments: after this description !

 

this is the solution !!!

also check the files containing the DSM Version

cat /etc/VERSION cat /etc.defaults/VERSION

if the one in /etc shows 6.2.3 and the one in /etc.defaults shows 6.2.4 delete or rename one with 6.2.4 and copy the one with 6.2.3 to that place (a version file with slightly more content is also in the *.pat file that can be opened with 7zip, that can be used for comparison too)

report say's its working too if you just delete both VERSION files

 

Best regards

 

[IG-88]

10 hours ago, use-nas said:

After updating to 6.2.4, you can replace zImage with flash with version from 6.2.3, then the system will boot - that's the idea.

 

be careful with this one, it will finish the update to 6.2.4 and results in a not completely working system

tested this one about 2 weeks ago

error message on login in web gui, no packages (not even file station), no network settings, ...

also it will make some drivers not working as you combine a binary older kernel with newer binary drivers from different kernel source

the resulting system is iffy at best and without sorting out the obvious problems and extensive testing (it can break btrfs if you are unlucky?) i would not dare to suggest it

at least ssh was still working so access to the system is possible (IF the nic driver is still working)

 

@use-nas any solutions you found for the resulting iffy 6.2.4 install that will be the result of your suggestion?

 

in theory it might be easier to downgrade a system in that state back to 6.2.3 as you don't need a recovery linux (when ssh was active before the update) but i had no time to test this thoroughly with diffrent hardware and nic's and the mix of different drivers and kernels might also result in a not accessible systems for some people when nic drivers fail (not sure about storage drivers, might get more messy?)

it seemed much safer to get back to the old system before applying the 6.2.4 update to the whole system and try to boot a mix of drivers and kernel (the steps above remove the update files before the update is executed)

keep in mind there are essential 6.2.4 drivers in rd.gz that are combined with a 6.2.3 kernel that way

Edited April 10, 2021 by IG-88

[use-nas]

I was able to downgrade without issue, all packages are in place.

[IG-88]

1 hour ago, use-nas said:

I was able to downgrade without issue, all packages are in place.

 

any activity i the russian section of the forum in this regard? more people used this way successful and more interesting people having problems with it?

i could integrate it here as possible way (maybe with a warning), but would prefer to have seen more feedback if people already tried it

[Mjombly]

The VERSION files weren't there when I followed these steps. It looked like it had worked, I got to the migration screen, but now it's unreachable again. What did I miss?

 

I followed all the steps except the version file part.

 

Assuming it's migrated me back to 6.2.4 again?

 

EDIT 1: Found them in the /mnt - both files show 6.2.3 so I think I'm good to go

EDIT 2: Just spotted the step about Manual Install and using the .pat file I downloaded - it looks like it's working now - Thank you so much!!

Edited April 10, 2021 by Mjombly
Spotted my mistake!

[Pepper1]

worked for me. Thanks  IG-88

[grajek_1]

worked for me - so my xpentology works with DSM 6.2.3-25426 Update 3

but the problem is that HDD do not hibernate.

in messages I can see new lines like 

kernel: [11620.550076] Invalid disk Number [9] 

...

kernel: [11620.594255] Invalid disk Number [16] 

which I think stops hibernating

 

I skipped one step: "migrate" to version 6.2.3 - how to do it? when I try to manual install firmware from DSM I get error (I tried few pats files):

 

Failed to accomplish the update! (errno = 21)
 

[IG-88]

10 hours ago, grajek_1 said:

worked for me - so my xpentology works with DSM 6.2.3-25426 Update 3

...

I skipped one step: "migrate" to version 6.2.3 - how to do it? when I try to manual install firmware from DSM I get error (I tried few pats files):

Failed to accomplish the update! (errno = 21)

 

you are on 6.2.3 u3 (working) and want to update to ... 6.2.3 and it does not work?

there seems to be something missing

 

10 hours ago, grajek_1 said:

but the problem is that HDD do not hibernate.

in messages I can see new lines like 

kernel: [11620.550076] Invalid disk Number [9] 

...

kernel: [11620.594255] Invalid disk Number [16] 

which I think stops hibernating

 

that thread is specific for the downgrade, for other problems please open your own thread in a appropriate section

(and imho its no good having just one line from the log, it needs context and without dmesg it will be hard to see what disk got what number - and no information about the systems hardware or what type of dsm or loader was used ... i'm sure you know exactly about these things but keep in mind we don't and you need to give information when you expect to get help or advise)

[grajek_1]

sure, I will start new thread. thanks

[letrom]

Hello
I follow the tutorial 
so I end up  migrating my Xpenology with "DSM_xxxxx_25426.pat" (Manually) and I can see WebInterface to log in
Unfortunatly none of any of my Login/passwords works !!
What could I've done wrong ?
Any help would be much appreciated 
 

[Jiel62]

Thank you for your help  

Works for me !

[Rikk]

Thanks a lot for this useful and accurate how to!

Rikk

[Bob Jones]

Fantastic Worked great for my HP N54L thanks for all your hard work IG-88, I will leave the upgrade button alone 🥳

[c_c_b]

Worked perfectly, can't thank you enough @IG-88!

[xnaron]

I had 

On 4/8/2021 at 11:43 AM, IG-88 said:

 

then remove some files with this

rm -rf /mnt/SynoUpgradePackages
rm -f /mnt/SynoUpgrade.tar
rm -f /mnt/SynoUpgradeindex.txz
rm -f /mnt/SynoUpgradeSynohdpackImg.txz
rm -f /mnt/checksum.syno
rm -f /mnt/.syno/patch/*

 

I have /mnt/SynoUpgradeindexdb.txz  not  /mnt/SynoUpgradeindex.txz  should I remove it instead?

I also have /mnt/SynoUpgrade.tar.gz .... should I remove that?

[IG-88]

14 hours ago, xnaron said:

I have /mnt/SynoUpgradeindexdb.txz  not  /mnt/SynoUpgradeindex.txz  should I remove it instead?

I also have /mnt/SynoUpgrade.tar.gz .... should I remove that?

yes, as the start process looks for update files and we dont want the update to be installed i would remove the files

they are clearly belonging to the update process and doe not relate to a normal running dsm system

[Nekely]

 

I am following the process, but when I get to check the VERSION. I see the one in / etc, but /etc.defaults shows me that it is not a file or directory. when listing / mnt, if it appears to me, but I can't access it

 

 

edited: Solved, It works for me, thanks

[Karthik Dorai]

This really saved my ass! Thank you so much. Accidentally updated to 6.2.4-25556 and my synology server did not boot up. I was very sure the bootloader can support it but no idea what was the reason/hiccup for not booting into the system. The tips in this post helped me to revert back to 6.2.3-25426. Phew! 

 

No more updating to the latest version, no more.

[unmesh]

What has worked for me in the past is to disconnect the old drives, add a new (in my case small size) drive and flash a new bootloader USB. I then install the last known DSM version onto the new drive using the same login and password. Then I add back the original drives and DSM offers to correct the version on them (it might be the migrate option but I don't remember). I let it do that, power down, remove the new drive, let it reboot with only the original drives and all was fine.

 

I keep good records of what is running and save the bootloader images with their modified grub.cfg and the .pat files which helps. As does having a spare SATA port!

[IG-88]

 

10 hours ago, unmesh said:

What has worked for me in the past is to disconnect the old drives, add a new (in my case small size) drive and flash a new bootloader USB. I then install the last known DSM version onto the new drive using the same login and password.

 

you would not have to when using this method, you do a fresh install and loose all settings of the old one, you could downgrade to any dsm version as long as you have a loader for it, the only part you are reusing is the data partition(s) you created after installing dsm

 

10 hours ago, unmesh said:

Then I add back the original drives and DSM offers to correct the version on them (it might be the migrate option but I don't remember).

you do boot from the usb you newly created and the new disk and with it you have a new raid1 set, you dont migrate anything (you loose all settings like users, shares, ...) because you just fill up your new raid1 with the system and swap  partitions of your old drives (raid repair of the new raid1 from the new disk) and deleting the content of the 1st two partitions (system and swap) of your old disks on the way

depending of the complexity of your installation it might be worth the effort to try another way and keep the settings or have a backup of the system and packages for the dsm version you use (like with hyperbackup from synology), then you can (fresh) install the dsm version you had before and restore the system state after the default system is back and running

 

10 hours ago, unmesh said:

I keep good records of what is running and save the bootloader images with their modified grub.cfg

that can be helpful but when using a new usb to boot from, you will still need to mod the grub.cfg for the new vid/pid of the usb flash drive (and might still need some documentation to remind you of that)

when using different hardware for recovery there can be added things, like when using 918+ that needs a 4th gen intel (haswell) as minimum and then using the loader at hand (1.04b) with a older hardware you might have around will not work if the cpu is to old

a documentation is suggested in parallel as it's often not that simple as it looks in some youtube videos