Thanks for your great work @sgissi - works perfectly fine!
do you have any idea what’s the Part 1…4 at the beginning of the fwtable about?
is it actually necessary to pad dtb and kernel, if so by how much?
To all of you having already compiled a kernel for the MCH(D) - I disabled the ANDROID_PARANOID_NETWORK but still get socket: Operation not permitted
How much of that Android stuff can I actually disable, we’re using Debian afterall?
I also noticed that there is ony about 730MB RAM of the total 1GB. Maybe disabling some graphics support in the kernel would allow to map the rest?
From the uboot source code, the parts are totally ignored on the Monarch (WDMC Home), I didn’t read through the Pelican (WDMC Home Duo) boot code yet, likely it uses it for eMMC partitioning of some sort. I plan on removing all parts and see how the boot behaves.
On the padding, there is no need for padding from the source code side. It will be automatically padded to fill the disk sector (512 bytes). The initrd (rootfs) seems to be a different story, I tried booting from an unpadded CPIO image and, while it loaded the file from USB without problems, the kernel panicked about not finding the root filesystem. I need to experiment more on why this happens, maybe it expects enough space to decompress the file. Source code does not help at all here.
For RAM, I have disabled anything that reads Android, it boots to minimal shell without problems. I’m yet to install Debian though. Even on minimal shell, RAM is limited at 730M because a large amount is reserved on the DTB. I think it is for video in which case we can try and reduce but I don’t know if it breaks the CPU. Unfortunately no datasheet available…
I seem to have a kernel config that I can work with. I removed all of the framebuffer and sound modules, as well as all of the Android references.
All the networking options are built as modules. This way the kernel size shrunk by 25%. Running free shows a total of 750804 bytes.
I wonder if I can remove EFI and Initrd support from the kernel too…
For compilation I used gcc-4.8 from the Debian Jessie repository (native on the device).
I commented quite a lot in drivers/net/ethernet/realtek/r8169soc.c and drivers/rtc/rtc-rtd1295.c to make all of the constant debug messages go away.
I still get ping: socket: Operation not permitted working as an unprivileged user (and I no longer have that Android_Networking_group_restriction option). Haven’t seen this before - will continue to investigate.
(OK, this was probably caused by my install method - tar doesn’t copy the capabilities… setcap cap_net_raw+ep /bin/ping)
(And I didn’t use any padding before writng Kernel and DTB to disk - works without, just as @sgissi pointed out).
Thanks for that! I went the opposite way for the kernel and have no modules. All the options I need are compiled in. The kernel turned out at 14M out of the 32M allocated in the disk. EFI is safe to remove but initrd isn’t. When booting, a minimal initrd from the rootfs partition mounts the right partitions and then switch_root to boot the OS (Debian/Alpine/Arch/etc). If you have a patched uBoot where you can edit the bootargs to select the SATA disk as root, then you could do away with initrd. In any case, the RAM disks are released shortly after. The bulk of the missing RAM comes from “reserved” memory, likely somewhere in the DTB, I suspect the ION part.
I did remove all parts from the table, it is indeed not used for anything. Looking at the Pelican (WDMCH Duo) that boots from eMMC, the parts are also ignored. It seems used only when booting from NAND flash which is not the case for WD. I have updated the fwtablectl tool with the ability to remove parts, even if they are harmless.
I successfully installed Alpine today, total installed size is a little over 100Mb, this way I only use the root partition on sda22 and have lots of spare space.
Good catch on ping, it needs access to raw sockets, setcap should fix it. Maybe bsdtar keeps the capabilities? I know Arch Linux uses it.
Lastly, no padding needed for kernel and DTB indeed. Rootfs needs padding, no idea really why.
Regarding uBoot, we just need to find out, how to specify the correct fw_env.conf to the uBoot tools package. Then we could alter the boot args.
I looked at the mtd dump, but the bootargs seem to be in a sort of filesystem, which I haven’t seen before.
Also I am thinking of modifying the RescueRootfs (which acts as the initrd) in order to take out the /usr and /var mounts. That should happen in the OS init process according to the fstab.
Except for the Golden image boot, the bootargs are hardcoded in uBoot. I don’t have the source of the 64-bit uBoot to know if it is possible to overwrite. Another option is to hardcode the args (and even the initrd) on the kernel itself.
Changing the RescueRootFS is easy. Extract the current one to a folder, edit the init script and package it up again. I built my own rescue and boot rootfs from scratch, works perfectly.
The bootargs are on the dtb file. They aren’t “harcoded” on the bootloader, if you want to change the bootargs, change the dts file (the source of the dtb) in your case it must be the monarch dts file. That’s how i make the hmcd boot with the monarch files before we had a debian install method. Also the reserved memory, and almost all hardware initialization is on the dtb, if you want to change something, you don’t need to change the bootloader at all, just change the dtb source files
How to connect from win7 to Samba on Debian?
I created Share folder, I can see it on win7, but I can;t open it.
It says that system windows can’t gain access to \WDnas\samba.
You don;t have permission to \Wdnas\samba. Contact the administrator to gain the access.
I tried to create new ueser in OMV, and log with this data, but it doesn’t work
I am very heavily considering this – but please can someone more knowledgeable than me confirm that this will not remove any of my own files from the /data/wd/diskVolume0/samba/share folder?
I didn’t see anything about the led, where I have my NAS it doesn’t bother me. Right now mine it working fine, the only thing i look into it was the fan, because the disks where too hot now that is summer. You can change the fan speed modifying /sys/devices/platform/9801bc00.rtk_fan/fan_ctrl_speed (values 1 to 10) You can look is exist something similar for changing the led
Thanks for this guide for buster upgrade… Was trying this out…
Not sure what should be copying to the usb… Is it the decompressed var & usr directories or compressed files.i tried the directories but as it’s a FAT32 filesystem the symlinks were giving errors.
So I tried with the compressed files (with their original names) used all three and ended in boot loops…
Should there be any other files in the OMV (lowercase) folder? ( Fwtable.bin, rootfs.bin or bootConfig).
Also should the other 4 files be there in the USB root directory? (Bluecore.audio, rescue.root.sata.cpio.gz_pad.img, rescue.sata.dtb, data.uimage)
I also put my compiled kernel, modules and dtb there.
You will need @sgissi 's fwtablectl for changing the fwtable.bin - it’s not going to boot otherwise!!!
