HommiePeter

Dear Sebj thanks very much for this (although it is strange that to my experience the some .ko files (amongst others synoacl_vfs.ko is not made during the build process of a 5.1 kernel....). Could you make them available in a tar of zip file on this forum ?

The easiest way I've found to crack open the NanoBoot Image is to mount it in Linux. The build scripts on Sancome's Git Repository are a big help. Here is the line that mounts the IMG file: mount -o loop,offset=32256 Synoboot_5.0-4458_x64_3612xs.img /mnt/img Once the Image is mounted you can navigate to it just like any other device or directory: cd /mnt/img Just remember to unmount when you're done: umount /mnt/img Your changes will be reflected in the Image file that you mounted. As for separating the kernel & ramdisk, they are already separated within the Boot Image. The 'zImage' file is the kernel and the 'rd.gz' archive is the ramdisk. If you are looking for more details about how the Image file is built you should check out the '02-build-img-file.sh' in Sancome's Git Repository. Jman, thanks for your feedback but that is indeed all based in the image that is included in the build environment. What i mean is the Nano boot images that you can download here http://www.xpenology.nl/boot-images/#IMG (choose IMG (USB image voor installatie op hardware) i use 5.0.3.2.). If you mount that images only a zImage and a boot folder is presents. No ramdisk (rd.gz) file seems to be present (also no other partition where it is stored on). But this version allows you to install a 5004 pat file.

Dear Jman420, Indeed a interesting thought which has crossed my mind as Well but i have not figured out yet how to separate the ramdisk from the kernel with nanoboot his images. Furthermore Nanoboot 5.0.3.2 installs the 5004 pat file (correctly, installation procedure ends without errors) but on the reboot it states no volumes mounted. Any suggestions on how to crack the nanoboot image open ? Ps could anyone with a official 5.1 installation provide us with a file dump of the dmesg and messages log files right after booting up ? And show us the result of ls *syno*.* in the lib/modules folder. Thanks in advance

Hmmmm which boot image did you use kali ? What i find strange is that nano boot 5.0.3.2. installs 5004 pat files without any problem so where are we missing the issue....

Guys i think with the new release(s) synology changed the way the handle Access Control lists on the EXT4 drivers. -> If i use the current kernel build (with the enhancement of also coping a synoacl_vfs.ko in the image the system boots normal on a 4493 installation of DSM. Once a go to install/de-install modus the installations does indead fail. Strangely is the fact that Nanoboot 5.0.3.2. does allow you to install 5004, without any errors. Booting 5004 with the new build images leads to the normal error and the unmounting of all volumes. In the messages log one can read the following. [ 2.999826] synoacl_vfs: Unknown symbol __vfs_setxattr_noperm (err 0) [ 29.121477] thermal_sys: exports duplicate symbol generate_netlink_event (owned by kernel) insmod: can't insert '/lib/modules/thermal_sys.ko': invalid module format Dec 24 15:47:08 DiskStation kernel: [ 29.250561] processor: exports duplicate symbol acpi_processor_get_bios_limit (owned by kernel) insmod: can't insert '/lib/modules/processor.ko': invalid module formatinsmod: can't insert '/lib/modules/synoacl_vfs.ko': unknown symbol in module, or unknown parameter Dec 24 15:47:09 DiskStation kernel: [ 30.243642] synoacl_vfs: Unknown symbol __vfs_setxattr_noperm (err 0) if you look a the original kernel parameters you see CONFIG_EXT4_FS=y CONFIG_EXT4_FS_XATTR=y # CONFIG_EXT4_FS_POSIX_ACL is not set # CONFIG_EXT4_FS_SECURITY is not set # CONFIG_EXT4_DEBUG is not set Inclusion of the SYNO_ACL for EXT is no longer there. Giving the impression that access controle is handled via eXtended Attributes.... CONFIG_EXT4_FS_SYNO_ACL=y Maybe this is the explanation why the volumes are not mounting.

He Jman in /var/log/dmesg you can find detailed information on the boot process (cat dmesg) of for the last boot you can type dmesg as command After booting the new build image that is based on your excellent work (i found the following maybe interesting logging entries see synoacl warnings) [Tue Dec 16 14:38:00 2014] EXT4-fs (dm-0): synoacl module has not been loaded. Unable to mount with synoacl, vfs_mod status=-1 [Tue Dec 16 14:38:07 2014] EXT4-fs (sdu1): synoacl module has not been loaded. Unable to mount with synoacl, vfs_mod status=-1 [Tue Dec 16 14:38:00 2014] EXT4-fs (dm-0): synoacl module has not been loaded. Unable to mount with synoacl, vfs_mod status=-1 [Tue Dec 16 14:38:00 2014] EXT4-fs (dm-0): barriers disabled [Tue Dec 16 14:38:00 2014] EXT4-fs (dm-0): mounted filesystem with writeback data mode. Opts: usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl,data=writeback,oldalloc [Tue Dec 16 14:38:07 2014] EXT4-fs (sdu1): synoacl module has not been loaded. Unable to mount with synoacl, vfs_mod status=-1 [Tue Dec 16 14:38:07 2014] EXT4-fs (sdu1): mounted filesystem without journal. Opts: nodelalloc,synoacl,data=ordered,oldalloc [Tue Dec 16 14:38:07 2014] netlink: 12 bytes leftover after parsing attributes. [Tue Dec 16 14:38:08 2014] init: crond main process (10465) killed by TERM signal [Tue Dec 16 14:38:09 2014] init: sshd main process (10608) terminated with status 255 [Tue Dec 16 14:38:09 2014] init: httpd-user main process (13599) killed by TERM signal [Tue Dec 16 14:38:10 2014] eth0: no IPv6 routers present [Tue Dec 16 14:38:14 2014] netlink: 12 bytes leftover after parsing attributes. [Tue Dec 16 14:38:15 2014] loop: module loaded [Tue Dec 16 14:38:15 2014] init: smbd main process (14114) killed by TERM signal [Tue Dec 16 14:38:19 2014] md2: detected capacity change from 55165779968 to 0 [Tue Dec 16 14:38:19 2014] md: md2: set sda5 to auto_remap [0] [Tue Dec 16 14:38:19 2014] md: md2 stopped. [Tue Dec 16 14:38:19 2014] md: unbind [Tue Dec 16 14:38:19 2014] md: export_rdev(sda5) [Tue Dec 16 14:38:19 2014] md: md1 in immediate safe mode [Tue Dec 16 14:38:19 2014] md: md0 in immediate safe mode [Tue Dec 16 14:38:19 2014] init: dsm-services main process (12124) killed by KILL signal [Tue Dec 16 14:38:19 2014] init: tty main process (12400) killed by KILL signal [Tue Dec 16 14:38:19 2014] init: tty main process ended, respawning [Tue Dec 16 14:38:19 2014] init: before-halt main process (16460) killed by KILL signal [Tue Dec 16 14:38:21 2014] init: rc-sysinit main process (16517) terminated with status 255 Further more there is /var/log/scemd.log for internal synology logging which might be interesting.

Dear Andrew i did the following 1) i extracted the the toolchain tar file and copied the /linux-3.x folder to the workspace folder that is needed by the Sancomes rep 2) i have adjusted the the 01-unzip-linux-3.x.sh script to work with the fact that a ./linux-3.x folder is already present. I there for extend the else clause of the second if statement with else echo "\033[41;37m The linux-3.x folder already exists. patching existing \033[0m" cp -p ./xpenology/patches-linux-3.x/linux-3.x-xpenology-4418.patch ./workspace/ cd workspace patch -p0 < ./linux-3.x-xpenology-4418.patch rm -f linux-3.x-xpenology-4418.patch cp -p ../xpenology/.config ./linux-3.x/ cd ../ 3) Executed than steps a (run ./01-unzip-linux-3.x.sh) and make commands (and not changing any settings in the menu config because the config settings are part of the sancomes rep so did not want to mess with that yet) cd ./workspace/linux-3.x make ARCH=x86_64 CROSS_COMPILE=../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- menuconfig make ARCH=x86_64 CROSS_COMPILE=../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- modules make ARCH=x86_64 CROSS_COMPILE=../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- bzImage 4) I copied and rename the synobios.ko for branche 5004 of DSM 5.1 (thanks to vortex) to the folder /xpenology/synobios/synbios-synology-5.1-5004.ko 5) i have adjusted the 02-build-img-file.sh to include the synobios (patched 5004) file. 6) Started to build the first image (became root and executed sudo su -) before starting the script 02-build-img-file.sh The script completed successfully although the patching gave somethings an error patching file rd-orig/etc/rc Hunk #1 FAILED at 479. Hunk #2 FAILED at 542. Hunk #3 FAILED at 561. Hunk #4 FAILED at 612. Hunk #5 FAILED at 636. Hunk #6 FAILED at 673. 6 out of 6 hunks FAILED -- saving rejects to file rd-orig/etc/rc.rej patching file rd-orig/etc/rc.network Hunk #1 succeeded at 76 (offset 3 lines). Hunk #2 succeeded at 90 (offset 3 lines). Hunk #3 succeeded at 115 (offset 3 lines). Hunk #4 succeeded at 313 (offset 3 lines). Hunk #5 FAILED at 962. 1 out of 5 hunks FAILED -- saving rejects to file rd-orig/etc/rc.network.rej patching file rd-orig/etc/rc.subr patching file rd-orig/etc/rc.volume patching file rd-orig/linuxrc.syno Hunk #1 succeeded at 1 with fuzz 2. Hunk #2 FAILED at 33. Hunk #3 succeeded at 48 (offset 2 lines). Hunk #4 FAILED at 166. Hunk #5 FAILED at 276. Hunk #6 FAILED at 316. Hunk #7 FAILED at 343. Hunk #8 succeeded at 318 (offset -50 lines). Hunk #9 succeeded at 353 (offset -46 lines). Hunk #10 FAILED at 410. 6 out of 10 hunks FAILED -- saving rejects to file rd-orig/linuxrc.syno.rej Burned the image on my iMac to an USB disk (according explenation in the WHO TO section of this site) and booted the image with the results mentions earlier Because i linked the outcome of the first boot result to the errors during patching in the build image script. I therefor simply deleted (put an # in front of it) the patching rules in the build image script. And builded a second image and burned it to the USB stick again but the outcome of the result was the same Also adding vid=0x0EA0 pid=0x2169 in the kernel commands in grub.conf and menu.lst did not change the outcome of the boot process. So my conclusion so far is that the patching errors are not causing the current boot result (not saying that the need to be corrected of curse). Strangely the orginale scrip op sancome contained an error in coping the synobios the wrong (non existing) file and the the kernel booted completely till the login prompt...... will reinvestigate further but tips and suggetions are of course welcome Greetings I know its al a bit straight forward but you got to start somewhere.

