[arch-general] Removing initrd (For use with GRUB2, LVM, GPT)
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
Btw, If I do decide to go with the alternative layout, then I ask myself what is the point of complicating my life and using GRUB2? If the /boot and / will be on physical partitions, the only reason I see to use GRUB2 is for the official GPT support (as oppose to GRUB-Legacy patched GPT support). -- Jonathan Vasquez
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.
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
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.
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
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
So for the past few days I've been working on removing the initram, how the it works, the kernel, booting process, MBR, etc and I successfully managed to remove the initramfs. So Arch works, it ends up booting to the desktop, and all that good stuff. Although, without the initramfs, I noticed that when I boot my computer, I don't get any of the messages that Arch normally throws out "Welcome to Arch" , "Staring udev", etc etc. It's just a blank screen until it reaches kdm. When I go to shutdown, I do see these output messages, of when it's stopping the services etc. I checked the /etc/rc.sysinit, and the other rc files and functions, and I see that Arch is really integrated with the use of initramfs. Is this a good thing? Shouldn't the use of an initramfs be optional? (Sure a person can decide to use it to take the extra benefits, but should the initramfs be integrated enough into the system where the output messages don't get displayed?) -- Jonathan Vasquez
On Thu, Jan 12, 2012 at 3:00 AM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
but should the initramfs be integrated enough into the system where the output messages don't get displayed?)
I think the initscripts produce what you see while booting and shutting down. Is there anything written to your /var/log/boot ?
On Wed, Jan 11, 2012 at 10:41 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
On Thu, Jan 12, 2012 at 3:00 AM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
but should the initramfs be integrated enough into the system where the output messages don't get displayed?)
I think the initscripts produce what you see while booting and shutting down. Is there anything written to your /var/log/boot ?
Yup they are. But I believe they are depending on the initramfs, because without it, it doesn't show the Arch messages. With initramfs (created for my kernel, default hooks, nothing else): http://twitpic.com/867uyh Without initramfs: http://twitpic.com/867vss My kernel is monolithic, but I've enabled initramfs support for the purposes of the Arch messages. It also has module support for modules I built outside of the kernel like nvidia and virtualbox. dmesg.log: http://paste.pocoo.org/show/533609/ crond.log http://paste.pocoo.org/show/533610/ Here are the messages for the boot screen (/var/log/boot): http://paste.pocoo.org/show/533611/ Everything is pretty much working (sound, graphics, microphone, camera, etc). I just have to fix my suspend which works in Gentoo but not in Arch. I'm probably missing something, but that is another issue. -- Jonathan Vasquez
Btw, for the first picture, it says that /usr is not mounted. I believe that is because my /usr in in /dev/mapper/arch-usr and that doesn't get mounted until later in the boot process. -- Jonathan Vasquez
On Wed, Jan 11, 2012 at 11:01 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Btw, for the first picture, it says that /usr is not mounted. I believe that is because my /usr in in /dev/mapper/arch-usr and that doesn't get mounted until later in the boot process.
-- Jonathan Vasquez
Is there any way to choose when to load specific stuff? In gentoo you could do this by selecting a runlevel by name (sysinit, boot, default, shutdown). I don't know if this is possible in Arch. -- Jonathan Vasquez
On Thu, Jan 12, 2012 at 5:03 AM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Is there any way to choose when to load specific stuff? In gentoo you could do this by selecting a runlevel by name (sysinit, boot, default, shutdown). I don't know if this is possible in Arch.
Not sure if that's what you're asking about but https://wiki.archlinux.org/index.php/Runlevels You can create and use your own too.
On Wed, Jan 11, 2012 at 10:01 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Btw, for the first picture, it says that /usr is not mounted. I believe that is because my /usr in in /dev/mapper/arch-usr and that doesn't get mounted until later in the boot process.
On Wed, Jan 11, 2012 at 10:03 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Is there any way to choose when to load specific stuff? In gentoo you could do this by selecting a runlevel by name (sysinit, boot, default, shutdown). I don't know if this is possible in Arch.
imo, you're headed down a path that will just lead to frustration, and is reliant on legacy models/codepaths. *why* do you want to avoid initramfs? it's use enables the kernel to accommodate even the most esoteric setups ... no gain in dropping it, unless you are using it for embedded devices, and even then it's useful. the initramfs does some initialization of the environment, and the various scripts that generate it try to include all sorts of stuff. you may be seeing a black screen because the kernel verbosity is too low or never set, or maybe you pulled a KMS driver into the initramfs in the past ... difficult to know ... maybe udev was probing something you forgot about. the kernel wants to be as dumb as possible about the ridiculous stuff userspace wants to do, and i fully expect the kernel to be dumbed down even further ... i personally don't think the user should have an [official] choice to drop initramfs; IIRC, some modules can't even be built into the kernel because they are mutually exclusive with other variants (symbol clashes), and userspace must decide which should be included. what is the motivation exactly? my grub2 GPT partition is ~128MiB, kinda big, but that still only represents 1/600th of my small, 60GiB disk. what is the benefit you seek? recompiling the kernel to switch from an ext4 to btrfs root sounds pretty annoying to me ;-) -- C Anthony
On Wed, Jan 11, 2012 at 11:19 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
On Wed, Jan 11, 2012 at 10:01 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Btw, for the first picture, it says that /usr is not mounted. I believe that is because my /usr in in /dev/mapper/arch-usr and that doesn't get mounted until later in the boot process.
On Wed, Jan 11, 2012 at 10:03 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Is there any way to choose when to load specific stuff? In gentoo you could do this by selecting a runlevel by name (sysinit, boot, default, shutdown). I don't know if this is possible in Arch.
imo, you're headed down a path that will just lead to frustration, and is reliant on legacy models/codepaths. *why* do you want to avoid initramfs? it's use enables the kernel to accommodate even the most esoteric setups ... no gain in dropping it, unless you are using it for embedded devices, and even then it's useful.
the initramfs does some initialization of the environment, and the various scripts that generate it try to include all sorts of stuff. you may be seeing a black screen because the kernel verbosity is too low or never set, or maybe you pulled a KMS driver into the initramfs in the past ... difficult to know ... maybe udev was probing something you forgot about. the kernel wants to be as dumb as possible about the ridiculous stuff userspace wants to do, and i fully expect the kernel to be dumbed down even further ... i personally don't think the user should have an [official] choice to drop initramfs; IIRC, some modules can't even be built into the kernel because they are mutually exclusive with other variants (symbol clashes), and userspace must decide which should be included.
what is the motivation exactly? my grub2 GPT partition is ~128MiB, kinda big, but that still only represents 1/600th of my small, 60GiB disk. what is the benefit you seek? recompiling the kernel to switch from an ext4 to btrfs root sounds pretty annoying to me ;-)
--
C Anthony
Simplicity and minimalism would be what motivates me the most. If I don't need an initramfs to get my system boot up, why have one? I know the benefits that initramfs provides, but I don't need any of them. All I need my computer to do is start, find the kernel, boot my comp to the terminal or X11 (depending on my setup). My set up atm that lets me have GPT, GRUB2, LVM, all without needing initramfs, and future proofs me the need to move the physical partitions in the drive (not the logical ones inside the lvm) is: /dev/sda1 BIOS Boot Partition 32M /dev/sda2 /boot ext2 100M /dev/sda3 / ext4 2G /dev/sda4 Linux LVM (name: arch) Created in a (read most, write last order .. if it matters inside LVM) /dev/arch/swap 2G /dev/arch/usr 10G /dev/arch/tmp 10G /dev/arch/opt 5G /dev/arch/var 10G /dev/arch/home 500G 400G Free in LVM Pool -- Jonathan Vasquez
On Wed, Jan 11, 2012 at 10:29 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Simplicity and minimalism would be what motivates me the most. If I don't need an initramfs to get my system boot up, why have one? I know the benefits that initramfs provides, but I don't need any of them. All I need my computer to do is start, find the kernel, boot my comp to the terminal or X11 (depending on my setup).
well, i hear ya, but i'd argue you already *have* the minimalist setup ... life is about balance friend :-) i'm not sure too many would agree (my time is more important that pedantic minimalism) hence support may be hard to come by. although, this paragraph is backed by little more than imaginary statistics and [possibly misguided] intuition.
My set up atm that lets me have GPT, GRUB2, LVM, all without needing initramfs, and future proofs me the need to move the physical partitions in the drive (not the logical ones inside the lvm) is:
/dev/sda1 BIOS Boot Partition 32M /dev/sda2 /boot ext2 100M /dev/sda3 / ext4 2G /dev/sda4 Linux LVM (name: arch)
... because you desire to drop the initramfs, you've lost the ability to manage / with LVM2, and that sux. 2GiB *might* be enough, never was nearly enough for me (though, i reject the idea of oodles of partitions) ... but what if it's not? by generating a teeny 4Mib file, you're / moves to LVM2, and you never have to rebuild the kern if you change FS, change hardware, change <insert here> ... dunno, nice trade off to me ... won't say anything further about it ;-)
Created in a (read most, write last order .. if it matters inside LVM) /dev/arch/swap 2G /dev/arch/usr 10G /dev/arch/tmp 10G /dev/arch/opt 5G /dev/arch/var 10G /dev/arch/home 500G
btw, if swap is on LVM2, you'll want to flag it contiguous (-Cy on `lvcreate`) if you didn't already. also, not sure if you need it, but hibernation will be impossible without initramfs if swap is on LVM2. lastly, be aware that a separate `/usr` is rapidly degrading into a next-to-unsupported/awkwardly-handled configuration ... while a lack of initramfs avoids the need to mount it pre-root, you may still have issues during early boot ... especially since soon, if not now, Arch initscripts will fully expect `/usr` to be available before pid 1 (Tom or someone else would need to confirm this). -- C Anthony
On Thu, Jan 12, 2012 at 12:36 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
On Wed, Jan 11, 2012 at 10:29 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Simplicity and minimalism would be what motivates me the most. If I don't need an initramfs to get my system boot up, why have one? I know the benefits that initramfs provides, but I don't need any of them. All I need my computer to do is start, find the kernel, boot my comp to the terminal or X11 (depending on my setup).
well, i hear ya, but i'd argue you already *have* the minimalist setup ... life is about balance friend :-) i'm not sure too many would agree (my time is more important that pedantic minimalism) hence support may be hard to come by. although, this paragraph is backed by little more than imaginary statistics and [possibly misguided] intuition.
Well I'm not trying to be minimalistic just to be minimalistic. I'm picky about how my things are organized on my system, and the files I have installed. If I have the power to remove something unnecessary, then I most likely will remove it ;). I do agree with you that life is about balance. I might go back to using an initramfs, but not atm, probably when I learn how to make my own basic initramfs haha with busybox and my own /init script (For learning purposes primarily).
My set up atm that lets me have GPT, GRUB2, LVM, all without needing initramfs, and future proofs me the need to move the physical partitions in the drive (not the logical ones inside the lvm) is:
/dev/sda1 BIOS Boot Partition 32M /dev/sda2 /boot ext2 100M /dev/sda3 / ext4 2G /dev/sda4 Linux LVM (name: arch)
... because you desire to drop the initramfs, you've lost the ability to manage / with LVM2, and that sux. 2GiB *might* be enough, never was nearly enough for me (though, i reject the idea of oodles of partitions) ... but what if it's not? by generating a teeny 4Mib file, you're / moves to LVM2, and you never have to rebuild the kern if you change FS, change hardware, change <insert here> ... dunno, nice trade off to me ... won't say anything further about it ;-)
Yea.. I know it sucks.. previously my set up was just as you said, I still have that setup in my old Arch drive (That I haven't formatted). I'm assuming you already know how my old setup was since you mentioned me losing the ability to manage / under LVM2. 2GB is more than needed, 1GB would be more minimal, but you just have to make sure you use the other partitions inside of the LVM, since /usr, /var , etc take up a lot of space for applications and packages. I agree, for a small initramfs I gain a lot. I wanted to see if this was possible under Arch, under my setup, clearly it is, but it has a cost :(. As for rebuilding the kernel, I built support for ext2/3/4 directly into the kernel. So if I need to switch to btrfs, I can recompile yes, but it only takes me like 5-7 minutes to rebuild since my kernel is just for my computer. I could also rebuild it months in advance with btrfs support as well and not have to worry about it later on :). Changing hardware, I hardly do this anymore, so doesn't really affect me, if this happens, then I would gladly explore the kernel configuration again and learn about my new system :).
Created in a (read most, write last order .. if it matters inside LVM) /dev/arch/swap 2G /dev/arch/usr 10G /dev/arch/tmp 10G /dev/arch/opt 5G /dev/arch/var 10G /dev/arch/home 500G
btw, if swap is on LVM2, you'll want to flag it contiguous (-Cy on `lvcreate`) if you didn't already. also, not sure if you need it, but hibernation will be impossible without initramfs if swap is on LVM2. lastly, be aware that a separate `/usr` is rapidly degrading into a next-to-unsupported/awkwardly-handled configuration ... while a lack of initramfs avoids the need to mount it pre-root, you may still have issues during early boot ... especially since soon, if not now, Arch initscripts will fully expect `/usr` to be available before pid 1 (Tom or someone else would need to confirm this).
Yup, my swap was made contiguous. I don't hibernate and took that into account when making my partition layouts. I just suspend to ram which can be done still in my layout. That would be an unfortunate event if I am required to have to do some of those things.
--
C Anthony
Overall, as I said in the beginning, I may end up going back to using an initramfs to simplify the partition layouts in general. Using an initramfs, pretty much, has nothing but advantages. Although hacking to see if something is possible surely is fun, .. if only for a while. -- Jonathan Vasquez
On Thu, Jan 12, 2012 at 1:07 AM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
On Thu, Jan 12, 2012 at 12:36 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
On Wed, Jan 11, 2012 at 10:29 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Simplicity and minimalism would be what motivates me the most. If I don't need an initramfs to get my system boot up, why have one? I know the benefits that initramfs provides, but I don't need any of them. All I need my computer to do is start, find the kernel, boot my comp to the terminal or X11 (depending on my setup).
well, i hear ya, but i'd argue you already *have* the minimalist setup ... life is about balance friend :-) i'm not sure too many would agree (my time is more important that pedantic minimalism) hence support may be hard to come by. although, this paragraph is backed by little more than imaginary statistics and [possibly misguided] intuition.
Well I'm not trying to be minimalistic just to be minimalistic. I'm picky about how my things are organized on my system, and the files I have installed. If I have the power to remove something unnecessary, then I most likely will remove it ;). I do agree with you that life is about balance. I might go back to using an initramfs, but not atm, probably when I learn how to make my own basic initramfs haha with busybox and my own /init script (For learning purposes primarily).
My set up atm that lets me have GPT, GRUB2, LVM, all without needing initramfs, and future proofs me the need to move the physical partitions in the drive (not the logical ones inside the lvm) is:
/dev/sda1 BIOS Boot Partition 32M /dev/sda2 /boot ext2 100M /dev/sda3 / ext4 2G /dev/sda4 Linux LVM (name: arch)
... because you desire to drop the initramfs, you've lost the ability to manage / with LVM2, and that sux. 2GiB *might* be enough, never was nearly enough for me (though, i reject the idea of oodles of partitions) ... but what if it's not? by generating a teeny 4Mib file, you're / moves to LVM2, and you never have to rebuild the kern if you change FS, change hardware, change <insert here> ... dunno, nice trade off to me ... won't say anything further about it ;-)
Yea.. I know it sucks.. previously my set up was just as you said, I still have that setup in my old Arch drive (That I haven't formatted). I'm assuming you already know how my old setup was since you mentioned me losing the ability to manage / under LVM2. 2GB is more than needed, 1GB would be more minimal, but you just have to make sure you use the other partitions inside of the LVM, since /usr, /var , etc take up a lot of space for applications and packages. I agree, for a small initramfs I gain a lot. I wanted to see if this was possible under Arch, under my setup, clearly it is, but it has a cost :(.
As for rebuilding the kernel, I built support for ext2/3/4 directly into the kernel. So if I need to switch to btrfs, I can recompile yes, but it only takes me like 5-7 minutes to rebuild since my kernel is just for my computer. I could also rebuild it months in advance with btrfs support as well and not have to worry about it later on :). Changing hardware, I hardly do this anymore, so doesn't really affect me, if this happens, then I would gladly explore the kernel configuration again and learn about my new system :).
Created in a (read most, write last order .. if it matters inside LVM) /dev/arch/swap 2G /dev/arch/usr 10G /dev/arch/tmp 10G /dev/arch/opt 5G /dev/arch/var 10G /dev/arch/home 500G
btw, if swap is on LVM2, you'll want to flag it contiguous (-Cy on `lvcreate`) if you didn't already. also, not sure if you need it, but hibernation will be impossible without initramfs if swap is on LVM2. lastly, be aware that a separate `/usr` is rapidly degrading into a next-to-unsupported/awkwardly-handled configuration ... while a lack of initramfs avoids the need to mount it pre-root, you may still have issues during early boot ... especially since soon, if not now, Arch initscripts will fully expect `/usr` to be available before pid 1 (Tom or someone else would need to confirm this).
Yup, my swap was made contiguous. I don't hibernate and took that into account when making my partition layouts. I just suspend to ram which can be done still in my layout. That would be an unfortunate event if I am required to have to do some of those things.
--
C Anthony
Overall, as I said in the beginning, I may end up going back to using an initramfs to simplify the partition layouts in general. Using an initramfs, pretty much, has nothing but advantages.
Although hacking to see if something is possible surely is fun, .. if only for a while. -- Jonathan Vasquez
I was reading this and it reminded me of what you said Anthony: http://fedoraproject.org/wiki/Features/UsrMove -- Jonathan Vasquez
I was reading this and it reminded me of what you said Anthony: http://fedoraproject.org/wiki/Features/UsrMove
-- Jonathan Vasquez
I'm definitely going to be moving back to my old drive (with the old partition style /dev/sda1 EF02, /dev/sda2 ALL LVM (Boot, /, , swap, home)) and using initramfs. I just finished reading this page on it: http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Introducing-in... I have to admit.. I am impressed, the reasons why initramfs was made, why it replaced initrd, why it was even necessary in the first place, are very well needed. I'm now sure I would have regretted permanently staying on a system without initramfs and it's definitely was stupid (well there were a few valid reasons why) of me to even think about removing the initrd, but I'm happy I learned all this info. It was a good experience. But now time to move back to my simple kernel/initramfs based system with only 2 parts and 1 has all lvms. -- Jonathan Vasquez
On Thu, Jan 12, 2012 at 5:01 AM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Btw, for the first picture, it says that /usr is not mounted. I believe that is because my /usr in in /dev/mapper/arch-usr and that doesn't get mounted until later in the boot process.
You should still get boot messages during boot even without an initramfs, anything else is a bug in initscripts. Initscripts does not strictly speaking depend on an initrams, but if it is there it will take advantage of the benefits. However, mounting without /usr is not supported, so as long as you do that weird things will happen and any bug reports will be closed as "wont fix". Luckily, it will soon be possible to mount /usr before starting init, so your lvm setup should be supported. However, this is done in the initramfs (the only sane place to do it). Using an initramfs is essentially required unless you have a very simple setup (/usr on the rootfs and no lvm/md/crypt involved). Even if you have a simple setup it will give you nice benefits like the ability to fsck the rootfs before mounting it, and unmounting it properly before shutting down. Cheers, Tom
participants (6)
-
C Anthony Risinger
-
Jan Steffens
-
Jonathan Vasquez
-
Karol Blazewicz
-
Thomas Bächler
-
Tom Gundersen