Recommended Posts

Just remove the rmmod from linuxrc / updater.sh in the initrd do the same thing.

 

I have something weird, It said the system volume has crashed, it is fixed by a reboot but sometimes it appears again...

 

I found this weird thing in messages :

 

storagehandler.cgi : raid_disk_create.c:88 failed to fopen /sys/block/md1/md/dev-sda2/slot, errno=Too many levels of symbolic links

 

Is anyone already seen that in previous DSM ? (I can't tell DSM4.3 is the first one for me).

 

NOTE : I try an upgrade to 3776.3 we will see :razz:

 

EDIT 2 : woops :smile:

 

Oct 15 21:12:22 DiskStation updater: updater.c:4197 The SynoBoot partitions exist.
Oct 15 21:12:22 DiskStation updater: updater.c:2413 SYNORedBootUpdCheckAndApply(2413): Skip bootloader update, no uboot_do_upd.sh exists
Oct 15 21:12:22 DiskStation updater: boot_lock.c(224): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6)
Oct 15 21:12:22 DiskStation updater: updater.c:4293 fail to unlock boot partition
Oct 15 21:12:22 DiskStation updater: updater.c:4537 Failed to accomplish the update! (errno = 21)

 

I will need to dig this one too.

Share this post


Link to post
Share on other sites
Just remove the rmmod from linuxrc / updater.sh in the initrd do the same thing.

 

I have something weird, It said the system volume has crashed, it is fixed by a reboot but sometimes it appears again...

 

I found this weird thing in messages :

 

storagehandler.cgi : raid_disk_create.c:88 failed to fopen /sys/block/md1/md/dev-sda2/slot, errno=Too many levels of symbolic links

 

Is anyone already seen that in previous DSM ? (I can't tell DSM4.3 is the first one for me).

 

NOTE : I try an upgrade to 3776.3 we will see :razz:

 

I had a really similar problem, with an apt-mirror binary I was trying to use. First symlink level (from /volume1/@appstore/apt-mirror/bin/apt-mirror to /bin/mirror), no other files that are used were linked, and I still got this message.

 

EDIT 2 : woops :smile:

 

Oct 15 21:12:22 DiskStation updater: updater.c:4197 The SynoBoot partitions exist.
Oct 15 21:12:22 DiskStation updater: updater.c:2413 SYNORedBootUpdCheckAndApply(2413): Skip bootloader update, no uboot_do_upd.sh exists
Oct 15 21:12:22 DiskStation updater: boot_lock.c(224): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6)
Oct 15 21:12:22 DiskStation updater: updater.c:4293 fail to unlock boot partition
Oct 15 21:12:22 DiskStation updater: updater.c:4537 Failed to accomplish the update! (errno = 21)

 

I will need to dig this one too.

 

Do we have the updater source code? If yes, we can trace the error a bit further, but it seems to be that it fails to get the synoboot partitions (maybe it is trying to do so from a hard drive, and thus it fails?). Does /dev/synoboot2 exist? Maybe we can route the initial boot USB to /dev/synoboot* somehow?

 

Or, better idea. Why not make actual bootable hard drives? I'm tired that we need a plus boot USB, maybe it could be hacked around so that we get an actual Synology setup?

Share this post


Link to post
Share on other sites

Booting on HDD is not possible as drives are parts of a raid array. I know why it failed my synoboot contains only one partition. I have to find the layout of a real synoboot and the contents.

 

We don't have the source of the updates by the way.

 

For the symlink issue it's weird as my volume is empty - fresh install -

 

I will keep you posted.

Share this post


Link to post
Share on other sites
Booting on HDD is not possible as drives are parts of a raid array. I know why it failed my synoboot contains only one partition. I have to find the layout of a real synoboot and the contents.

 

We don't have the source of the updates by the way.

 

For the symlink issue it's weird as my volume is empty - fresh install -

 

I will keep you posted.

 

