Jump to content
XPEnology Community

Upgrading DSM


merve04

Recommended Posts

17 hours ago, merve04 said:

When i comes to upgrading to a newer version of dsm, is it best to apply dsm update first, then update extra on usb or update usb extra first then apply dsm update?

as always the answer is - it depends ...

when staying inside a dsm main line like 6.0, 6.1, 6.2 you usually don't need a new loader and you don't need new drivers - except for 6.2.1/6.2.2 where synology changed the kernel settings in a way making drivers incompatible - but that's history, when you do the usual you start with the loader and use the latest dsm *.pat file, for 6.2 it would be 6.2.0 kernel on the loader and 6.2.3 *.pat file and that is supposed to work (as its neither 6.2.1/6.2.2 and with in a main line)

 

when doing a change in main line and loader its always also a change in extra.lzma aka drivers, the loader comes with a set of drivers and there is usually a extended version with more drivers

 

a "safe" way when updating to a new dsm line an loader would be to first prepare the loader, test it and then do the update

when just doing a update from 6.1 (loader 1.02b) to 6.2.3 you end up with a kernel of 6.2.3 written to loader 1.02b so the loader does not match the kernel and also the drivers in the extra.lzma do not match anymore (still the one made for 1.02b dsm 6.1)

you are half way in the update (new dsm extracted on disk and kernel copied to loader before reboot) and you system does not boot anymore

the way forward now is the new loader for the new dsm main version to boot and continue, but it can be a problem (depending on experience and know how) to get the new loader to boot properly and there might even be the need of the (new) extended drivers, if you don't get the new loader flying you have no option to boot as you old boot usb has the new loader and cant boot the old system and the new loader is not ready

 

the safer way is to know you will need a new loader and make it ready before updating dsm - and thats pretty simple, you shut down you dsm system, cut power to all hdd's/ssd's, remove the boot usb and ready a new one the way the tutorial describes it (in our example you make 1.03b or 1.04b ready) you plug the new usb, connect any old (empty!, no partitions) hdd/ssd and boot up, 1st step find it in network (boot ok, kernel and driver running) to make sure you have the right vid/pid usb you will need to install to the one empty hdd/ssd, this not only makes sure your vid/pid is ok it also copy's the kernel of you dsm version you want to install to the usb and if the install of the complete dsm with reboot works its sure to work with the old system on updating

if you use any special storage or network controller, that's the point where you check - before the update and it a hardware is not found/not working you can try a extra.lzma with more drivers with your new loader - if all this does not end good, you still have your old usb and the old disks all untouched, replug all old stuff (revert bios settings if you did anything like this)  and your old dsm should boot as always and you can think about what went wrong

 