Hi guys i have now been compiling images with the newly published toolchains and branche code according to the nano boot script https://github.com/sancome/DSM-5.0-4458_dsgpl-4418 I have also used the new patched synobios.ko that vortex published yesterday, but i still do not have a fully booting kernel. The last message it shows is "Booting the kernel" it interacts with the available harddisks and than stops..... Booting the same disks with an earlier working nano boot USB sticks also shows nog logging records in /var/log ....... Any suggestions ? Greetings

Looks like Synology has changed the logic in SetMicropId() so the offsets have moved and the old byte signature is invalid. I'm not sure which register we need to get the Model Id into in order for it to be returned correctly. I don't have much experience or success with reverse engineering, but I've been looking at the objdump for it. Gonna experiment with some new patches later today. A couple of pages back I posted a link to another thread with some details on what needs to be patched. Its probably a good starting point, but will need to be modified for the new file. Dear Jman240 i have also been looking at and comparing the synobios,ko exports 5.1-5004, 5.0-4458 (patched) and 4.3-3872(patched) still have not found any logic in which microcode needs to be chanced to trigger the right return values. Will look at your previous post. Would be good to share thoughts. Greetings

Sorry no positive news yet. Have been cooking some images but no success jet. Have currently a new kernel in the oven (according to the script from nanoboot). Have also been looking at the synobios.ko but don't know here and what to change with regards the SetMicropId(). Text offsets do not seem to match..... puzzling (any one suggestions ...) Currently working with the patched version for branche 4458

