• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About idstein

  • Rank

Recent Profile Visitors

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

  1. The tools sources does not matter! You only need some custom gcc toolchain, if you have some sort of obscure CPU architecture. For the Intel or AMD x86/AMD64 instruction set which all most every XPenology build uses, we do not depend on these toolchains. You can compile and build the kernel with a standard gcc toolchain using if necessary cross compilation for x64 on a x86 machine or something similar. Thats no magic at all
  2. Well, I think it's beyond my skills. I first put the list of files to a text file resulting in something like this: DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV) 2113122 0x203E62 Zlib compressed data, default compression 2118901 0x2054F5 Zlib compressed data, default compression 2600084 0x27AC94 Zlib compressed data, best compression 2866326 0x2BBC96 Zlib compressed data, defa
  3. My search for the first occurrence of CPIO magic header and ending string have been rewarded with a 35 Byte large cpio package. Consequently, I believe the vmlinux contains multiple cpio sections and you have to find the right one. I've used 'binwalk' to find the correct CPIO package. As there are many false positive inside the vmlinux binary, I simply decompressed everything binwalk found.
  4. Thats what I've done to extract ramdisk from nanoboot in order to include additional driver module in it and make some changes in rc files: 1. We need to extract zImage to vmlinux bunary by using scripts/extract-vmlinux utility in kernel source tree. 2. In vmlinux binary search for cpio magic string '0707'. That will give us start of ramdisk offset. 3. In vmlinux binary search for end of cpio magic string 'TRAILER!!!'. From this we can calculate the size of cpio binary. 4. Strip cpio ramdisk binary from vmlinux by using dd utility and starting offset and size. 5. Extract files from ramdis
  5. Yet a better place would be inside rd.gz, which is an lzma compressed cpio archive. I thin the hda1.tgz is used for the SATA DOM (or only the installed synology partition) where as the rd.gz is the actual ramdisk used as rootfs during system startup of Synology systems. @Difference between nanoboot From what I see from my inspection is that it basically uses the old way of assembling a ramdiskfs. That is bundling it inside the kernel image (=zImage). See ... tramfs.txt for further details. However, there are also different boot parameters such
  6. Looking at the PAT files from DSM 5.0 respectively revision 4458 or 4493 and compare it to the most recent DSM 5.1 PATs respectively revision 5004 or 5021, you will notice a huge difference between the updater executable. They do seem to have moved out all basic C lib and BIOS, crypto stuff to H2OFFT-Lx64. In addition to that the updater lack the references to syno_dual_head (USB and SATA DOM parallel boot). Consequently, I assume they have changed the way the updater works. It has nothing to do with the kernel, that we can actually build due to GPL source code access. The update howev
  7. Could also please check the following `ll /lib/libsyno*`? I believe by inspecting a most recent PAT (5010) that there exists a new lib called libsynovfs. That could mean that they have moved the virtual file system to the user space?
  8. I've just been checking on my XPenology NAS that there is a synoacl_ext4, but there isn't diskstation> ll /lib/modules/syno* -rw-r--r-- 1 root root 23840 May 30 2014 /lib/modules/synoacl_vfs.ko -rw-r--r-- 1 root root 66416 Jun 8 2014 /lib/modules/synobios.ko Yet XPenology tries to load the kernel modules synoacl_vfs AND synoacl_ext4. diskstation> lsmod | grep acl synoacl_vfs 16275 2 Consequently, I believe formerly there has been syndical_ext4 module, but as of now it has become part of the kernel ext4 module using the kern
  9. No, that basically ensures that the path /sbin/sysctl is present and only if that's the case set the system control values. Actually, at that place I would have placed a -x for checking, that /sbin/sysctl is executable Refer to for further details.
  10. As this is a kernel image, you can not boot straight forward with it in VirtualBox. VirtualBox simulates a complete virtual machine in opposite to qemu/KVM. Consequently, it directly switches to the boot devices MBR and tries to find a bootloader which is not present in your img file. Take a look at for further details on how to package your compiled kernel image with GRUB (Legacy) to a bootable ISO.
  11. +1 There's even a standard configuration for Synology KVM builds in the kernel! But my kernel build does not seem to start. I will investigate that, if I have some time to spare. Even though it's currently possible to run DSM with decent performance on a Xen domU, virtio drivers are still missing in the Nanoboot build. That means you need to turn on Veridian virtualisation and HVM (instead of PV). Here's a cut down version of my XL configuration: builder = 'hvm' name = "synology" memory = 4096 vcpus = 2 # Nanboot image (first; read-only) and some virtual disk as boot disk t