Am 2017-07-26 09:55, schrieb Tobias Doerffel:
May I ask what you changed? Because if it's something that could
be interesting to other users this might be added to the package
in general. Also, as I'm upstream for it, I'm always a bit curios what
use cases people have for the package.
The use case for us is to implement a (read-only) live system boot for
an embedded system. For this to work we need to mount a tmpfs, mount a
vfat partition which contains the rootfs as squashfs image, mount the
squashfs image and merge it with the tmpfs via overlayfs into the
final root - nothing the kernel is able to do OOTB. The required
changes to tiny-initramfs are very specific (filenames, paths etc.)
thus likely not suitable for upstream.
But the general principle does sound like a use case that other
people might also have. As I said in the upstream README: especially
for embedded applications I'd be interested in adding support for
things people do in that field.
So to recap in a more generic sense, you'd need (from the top of my
head):
- support pre-mounting arbitrary things an arbitrary amount of
times (1. mount vfat, 2. mount squashfs, 3. mount tmpfs)
- loopback support for mounting the squashfs image
I think this could easily be implemented generically (without
using too much space) in the following manner:
- initramfs CPIO archive must contain directories where the
stuff is mounted to
- parse an option tirfs.premount=what:/where:type:options (name
subject to bikeshedding) from the kernel command line
Then you could do the following:
- add /vfat /squashfs /tmpfs /tmpfs.work to the initramfs CPIO
archive
- pass the following additional command line options to the
kernel:
tirfs.premount=/dev/somedevice:/vfat:vfat
tirfs.premount=/vfat/squashfs.image:/squashfs:squashfs:loop
tirfs.premount=none:/tmpfs:tmpfs:size=...
tirfs.premount=none:/tmpfs.work:tmpfs:size=...
root=overlay rootfstype=overlay
rootflags=lowerdir=/squashfs,upperdir=/tmpfs,workdir=/tmpfs.work
And then it should just work.[tm]
(I wrote this down off the top of my head, there are likely some
details that aren't right there.)
If I added this kind of generic support to tiny-initramfs, would
that be useful to you?
We used initramfs-tools with a
custom local script before but this generated a 2 MB initrd whereas
the size with tiny-initramfs is just 10 KB :-)
:-)
Regards,
Christian
