The attached patch to generic/linuxrc adds another way to specify a root filesystem, for example "root=/dev/ram0 real_root=IMAGE=ftp://192.168.20.4/root_small.tgz". This would fetch the given tarball by running wget (needs to be enabled in the busy-config files), and unpack it into a new tmpfs mounted on /newroot, which is then used as the root filesystem. The advantage is that it allows for using rather big "ramdisks" in a very simple and quick fashion, and without touching the real initrd/initramfs. The big chunk is not downloaded by limited pxe code, but through the native linux drivers and TCP, so a 60MB image (130MB uncompressed) takes only 5 seconds or so. My own use for it is mainly in hardware testing, but I can also imagine it being useful for diskless clusters. Reproducible: Always
Created attachment 145003 [details, diff] Add tarball rootfs support The busybox wget applet should probably be enabled for all platforms if this is applied
Created attachment 169176 [details, diff] Updated patch for genkernel 3.4.10 Update to latest genkernel, also adds tmprootsize option which is passed through to the size mount option of tmpfs.
I apologize that this has taken so long, but genkernel development went on hiatus for a bit while we split off to our own development hosting. Could you rebase the patch against the repository at git://git.wolf31o2.org/projs/genkernel.git instead? We'll be using that to develop 3.4.11 and it's much easier to work with patches that apply cleanly into the repository. Thanks
Created attachment 170648 [details, diff] Bump to git version, untested
I've committed the first half of this patch (the busy-config changes). Is the tmprootsize=foo parameter really necessary? By default, a tmpfs's size is half of physical memory. I know that if you're dealing with a system with 32MB of RAM, that's not very much, but are you really using a genkernel-build kernel/initramfs on a system with 32MB RAM? :) Also, what "formats" (123, 123k, 123m, etc.) does the 'size' parameter for a tmpfs take?
I actually added this parameter after trying to run my stuff on a board with just 1GB RAM instead of 8GB boards as before and needed a quick fix when the 512M had run out. Stepping back I think I could do without it as there is a big chunk that is not part of the image itself, but loaded by the image later in the boot process, so the tmpfs could be resized before that chunk comes in. In case you wonder, it's a diagnosis/upgrade image for the boards and the "big chunk" is mostly an FPGA update toolkit :) The parameter didn't feel quite right to me either, and assuming that the above alternative works I won't miss it. The size qualifiers are found in mount(8): Mount options for tmpfs The following parameters accept a suffix k, m or g for Ki, Mi, Gi (binary kilo, mega and giga) and can be changed on remount.
Before I commit this, have you boot-tested this with current git? Also, any reason that https can't be supported? The wget in busybox should work just fine with it.
Boot-test performed, worked nicely. However I had some trouble since I usually use arguments like "console=tty0 console=ttyS0,115200n8" and output was dead after execution passed "# Redirect output to a specific tty"... Seems like busybox wget doesn't support SSL. But OTOH I can hardly imagine a situation in which one would would like boot over a insecure network.
PS: Adding keyword "Inclusion" and "[patch] " prefix to better show this bugs nature in searches...
