| |||||||||||||
The case for the /usr mergeThe case for the /usr mergePosted Jan 27, 2012 22:32 UTC (Fri) by gb (subscriber, #58328)In reply to: The case for the /usr merge by misc Parent article: The case for the /usr merge
Oh, seem i touched topic which is very heavy, and largely off-topic for the article...
initramfs: without it, a *lot* is impossible. No heavily modular kernels. No rootfs on LVM. No rootfs on md/RAID. No rootfs on any other filesystem requiring userspace involvement to mount. No rootfs over the network (sounds silly for most machines until you have a disk failure and can revive the system, temporarily mounting everything over the network, with a one-line change). The list goes on and on. And the cost of the initramfs? These days, nearly nil.
Sure. It's not avoidable for it's purpose, i see no other way than loading two files with bootloader, it just seems pity for me that where is no simplier way to solve problem of unaccessible /. Sidenote, you CAN have / on mdraid without initrd, kernel can autodetect / array and run init from mounted lets say /dev/md0, modularity of kernel is almost not impacted too because you can put all modules on /, only modules you really need in initrd are modules to mount your /, ie fs module, hdd device module and partition style support.
But i meant a bit different thing talking about / contents in initrd. i meant that it's so less natural to edit it than normal files on / that such rescue tools location seems inappropriate.
(Log in to post comments)
The case for the /usr merge Posted Jan 27, 2012 22:59 UTC (Fri) by nix (subscriber, #2304) [Link]
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.
The case for the /usr merge Posted Jan 27, 2012 23:19 UTC (Fri) by gb (subscriber, #58328) [Link]
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.
initramfs Posted Jan 28, 2012 12:22 UTC (Sat) by bjartur (guest, #67801) [Link]
You should be able to mess with initramfs gzipped CPIO archives just fine.
IMO initrd/initramfs is a great thing for portable operating systems such as live CDs and installers, because there is no way they can know in advance what hardware they might need to support before they are booted. And having an emergency kernel and rootfs populated with recovery tools could easily come in handy.
On regular, fairly static systems, where you don't replace your MBR with a GPT or a BSD disklabel after every other reboot, you can compile the stuff you always need into the kernel image and load additional modules lazily. But if disks and video cards vary from boot to boot, initramfs might actually be considered an optimization, allowing you to disable module unloading and use userspace tools to aid boot.
But none of this is why mainstream distros use initramfs. The actual reason is that they insist on distributing kernel binaries, but are OK with users assembling initramfs images. And who can blame them, compiling kernels takes CPU time.
|
|||||||||||||