Prev: Installing memtest86 in Lenny fails to copy the actual binary
Next: Making use of volume control keys
From: d.sastre.medina on 29 May 2010 13:00
I think my previous post requires some more info:

I've got three HDs, two of them (twin disks) have two partitions,
one /boot partition (md0) and the other one for LVM filesystems (md1),
where root_vg-root_lv lives (among others). The third disk is unpatitioned,
and has one only lv (var_lv)

So, provided this autogenerated grub.cfg entry:

menuentry "Debian GNU/Linux, with Linux 2.6.32-3-686-bigmem" --class debian --class gnu-linux --class gnu --class os {
insmod raid
insmod mdraid
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set 785366b0-d597-4e9c-9284-b6b9161236ed
echo Loading Linux 2.6.32-3-686-bigmem ...
linux /vmlinuz-2.6.32-3-686-bigmem root=/dev/mapper/root_vg-root_lv ro rootdelay=25 quiet
echo Loading initial ramdisk ...
initrd /initrd.img-2.6.32-3-686-bigmem
}

...and compared to the examples in the grub wiki¹:

Example grub.cfg for LVM

Below is a sample grub.cfg using LVM. Linux is installed under
MainGroup-linuxLV where MainGroup is the VolumeGroup und linuxLV is
the logical volume. Notice that vmlinuz (the linux kernel) and
initrd.img are lying in the logical volume and can be accessed by
symlinks.

set timeout=20
set default=0
menuentry "Linux on LVM" {
insmod lvm
set root=(MainGroup-linuxLV)
linux /vmlinuz root=/dev/mapper/MainGroup-linuxLV
initrd /initrd.img
}

Example grub.cfg for RAID

This is an example of grub.cfg when the /boot filesystem is on a RAID
device.

insmod raid
set root=(md0)
search --fs-uuid --set 155c8fdb-607f-45a4-bd6d-0dd89f21eac2

menuentry "Linux" {
insmod raid
set root=(md0)
search --fs-uuid --set 155c8fdb-607f-45a4-bd6d-0dd89f21eac2
linux /vmlinuz-2.6.31 root=LABEL=root ro
initrd /initrd.img-2.6.31
}

I can't find documented the scenario when /boot resides in /dev/md0
and root filesystem is mounted in /dev/mapper/root_vg-root_lv (md1, in
my case).

Removing the `quiet' option shows LVM log lines appearing *before*
mdadm lines, which suggest some timming issues in the init scripts(?).

Again, any hints are appreciated.

Regards.

¹ http://grub.enbug.org/LVMandRAID

--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
From: Tom H on 29 May 2010 17:50
On Sat, May 29, 2010 at 7:06 AM, David Sastre Medina
<d.sastre.medina(a)gmail.com> wrote:
>
> Grub2 is failing to boot a softRAID1 + LVM2 squeeze box.
> The error is "can't find root_vg-root_lv". After that, it drops me to
> a initrd shell, but my USB keyboard stops working, so I must
> button-reboot.
> There are two kernels installed.
> I've attached grub.cfg. It's an automated cfg from update-grub2.
> I already tried adding rootdelay without success in /etc/default/grub
> GRUB_CMDLINE_LINUX_DEFAULT="rootdelay=15 quiet"
> Weird stuff: I have upgraded this box from lenny a week ago or
> so. No problems booting.
> It used to have a bpo kernel, but since squeeze's repo has the
> same (2.6.32-3) kernel, I installed it and uninstalled the bpo one.
> No problems booting yet.
> Afterwards, I had to `/etc/init.d/vbox setup' to be able to use VBox
> again (dkms failed, it seems) and re-run the makeselved script to
> install the ATI propietary driver. This box has an ATI Radeon
> HD 4550.
> Kernel 2.6.32-2 stops booting, so I use 2.6.32-2 while I do some
> research about it.
> Yesterday, 2.6.32-2 booted without problems, but
> since I had ATI propietary driver installed only for 2.6.32-3, I run
> the installer in 2.6.32-2. Today this kernel doesn't boot either.
>
> root(a)sysresccd /root % mdadm --detail /dev/md0
> /dev/md0:
> ...
>           UUID : 8052f7d4:54a97fbb:731031f6:bc3d041c

