idstein
-
Posts
11 -
Joined
-
Last visited
Posts posted by idstein
-
-
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.
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, default compression 3241685 0x3176D5 LZMA compressed data, properties: 0xB8, dictionary size: 2097152 bytes, uncompressed size: 807683271 bytes 3924944 0x3BE3D0 Zlib compressed data, compressed 3950308 0x3C46E4 Zlib compressed data, compressed 4084752 0x3E5410 Zlib compressed data, best compression 4205012 0x4029D4 Zlib compressed data, best compression 4321820 0x41F21C Zlib compressed data, best compression 4532468 0x4528F4 Zlib compressed data, best compression
But then I fail
. Can't seem to find the rd image or I don't know how to use dd and cpio. I've use some commands like: grep -abo 0707 vmlinux | head -n1 and grep -abo TRAILER vmlinux | head -n1 and these give me some numbers back.
I then use dd with offset to export to .cpio. But can't seem to extract the cpio.
It's beyond my skillset...
The following will automatically extract any found compressed data (including the initramfs)
binwalk -e vmlinux
-
What are the commands for below steps:
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 ramdisk using cpio.
I've got it extracted using the script, but I can't seem to find any cpio commands that makes sense.
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.
-
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.
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 ramdisk using cpio.
After making some changes to include your ramdisk files in kernel you need to do a reverse procedure:
1. Use cpio to pack files in one binary.
2. Use make config in kernel sources to set init_ramdisk to your file (somewhere in 'General kernel parameters' menu).
3. Make kernel zImage which will include your ramdisk. Put it in .IMG or simply copy it to mounted flash disk overwriting old version.
So i've just checked Nanoboot's initramfs and the scripts are a little bit different. In details:
- Kernel boot parameter upgrade replaces only some lines in /etc/VERSION instead of a complete file
- init scripts always remove /dev/synobios if present
- init scripts replace some standard Synology bin's such as scemd
You can find the compressed initramfs (gzipped) here: https://www.dropbox.com/s/xlbwzp4nmjqx7 ... fs.gz?dl=0
-
u can find it into the hda1.tgz inside the .pat
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 https://www.kernel.org/doc/Documentatio ... tramfs.txt for further details.
However, there are also different boot parameters such as upgrade= that is not present with our current available gnoboot source code. Therefore, I believe there are changes (even though probably very subtile ones) in the nanoboot source.
-
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 however, is bundled with the PAT and inaccessible for us.
So far I have had no success to modify the updater due to my lack in ASM skill. But maybe someone else can continue here. It does not contain any reference to '/dev/synoboot' nor '/dev/synoboot2'.
-
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?
-
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 kernel flag CONFIG_EXT4_FS_SYNO_ACL.
Could someone check on a real device which modules are available using `ll /lib/modules/syno*`? Thanks!
-
Looking at the patching for rc file. Am I correct that the -e command is for: Use this option to ignore errors about unknown keys.
Does this mean if it see an error it ignores it and continues a process, or if you don't use this -e command, the error is detected, not ignored and a process stops?
Just want to know if this matters or not. Or if it's just for suppressing error messages.
Example for patching rc file.
if [ -r "/etc.defaults/sysctl.conf" ]; then
+ [ -e /sbin/sysctl ] && \
/sbin/sysctl -p /etc.defaults/sysctl.conf
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 http://www.thegeekstuff.com/2010/06/bash-conditional-expression/ for further details.
-
So, I have a VM setup and manage to get though the cross compile steps and generate synoboot_5.1-5004_x64_3612xs.img.
What I don't know is what to DO with the .img file to cause a VM to boot from this.
I tried vboxmanage convert raw, but that didn't work.
How do I get from the .img file to either a bootable .iso, or a bootable .vdi or .vmdk?
Andrew
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 http://wiki.osdev.org/Bootable_El-Torito_CD_with_GRUB_Legacy for further details on how to package your compiled kernel image with GRUB (Legacy) to a bootable ISO.
-
Hi,
I was previously trying to run gnoBoot on XenServer. Any chance you could add Xen virt drivers in future build? Currently nanoboot cant find NICs and HDDs..
http://wiki.xenproject.org/wiki/Mainlin ... mU_Support
There might be another issue, virtualized HDD will be /dev/xvda.. /dev/xvdb .. etc.. instead of /dev/sda ...
If needed I can provide testing, etc..
Thank you
+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 to install apps to them disk = ['file:/etc/xen/images/nanoboot/latest.img,hda,r','file:/etc/xen/images/synology.img,hdb,w'] #boot = 'dc' vif = [ 'mac=00:16:3E:58:D7:8A,bridge=xenbr0,model=e1000' ] # No virtio tty (=console) drivers => Use VNC as a console replacement vnc = 1 # ACPI and APIC events acpi=1 apic=1 # Windows virtualization viridian =1 # PCI passthrough of an Intel SATA controller to get physical disk control xen_platform_pci=1 pci = ['00:1f.2']
New DSM BETA 5.1 4977 Available
in General Installation Questions/Discussions (non-hardware specific)
Posted
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