Andrew Thanks for the update i start will start downloading the new version and rebuild a new image based on the new versions. Keep you posted.... Greetings

Thank you all for the offers for testing, but the build first needs to boot correctly prior to make ik general available for testing on different hardware. In that respects the test yesterday evening where a bit disappointing on my a) ATOM 330N XPENOLOGY NAS the system booted but had no support for network and the keyboard did not work correctly b) ICore 3 XPENOLOGY NAS the system only booted after disabling my USB 3.0 in the bios but after presenting the Diskstation login promt, it shows (after a couple of seconds) is say Shutdown System..... Conclusion is that there is still some investigation to be done. Will look further this weekend. Greetings

First Image is created, doing tests tonight (lets keep our fingers crossed .pat Files has not been patched. The previous versions aren't patched either. This is done, if needed, through the boot image. For the source files from Sancome (Nanoboot) see: https://github.com/sancome/DSM-5.0-4458_dsgpl-4418 and for some instructions: http://nanoboot.eu.org/source

Is it just me or is the 5.1 Tool chain Intel x86 Linux 3.2.40 (Bromolow) the same as the 5.0 Tool chain Intel x86 Linux 3.2.40 (Bromolow)??

New DMS 5.1 Toolchains are available .... http://sourceforge.net/projects/dsgpl/files/DSM%205.1%20Tool%20Chains/