FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 01-09-2012, 05:33 AM
Jonathan Vasquez
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

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
 
Old 01-09-2012, 07:41 AM
Jan Steffens
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

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.
 
Old 01-09-2012, 08:30 AM
Jonathan Vasquez
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

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
 
Old 01-09-2012, 09:17 AM
Thomas Bächler
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

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.
 
Old 01-09-2012, 07:13 PM
Jonathan Vasquez
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

>> 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
 
Old 01-12-2012, 01:00 AM
Jonathan Vasquez
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

>> 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
 
Old 01-12-2012, 02:41 AM
Karol Blazewicz
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

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 ?
 
Old 01-12-2012, 02:59 AM
Jonathan Vasquez
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

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
 
Old 01-12-2012, 03:01 AM
Jonathan Vasquez
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

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
 
Old 01-12-2012, 03:03 AM
Jonathan Vasquez
 
Default Removing initrd (For use with GRUB2, LVM, GPT)

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
 

Thread Tools




All times are GMT. The time now is 12:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org