Although unrelated to your ati install and what it may have done, I
see two possible problems when looking at your grub.cfg.

1. There isn't an "insmod lvm" within the menuentry stanza. ext2,
raid, and mdraid are insmod'd twice in the header and once in the
menuentry and lvm is inmod'd just once in the header. (This is one of
the grub2 mysteries; why multiple insmods of the same modules?). I
doubt that this is the source of the problem (the first insmod must be
enough!) but you could add "insmod lvm" within the menuentry.

2. In the uuid of the search line, what is
785366b0-d597-4e9c-9284-b6b9161236ed? One of your /dev/sX1's uuid?
Since raid and mdraid are loaded, can't you/shouldn't you use the md0
uuid above?


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/AANLkTinOL3roXqYkv5Bcb9oRGZOfdvRCcrJ88PRit1C8(a)mail.gmail.com
From: d.sastre.medina on 30 May 2010 07:20
On Sat, May 29, 2010 at 05:44:22PM -0400, Tom H wrote:
> On Sat, May 29, 2010 at 7:06 AM, David Sastre Medina
> <d.sastre.medina(a)gmail.com> wrote:
> >
> > Grub2 is failing to boot a softRAID1 + LVM2 squeeze box.
> >
> > root(a)sysresccd /root % mdadm --detail /dev/md0
> > /dev/md0:
> > ...
> >           UUID : 8052f7d4:54a97fbb:731031f6:bc3d041c
>
> I see two possible problems when looking at your grub.cfg.
>
> 1. There isn't an "insmod lvm" within the menuentry stanza. ext2,
> raid, and mdraid are insmod'd twice in the header and once in the
> menuentry and lvm is inmod'd just once in the header. (This is one of
> the grub2 mysteries; why multiple insmods of the same modules?). I
> doubt that this is the source of the problem (the first insmod must be
> enough!) but you could add "insmod lvm" within the menuentry.

Already tried that. No success.

> 2. In the uuid of the search line, what is
> 785366b0-d597-4e9c-9284-b6b9161236ed? One of your /dev/sX1's uuid?
> Since raid and mdraid are loaded, can't you/shouldn't you use the md0
> uuid above?

I also tried that. It fails.
That UUID belongs to /root_vg-root_lv, where the root filesystem
resides.
The UUID can be confirmed at the grub propmt issuing
grub> ls (root_vg-root_ls)

Note that `boot' is a multidisk partition (sda1 and sdb1, which assemble
md0), thus root='(md0)' makes sense from a grub point of view. And md1
is the result of assembling sda2 and sdb2. This md device has only one VG
on top of it, root_vg, with several LVs in it, one of these LVs being my
root_lv.

This my default menuentry now:

menuentry "Debian GNU/Linux, with Linux 2.6.32-3-686-bigmem" --class
debian --class gnu-linux --class gnu --class os {
insmod raid
insmod mdraid
insmod lvm
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set 785366b0-d597-4e9c-9284-b6b9161236ed
echo Loading Linux 2.6.32-3-686-bigmem ...
linux /vmlinuz-2.6.32-3-686-bigmem root=/dev/mapper/root_vg-root_lv ro rootdelay=15 quiet
echo Loading initial ramdisk ...
initrd /initrd.img-2.6.32-3-686-bigmem
}

The `set root' entry says what is *root* for grub, I understand this as:
where are /boot/grub/grub.cfg, /vmlinuz-`uname -r` and /initrd.img-`uname -r`
So IMHO it should be called boot='(md0)' for better undestanding and
disambiguation from the *other* root in the `linux' line.
The GRUB root device is not the same as the Linux kernel root= parameter.
BTW this command is undocummented in the wiki, still uses grub-legacy's
info, which doesn't apply anymore, given the `root' command has been
replaced.

