#337 Issue closed: Grub and LVM issues¶
Labels: support / question
Florent38 opened issue at 2013-11-25 12:17:¶
Hi,
On RHEL 6.4 with lvm on three hard drive (sda, sdb, sdc and boot
partition on sda1) :
The ouput of lsblk :
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 3,5G 0 rom
sda 8:0 0 8G 0 disk
├─sda1 8:1 0 500M 0 part /boot
└─sda2 8:2 0 7,5G 0 part
├─vg_virtualbox-lv_root (dm-0) 253:0 0 6,4G 0 lvm /
└─vg_virtualbox-lv_swap (dm-1) 253:1 0 2G 0 lvm [SWAP]
sdb 8:16 0 512M 0 disk
└─vg_virtualbox-lv_root (dm-0) 253:0 0 6,4G 0 lvm /
sdc 8:32 0 512M 0 disk
└─vg_virtualbox-lv_root (dm-0) 253:0 0 6,4G 0 lvm /
Rear install grub on sda, sdb, and sdc.
1/
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub> device (hd0) /dev/sda
grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup --stage2=/boot/grub/stage2 --prefix=/grub (hd0)
Checking if "/grub/stage1" exists... yes
Checking if "/grub/stage2" exists... yes
Checking if "/grub/e2fs_stage1_5" exists... yes
Running "embed /grub/e2fs_stage1_5 (hd0)"... 27 sectors are embedded.
succeeded
Running "install --stage2=/boot/grub/stage2 /grub/stage1 (hd0) (hd0)1+27 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.
grub> quit
2/
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub> device (hd0) /dev/sdb
grub> device (hd1) /dev/sda
grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup --stage2=/boot/grub/stage2 --prefix=/grub (hd0)
Checking if "/grub/stage1" exists... yes
Checking if "/grub/stage2" exists... yes
Checking if "/grub/e2fs_stage1_5" exists... yes
Running "embed /grub/e2fs_stage1_5 (hd0)"... failed (this is not fatal)
Running "embed /grub/e2fs_stage1_5 (hd1,0)"... failed (this is not fatal)
Running "install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) /grub/stage2 p /grub/grub.conf "... succeeded
Done.
grub> quit
3/
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub> device (hd0) /dev/sdc
grub> device (hd1) /dev/sda
grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup --stage2=/boot/grub/stage2 --prefix=/grub (hd0)
Checking if "/grub/stage1" exists... yes
Checking if "/grub/stage2" exists... yes
Checking if "/grub/e2fs_stage1_5" exists... yes
Running "embed /grub/e2fs_stage1_5 (hd0)"... failed (this is not fatal)
Running "embed /grub/e2fs_stage1_5 (hd1,0)"... failed (this is not fatal)
Running "install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) /grub/stage2 p /grub/grub.conf "... succeeded
Done.
grub> quit
Here is the full log of rear recover -D : https://gist.github.com/Florent38/7640386
gdha commented at 2013-11-26 11:27:¶
The question is did your system boot up properly?
Florent38 commented at 2013-11-26 11:37:¶
Yes only if the first boot order is on sda.
gdha commented at 2013-11-26 13:26:¶
Hum, seems to me we might have hit one of the problems with grub itself - see http://lists.gnu.org/archive/html/bug-grub/2009-11/msg00024.html
@dagwieers in script 21_install_grub.sh you've added the check:
if (( $? == 0 )); then
NOBOOTLOADER=
fi
I wonder shouldn't we have foreseen an exit out of the do-loop when grub was successful?
Florent38 commented at 2013-11-27 13:45:¶
I don't understand the aim of the do-loop.
When Rear restore a system with 2 or more disks. Rear have to install
Grub only on the MBR of one disk (which contains the boot partition).
jhoekx commented at 2013-11-27 13:55:¶
I don't know the exact reason anymore, but @dagwieers had a good explanation for why we should do it on all disks. I think it was multipath related.
Is it causing problems?
schlomo commented at 2013-11-27 14:04:¶
With any kind of MPIO or SW RAID you should anticipate booting off any
of
the related devices.
BTW, if you don't test that "feature" then it probably won't work (sad
experience I made with SW RAID and first disk broken).
On 27 November 2013 14:55, Jeroen Hoekx notifications@github.com wrote:
I don't know the exact reason anymore, but @dagwieershttps://github.com/dagwieershad a good explanation for why we should do it on all disks. I think it was
multipath related.Is it causing problems?
—
Reply to this email directly or view it on GitHubhttps://github.com/rear/rear/issues/337#issuecomment-29385628
.
jhoekx commented at 2013-11-27 14:15:¶
Yes Schlomo, that's indeed the explanation.
We had to recover machines with a software RAID over two HW RAID controllers. In order to let them boot reliably we had to add the loop.
schlomo commented at 2013-11-27 14:22:¶
IMHO, any disk with a copy of the OS on it should be bootable. If we
don't
know which disks have an OS on it, then better make them all bootable.
On 27 November 2013 15:15, Jeroen Hoekx notifications@github.com wrote:
Yes Schlomo, that's indeed the explanation.
We had to recover machines with a software RAID over two HW RAID
controllers. In order to let them boot reliably we had to add the loop.—
Reply to this email directly or view it on GitHubhttps://github.com/rear/rear/issues/337#issuecomment-29386995
.
gdha commented at 2013-11-27 15:24:¶
However, the question here is: did every disk contain a boot partition? Apparently not, so it might be that we should check this first before applying blindly grub on it - as I said before the exit code of the old grub is bad (or always 0 even if it fails).
jhoekx commented at 2013-11-27 15:39:¶
Is there something that fails when you add multiple MBRs?
If not, the comments in finalize/Linux-i386/21_install_grub.sh seem to indicate we encountered a case where we needed to boot from another disk and that it was fixed by adding it to all disks. As long as that's not causing problems, I would continue to do so.
gdha commented at 2013-11-28 07:33:¶
Do we all agree it is the expected behavior? As long as the system boots up properly it is not considered as a problem.
Florent38 commented at 2013-11-28 08:39:¶
It's not causing problems for the moment.
But I'm interested by explanations of @dagwieers.
gdha commented at 2014-05-22 12:27:¶
guess we better close this issue?
[Export of Github issue for rear/rear.]