HommiePeter

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About HommiePeter

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 ?
  2. 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 th
  3. 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/modu
  4. 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....
  5. 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 followi
  6. 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 (
  7. 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 < ./l
  8. 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
  9. 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 Jman
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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)??
  15. New DMS 5.1 Toolchains are available .... http://sourceforge.net/projects/dsgpl/files/DSM%205.1%20Tool%20Chains/