How to update DSM6.2 to DSM 7.1

[gregos]

Hello Guys!

Can someoene make a step by step tutorial on update? I read the forum for several hours, but not yet sure by the steps. So now i'm running 6.2.3 on a custom built pc, running dsm3617xs. Should i start update from controller (only 7.0.1 offered), then create a new pendrive with redpill loader, and boot with that after first reboot of nas pc, then follow the instruction? Or should i retrieve something from the old pendrive first? Sorry for being noob, but i don't want to loose any data or settings, and i don't currently have any other spare pc to test.....
Thank you!

Gergely

Edited April 22, 2022 by gregos

[gregos]

Hi! I'm using TCRP. With the previous DSM i was using Jun's mod. Also i checked the USB VID&PID, seems to be matching with the flash drive's VID&PID.

[IG-88]

On 4/22/2022 at 6:39 AM, gregos said:

I read the forum for several hours, but not yet sure by the steps.

its the same as a fresh install but when dsm install process detects a "older" version on disk it will "migrate" aka update it to the new one (and in case of 6->7 there are major differences with packages so you might need to replace same after the update with 7.0 aware versions - automatically happens for syno's own packages from there repository), it can also be a different model of synology and the migrate will take as much as possible to the now model, so you can exven change from 3615 to 918+ or 3622 in that process

you would just shutdown your 6.2.3, remove the old usb and insert the one with the 7.x loader

its suggested to prepare/test  the 7.x loader with a single blank disk (even a old small disk is ok), so you are sure it works, detects you hardware and you could even test packages with 7.x that way

when finished testing the single test-disk can be deleted and the 7.x loader usb can be used for updating your old 6.2.3 dsm disks

 

its the same situation on a original synology hardware (internal usm dom) when a old hardware with loader 6.2.x breaks and the new hardware sent to the customer comes with a recent 7.1 loader on the internal usb dom, the customer puts in his disks, boots up and does the update to 7.1

(the usb dom only holds the loader/kernel of DSM, the DSM OS itself  is stored on every disk as a raid1 2.4GB partition)

 

[gregos]

2 hours ago, IG-88 said:

its the same as a fresh install but when dsm install process detects a "older" version on disk it will "migrate" aka update it to the new one (and in case of 6->7 there are major differences with packages so you might need to replace same after the update with 7.0 aware versions - automatically happens for syno's own packages from there repository), it can also be a different model of synology and the migrate will take as much as possible to the now model, so you can exven change from 3615 to 918+ or 3622 in that process

you would just shutdown your 6.2.3, remove the old usb and insert the one with the 7.x loader

its suggested to prepare/test  the 7.x loader with a single blank disk (even a old small disk is ok), so you are sure it works, detects you hardware and you could even test packages with 7.x that way

when finished testing the single test-disk can be deleted and the 7.x loader usb can be used for updating your old 6.2.3 dsm disks

 

its the same situation on a original synology hardware (internal usm dom) when a old hardware with loader 6.2.x breaks and the new hardware sent to the customer comes with a recent 7.1 loader on the internal usb dom, the customer puts in his disks, boots up and does the update to 7.1

(the usb dom only holds the loader/kernel of DSM, the DSM OS itself  is stored on every disk as a raid1 2.4GB partition)

 

Hi! Thanks for this guidline! I will try to find some spare HDD at home, and i'll give it a try! Have a nice day

 

[gregos]

On 4/24/2022 at 5:14 PM, IG-88 said:

its the same as a fresh install but when dsm install process detects a "older" version on disk it will "migrate" aka update it to the new one (and in case of 6->7 there are major differences with packages so you might need to replace same after the update with 7.0 aware versions - automatically happens for syno's own packages from there repository), it can also be a different model of synology and the migrate will take as much as possible to the now model, so you can exven change from 3615 to 918+ or 3622 in that process

you would just shutdown your 6.2.3, remove the old usb and insert the one with the 7.x loader

its suggested to prepare/test  the 7.x loader with a single blank disk (even a old small disk is ok), so you are sure it works, detects you hardware and you could even test packages with 7.x that way

when finished testing the single test-disk can be deleted and the 7.x loader usb can be used for updating your old 6.2.3 dsm disks

 

its the same situation on a original synology hardware (internal usm dom) when a old hardware with loader 6.2.x breaks and the new hardware sent to the customer comes with a recent 7.1 loader on the internal usb dom, the customer puts in his disks, boots up and does the update to 7.1

(the usb dom only holds the loader/kernel of DSM, the DSM OS itself  is stored on every disk as a raid1 2.4GB partition)

 

Hi IG-88! Can you please tell me where can i find the user_config.json to move to the new loader? As i can not find it.... On the redpill flashdrive i can see them, but i can not map drives to my old pendrive, so i can not move serial & mac.... (i created the redpill loader following the tutorial on this forum, including ssh, rploader commands, etc. on a spare hdd, with a spare pendrive.)

 

Thanks in advance!

Gergely

[IG-88]

4 hours ago, gregos said:

where can i find the user_config.json to move to the new loader?

that depends on the loader you are using, user_config.json belongs to tinycore and the "results" after using this file will end in in the 1st partiton in grub.cfg

in that regard the rp loader is still the same as jun's loader, the values end  up as kernel parameters in grub.cfg

looks like this in grub.cfg: (see the vid/pid, sn and mac?)

linux /zImage HddHotplug=0 withefi console=ttyS0,115200n8 netif_num=1 syno_hdd_detect=0 syno_port_thaw=1 vender_format_version=2 earlyprintk mac1=E7ACA9ACDCFF syno_hdd_powerup_seq=1 pid=0x0001 log_buf_len=32M syno_hw_version=DS918+ vid=0x46f4 earlycon=uart8250,io,0x3f8,115200n8 sn=1330NZN012245 elevator=elevator root=/dev/md0 loglevel=15

 

so either do it the tc way and work with its commands and user_config.json or the plain rp way by editing grub.cfg directly

but if you use tc later on then the values in grub.cfg will be overwritten later when tc writes its values to the grub.cfg

 

edit:  user_config.json would be stored in the 3rd partion where tc resides

mydata.tgz

\home\tc\user_config.json

Edited April 25, 2022 by IG-88

[gregos]

Thank you  I'll give it a  try ...

Let's see if i can do it

[gregos]

On 4/26/2022 at 12:11 AM, IG-88 said:

that depends on the loader you are using, user_config.json belongs to tinycore and the "results" after using this file will end in in the 1st partiton in grub.cfg

in that regard the rp loader is still the same as jun's loader, the values end  up as kernel parameters in grub.cfg

looks like this in grub.cfg: (see the vid/pid, sn and mac?)

linux /zImage HddHotplug=0 withefi console=ttyS0,115200n8 netif_num=1 syno_hdd_detect=0 syno_port_thaw=1 vender_format_version=2 earlyprintk mac1=E7ACA9ACDCFF syno_hdd_powerup_seq=1 pid=0x0001 log_buf_len=32M syno_hw_version=DS918+ vid=0x46f4 earlycon=uart8250,io,0x3f8,115200n8 sn=1330NZN012245 elevator=elevator root=/dev/md0 loglevel=15

 

so either do it the tc way and work with its commands and user_config.json or the plain rp way by editing grub.cfg directly

but if you use tc later on then the values in grub.cfg will be overwritten later when tc writes its values to the grub.cfg

 

edit:  user_config.json would be stored in the 3rd partion where tc resides

mydata.tgz

\home\tc\user_config.json

Hello Guys & IG-88!

Can you please help me out! Since my last post, i built a test nas, with same config as the current baremetal. I have no sucess with this update.... So i use JUN's mod, ds3617xs as base, and modified the vid& pid& serial& sata port map etc. manually at tc's user_config.json.... At my latest trial, i left the ./rploader.sh serialgen; identify.... etc steps, went to image build straight forward, but i still lost my serial, mac, etc.... And when i try to install DSM from browser, it always says .pat is damaged, and can not finish update (in this case i did not care serial, different IP address etc.) i just wanted to try if i can even install 7.1 from 6.2 .....

So basically i would like to get some help, what to do step by step for updating my DSM 6.2 preserving all my config, data, serial, mac etc... (from Jun's Loader) to TC 7.1 .... Maybe i just miss some steps or i have no clue.....

Thank you!

[flyride]

https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/

 

[gregos]

5 hours ago, flyride said:

https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/

 

Hello! 

Thank you, i'll have a look..

 

[gregos]

Hi Guys! 

I succesfully installed dsm 7.1, but i have some issues. After each reboot, i have to rebuild loader, as after reboot, when i go to the ip of nas, it says, it needs to be installed (as per the first install). If i rebuild the loader, i can then use the nas as before (with existing users and settings intact). Does anyone have a solution for this? 

Thank you! 

[rojoone2]

Can you tell us the specs of you build and list the commands you used for your build? 

 

[gregos]

1 hour ago, rojoone2 said:

Can you tell us the specs of you build and list the commands you used for your build? 

 

Hi!

Its an Intel motherboard ,I3-3240 CPU, 16Gb Ram -- Baremetal.

For bootloader rebuild i only use :

./rploader.sh build broadwellnk-7.1.0-42661

then

./rploader.sh clean now; rm -rf /mnt/sdb3/auxfiles; rm -rf /home/tc/custom-module; ./rploader.sh backup now;

Then

sudo reboot

After this everything works as before. If I restart the NAS, it goes to synology web assistant page, then asks for install. If i rebuild tcrp bootloader, then everything back to normal....

[rojoone2]

There are necessary commands before the build process that you did not list here.

You don't have to manually enter you pid, vid and mac like with Jun's old loaders.

There are commands in RPTC that can do that for you. (The DS3622xs+ is a good choice to go with by the way)

These are the commands I used to build my DS3622xs+ on a Gigabyte motherboard with a 6th gen i5 processor:

 

./rploader.sh clean 

./rploader.sh update

./rploader.sh fullupgrade

./rploader.sh serialgen DS3622xs+

./rploader.sh serialgen DS3622xs+ realmac

./rploader.sh identifyusb

./rploader.sh satamap

./rploader.sh build broadwellnk-7.1.0-42661

 

The loader will ask if you want to remove the old files .. answer yes

Then sudo reboot.

 

Give this a try and post your results.

 

[gregos]

8 minutes ago, rojoone2 said:

There are necessary commands before the build process that you did not list here.

You don't have to manually enter you pid, vid and mac like with Jun's old loaders.

There are commands in RPTC that can do that for you. (The DS3622xs+ is a good choice to go with by the way)

These are the commands I used to build my DS3622xs+ on a Gigabyte motherboard with a 6th gen i5 processor:

 

./rploader.sh clean 

./rploader.sh update

./rploader.sh fullupgrade

./rploader.sh serialgen DS3622xs+

./rploader.sh serialgen DS3622xs+ realmac

./rploader.sh identifyusb

./rploader.sh satamap

./rploader.sh build broadwellnk-7.1.0-42661

 

The loader will ask if you want to remove the old files .. answer yes

Then sudo reboot.

 

Give this a try and post your results.

 

Hi!

I manually editid the user_config.json because if i don't , with the commands you posted above, i could never achieve my serial and mac to be the same (as before). I manually copied the satamap, serial, usb PID & VID from previous dsm's grub.cfg, in this way i could keep my serial, mac, etc.....

  

[rojoone2]

12 minutes ago, gregos said:

Hi!

I manually editid the user_config.json because if i don't , with the commands you posted above, i could never achieve my serial and mac to be the same (as before). I manually copied the satamap, serial, usb PID & VID from previous dsm's grub.cfg, in this way i could keep my serial, mac, etc.....

  

Are you using the same USB drive you used in the old build?

 

./rploader.sh serialgen DS3622xs+ realmac  uses your real MAC address.

 

The serial needs to be changed because you are building a different platform: DS3617 now to DS3622.

 

 

[gregos]

3 minutes ago, rojoone2 said:

Are you using the same USB drive you used in the old build?

 

./rploader.sh serialgen DS3622xs+ realmac  uses your real MAC address.

 

The serial needs to be changed because you are building a different platform: DS3617 now to DS3622.

 

 

Yes, i'm using the same usb, same lancard. Everything is the same. It was just an update from dsm 6.2. 

[rojoone2]

That's fine, gutsy.. but fine. You still need to follow the commands above and change the serial to match the platform.

The DS3622xs+ is the newer model to the DS3617xs and thus the difference.

You should only have to migrate when done (with you real mac address) and also be able to restart without having to reinstall the DSM.

[gregos]

I understand that. I was able to install the 7.1dsm, i only have to rebuild the bootloader in case any restart. Also i use the real mac address of the NIC. Other then that i was able to use it for the last week. Today i only had to reboot it, thats when the issue occured. I'm not sure if the serial has to do anything with the reboot issue. I think if there was any problem with the serial, i wont be able to install the 7.1 itself. But if you think it is the problem i'll try to do a serialgen. 

Thank you very much for the help! 

Edited June 23, 2022 by gregos

[IG-88]

On 6/23/2022 at 10:30 PM, gregos said:

I'm not sure if the serial has to do anything with the reboot issue. I think if there was any problem with the serial, i wont be able to install the 7.1 itself.

the serial usually has no effect when installing, the usb vid/pid needs to mach the values of the usb used for installing/starting

so check usb's vid/pid in the grub.cfg that was created from the user_config.json (when building and using "./rploader.sh identifyusb" it should match the usb's hardware)

check the hardware usb id with another computer and compare that to whats in the grub.cfg (that one is used when starting the loader, that the part where the "rp" of the tc rp loader kicks in, the tc part is to configure the loader that is later used when booting up dsm)

serial only comes into play when it comes to some licensing stuff like multimedia codec's or camera licenses (like default two and more on some systems like dva)

a invalid serial should not prevent the system from booting up into dsm

[pocopico]

On 6/23/2022 at 11:30 PM, gregos said:

I understand that. I was able to install the 7.1dsm, i only have to rebuild the bootloader in case any restart. Also i use the real mac address of the NIC. Other then that i was able to use it for the last week. Today i only had to reboot it, thats when the issue occured. I'm not sure if the serial has to do anything with the reboot issue. I think if there was any problem with the serial, i wont be able to install the 7.1 itself. But if you think it is the problem i'll try to do a serialgen. 

Thank you very much for the help! 

Are you using Juns mode ? On reboot the system will fetch the last smallupdate and if you dont have the miniroot matching  with the root it will fallback into re-install. 

 

If you are not using Juns mode, you can run TCRP to run the postupdate process.

[pocopico]

6 hours ago, gregos said:

Hi! I'm using TCRP. With the previous DSM i was using Jun's mod. Also i checked the USB VID&PID, seems to be matching with the flash drive's VID&PID.

 

Then on your next reboot, select Tinycore and when in TCRP please execute

 

./rploader.sh postupdate

 

this will recreate the rd.gz to match the upgraded root

[gregos]

Thank you! I'll try that.