User: Password:
|
|
Subscribe / Log in / New account

Embedded Linux: Small Root Filesystems

Embedded Linux: Small Root Filesystems

Posted Nov 22, 2006 11:26 UTC (Wed) by nix (subscriber, #2304)
Parent article: Embedded Linux: Small Root Filesystems

One point that was perhaps not made strongly enough is that pivoting is an initrd thing *only*. initrd and initramfs are separate things and work quite differently. Notably, initrds are whole filesystem images, so once you're done with them you have to get rid of them (hence the nasty pivot_root(2) kludge, the even nastier echo-stuff-into-a-file-under-/proc kludge, and so on). None of this is necessary with initramfses, although the busybox switch_root tool remains useful (principally because deleting the contents of the initramfs would leave a shell script rather stuck when it came to chrooting into the real root filesystem).

I'd also recommend linking busybox (and anything else on your initramfs) agaisnt uClibc or some other tiny libc, and linking it statically, because when you only have one or two binaries, the savings from avoiding inclusion of unused symbols exceed the space wasted by duplicating those symbols in many binaries.

Using initramfses is particularly important for those of us who boot from filesystems that require userspace support to bring up, such as LVM or md/raid with v1 superblocks. It also means you can fsck the root filesystem *before* mounting it (it's always seemed icky and dangerous to me to fsck any mounted filesystem, and why should / be different?).

Also, the extra flexibility makes it really easy to hack in new features on demand. When I had a double disk failure earlier this year, it was a matter of a few minutes' work to bring up the network block device before mounting /; then I could distribute the RAID array containing the root filesystem partially onto another machine across the network. (Of course this was a real kludge and not desirable for long-term use: among other things, because nbd uses TCP/IP connections, whenever the remote machine rebooted, the root filesystem on the local one vanished too: but it meant I could keep running after a fashion until the disks were replaced.)

Plus, because initramfses are built into the kernel, if you have a modular kernel you don't need to worry about the modules getting out of synch with the kernel you're running. (In my experience this was a persistent headache with initrds.)


(Log in to post comments)

Embedded Linux: Small Root Filesystems

Posted Nov 26, 2006 0:31 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

initrd and initramfs are separate things and work quite differently. Notably, initrds are whole filesystem images, so once you're done with them you have to get rid of them (hence the nasty pivot_root(2) kludge ...

I don't get the distinction. First of all, there's some confusion because "filesystem image" means two different things.

On the one hand, it's the entity that you create when you mount and destroy when you unmount, and by that definition the rootfs filesystem image (which gets loaded with files from a cpio archive) doesn't seem any less whole to me than the initrd filesystem image. pivot_root() allows you to unmount an initrd filesystem, thus destroying it and freeing its memory as well as removing its names from the namespace. Why don't you need to do that with initramfs?

In its other meaning, a filesystem image is a copy of the bits that make up a filesystem, such as what the boot loader uses to convey initrd contents to a 2.4 kernel. Pivoting has nothing to do with getting rid of that kind of filesystem image. And it's equivalent to "getting rid of" the cpio archive used with initramfs.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds