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