Can't boot 11.3 from GRUB in MBR

English Install/Boot/Login
#1

Issue: when I install GRUB to the MBR from openSUSE 11.3, GRUB malfunctions: When I attempt to boot, the sytem goes through its BIOS checks, (listing drives on the system, etc.) then reboots when the GRUB menu should appear.

(Originally I thought that 11.3 GRUB in the non-MBR location (hd0,1) was fine, but then I remembered that I originally installed 11.2 then upgraded to 11.3 using “zypper dup”. Installing 11.3 GRUB to (hd1,1) results in the same issue described above.)

Environment:

  • (hd0,0) and (hd1,0) are an md raid mirror containing the ext3 boot partition for openSUSE 11.1. If I install GRUB from here to the MBR, all is well.
  • (hd0,1) and (hd1,1) are an md raid mirror containing the ext3 boot partition for openSUSE 11.3. GRUB is installed in (hd0,1). I can boot 11.3 (with GRUB probably installed by 11.2) using a chainloader from the 11.1 GRUB.

Here is the problem: when I install openSUSE 11.3 GRUB to (hd0) using the following procedure, I end up in an infinite boot loop:

# grub hd0 --device-map=device.map
grub> root (hd0,1)
grub> setup (hd0)
grub> quit

Using the equivalent procedure to install the openSUSE 11.1 GRUB to (hd0) works fine.

I also installed 11.3 GRUB to (hd1) and (hd1,1) using an equivalent procedure. Chainloading this also causes the system to reboot when the GRUB menu should appear.

device.map:

(hd0)   /dev/disk/by-id/scsi-SFUJITSU_MAW3073NP_...
(hd1)   /dev/disk/by-id/scsi-SFUJITSU_MAW3073NP_...
(hd2)   /dev/disk/by-id/ata-ST3500630AS_...
(hd3)   /dev/disk/by-id/ata-Hitachi_HDS721010CLA332_...

menu.lst:

# Modified by YaST2. Last modification on Sat Oct  2 10:48:52 EDT 2010
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 2
timeout 8
gfxmenu (hd0,1)/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.3 - 2.6.34.7-0.3 (default)
    root (hd0,1)
    kernel /vmlinuz-2.6.34.7-0.3-default root=/dev/liz_sys_vg/root1 noresume splash=silent quiet showopts vga=0x346
    initrd /initrd-2.6.34.7-0.3-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.3 - 2.6.34.7-0.3
    root (hd0,1)
    kernel /vmlinuz-2.6.34.7-0.3-default root=/dev/liz_sys_vg/root1 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x346
    initrd /initrd-2.6.34.7-0.3-default

###Don't change this comment - YaST2 identifier: Original name: xen###
title Xen -- openSUSE 11.3 - 2.6.34.7-0.3
    root (hd0,1)
    kernel /xen.gz vgamode=0x346 
    module /vmlinuz-2.6.34.7-0.3-xen root=/dev/liz_sys_vg/root1 noresume splash=silent quiet showopts vga=0x346
    module /initrd-2.6.34.7-0.3-xen

(snip)

output from # grub hd0 --device-map=device.map

grub>
      root (hd0,1)
 Filesystem type is ext2fs, partition type 0xfd

grub>
      setup (hd0) 
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  17 sectors are e
mbedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,1)/boot/g
rub/stage2 /boot/grub/menu.lst"... succeeded
Done.
grub>

Any suggestions?

#2

I was tempted to tell you what to do. But just wait because there are a bunch of grubby fanatics online right now. They have this subject sewn up as tight as a ducks bottom.

#3

Can you show us the files (hd0,0)/boot/grub/device.map and (hd0,1)/boot/grub/device.map ?

#4

(hd0,0)/boot/grub/device.map

(hd0)   /dev/sda
(hd1)   /dev/sdb
(hd2)   /dev/sdc
(hd3)   /dev/sdd

(hd0,1)/boot/grub/device.map

