On Tue, Mar 13, 2012 at 8:29 PM, Joshua Kinard <ku...@gentoo.org> wrote: > > My contention is that I shouldn't need an initramfs loaded into my kernel to > get my system into a minimally-usable state. I've been running separate > /usr setups for 10+ years, and only now, such a setup breaks, hence my beef > with Fedora's assertion that such a setup is wrong.
I was thinking about this and here is another way to think about it. Right now you can't boot a linux kernel without a whole bunch of c/asm code in linux. That code is necessary to do arch-specific setup, locate the root device, mount it, and run init. The new model is that you can't boot a linux kernel without a whole bunch of c/asm code in linux, and a bunch of scripts and userspace code in a blob (that can potentially be part of the kernel image). You could view this as a simple refactoring of code. Instead of all the boot logic being in c/asm which is hard to tweak, now some of it is written in bash and a bunch of userspace tools. All of this can just be viewed as part of the kernel - it can even be part of the same file if you want. Obviously this isn't a perfect analogy, as a bunch of userspace tools already existed but now require the extra glue code to work (mounting /usr). Once upon a time you didn't even need grub or lilo to boot - you could just stick the kernel at the start of your boot disk and the first 512 bytes of the kernel conveniently contained a boot sector. That code actually still exists but simply tells the user to bugger_off. So, you really could just view this as another step in the evolution of the linux boot process. After seeing some of the more exotic boot processes used in ARM/etc stuff like this just doesn't throw me for much of a loop. And, if you setup dracut/genkernel appropriately it really is just one extra step to make your system bootable. Rich