Yes, there are two partitions in RAID, one for the OS itself (2 or 5GB? Can't recall), and the remaining space behind that for the actual volume.

But there are also a few extra partitions at the beginning, those are the synoboot ones. All it misses is an actual bootloader (e.g. GRUB) from the beginning.

 

By my understanding, the only problem with that is that GRUB does not like the way Synology manages the hard drives, and this causes GRUB not to be able to boot the OS (if I get it right, the problem is that all the synoboot parts are on every disk, and GRUB can't decide which one to boot, or something like that?)

Share this post


Link to post
Share on other sites
Just remove the rmmod from linuxrc / updater.sh in the initrd do the same thing.

 

I have something weird, It said the system volume has crashed, it is fixed by a reboot but sometimes it appears again...

 

I found this weird thing in messages :

 

storagehandler.cgi : raid_disk_create.c:88 failed to fopen /sys/block/md1/md/dev-sda2/slot, errno=Too many levels of symbolic links

 

Is anyone already seen that in previous DSM ? (I can't tell DSM4.3 is the first one for me).

 

NOTE : I try an upgrade to 3776.3 we will see :razz:

 

EDIT 2 : woops :smile:

 

Oct 15 21:12:22 DiskStation updater: updater.c:4197 The SynoBoot partitions exist.
Oct 15 21:12:22 DiskStation updater: updater.c:2413 SYNORedBootUpdCheckAndApply(2413): Skip bootloader update, no uboot_do_upd.sh exists
Oct 15 21:12:22 DiskStation updater: boot_lock.c(224): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6)
Oct 15 21:12:22 DiskStation updater: updater.c:4293 fail to unlock boot partition
Oct 15 21:12:22 DiskStation updater: updater.c:4537 Failed to accomplish the update! (errno = 21)

 

I will need to dig this one too.

 

 

Volume crash during reboot or sheduled power-off is known bug in 4.3

http://forum.synology.com/enu/viewtopic ... 67#p281159

http://forum.synology.com/enu/viewtopic ... 29&t=74180

http://forum.synology.com/enu/viewtopic ... 29&t=74361

Share this post


Link to post
Share on other sites

Here is my working 4.3 virtual with 'mount --rbind' pci-devices fix. Only for testing, but seems everything is working. For production please wait for neXus's /VeNoM's version. Based on Trantor's 4.3 build. Files are updated to 3776-3, boot device isn't. VirtualBox required. Default login is admin/admin.

 

https://mega.co.nz/#!ZtRTGR7K!anlF3ED9L ... gr1mn8I9zw (624.3 MB)

Share this post


Link to post
Share on other sites

Well, Dealing with autoupdates, it tries to update the bios (which failed), no idea if we can deal with as the updater process is in the PAT firmware downloaded.

 

It means, upgrade may work with synoassistant or we need to strip some informations from PAT upgrades and feed the DSM with it...

Share this post


Link to post
Share on other sites
Well, Dealing with autoupdates, it tries to update the bios (which failed), no idea if we can deal with as the updater process is in the PAT firmware downloaded.

 

It means, upgrade may work with synoassistant or we need to strip some informations from PAT upgrades and feed the DSM with it...

 

How about creating virtual devices to update? Then it would go through fine, and we wouldn't need to modify anything.

I know it is a lot more work, and I'm just brainstorming here, but that's how good ideas are born :smile:

Share this post


Link to post
Share on other sites

The process use a dedicated module inside the PAT file, and also use /dev/mem... will be hard to fool. The updater process is also inside the PAT file.

Share this post


Link to post
Share on other sites

What is in there that is so appealing compared to 4.2? Let's assume that I don't care for anything other than pure NAS functionality.

Share this post


Link to post
Share on other sites
What is in there that is so appealing compared to 4.2? Let's assume that I don't care for anything other than pure NAS functionality.

 

Extra packages (such as a working Git server), if NeXuS can solve it then continuous updates, plus the ability to install deb packages (if I got it right, 4.3 has dpkg built-in).

Share this post


Link to post
Share on other sites

Use mknod /dev/synoboot2 b major minor to partition 1 from the USB stick and the update might work.

The updater needs to find checksum.syno grub_cksum.syno on that partition.

On the test below I am missing the ROM file.

 

Oct 17 09:29:56 DiskStation43a updater: updater.c:4093 Start of the updater...
Oct 17 09:29:56 DiskStation43a updater: updater.c:4191 This is X86 platform
Oct 17 09:29:56 DiskStation43a updater: updater.c:4197 The SynoBoot partitions exist.
Oct 17 09:29:56 DiskStation43a updater: updater.c:2413 SYNORedBootUpdCheckAndApply(2413): Skip bootloader update, no uboot_do_upd.sh exists
Oct 17 09:29:58 DiskStation43a updater: updater.c:821 Kernel Version: 3.2.40
Oct 17 09:29:58 DiskStation43a updater: updater.c:901 failed to get old BIOS version
Oct 17 09:29:58 DiskStation43a updater: updater.c:4363 fail to upgrade BIOS
Oct 17 09:29:59 DiskStation43a updater: updater.c:4537 Failed to accomplish the update! (errno = 21)
Oct 17 09:30:00 DiskStation43a upgrade.cgi: smallupdate.cpp:892 failed to exec updater -r
Oct 17 09:30:00 DiskStation43a upgrade.cgi: smallupdate.cpp:1071 failed to update flash
Oct 17 09:30:00 DiskStation43a upgrade.cgi: upgrade.cpp:1303 Fail to apply small update
Oct 17 09:30:02 DiskStation43a synoindexd: synoindexd.c:66 SYNOShareEnum failed, synoerr=0xB500
Oct 17 09:30:02 DiskStation43a cupsd[15967]: [conf.c:1893] Filter "pstoraster" not found.

Share this post


Link to post
Share on other sites

Yes same stage, it loads a module in order to flash the bios and fail.

 

Edit : Monod is not needed for me a my USB stick is reconized as synoboot device.

Share this post


Link to post
Share on other sites

I'm not a programmer, but i start to follow you in "figth" with DSM4.3, can be possibile emulate bios ? build a sort of dummy dev that emulate bios flash with correct major and minor number.

If i wrote useless words please, delete :grin:

Share this post


Link to post
Share on other sites

Well it use a module in order to have direct memory access through the kernel. A binary is then used to fetch information and flash updates.

 

It is "possible" but need a lot of work.

 

I try to find a workaround...

 

EDIT :

 

As a workaround, let DSM download the files, go to /volume1/@smallupd@te_deb, un pack the flashupdate deb, replace updater with a shell script 'exit 0', repack, replace and push the button. I can easy be scriptable.

 

The flashupdate is here to update synoboot, but we don't care.

 

Note : it may break your DSM, I suggest you to try on a virtual machine before.

 

I update from 3776 to 3776-3 and everything is working fine.

Share this post


Link to post
Share on other sites

Use this from task scheduler, manual run after download update, then update.

 

sed 's/flashupdateDeb/flashupdateDeb1/' /autoupd@te.info > /autoupd@te.info1
mv /autoupd@te.info1 /autoupd@te.info

Share this post


Link to post
Share on other sites

@postdeals : Check 1 page behind, there is first "alpha" realease from k3dt.

 

Here is my working 4.3 virtual with 'mount --rbind' pci-devices fix. Only for testing, but seems everything is working. For production please wait for neXus's /VeNoM's version. Based on Trantor's 4.3 build. Files are updated to 3776-3, boot device isn't. VirtualBox required. Default login is admin/admin.

 

https://mega.co.nz/#!ZtRTGR7K!anlF3ED9L ... gr1mn8I9zw (624.3 MB)

Share this post


Link to post
Share on other sites
@postdeals : Check 1 page behind, there is first "alpha" realease from k3dt.

 

Here is my working 4.3 virtual with 'mount --rbind' pci-devices fix. Only for testing, but seems everything is working. For production please wait for neXus's /VeNoM's version. Based on Trantor's 4.3 build. Files are updated to 3776-3, boot device isn't. VirtualBox required. Default login is admin/admin.

 

https://mega.co.nz/#!ZtRTGR7K!anlF3ED9L ... gr1mn8I9zw (624.3 MB)

 

What about a image to install without vmware??

Share this post


Link to post
Share on other sites

What about a image to install without vmware??

 

 

Its easy. Install Trantor's 4.3 test build (with newer bzImage), then login into ssh and copy /proc/bus/pci into for example /root/pci and append content of my file /root/pci/devices-append to your /root/pci/devices. Then edit /etc/rc and insert mount --rbind /root/pci/ /proc/bus/pci/ after "export HOME PATH". Reboot and it should work.

Share this post


Link to post
Share on other sites

What about a image to install without vmware??

 

 

Its easy. Install Trantor's 4.3 test build (with newer bzImage), then login into ssh and copy /proc/bus/pci into for example /root/pci and append content of my file /root/pci/devices-append to your /root/pci/devices. Then edit /etc/rc and insert mount --rbind /root/pci/ /proc/bus/pci/ after "export HOME PATH". Reboot and it should work.

 

Dont you have a easier way?? :oops:

Share this post


Link to post
Share on other sites

Dont you have a easier way?? :oops:

 

The easiest known way is expensive. Buy the real device, click on the update, done. You have the latest.

Share this post


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.