[arch-general] Removing initrd (For use with GRUB2, LVM, GPT)

[Jonathan Vasquez]

>> When I compiled my custom kernel (from upstream, and yes I did enable
>> device mapper support compiled into the kernel, I've also experimented
>> with it as a module), the kernel fails to see the / partition.
>
> Short answer: It's not possible. The kernel is unable to scan for LVM
> and activate it, all of this is done by a userspace program (lvm). There
> is no intention or reason to change this. If you want to enable LVM in
> Linux before mounting /, you need initramfs.

Right. What I was wondering is that since I don't want to scan for LVs
and I know the direct path inside the LVM for the partition I want,
why wouldn't compiling dm-mod directly into the kernel, and specifying
the root= path to the LV path not work? Since scanning is not
important, and the path is provided, shouldn't the kernel say "Hey, I
don't know how to scan, but I can read LVMs since you compiled it into
me, and you gave me the direct path, so I will just read the LVM and
go in it"?

> Of course not. Grub has no way of passing the necessary information to
> Linux, and the device mapper can only be configured from inside Linux,
> not by boot parameters.

I figured that out the hard way haha (Experimentation).

>> So that the /init script
>> inside the initrd does what it needs (like `vgchange -a y` then
>> mounting /dev/arch/root as newroot and transferring control back to
>> the kernel with that new root parameter).
>
> Wrong.
>
> This is how the old 'initrd' used to work. The initrd script (called
> /initrc back then) would use some barely documented way to tell the
> kernel the new root device and terminate. The kernel would then do the
> initialization.
> Newer versions of initrd used pivot_root and chroot/exec to do this task
> themselves, but this has also been abandoned.
>
> Nowadays, initramfs is used - initramfs is an archive which is extracted
> into memory, then /init is called. /init is responsible for mounting /,
> deleting the contents of initramfs from memory and calling the real init
> binary. After the kernel calls /init, control is never transferred back
> to the kernel. If you would terminate /init, the kernel would panic.

Hmm I almost had it then :). So with initrd, the script returns back
to the kernel, while with the initramfs, it's linear, and never
returns to the kernel.

>> I guess what I need to do is rethink my partition layout because I
>> cannot see a way to boot my root LVM partition without initrd, without
>> doing a few things.
>
> There is no way.

What I mean't by this was that in order not to use an initramfs, I
would have to redo my layout. The layout I was thinking about that
would not need an initramfs is on the second image link.

/dev/sda1 BIOS Boot Partition
/dev/sda2 /boot
/dev/sda3 /
/dev/sda4 LVM
-----------> /usr, /var, /tmp, /opt, /home

>> The point of the above set up is to minimize real partition usage, and
>> maximize lvm usage for the benefits of flexibility (involving
>> resizing, shrinking, and adding more space) without the need for
>> initrd. In term simplifying the entire system.
>>
>> There are of course other ways to simplify the system, and I'm not
>> against using initrd in any way, but it's something that I would not
>> want to use, or learn not to be dependent on.
>
> The benefit of LVM outweighs any disadvantages an initramfs might have.
>
> Btw, there are nowadays many more reasons why using an initramfs is
> preferred. By depending on initramfs, you can simplify system
> initialization greatly. In the future, it is likely that booting a Linux
> system without initramfs will only be possible in very simple cases - at
> least that is the direction we are moving towards.
>

You are correct. It simplifies it in a lot of ways, also complicates
it as well since you need an extra set of files (included in the
initramfs).

Thanks for the wonderful response. I really enjoyed reading it.

-- 
Jonathan Vasquez