On Sun, Jul 15, 2012 at 2:25 PM, Duncan <[email protected]> wrote: > So I have the general idea, > but doing it from an initr* with limited tools available will be > interesting. >
Dracut modules can specify any tools they need, and they will be loaded into the initramfs. Obviously you'll want to use some discretion here. > As for the tmpfs rootfs itself, I have the vague idea that I'd > "simply" (note the scare-quotes) use what's normally the initial root > that's essentially thrown away, only I'd not throw it away, I'd just > mount everything on top, keep using it, and /somehow/ ensure that > anything running from it directly terminates one way or another, so that > I don't have old processes stuck around using the mounted-over points. I suspect you could do that, but you'd probably have to change the cleanup code, and you need to keep in mind that the initramfs runs on ramfs and not tmpfs. While similar there are a few important differences. Ramfs does not support size limits, so you can extinguish all of your ram easily enough. Ramfs also does not swap, which means that any actual content in that filesystem will waste ram, whether it is used or not. Anything that writes to it could wipe out all your memory even if you have swap available. The design of ramfs is designed for simplicity rather than robustness (you can support an initramfs on a system that otherwise lacks the drivers for tmpfs. > Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently, > tho the traditional /usr/src/, /usr/local, and /usr/portage are either > pointed elsewhere with the appropriate vars or mountpoints/symlinks to > elsewhere. Of course that'd have to change a bit for a tmpfs rootfs, > since /lib64, /usr and /etc would obviously be mounted from elsewhere, > but they could still be either symlinked or bind-mounted to the > appropriate location on the single (read-only) system-filesystem. Giving it a little thought, the simplest tmpfs-based root would be one that defines a tarball as a the root. The system would create a tmpfs, extract the tarball to it, and then use the existing fstab-sys module to mount stuff on top of that. This gives you the option of actually putting some content in the tarball, or just storing an empty directory structure in it. A tarball would let you set permissions/etc and be a bit more generic than writing a custom script. If you wrote a module to do this I wouldn't be suprised if upstream let you merge it. You'd just need to define some kind of sane syntax for it (root=TAR=path...to...tarball - though how a path works with nothing mounted you'd have to define). Maybe you define the tarball at initramfs creation (as is done with fstab.sys and mdadm.conf). > > FWIW I remember being truly fascinated with the power of symlinks when I > first switched from MS. Now I consider them normal, but the power and > flexibility of bind-mounts still amazes me, especially since, as with > symlinks, it's possible to bind-mount individual files, but unlike > symlinks (more like hard-links but cross-filesystem), it's possible to > have some of the bind-mounts read-write (or dev, exec, etc) while others > are read-only (or nodev, noexec...). Yup, my /usr and /var are bind-mounts - I was following the pre-initramfs raid guide and had my root on a raid1, and wanted to keep it minimal. However, rather than having 47 individual filesystems in lvm I only defined a few and bind-mounted half the tree off of one of them. Fstab.sys seems to handle that just fine (mounting the main mountpoint first, and the bind mounts afterwards). Rich
