AllGamer

memo: Upgrading DSM 5.2-5644.5 to 5.2-5967.1

Recommended Posts

OK... after spending few hours Saving / Recovering from a BAD upgrade, here are a few notes to keep in mind. :geek:

 

[Less than 12 HDDs]

If you have less than 12 Disk or less in your XPEnology DSM server, it's very safe to upgrade and completely painless.

 

That being said, even if it's "safe"

 

Make sure to Backup Your Data before you even attempt to upgrade, you never know when the universe will throw you a curve ball. :wink:

 

[More than 12 HDDs]

However! if you have more than 12 Disk in your DSM server... well get ready for some long work.

 

:eek: There is no easy way around this, only Safety measure and best practices.

 

0. Make sure you have the new 5.2-5967.1 USB boot prepared and ready. (I had to create the USB twice, the first time didn't boot from the USB for whatever reason.)

1. Hot Swap eject all your HDD that are above Disk #12, so in my case I have from Disk # 13 to Disk # 24. (I should have ejected them to save myself some trouble)

2. Install or upgrade DSM 5.2-5644.5 to 5.2-5967.1 using the .pat file.

3. After you first boot back into the DSM, it'll be version 5.2-5967.1, you will have lost the settings from your synoinfo.conf, You'll be asked to also configure a few missing settings. (if you have a backup of the Synology settings file, you can restore after you bypass the menus)

5. Before you even bother editing the synoinfo.conf, it is HIGHLY recommended to upgrade the remaining disks 13 to 24 or whatever extras you have, to use the new DSM system partitions.

You can use a cloning tool to only copy the system partitions from the existing upgraded volumes (any disk from 1 to 12)

or

You can go CYCLE your additional volumes located on Disk #13 and above.

 

Both methods are tedious, as it require you to eject physical HDDs in volume groups to work with.

 

I went with the Disk Cycling option, as it was a little more straightforward, but still annoying.

From my disks 1 to 12, I had 2 separate volumes there, which made the job a little bit easier. When I created this server I knew and I expected this kind of trouble, so I intentionally created 1 large volume with 8 disks and a smaller volume with 4 disks, this let me easily swap the volumes in and out of the server via Hot Swap.

 

So, I removed a full volume set of 8 disks

then I proceeded to swap in the remaining Volumes that are still with the old DSM 5.2-5644.5 system partitions

when you plug them in, it will be detected as Crashed, and It will ask you to Repair :???:

 

Repair is safe, by selecting Repair, it will update the DSM partitions to the new 5.2-5967.1 system partitions, your data will not be touched.

 

So repeat this process a few time, until all your additional disks and volumes from Disk 13 and above are upgraded to the new DSM version.

 

Once that is done, it'll be safe to update the synoinfo.conf to enable the additional drives.

 

[Why?]

Now, You'll probably ask WHY? not update synoinfo.conf first, and then not have to do the Hot Swap music chair?

 

Because I tried the lazy way frst and it doesn't work, as soon as the new DSM 5.2-5967.1 boots up and detects some disks partitions are still running the old 5.2-5644.5, the :evil: DAMN thing will automatically reboot your machine to force it into Factory Default mode, then you'll be forced to do the steps 1 to 4 again, and all the hard work is gone and you need to start from scratch again.

 

:oops: This is how I lost a few hours, when it could have been done in less than 30 min.

 

I tried the other lazy way by adding the HDD after the upgrade, hoping it will offer you the option to "Repair" ... but nope,

they will be detected as Brand NEW HDDs ("not initialized"), and you WILL lose your data if you select the option to create volume or initialize the disk.

 

If you leave the HDDs pluged-in then it causes the endless reboot, because it keeps going into Factory Default mode.

 

So, the only Safeway, and trouble free way, is by doing the Music Chair upgrade with the volume sets, or cloning the 5.2-5967.1 system partitions to the remaining drives.

Share this post


Link to post
Share on other sites

Thanks, I suffered this on a new installation on my 16 bay unit until I realised.

 

Does the boot loader contain any details around the number of bays etc. or is it simply a way to boot the kernel and prepare it for the new DSM update using the PAT file? Having looked at the PAT file, it obviously contains the synoconfig for the ds3615xs which is limited to 12 slots but I wonder if there is a way the boot loader can inject a modified one after unpacking? Probably not, but worth exploring?

Share this post


Link to post
Share on other sites

I'm running a 16 bay unit unit and updates but with not so much pain, maybe I'm just lucky? :smile:

 

My process was

 

Create new XPE .5967.1 boot drive

Using a 'spare' mobo and HDD boot up XPE install DSM and create/delete a volume

Edit/save synoinfo.conf to 16 HDD configuration

Move 'edited' XPE .5967.1 boot drive to live box

Boot live box

Update DSM .5967 through control panel

 

All worked ok with no loss of array or volumes

 

I've used this process before having learned in the past that a new boot drive overwrites synoinfo.conf :smile:

Share this post


Link to post
Share on other sites
I'm running a 16 bay unit unit and updates but with not so much pain, maybe I'm just lucky? :smile:

 

My process was...

 

I pretty much did the same thing on the first try, only to find out it didn't like it, because when the .pat file was installed, it was only applied to some drives (12 default), but not all drives.

 

so, after the reboot, the DSM will go insane as it detects the old version is still in the remaining drives, and it will automatically boot into factory default mode, with no option for you to repair or recover until you complete the "migration"

 

which basically repeats the same thing over and over, unless i swapped the upgraded drives out, and replaced them with the drives that did not have the update, to get all the drives with the correct version of the update, and then it will boot properly when all the drives are running the proper version.

 

I was hoping that by installing the .pat file, while My version of the synoinfo.conf file was there, it would read and write to all drives, but seems like it gets ignored and uses the version from the .pat file, and the "easy" way didn't work out.

 

next time I upgrade, I'll just eject all drives over #13, let the system do the default 12, then repeat the upgrade again, after ejecting the updating ones, and inserting the remaining 12 drives (13 to 24), since I only have 24 drives, that means only need to 1 swap once, and do the upgrade for each set.

 

It was a good learning experience. :razz:

Share this post


Link to post
Share on other sites
Thanks, I suffered this on a new installation on my 16 bay unit until I realised.

 

Does the boot loader contain any details around the number of bays etc. or is it simply a way to boot the kernel and prepare it for the new DSM update using the PAT file? Having looked at the PAT file, it obviously contains the synoconfig for the ds3615xs which is limited to 12 slots but I wonder if there is a way the boot loader can inject a modified one after unpacking? Probably not, but worth exploring?

 

 

the synoinfo.conf is the file that contains the information about the amount of SATA drives, eSATA drives, USB ports, and Max number of disks.

 

the synoinfo.conf is inside the .PAT file, I don't know how to edit the .PAT file before upgrading the system.

 

technically speaking that would be the best option, and would save us a lot of trouble if we can pre-edit the synoinfo.conf before it gets deployed.

 

the USB boot doesn't contain this information, it's only used to boot up the kernel to run DSM

Share this post


Link to post
Share on other sites

Yes it would be. 7Zip can undo the PAT file but I'm not sure about rebuilding it.

 

I've been looking through the PAT file for the rs18016xs+ and as that natively has SAS support and uses SAS HBAs and not SATA, that synoinfo.conf does not contain the portcfg line, instead it uses SAS_Enclosure_max which is set to 14... Would be interesting to see a boot loader that would allow the RS to load up as that might enumerate SAS backplanes properly & allow for more than 12 drives without editing...

Share this post


Link to post
Share on other sites

So the PAT file is a tar archive, so I guess if you extract HDA1 from within this archive and then change the synoinfo.conf and then repack as tar it should allow you to keep the 24 bay drive setup, worth a go in esxi?

Share this post


Link to post
Share on other sites

Hopefully Synology is doing some sort of verification that the file has not been tampered with, and modifying it may cause that to determine it is not a legitimate pat file. I am just guessing, though, and this may not be accurate.

Share this post


Link to post
Share on other sites

Yeah maybe a hash check on the length, easy way to check is for someone to create a new virtual machine with an older install and then edit the PAT and then try to install, if it works then we have a solution until such time that they incorporate verification.. If not, then spare HDDs or AllGamers method will by the way.

Share this post


Link to post
Share on other sites

Thanks for the help. I think this is where I may be stuck. I'm trying to do 60 drives in a storage pool, and they come up as not initialized when i enable them on synoinfo.conf. So... Now i need to come up with some ideas.

Share this post


Link to post
Share on other sites