Jump to content
XPEnology Community

DSM 5.0-4493 Update 7


djf

Recommended Posts

I did the same thing also, updated my Xpenology box without the SSH command and my DSM version is also showing up as Update 7. All files and permission are intact. Strange!

 

Another strange thing that I found out is that my real Synology box, a DS110j, does *NOT* show Update 7 when I checked for updates. It's currently at DSM 5.0-4493 Update 5 and according to the status, it is still up-to-date. Maybe the shell shock security issue doesn't affect ARM-based Synology NAS?

 

Weird, because the sed command prevents flash update; which would be were gnoboot/nanoboot lives.

 

Here's an example of the script the update process normally runs:

 

autoupd@te.info

{
"blNeedReboot":true,
"buildnumber":4418,
"debDir":"/volume1//@smallupd@te_deb",
"flashupdateDeb":"flashupdate_5.0-4418-s1_all.deb",
"installDeb":["apache-2.2.x-bromolow-bin_2.2.25-4418-s1_all.deb",
"lnxessential-bromolow-bin_5.0-4418-s1_all.deb",
"samba-3.6.x-bromolow-bin_3.6.9-4418-s1_all.deb",
"dsm-bromolow-bin_5.0-4418-s1_all.deb",
"dsm-AdminCenter-bromolow-bin_5.0-4418-s1_all.deb",
"postgresql-9.3.x-bromolow-bin_9.3.1-4418-s1_all.deb"],
"newSmallFixNumber":1,
"smallupdateDeb":"smallupdate_5.0-4418-s1_all.deb",
"updateType":"smallupdate"
}

 

And the sed command, which if applied to the above example spoofs the location where flashupdate_5.0-4418-s1_all.deb is applied (to flashupdateDeb1):

sed -i 's/flashupdateDeb/flashupdateDeb1/' /autoupd@te.info

 

I'm curious what is different that it worked for you guys without halting the update, or messing up your nanoboot.

Link to comment
Share on other sites

I updated from update 4 to 7 using the GUI without running the SED script.

All file permissions were missing.

I also updated the packages including DS Audio to 5.3-2733 which is marked as beta and have since reverted to 5.2 but still DS audio does not find any music.

I can still see all my library in \Music and in MediaLibrary it is showing re-indexing files.

 

Any idea what file permissions are required?

 

 

Edit

All music back after re-index

Link to comment
Share on other sites

I needed 3 reboots.

First one to remount the volume although as mentioned data was still accessible.

Second so that SMART data was reported correctly - HDD temps reported as -1°c

Third so that package status was available (Stopped/Running) was missing.

File permissions sorted as mentioned and unticked box to look for beta updates as DS Audio 5.3 beta didn't find any media. Reverted to 5.2 and library rescanned successfully.

Link to comment
Share on other sites

to Dipper315

 

try to reboot one or two times ...

 

3sveHHh.jpg

Updated successfully, but it said "all volumes have been unmounted". I can still access the data. What's wrong?

------------------Edit----------------------

System corrupted after reboot......

 

See the instructions of update 5, http://www.xpenology.nl/installatie-dsm ... -update-5/.

 

Restored back to 4493 base. I might try a later date. Good Guide btw.

Link to comment
Share on other sites

Nick,

I don't see any issue with going straight from U1 to U7 although you might need to make sure your boot .iso/usb is 4493 _U7 (not too sure if this is a show stopper or not).

 

Regarding the magical commands, here is how the update procedure works, as I understand it:

Downloading (either straight from synology, or manual from a .pat file) creates two files, one is the .pat file, the other is an "Update info" file.

The .pat file is just a compressed archive, ins some cases the synology will uncompress it to /volume1/@tmp/some directory, in some cases it just downloads the .pat to /volume1/@temp/some_number.pat. Whether the .pat file is uncompressed or not seems to be dependant on how major the update is, but is anyways uninmportant with respect to the "magical Command"

 

The "update info" file will either just have a string indicating where the uncompressed.pat file is, or a list of each individual update and where they are if the update is uncompressed by the download mechanism.

 

