The case for the /usr merge [LWN.net]

The case for the /usr merge

Posted Jan 27, 2012 22:59 UTC (Fri) by nix (subscriber, #2304)
In reply to: The case for the /usr merge by gb
Parent article: The case for the /usr merge

You don't have to load two files with the bootloader to use an initramfs. They can be automatically assembled by the kernel build process and merged into the kernel image, whereupon the bootloader need not know of it at all. Most distros don't do this purely because they ship the binary over to the user but want to assemble the initramfs on the user's machine. For those of us building our own kernels, this is not a concern. In this situation you never need to edit it, either, just as you never need to edit the binary kernel image: just change its source and rebuild the kernel.

You can only have / on md/raid with in-kernel mounting if you want to use a somewhat-horrible and somewhat-deprecated v0.90 array. v1.x arrays are not supported and may never be.

to post comments

The case for the /usr merge

Posted Jan 27, 2012 23:19 UTC (Fri) by gb (subscriber, #58328) [Link] (1 responses)

Embedding mostly for embedded systems i guess, i didn't mentioned all this details just to keep post in reasonable size :)

The case for the /usr merge

Posted Jan 28, 2012 14:56 UTC (Sat) by nix (subscriber, #2304) [Link]

I find embedding really useful even for non-embedded systems, and *particularly* for heavily modular kernels in which you must load modules from the initramfs just to mount root.

The problem with a non-embedded initramfs is that it can get out of synch with the kernel it goes with, especially if it has modules in it. So you might find that you preserve your kernel for future use in case of emergency but, oops, it's useless, it has the wrong initramfs and won't boot. With an initramfs linked into the kernel image, that is completely impossible: the kernel is a single self-contained file again. And that's a very valuable property.