On Tue, Mar 13, 2012 at 8:29 PM, Joshua Kinard <kumba@g.o> 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