(hd0)   /dev/disk/by-id/scsi-SFUJITSU_MAW3073NP_...
(hd1)   /dev/disk/by-id/scsi-SFUJITSU_MAW3073NP_...
(hd2)   /dev/disk/by-id/ata-ST3500630AS_...
(hd3)   /dev/disk/by-id/ata-Hitachi_HDS721010CLA332_...

(I redacted the drive serial numbers. Can’t be too careful.)

I verified that the drive orders match for the two map files, and that I get the same results if I use the (hd0,0) device.map with (hd0,1).

#5

I dunno but are you supposed to use (hd0,1) when you’re using LVM volumes?


grub >  find  /grub/stage1  ## probably should be (hd0,0)
grub >  setup hd0    ## assuming hd0 from find

or


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
}

Alternately, can you install grub to the mbr instead of the partition?

#6

(hd0,1) is not an LVM volume. As I mentioned in the OP, it is an ext3 partition in an md raid mirror.

Alternately, can you install grub to the mbr instead of the partition?

As I mentioned in the OP, I first tried installing to (hd0) (aka mbr). The result was an infinite reboot loop. Since this required booting from an install CD and using rescue mode to recover, I’d rather not do that again until I have successfully chainload to a working GRUB installed to (hd1) or (hd1,1).

#7

Yes you did, I missed the Raid but saw you named a volgroup.

But my question is basically the same, shouldn’t you set grub to look at raid volume instead of individual partition, ie, grub-install (Raidgroup,0) instead of grub-install (hd0,1) ?

Example maybe?
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
}

#8

Thank you for your advice, tararpharazon. Your mention of the grub-install tool, which I had never used, inspired me to find a solution. Unfortunately I was not comfortable following your advice, as the script has been renamed grub-install.unsupported, and its use is discouraged.

What I determined to be the problem was I had a mismatch between the “grub” command and the stage files in my boot partition. (Presumably this was caused by upgrading using “zypper dup”.) After executing the following commands:

# rm /boot/grub/*stage*
# cp /usr/lib/grub/* /boot/grub/

I was able to use the grub commands I described in the OP successfully.

#9

On 2010-10-16 03:06, randyC08 wrote:
>
> Thank you for your advice, tararpharazon. Your mention of the
> grub-install tool, which I had never used, inspired me to find a
> solution. Unfortunately I was not comfortable following your advice, as
> the script has been renamed grub-install.unsupported, and its use is
> discouraged.

There are two, one grub-install and another grub-install.unsupported, both from the grub rpm.

> What I determined to be the problem was I had a mismatch between the
> “grub” command and the stage files in my boot partition. (Presumably
> this was caused by upgrading using “zypper dup”.) After executing the
> following commands:

Uh?

> Code:
> --------------------
> # rm /boot/grub/stage
> # cp /usr/lib/grub/* /boot/grub/
> --------------------

Now that is very strange. I would use rpm --verify against those files.

>
> I was able to use the grub commands I described in the OP successfully.

Well, Glad you got it.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

#10

Glad you found the error.

As for grub-install, as Carlos E.R. wrote. Grub-install is for booting for rescue DVD/CD and installation for instance when YAST boot menu changes screws up your boot partition, but it’s discouraged because YAST is the preferred GUI method for boot menu changes.

I’ve generally repair grub from the boot DVD/CDs an I use the individual grub commands and the grub-install command.

#11

Where did I lose you, Carlos?

The files in /boot/grub do not belong to any package, therefore they were not updated by “zypper dup”. The files in /usr/lib/grub verify fine.

I didn’t mention that I had tried yast bootloader. It reported: “Error: Because of the partitioning the boot loader cannot be installed properly.” The option to install to the boot partition was greyed out, so I didn’t attempt to use the tool. The option to install to the root partition was enabled, which I thought was odd since the root partition is in LVM.

I recall having had no issues with the installation of 11.2, including bootloader, so I don’t understand why 11.3 yast bootloader tool couldn’t deal with my partitioning.

Regarding the script grub-install, on 11.3 if you call it with a parameter it refuses to do anything, instructing you to either use grub-install.unsupported, or call it with no parameters, in which case it will attempt to run with the existing grub.conf. (In my case grub.conf bears no resemblance to the options I selected when I installed 11.2, so this is useless.)