Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
On Mon, May 31, 2010 at 5:42 PM, d.sastre.med...@gmail.com wrote:
Thanks for the comments and help.
I have edited /boot/grub/grub.cfg to match my devices by UUID as
proposed, getting UUIDs from blkid /dev/md{0,1} (previously I run
blkid -g):
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 present in some tests)
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set here blkid /dev/md0
echo Loading Linux 2.6.32-3-686-bigmem ...
linux /vmlinuz-2.6.32-3-686-bigmem root=UUID=here blkid /dev/md1
ro rootdelay=15
echo Loading initial ramdisk ...
initrd /initrd.img-2.6.32-3-686-bigmem
}
It doesn't boot. Note a added `rootdelay=15' and removed `quiet' to be
able to see what happens.
Still LVM tries to initialize before mdadm (is that correct, anyway?),
and ends up waiting for the root filesystem until I'm dropped to busybox.
While at the initramfs prompt, simply by issuing `vgchange -ay' and
exiting (Ctrl-D) I can boot the box. Luckily, I had a PS2 keyboard
around, because the USB one wouldn't work.
The output of `vgchange -ay' might be informative. Here is one
example, but one line is output for each LV:
udevd-work[number]:kernel provided name 'dm-2' and
NAME='mapper/root_vg-var_lv' disagree, please use SYMLINK+= or change
the kernel to provide the proper name.
This looks like #581715 or #581593.
In both reports, however, it is said it's a harmless warning.
I can confirm that, at least, while testing the
linux /vmlinuz-2.6.32-3-686-bigmem root=/dev/mapper/root_vg-root_lv
variant, I can boot the system from initramfs after
`vgchange -ay' + Ctrl-D
regardless the warnings.
After booting, running `upgrade-grub or upgrade-grub2' won't help.
This looks like a problem elsewhere (udev, initramfs-tools, ...), but
not grub.
I agree. It's an initrd problem. You could start by deleting and
re-creating it with
update-initramfs -d -k...
update-initramfs -c -k...
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktin92d6uryfrtqlbftwcpror4upl6imba23rh...@mail.gmail.com
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
d.sastre.med...@gmail.com wrote:
Thanks for the comments and help.
I have edited /boot/grub/grub.cfg to match my devices by UUID as
proposed, getting UUIDs from blkid /dev/md{0,1} (previously I run
blkid -g):
Good.
It doesn't boot.
Bummer.
Note a added `rootdelay=15' and removed `quiet' to be
able to see what happens.
Good thinking.
Still LVM tries to initialize before mdadm (is that correct, anyway?),
and ends up waiting for the root filesystem until I'm dropped to busybox.
While at the initramfs prompt, simply by issuing `vgchange -ay' and
exiting (Ctrl-D) I can boot the box. Luckily, I had a PS2 keyboard
around, because the USB one wouldn't work.
Ah, good, so, grub correctly detects the kernel and initrd files and loads
them. The kernel then takes control and starts the initramfs process which
you are reporting as failing.
This is further down the boot process than any grub or kernel.
Have you tried the:
update-initramfs -u
command to reconstruct the initramfs file used?
The output of `vgchange -ay' might be informative. Here is one
example, but one line is output for each LV:
udevd-work[number]:kernel provided name 'dm-2' and
NAME='mapper/root_vg-var_lv' disagree, please use SYMLINK+= or change
the kernel to provide the proper name.
This looks like #581715 or #581593.
In both reports, however, it is said it's a harmless warning.
I can confirm that, at least, while testing the
Yes, it's a harmles warning.
linux /vmlinuz-2.6.32-3-686-bigmem root=/dev/mapper/root_vg-root_lv
variant, I can boot the system from initramfs after
`vgchange -ay' + Ctrl-D
regardless the warnings.
After booting, running `upgrade-grub or upgrade-grub2' won't help.
This looks like a problem elsewhere (udev, initramfs-tools, ...), but
not grub.
Try the `update-initramfs -u` command. It may solve the issue, if that
doesn't work, contact the initramfs maintainer, or file a bug, that will
solve the problem.
Good luck.
--
Antonio Perez
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/4149443.dcc6gmi...@rnqqfki.eternal-september.org
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
d.sastre.med...@gmail.com put forth on 5/30/2010 4:45 PM: 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 :) This is very old, but I think the basic information is still valid. BIOS has changed considerably in the past 10 years, and I'd assume is smarter across the sea of manufacturers. This should be taken into account regarding the enumeration of drives and the BIOS boot behavior. http://www.faqs.org/docs/Linux-mini/Boot+Root+Raid+LILO.html#ss3.1 -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c04c56d.8070...@hardwarefreak.com
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
On Tue, Jun 01, 2010 at 03:31:41AM -0500, Stan Hoeppner wrote: d.sastre.med...@gmail.com put forth on 5/30/2010 4:45 PM: 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. [ snip ] But first I'll need to refresh my LILO skills. It's been a while :) This is very old, but I think the basic information is still valid. BIOS has changed considerably in the past 10 years, and I'd assume is smarter across the sea of manufacturers. This should be taken into account regarding the enumeration of drives and the BIOS boot behavior. http://www.faqs.org/docs/Linux-mini/Boot+Root+Raid+LILO.html#ss3.1 It looks like my problem is init scripts related, so I'm working in that direction for now. Thanks for the link, I'll keep this around to survive the forthcomming BootLoader Wars :-D -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB pgpJrpshFf3ev.pgp Description: PGP signature
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
d.sastre.med...@gmail.com wrote:
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.med...@gmail.com wrote:
Grub2 is failing to boot a softRAID1 + LVM2 squeeze box.
I use an equivalent setup and it was all automatically setup
correctly with the `update-grub2` command (once the system has
booted correctly).
Keep reading.
I have an 'md1' as '/boot' and an lvm2 '/' on 'md2', this is what my system
uses:
grub.cfg:
menuentry Debian GNU/Linux, with Linux 2.6.32-trunk-amd64 --class debian
--class gnu-linux --class gnu --class os {
insmod raid
insmod mdraid
insmod ext2
set root='(md1)'
search --no-floppy --fs-uuid --set 1be9c4e5-70cd-4662-81e6-44e76cff20d8
echoLoading Linux 2.6.32-trunk-amd64 ...
linux /vmlinuz-2.6.32-trunk-amd64
root=UUID=25defa7a-93cb-40eb-9a76-c326f0b2dffc ro vga=792
echoLoading initial ramdisk ...
initrd /initrd.img-2.6.32-trunk-amd64
blkid: `blkid /dev/md[1,2]` Use blkid -g first to clear any old stored key.
/dev/md1: UUID=1be9c4e5-70cd-4662-81e6-44e76cff20d8 TYPE=ext2
/dev/md2: UUID=25defa7a-93cb-40eb-9a76-c326f0b2dffc TYPE=ext2
grub-probe: grub-probe -t fs_uuid /boot, grub-probe -t fs_uuid /
1be9c4e5-70cd-4662-81e6-44e76cff20d8
25defa7a-93cb-40eb-9a76-c326f0b2dffc
mdadm: `sudo mdadm -D /dev/md[1,2] | grep UUID`
UUID : ff7e23a3:dc6327b6:73d158fc:63c6b3dd
UUID : 157b664b:7b41974f:73d158fc:63c6b3dd
It's booting fine all the time.
r...@sysresccd /root % mdadm --detail /dev/md0 /dev/md0:
UUID : 8052f7d4:54a97fbb:731031f6:bc3d041c
That UUID it's not the same that grub will use for boot.
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.
That is not your problem IMO.
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)
No, the `root` partition from the point of view of grub is the partition
where it is going to boot, i.e. /boot, then, the kernel will need the
`root` FS to use, that will be the UUID for /root_vg-root_lv in the `linux`
line.
Note that `boot' is a multidisk partition (sda1 and sdb1, which assemble
md0), thus root='(md0)' makes sense from a grub point of view.
Correct.
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.
That looks OK.
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
echoLoading 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
echoLoading 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.
Yes, that's exactly it.
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.
But grub has nothing to do with this parameter, it is a kernel `boot parameter`
well, more of a initrd boot parameter, but that is a different area:
http://www.mjmwired.net/kernel/Documentation/kernel-parameters.txt
line 2193.
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 believe there is a mistake, and, that the `HD` should be `NO`. Meaning
that if no variable name is supplied, the value is assigned to the `root`
variable.
This effectively
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
On Sun, May 30, 2010 at 7:13 AM, d.sastre.med...@gmail.com wrote:
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.med...@gmail.com wrote:
Grub2 is failing to boot a softRAID1 + LVM2 squeeze box.
r...@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?
1. The set root= and search .. lines are setting the root for grub
as you said, which is the partition where grub.cfg is (I wish that the
grub developers had called it groot or grubroot). Since you have a
separate /boot partition, using your root-lv's uuid doesn't make
sense.
2. If you are going to the grub prompt from the grub menu by pressing
c
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
Thanks for the comments and help.
I have edited /boot/grub/grub.cfg to match my devices by UUID as
proposed, getting UUIDs from blkid /dev/md{0,1} (previously I run
blkid -g):
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 present in some tests)
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set here blkid /dev/md0
echoLoading Linux 2.6.32-3-686-bigmem ...
linux /vmlinuz-2.6.32-3-686-bigmem root=UUID=here blkid /dev/md1 ro
rootdelay=15
echoLoading initial ramdisk ...
initrd /initrd.img-2.6.32-3-686-bigmem
}
It doesn't boot. Note a added `rootdelay=15' and removed `quiet' to be
able to see what happens.
Still LVM tries to initialize before mdadm (is that correct, anyway?),
and ends up waiting for the root filesystem until I'm dropped to busybox.
While at the initramfs prompt, simply by issuing `vgchange -ay' and
exiting (Ctrl-D) I can boot the box. Luckily, I had a PS2 keyboard
around, because the USB one wouldn't work.
The output of `vgchange -ay' might be informative. Here is one
example, but one line is output for each LV:
udevd-work[number]:kernel provided name 'dm-2' and
NAME='mapper/root_vg-var_lv' disagree, please use SYMLINK+= or change
the kernel to provide the proper name.
This looks like #581715 or #581593.
In both reports, however, it is said it's a harmless warning.
I can confirm that, at least, while testing the
linux /vmlinuz-2.6.32-3-686-bigmem root=/dev/mapper/root_vg-root_lv
variant, I can boot the system from initramfs after
`vgchange -ay' + Ctrl-D
regardless the warnings.
After booting, running `upgrade-grub or upgrade-grub2' won't help.
This looks like a problem elsewhere (udev, initramfs-tools, ...), but
not grub.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
pgprQaPbR1v3r.pgp
Description: PGP signature
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
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.med...@gmail.com wrote:
Grub2 is failing to boot a softRAID1 + LVM2 squeeze box.
r...@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
echoLoading 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
echoLoading 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
pgpcPfDpaijPe.pgp
Description: PGP signature
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
What happens when you use LILO instead of Grub?
d.sastre.med...@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.med...@gmail.com wrote:
Grub2 is failing to boot a softRAID1 + LVM2 squeeze box.
r...@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
echoLoading 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
echoLoading 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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c02bb79.3070...@hardwarefreak.com
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
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 pgpELQ6lE3Mv2.pgp Description: PGP signature
[ squeeze ] Grub2 RAID1 LVM2 boot failure
Hello,
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.
Follows some commands' ouput from within a rescueCD session.
r...@sysresccd /root % ll /mnt/md0
total 16M
drwxr-xr-x 4 root root 4.0K 2010-05-28 20:45 .
drwxr-xr-x 11 root root 180 2010-05-29 10:28 ..
-rw-r--r-- 1 root root 109K 2010-02-11 07:48
config-2.6.32-2-686-bigmem
-rw-r--r-- 1 root root 109K 2010-02-25 09:01
config-2.6.32-3-686-bigmem
drwxr-xr-x 3 root root 4.0K 2010-05-25 20:52 grub
-rw-r--r-- 1 root root 4.1M 2010-05-28 20:45
initrd.img-2.6.32-2-686-bigmem
-rw-r--r-- 1 root root 4.1M 2010-05-28 20:45
initrd.img-2.6.32-3-686-bigmem
drwx-- 2 root root 16K 2010-01-24 11:12 lost+found
-rw-r--r-- 1 root root 1.3M 2010-02-11 07:48
System.map-2.6.32-2-686-bigmem
-rw-r--r-- 1 root root 1.3M 2010-02-25 09:01
System.map-2.6.32-3-686-bigmem
-rw-r--r-- 1 root root 2.2M 2010-02-11 07:47
vmlinuz-2.6.32-2-686-bigmem
-rw-r--r-- 1 root root 2.2M 2010-02-25 09:00
vmlinuz-2.6.32-3-686-bigmem
r...@sysresccd /root % mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sun Jan 24 10:10:43 2010
Raid Level : raid1
Array Size : 979840 (957.04 MiB 1003.36 MB)
Used Dev Size : 979840 (957.04 MiB 1003.36 MB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Sat May 29 10:29:40 2010
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : 8052f7d4:54a97fbb:731031f6:bc3d041c
Events : 0.4
Number Major Minor RaidDevice State
0 8 170 active sync /dev/sdb1
1 8 331 active sync /dev/sdc1
r...@sysresccd /root % vgdisplay root_vg
--- Volume group ---
VG Name root_vg
System ID
Formatlvm2
Metadata Areas1
Metadata Sequence No 19
VG Access read/write
VG Status resizable
MAX LV0
Cur LV11
Open LV 0
Max PV0
Cur PV1
Act PV1
VG Size 148.11 GB
PE Size 4.00 MB
Total PE 37917
Alloc PE / Size 15984 / 62.44 GB
Free PE / Size 21933 / 85.68 GB
VG UUID XN1x4E-uBFZ-svSP-hQMr-kSHe-Ry3s-VtBcsH
r...@sysresccd /root % lvdisplay /dev/mapper/root_vg-root_lv
--- Logical volume ---
LV Name/dev/root_vg/root_lv
VG Nameroot_vg
LV UUIDFx1w1w-6nvb-aMh1-6iG1-pruF-VuiH-okk9cw
LV Write Accessread/write
LV Status available
# open 0
LV Size952.00 MB
Current LE 238
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:5
Any help is appreciated.
Regards.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=0
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
insmod raid
insmod mdraid
insmod lvm
insmod ext2
set root='(root_vg-usr_lv)'
search --no-floppy --fs-uuid --set a800ad33-1549-4f09-a187-d5c6f13942c4
if loadfont /share/grub/unicode.pf2 ; then
set gfxmode=640x480
insmod gfxterm
insmod vbe
if terminal_output gfxterm ; then true ; else
# For backward compatibility with
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
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
echoLoading 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
echoLoading 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
pgpyXJEYlBCLi.pgp
Description: PGP signature
Re: [ squeeze ] Grub2 RAID1 LVM2 boot failure
On Sat, May 29, 2010 at 7:06 AM, David Sastre Medina d.sastre.med...@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. r...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinol3roxqykv5bcb9orgzofdvrccrj88prit...@mail.gmail.com
