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


Recommended Posts

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

image.png.ada7dc1cfb0632618521216c4cb251a2.png

 

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 by IG-88
  • Like 4
  • Thanks 3
Link to post
Share on other sites
  • IG-88 changed the title to how to undo a unfinished update 6.2.3 to 6.2.4 (no boot after 1st step of update)

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 by use-nas
Link to post
Share on other sites
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)

 

Link to post
Share on other sites

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

Link to post
Share on other sites

@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

 

Link to post
Share on other sites
Posted (edited)
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 by IG-88
Link to post
Share on other sites
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

Link to post
Share on other sites

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 by Mjombly
Spotted my mistake!
Link to post
Share on other sites

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)
 

Link to post
Share on other sites
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)

Link to post
Share on other sites

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 
 

Link to post
Share on other sites

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?

Link to post
Share on other sites
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

Link to post
Share on other sites

 

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

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 2 weeks later...

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!

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.