On a real synology there is a flash memory device, which contains the boot code for the box. This device is updated by a patch called "flashupdatedeb". Since our xpenology boxes don't have a real flash device (this is why we boot from a usb or .iso image), we can't update that device. Presumably the synology update procedure will fail if it cannot update the boot device (obviously the first test for the update procedure is "Where did I boot from?, can I update it? If No, exit".

 

What the magical commant does is modify the "update info" file named "autoupd@te.info" , changing every instance of "flashupdatedeb" to "flashupdatedeb1" i.e. to an update that does not exist in the extracted directory structure. The sed command makes a 2nd copy of the "update Info" called "autoupd@te.info1, which we overwrite the orginal autoupd@te.info with via the "mv" command.

 

Fortunately the synology update procedure doesn't do any testing to see if every update listed in the .info file is actually there, so that when you then click on "update" in the GUI, the software then just steps through the updates listed in the info file, ignoring the flashupdatedeb (because it isn't listed) and wordlessly skipping the updateinfodeb1 (because it doesn't exist), but it updates everything else.

 

On updates that don't include changes to the flashdevice the magical command isn't needed.

 

The update info file is just a text file, you can look at it with any editor/viewer. The .pat file is just an archive, you can expand it with tar -xvf or 7zip in windows and see what is inside.

 

Andrew

Link to comment
Share on other sites

Nick,

I don't see any issue with going straight from U1 to U7 although you might need to make sure your boot .iso/usb is 4493 _U7 (not too sure if this is a show stopper or not).

 

Regarding the magical commands, here is how the update procedure works, as I understand it:

Downloading (either straight from synology, or manual from a .pat file) creates two files, one is the .pat file, the other is an "Update info" file.

The .pat file is just a compressed archive, ins some cases the synology will uncompress it to /volume1/@tmp/some directory, in some cases it just downloads the .pat to /volume1/@temp/some_number.pat. Whether the .pat file is uncompressed or not seems to be dependant on how major the update is, but is anyways uninmportant with respect to the "magical Command"

 

The "update info" file will either just have a string indicating where the uncompressed.pat file is, or a list of each individual update and where they are if the update is uncompressed by the download mechanism.

 

On a real synology there is a flash memory device, which contains the boot code for the box. This device is updated by a patch called "flashupdatedeb". Since our xpenology boxes don't have a real flash device (this is why we boot from a usb or .iso image), we can't update that device. Presumably the synology update procedure will fail if it cannot update the boot device (obviously the first test for the update procedure is "Where did I boot from?, can I update it? If No, exit".

 

What the magical commant does is modify the "update info" file named "autoupd@te.info" , changing every instance of "flashupdatedeb" to "flashupdatedeb1" i.e. to an update that does not exist in the extracted directory structure. The sed command makes a 2nd copy of the "update Info" called "autoupd@te.info1, which we overwrite the orginal autoupd@te.info with via the "mv" command.

 

Fortunately the synology update procedure doesn't do any testing to see if every update listed in the .info file is actually there, so that when you then click on "update" in the GUI, the software then just steps through the updates listed in the info file, ignoring the flashupdatedeb (because it isn't listed) and wordlessly skipping the updateinfodeb1 (because it doesn't exist), but it updates everything else.

 

On updates that don't include changes to the flashdevice the magical command isn't needed.

 

The update info file is just a text file, you can look at it with any editor/viewer. The .pat file is just an archive, you can expand it with tar -xvf or 7zip in windows and see what is inside.

 

Andrew

 

Super post. Have a beer token from me!

Thanks Andrew for taking the time out to type that.

Synology assistant confirmed i was on 4493 so simple update. Hung on restart but once forcibly shutdown, it was back up with no issues.

 

Thanks

N

Link to comment
Share on other sites

Nick,

I don't see any issue with going straight from U1 to U7 although you might need to make sure your boot .iso/usb is 4493 _U7 (not too sure if this is a show stopper or not).

 

Regarding the magical commands, here is how the update procedure works, as I understand it:

Downloading (either straight from synology, or manual from a .pat file) creates two files, one is the .pat file, the other is an "Update info" file.

The .pat file is just a compressed archive, ins some cases the synology will uncompress it to /volume1/@tmp/some directory, in some cases it just downloads the .pat to /volume1/@temp/some_number.pat. Whether the .pat file is uncompressed or not seems to be dependant on how major the update is, but is anyways uninmportant with respect to the "magical Command"

 

The "update info" file will either just have a string indicating where the uncompressed.pat file is, or a list of each individual update and where they are if the update is uncompressed by the download mechanism.

 

On a real synology there is a flash memory device, which contains the boot code for the box. This device is updated by a patch called "flashupdatedeb". Since our xpenology boxes don't have a real flash device (this is why we boot from a usb or .iso image), we can't update that device. Presumably the synology update procedure will fail if it cannot update the boot device (obviously the first test for the update procedure is "Where did I boot from?, can I update it? If No, exit".

 

What the magical commant does is modify the "update info" file named "autoupd@te.info" , changing every instance of "flashupdatedeb" to "flashupdatedeb1" i.e. to an update that does not exist in the extracted directory structure. The sed command makes a 2nd copy of the "update Info" called "autoupd@te.info1, which we overwrite the orginal autoupd@te.info with via the "mv" command.

 

Fortunately the synology update procedure doesn't do any testing to see if every update listed in the .info file is actually there, so that when you then click on "update" in the GUI, the software then just steps through the updates listed in the info file, ignoring the flashupdatedeb (because it isn't listed) and wordlessly skipping the updateinfodeb1 (because it doesn't exist), but it updates everything else.

 

On updates that don't include changes to the flashdevice the magical command isn't needed.

 

The update info file is just a text file, you can look at it with any editor/viewer. The .pat file is just an archive, you can expand it with tar -xvf or 7zip in windows and see what is inside.

 

Andrew

 

nice explaination.

Link to comment
Share on other sites

Thanks. I am by no means a programmer, but this is more System Engineer type stuff (I used to be a SSE). I'm still trolling around trying to figure out what makes it tick, but haven't worked with *nix for a looong time. I am working on compiling drivers for a cdrom, as a start to making an ultimate rip station.

 

As to the hang on restart... In my experience there seems to be problems with restarts on install/upgrade activity. I get much better results with having a terminal open and doing a poweroff whenever a restart is called for. This seems to be the case with both bare metal install AND Virtual Machines.

 

This week I managed to get beta5.1 running with a volume created simply by using poweroffs instead of restarts. If you just do restarts the beta 5.1 barfs on apparmor and won't recognize any disks.

 

Andrew

Link to comment
Share on other sites

So I've updated the from U4 to U7. Rebooted and found I had no volume nor disks anymore.

 

Did a shutdown -h now through ssh and manually turn my N54L back on again. When it came up, I had a volume, but still no disks.

Another reboot fixed all problems. Volume and Disks were back and healthy.

 

Permissions and ownerships were still in place.

Link to comment
Share on other sites

Ok i am starting to get gun-shy of DSM upgrades.

 

I just reinstalled my DSM to 4493 and did the update to 7. The thing restarted and i saw the post go all the way to "checking upgrade file", and then "post init" and there it sat for 20 minutes

 

I started having flashbacks to Sunday when I couldn't do anything to get my NAS to start. Anyway I physically powered down and then started it back up. and it came up after a few seconds at the "post init" screen.

 

Anyway I am going to do several restarts to see how they post before reinstalling all my files

Link to comment
Share on other sites

The links to download the .pat files from xpenology.nl started doing this since Poechi moved to a new provider, I am sure he is working on it.

 

Actually, the .pat files you need are exactly the same as the original synology ones, available at ukdl.synology.com, Poechi doesn't modify them in some way to make them work with xpenology (he told me his download link is supposed to refer to the synology ones).

 

Andrew

Link to comment
Share on other sites

  • 3 weeks later...

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...