Hey kids–
I have been frustrated quite frequently lately by the “no touchy!” nature of the Gen2 mycloud’s firmware, and am considering a somewhat dangerous/radical modification to my unit. Specifically, I am intending to do the following, but first a rundown of how Gen2 boots. I have no interest in mucking with the kernel image or the initrd, just to be clear. (I would like to USE my nas, not brick it.)
Early in the boot process, the gen2 firmware pushes several important system values to various locations in /proc, mounts a cramfs container from /boot, then passes execution there using /etc/rc.sh
#!/bin/sh
MOUNT_CMD="busybox mount"
UMOUNT_CMD="busybox umount"
${MOUNT_CMD} -o remount -w %root% /
echo "** Mounting /etc/fstab"
${MOUNT_CMD} -a
${UMOUNT_CMD} /proc
${UMOUNT_CMD} /usr/local/modules
sleep 1
${MOUNT_CMD} -t proc proc /proc
${MOUNT_CMD} -a
# Cgroup support
CGROUP_ROOT=/sys/fs/cgroup
${MOUNT_CMD} -t cgroup -o rw,memory,cpu cgroup ${CGROUP_ROOT}
echo 8192 > /proc/sys/vm/min_free_kbytes
echo 4096 > /proc/sys/net/core/somaxconn
echo 16777216 > /proc/sys/net/core/wmem_max
echo 16777216 > /proc/sys/net/core/rmem_max
echo 163840 > /proc/sys/net/core/wmem_default
–break–
echo 163840 > /proc/sys/net/core/rmem_default
echo 3000 > /proc/sys/net/core/netdev_max_backlog
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog
#echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo /sbin/mdev > /proc/sys/kernel/hotplug
mdev -s
touch /dev/mdev.seq
#for judge kernel or ramdisk if error
#mknod -m 777 /dev/REG c 88 0
#busybox insmod /lib/modules/reg.ko
#ubiattach /dev/ubi_ctrl -m 5 -O 2048
sync
sleep 1
–break–
#${MOUNT_CMD} -t ubifs ubi0:config /usr/local/config
mkdir -p /boot
${MOUNT_CMD} -o rw /dev/sda3 /boot
#sleep 1
#${MOUNT_CMD} -t squashfs -o loop /boot/boot/image.cfs /usr/local/modules
if [ ! -e /usr/local/config ]; then
mkdir -p /usr/local/config
fi
mount /dev/sda7 /usr/local/config
chk_image
/usr/local/modules/script/system_init
Now, the total size of the cramfs’s contents is smaller than the free space on the persistent config partition (HD_a7).
root@WDMyCloud /etc # df
Filesystem 1K-blocks Used Available Use% Mounted on
%root% 55529 33817 18845 64% /
/dev/ram0 55529 33817 18845 64% /
mdev 257248 32 257216 0% /dev
/dev/sda3 999576 211756 761116 22% /boot <--- Free space on /boot! *squee*
/dev/sda7 999576 1616 971256 0% /usr/local/config <----approx 1Gb free!
/dev/loop0 102144 102144 0 100% /usr/local/modules <---Approx 100mb used!
tmpfs 1024 0 1024 0% /mnt
tmpfs 40960 5632 35328 14% /var/log
tmpfs 102400 1760 100640 2% /tmp
/dev/sda4 951192 3600 931208 0% /mnt/HD_a4
/dev/sda2 3837304328 442537388 3355764440 12% /mnt/HD/HD_a2
This means we should be able to create a folder inside /usr/local/config, and completely mirror the contents of the cramfs container into it, then replace the cramfs container with a hyper minimal one that JUST contains the system_init script, with some changes at the very beginning for housekeeping purposes.
So, we want it to do the following:
unmount the cramfs container from /usr/local/modules, so that our dummy container is out of the way. Mount -o bind our /usr/local/config/cramfsmirror at /usr/local/modules so that our writable surrogate is in the expected place, then perform some root filesystem cleanups, like putting in symlinks for important things in /etc to /usr/local/config before any system daemons get started then:
continue normally
This would allow changes made after the system is fully up to become “persistent”, in as much as those changes will get restored after a reboot, and before system daemons start. This includes changes to the dashboard UI, and pals, as well as (theoretically) the crontab, and other things.
I think I can automate the entire process of performing this kind of modification using the USB startup script method, so that I can distribute a .zip for the USB stick’s contents, which when inserted at boot, will do the needful (clone existing cramfs contents to the new location [tar is present, so we can use it through some pipes to keep ownership and permissions intact, instead of using cp], unmount the cramfs container, rename the container’s file (deletion seems unnecessary), copy the new dummy one over, then gracefully down the nas). Remove the stick, then power on-- persistent system mods enabled.
Any thoughts or suggestions before I dig into this tomorrow?
We just need to do the needful, unmount the old container (so it is not in use), rename the container file, and copy the new one on. Bob’s your uncle.
