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

Jan Steffens jan.steffens at gmail.com
Mon Jan 9 03:41:43 EST 2012


On Mon, Jan 9, 2012 at 4:58 AM, Jonathan Vasquez <jvasquez1011 at gmail.com> wrote:
> 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.
>
> 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.. 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.
>
> I'm assuming this is why we need an initrd. 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).
>
> 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.
>
> Here is a few drawings I've made to think about my layout:
>
> (Current Layout)
> http://farm8.staticflickr.com/7016/6664419375_2ee9a7b794_b.jpg
>
> (Pondering Sheet)
> http://farm8.staticflickr.com/7168/6664367587_6ca149cfb3_b.jpg
>
> As you can see in the second sheet, my thoughts are as follows:
>
> Scenario 1. GRUB 2 starts, it finds /boot inside of the lvm, that then
> triggers the kernel to start, which then finds the root partition that
> is on a regular partition on the hdd, therefore no dm-mod support
> needs to be compiled directly into the kernel or to use an initrd to
> set up the environment before hand, after that happens, the init
> scripts (also /etc/fstab) load up dm-mod and load up /home which is
> inside of the lvm as well.
>
> Scenario 2. GRUB 2 starts, it finds /boot which is now on a normal
> partition, that then triggers the kernel which also finds / on a
> normal partition as well, and then the kernel triggers the systems
> init scripts, and loads up all the other partitions back into the /
> filesystem layout.
>
> 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.
>
> --
> Jonathan Vasquez

If you're not against initrd, then just keep using it. It's the
standard way of booting, not evil, and here to stay. The kernel alone
just isn't smart enough to boot from much more than a simple root
partition. And if it's modularized like our stock kernel, can't boot
alone at all (due to missing drivers).

By the way, my current setup is as follows:
sda (GPT)
- sda1: EFI System Partition (FAT), contains GRUB2, mounted at /boot
- sda2: swap
- sda3: Btrfs, mounted at /

Having grub and the kernels on the same partition simplifies the grub
configuration quite a bit.


More information about the arch-general mailing list