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