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

[Thomas Bächler]

Am 09.01.2012 04:58, schrieb Jonathan Vasquez:
> Hello everyone,
> 
> So I've been experimenting on removing my use of initrd and using the
> kernel directly.
> 
> My current setup is the following:
> 
> GPT, LVM, GRUB2 (So I can boot my partitions that are inside the LVM).
> 
> /dev/sda1 BIOS Boot Partition EF02 (GPT)
> /dev/sda2 Linux LVM (named arch)
> 
> /dev/arch/boot  - /boot
> /dev/arch/swap - swap
> /dev/arch/home - /home
> /dev/arch/root - /
> 
> 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.

> So I turn on my computer, BIOS starts, then GRUB2 starts, GRUB2 sees
> the /boot partition inside of the `arch` lvm because GRUB2 has support
> for it (insmod lvm), then when the kernel (which is inside the /boot
> partition inside the lvm) starts, the kernel "loses" the ability to
> find the partitions inside of the lvm. Which leads me to believe that
> GRUB2's ability to see lvm partitions doesn't carry over to the
> kernel..

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.

> rightfully so, 2 seperate applications. Then the kernel
> panics and says that I need to set the correct root= parameter. The
> parameter is set but the parameter is /dev/arch/root .. a partition
> inside of the lvm which the kernel cannot see after GRUB2 boots the
> kernel.

Correct.

> I'm assuming this is why we need an initrd.

Correct.

> 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.

> 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.

> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20120109/7203b561/attachment.asc>