The `search' line, as stated in the grub wiki:

Search devices by file, filesystem label or filesystem UUID. If --set
is specified, the first device found is set to a variable. If HD
variable name is specified, "root" is used.

I take this to mean that the first device found _which UUID is_ 785...
(the UUID of my root_gv-root_lv) will be the `root' filesystem.

And yet another definition of `root' after the `linux' call.
That one states that:

root=/dev/mapper/root_vg-root_lv which could be written also as:
root=LABEL=root or even
root=UUID=785366b0-d597-4e9c-9284-b6b9161236ed

The three of them should be right. None of them work.

If a suppress the `quiet' option from the `linux' line, what I can see
is LVM initializing *before* mdadm has get its job done:

"Volume group "root_vg-root_lv not found
Skipping volume group root_vg
Unable to find LVM volume root_vg-swap_lv
mdadm:/dev/md0 has been started with two drives
mdadm:/dev/md1 has been started with two drives
Gave up waiting fot root device."

So it looks like a timming issue *but*, I have tried to issue manually
the commands in the right order at the grub prompt:
1) insmod-ing raid, mdraid, lvm and ext2; setting root to md0;
2) searching for devices (also a variant without this step);
3) calling linux with the right root device
(all three variants of this step: dev name, UUID and LABEL and with
different rootdelay timmings, always without `quiet') and, finally;
4) calling initrd.

Failure again. No way root_vg to be found.

One further question: after a reboot, while at the grub screen, before
doing anything else, if a enter the command line and type `ls' at the
prompt, I can see all of my LVs, and listing anyone of them returns:
device name, filesystem type, label, last modification time and UUID.
Where does this info come from? Supossedly, there aren't mods loaded to
read that yet, until after `insmod' loads them, are there?


--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
From: Stan Hoeppner on 30 May 2010 15:30
What happens when you use LILO instead of Grub?

d.sastre.medina(a)gmail.com put forth on 5/30/2010 6:13 AM:
> On Sat, May 29, 2010 at 05:44:22PM -0400, Tom H wrote:
>> On Sat, May 29, 2010 at 7:06 AM, David Sastre Medina
>> <d.sastre.medina(a)gmail.com> wrote:
>>>
>>> Grub2 is failing to boot a softRAID1 + LVM2 squeeze box.
>>>
>>> root(a)sysresccd /root % mdadm --detail /dev/md0
>>> /dev/md0:
>>> ...
>>> UUID : 8052f7d4:54a97fbb:731031f6:bc3d041c
>>
>> I see two possible problems when looking at your grub.cfg.
>>
>> 1. There isn't an "insmod lvm" within the menuentry stanza. ext2,
>> raid, and mdraid are insmod'd twice in the header and once in the
>> menuentry and lvm is inmod'd just once in the header. (This is one of
>> the grub2 mysteries; why multiple insmods of the same modules?). I
>> doubt that this is the source of the problem (the first insmod must be
>> enough!) but you could add "insmod lvm" within the menuentry.
>
> Already tried that. No success.
>
>> 2. In the uuid of the search line, what is
>> 785366b0-d597-4e9c-9284-b6b9161236ed? One of your /dev/sX1's uuid?
>> Since raid and mdraid are loaded, can't you/shouldn't you use the md0
>> uuid above?
>
> I also tried that. It fails.
> That UUID belongs to /root_vg-root_lv, where the root filesystem
> resides.
> The UUID can be confirmed at the grub propmt issuing
> grub> ls (root_vg-root_ls)
>
> Note that `boot' is a multidisk partition (sda1 and sdb1, which assemble
> md0), thus root='(md0)' makes sense from a grub point of view. And md1
> is the result of assembling sda2 and sdb2. This md device has only one VG
> on top of it, root_vg, with several LVs in it, one of these LVs being my
> root_lv.
>
> This my default menuentry now:
>
> menuentry "Debian GNU/Linux, with Linux 2.6.32-3-686-bigmem" --class
> debian --class gnu-linux --class gnu --class os {
> insmod raid
> insmod mdraid
> insmod lvm
> insmod ext2
> set root='(md0)'
> search --no-floppy --fs-uuid --set 785366b0-d597-4e9c-9284-b6b9161236ed
> echo Loading Linux 2.6.32-3-686-bigmem ...
> linux /vmlinuz-2.6.32-3-686-bigmem root=/dev/mapper/root_vg-root_lv ro rootdelay=15 quiet
> echo Loading initial ramdisk ...
> initrd /initrd.img-2.6.32-3-686-bigmem
> }
>
> The `set root' entry says what is *root* for grub, I understand this as:
> where are /boot/grub/grub.cfg, /vmlinuz-`uname -r` and /initrd.img-`uname -r`
> So IMHO it should be called boot='(md0)' for better undestanding and
> disambiguation from the *other* root in the `linux' line.
> The GRUB root device is not the same as the Linux kernel root= parameter.
> BTW this command is undocummented in the wiki, still uses grub-legacy's
> info, which doesn't apply anymore, given the `root' command has been
> replaced.
>
> The `search' line, as stated in the grub wiki:
>
> Search devices by file, filesystem label or filesystem UUID. If --set
> is specified, the first device found is set to a variable. If HD
> variable name is specified, "root" is used.
>
> I take this to mean that the first device found _which UUID is_ 785...
> (the UUID of my root_gv-root_lv) will be the `root' filesystem.
>
> And yet another definition of `root' after the `linux' call.
> That one states that:
>
> root=/dev/mapper/root_vg-root_lv which could be written also as:
> root=LABEL=root or even
> root=UUID=785366b0-d597-4e9c-9284-b6b9161236ed
>
> The three of them should be right. None of them work.
>
> If a suppress the `quiet' option from the `linux' line, what I can see
> is LVM initializing *before* mdadm has get its job done:
>
> "Volume group "root_vg-root_lv not found
> Skipping volume group root_vg
> Unable to find LVM volume root_vg-swap_lv
> mdadm:/dev/md0 has been started with two drives
> mdadm:/dev/md1 has been started with two drives
> Gave up waiting fot root device."
>
> So it looks like a timming issue *but*, I have tried to issue manually
> the commands in the right order at the grub prompt:
> 1) insmod-ing raid, mdraid, lvm and ext2; setting root to md0;
> 2) searching for devices (also a variant without this step);
> 3) calling linux with the right root device
> (all three variants of this step: dev name, UUID and LABEL and with
> different rootdelay timmings, always without `quiet') and, finally;
> 4) calling initrd.
>
> Failure again. No way root_vg to be found.
>
> One further question: after a reboot, while at the grub screen, before
> doing anything else, if a enter the command line and type `ls' at the
> prompt, I can see all of my LVs, and listing anyone of them returns:
> device name, filesystem type, label, last modification time and UUID.
> Where does this info come from? Supossedly, there aren't mods loaded to
> read that yet, until after `insmod' loads them, are there?
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4C02BB79.3070100(a)hardwarefreak.com
From: d.sastre.medina on 30 May 2010 17:50
On Sun, May 30, 2010 at 02:24:41PM -0500, Stan Hoeppner wrote:
> What happens when you use LILO instead of Grub?

I haven't tried that yet.

First thing would be to know if the bootloader is to blame for not
having a bootable system. As of now, it would be some timming issues
related to initramfs-tools' scripts (wild guess).

Then, I'd need to know if LILO supports the configuration described
before, i.e., md0 contains /boot and md1 contains LVs, one of them
being /dev/mapper/root_vg-root_lv.

After that, I'd need to test the proper way to install/uninstall
software from an unbootable machine. I guess d-i allows installing
LILO on top of grub.
The purpose is either reinstalling grub-pc, downgrading to grub-legacy,
or installing LILO.
Other option would be using rescueCD, chroot into my system and install
from there. Suggestions are welcome.

But first I'll need to refresh my LILO skills. It's been a while :)

--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
 |  Next  |  Last
Pages: 1 2 3
Prev: Installing memtest86 in Lenny fails to copy the actual binary
Next: Making use of volume control keys