if the test with the new usb works out you can put the single hdd/ssd aside (don't needed anymore) and you have now two possible way's

1. boot the new usb, let the system find in network  (synology assistant or browser) and do a migration, that will copy the kernel (again) to the usb and the new dsm version to disk the automatic reboot will succeed as you already tested all this with the one test hdd/ssd

2. boot with you old usb int your old dsm version, remove the old usb, plug in the new (the boot media is not mounted  when dsm is running) and start the dsm update in the webgui, again the kernel is copied to usb (now already the new loader, the update process mount the boot media for this) and the new dsm version is copied to disk to make it update ready, on automatic boot the new usb will work (it was already tested) and the update process will run as it should be

 

Link to comment
Share on other sites

So I've ran 6.2.3 on my hardware so i know it works. Last time when i updated to latest, it broke hw transcoding in plex, I then made a new usb with new extra and was back in buisness, but that resulted in dsm going into recovery mode. This morning I tried pulling out my current usb so i could update extra and then update dsm but the problem is i can never read the stupid usb once the loader has been flashed on the usb key. So i just said why not just make a new usb with 1.04 and add the extra v0.13, keep in mind still on 6.2.2u6

Well i reboot server with new key, showed up as recoverable which i expected and proceeded to recover and that was the last id see dsm. Waited for about 30min.

I reflashed my usb key with untouched 1.04 loader minus the typicall grub settings and dsm came back fine.

So now Im in the process of upgrading to 6.2.3u2 and i know it will break my hw transcoding. Last time i did a new key with your extra files and was fine, but as mentioned triggers recovery, check quotas etc etc. There must be a better way?

 

edit;

Anyway, once 6.2.3u2 was completed, i took another usb key and flashed 1.04 with extra 0.13, rebooted, proceed with recover, 10min and back in dsm with hw working in plex.

Why is it not possible to just reload the usb key in osfmount and simply copy the extra files?

 

Edited by merve04
Link to comment
Share on other sites

26 minutes ago, merve04 said:

I then made a new usb with new extra and was back in buisness,

6.2.3 918+ comes with its own i915 driver and this collides with jun's driver in the loader (>2 years old), o addressed this in the extra/extra2 for 6.2.3, it would be enough to just replace the extra/extra2 after updating to 6.2.3

 

28 minutes ago, merve04 said:

but that resulted in dsm going into recovery mode.

 

when you just use a 1.04b loader it contains the dsm kernel of 6.2.0 and in your case there was already 6.2.3 in disk - a state that in original systems might occur when your box with the latest dsm breaks and you get a replacement hardware containing a older dsm boot loader on its internal usb

nothing unforeseen if you exactly know whats going on

 

34 minutes ago, merve04 said:

This morning I tried pulling out my current usb so i could update extra and then update dsm but the problem is i can never read the stupid usb once the loader has been flashed on the usb key

 

thats a windows 10 problem with the state of the loader not dsm, also not new a kind of side problem, you will get the same when using osfmount to handle the *.img

https://xpenology.com/forum/topic/29872-tutorial-mount-boot-stick-partitions-in-windows-edit-grubcfg-add-extralzma/

its not consistend through all win10 versions (with two every half a year it gets difficult to keep track)

with 1909 the 1st partition works but is only accasible with elevated rights in windows, it gets a drive letter but you can's access it, its possible to open notepad++ "as administrator"  and then you can access that drive letter and change grub.cfg

2nd partition does not get a drive letter and you can use additional tools to copy extra/extra2 or kernel to it (see link above, atm i use "Ext2 Volume Manager" for this task)

or just use linux and you will not see this problems

 

45 minutes ago, merve04 said:

So now Im in the process of upgrading to 6.2.3u2 and i know it will break my hw transcoding.

 

special thing with 6.2.3 and if you would follow  my instructions from above you would prepare a 1.04b, copy the new 6.2.3 kernel to it (zImage, rd.gz)  and copy the new extra/extra2 made for 6.2.3 to it - resulting is properly working boot media for 6.2.3 including hardware transcoding

 

45 minutes ago, merve04 said:

Last time i did a new key with your extra files and was fine, but as mentioned triggers recovery, check quotas etc etc. There must be a better way?

the recovery is when you "feed" a older kernel on the loader to a newer system (on disk), as written above, just copy the right kernel to the loader and nothing like that will happen, if the kernel on the boot it newer dsm will call it migratable, thats in my description above as 1.

22 hours ago, IG-88 said:

1. boot the new usb, let the system find in network  (synology assistant or browser) and do a migration, that will copy the kernel (again) to the usb and the new dsm version to disk the automatic reboot will succeed as you already tested all this with the one test hdd/ssd

 

cause and effect, when the process is understood its completely logical and predictable, you need to keep track what kernel and extra is where located and used and unfortunately with 6.2.1/6.2.2 there are incompatible combinations of kernel and extra.lzma inside the 6.2 line that can result in drives not working in some combinations, the new i915 driver in 6.2.3 is a little bonus to that (in both way's its working fine but also invalidates jun's backported i915 driver)

 

most of the problems are created as there are no complete loaders per dsm 6.2 versions (containing the proper kernel and extra.lzma) you would need a pretty big amount of loaders when trying to cover 6.2 (including my extra's), three for 6.2.0, five for 6.2.2 and four for 6.2.3 (we leave out 6.2.1 here as it is not important and it would make things even more complex) - in addition to jun's three loaders, and all this needs a short text that everyone understands - the later one in kind of a impossibility in itself

for legal reasons i'm not going to offer any complete loader but if some one wants to document the mess and offer loaders ready made i will help providing information's and suggestions (and extra.lzma's)

 

Link to comment
Share on other sites

Thanks for the reply, clearly this is the link i needed;

 

But for now im up and running, but this is booked for future updates if required.

Mac is my primary OS, i run windows as a VMM to do some of these tasks among others.

Anyway as always I appreciate your time and input IG-88.

Cheers

Link to comment
Share on other sites

1 hour ago, merve04 said:

Mac is my primary OS,

so its basically a unix (bsd)

i don't know how deep apple lets you handle things on the command line but in theory you should be able to use the recipes for mounting and changing the usb's partitions for linux in a similar way

 

mkdir -p /mnt/synoboot1
mkdir -p /mnt/synoboot2

echo 1 > /proc/sys/kernel/syno_install_flag
mount /dev/synoboot1 /mnt/synoboot1
mount /dev/synoboot2 /mnt/synoboot2

 

edit: if you are already using vm's, maybe use a linux vm for this

Edited by IG-88
Link to comment
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.

×
×
  • Create New...