On Mon, Jan 9, 2012 at 3:41 AM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Mon, Jan 9, 2012 at 4:58 AM, Jonathan Vasquez <jvasquez1011@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.
I guess my adventure to boot / without initrd has come to an end.. -_- I was studying the mkinitcpio code.. I have to say, shoutouts to the 4 devs.. you did a great job, my code would not even be close to that. -- Jonathan Vasquez