Grub doesn't install to partition boot record (PBR)

Bug #574883 reported by Christof Löwe
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Expired
Medium
Unassigned

Bug Description

Binary package hint: grub2

What i wanted to do is to install grub into the PBR to be able to chainload it from the grub menu from the grub in the master boot record.
But grub is not installed into PBR, nor by the alternate cd''s installer nor by running the grub-install command with --force-Option from from the runnning system or from the live system. It says bloklists are not recommended, but "installation finished, no error reported". But theres is no bootable Grub then. Choosing the chainload entry in the MBR's Grub shows "Invalid signature".

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: grub-pc 1.98-1ubuntu5
ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-21-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue May 4 04:32:05 2010
InstallationMedia: Kubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100406)
ProcEnviron:
 LANGUAGE=
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: grub2

Revision history for this message
Christof Löwe (christof-loewe) wrote :
Revision history for this message
Wolle (onkel-wolle) wrote :

I can reproduce exactly the same behaviour.

I installed the bootloader of my choice to MBR and intended to chainload several other OS from that.

Two of those OS should be Mint10-64bit (based on Ubuntu 10.10 64bit) and CAELinux (based on Ubuntu 10.04 bit). Installing GRUB2 to their respective partition boot records didnt succeed either with the standard Mint10 installation procedure (Though I could select /dev/sda6 during installation!) or with both Live systems.

In both of the live systems I did the following:

#### start code ####
caelinux@caelinux:/$ sudo grub-install --force --root-directory=/mnt /dev/sda6
/usr/sbin/grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea..
/usr/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is discouraged..
Installation finished. No error reported.

caelinux@caelinux:/$ sudo fdisk -l 2>/dev/null | egrep "Disk /|/dev/" | sed "s#^/dev/#Part /dev/#" | awk '{print $2}' | sed 's/://' | xargs -n1 -IX sudo sh -c "hexdump -v -s 0x80 -n 2 -e '2/1 \"%x\" \"\\n\"' X | xargs -n1 -IY sh -c \"case \"Y\" in '48b4') echo X: GRUB 2 v1.96 ;; 'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 oder höher ;; *) echo X: Kein GRUB Y ;; esac\""
/dev/sda: GRUB 2 v1.97 oder höher
/dev/sda1: Kein GRUB 00
/dev/sda2: Kein GRUB ffff
/dev/sda5: Kein GRUB 00
/dev/sda6: Kein GRUB 00
/dev/sda7: Kein GRUB 00
/dev/sda8: Kein GRUB 00
/dev/sda9: Kein GRUB 00
#### end code ####

This is reproducible. Apparently the grub-install command doesnt do, what it should per definition (Id say the man page is definition) but gives a success message anyway. Chainloading the respective partition PBRs results in the above mentioned "invalid signature".

Revision history for this message
Wolle (onkel-wolle) wrote :

I continued to search for a solution and found:
http://www.gnu.org/software/grub/manual/grub.html#Installing-GRUB-using-grub_002dinstall

The I tried, what the manual proposes for some USB devices (last paragraph of the refered section):
#### start code ####
caelinux@caelinux:~$ sudo -i
root@caelinux:~# losetup /dev/loop1 /dev/sda6
root@caelinux:~# mount /dev/loop1 /mnt
root@caelinux:/# grub-install --force --root-directory=/mnt /dev/loop1
/usr/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk. This is a BAD idea..
/usr/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and its use is discouraged..
Installation finished. No error reported.
root@caelinux:/# umount /mnt
root@caelinux:/# losetup -d /dev/loop1
root@caelinux:/# exit
logout
caelinux@caelinux:~$ sudo fdisk -l 2>/dev/null | egrep "Disk /|/dev/" | sed "s#^/dev/#Part /dev/#" | awk '{print $2}' | sed 's/://' | xargs -n1 -IX sudo sh -c "hexdump -v -s 0x80 -n 2 -e '2/1 \"%x\" \"\\n\"' X | xargs -n1 -IY sh -c \"case \"Y\" in '48b4') echo X: GRUB 2 v1.96 ;; 'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 oder höher ;; *) echo X: Kein GRUB Y ;; esac\""
/dev/sda: GRUB 2 v1.97 oder höher
/dev/sda1: Kein GRUB 00
/dev/sda2: Kein GRUB ffff
/dev/sda5: Kein GRUB 00
/dev/sda6: GRUB 2 v1.97 oder höher
/dev/sda7: Kein GRUB 00
/dev/sda8: Kein GRUB 00
/dev/sda9: Kein GRUB 00
#### end code ####

This obviously seems to work - at least GRUB is written to the PBR...

Why do I have to trick grub-install with a loop device? Isnt the --force option enough of a safeguard against users decisions?

DISCLAIMER!!!! This is just, what I found to appear as if it maybe could work!
Anybody who attempts something like that does so on his own risk!
I tried all of this on an empty hard disk, make sure you have complete and up-to-date backups before performing this somehow twisted approach!

Revision history for this message
Wolle (onkel-wolle) wrote :

The above described obviously does only write parts of GRUB to the designated PBR.

Performing

#### start code ####
insmod chain
chainloader (hd0,6)+1
#### end code ####

in order to chainload the partition prepared in the above mentioned way produces an error message

"Booting a command list" after which the system seems to halt/freeze...

Revision history for this message
Wolle (onkel-wolle) wrote :

In a next attempt, I tried to install SliTaz3.0 into sda1, which brought its bootloader grub-legacy (installed to MBR of sda). I intended to use Slitaz for maintainig the main bootloader which would be grub-legacy then.

Installing grub2 into the PBR of sda6 failed again, exactly the same results as above.

Conclusion: grub2 doesn't care about any other distro installed, doesn't care about any kind of boot code in the MBR... it just refuses to be installed in the PBR of sda6.

Maybe it would install to the PBR of a primary partition, as sda6 is a logical one...?

I'd say this is one or even two bugs:
-Grub2 doesn't install, where it should
-Grub2 gives a wrong result message

Revision history for this message
Colin Watson (cjwatson) wrote :

Hmm, how odd. I'll see if I can set up a few virtual machines to test this out. In the meantime, could you please add the --debug option to grub-install and post the output? That might speed things up for me.

Changed in grub2 (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Wolle (onkel-wolle) wrote :

Okay, I'll give it a try later this day.

In another discussion on this topic in a forum, I was advised to check the exit code. The grub-install command as stated above produces exit code 0.

To speed things up: Would you like to have any other information than the output of grub-install, the bootinfoscript and the grub detection command as stated above?

Revision history for this message
Wolle (onkel-wolle) wrote :

$ sudo grub-install --force --debug /dev/sda6 > grub-install.log 2>&1

$ sudo fdisk -l 2>/dev/null | egrep "Disk /|/dev/" | sed "s#^/dev/#Part /dev/#" | awk '{print $2}' | sed 's/://' | xargs -n1 -IX sudo sh -c "hexdump -v -s 0x80 -n 2 -e '2/1 \"%x\" \"\\n\"' X | xargs -n1 -IY sh -c \"case \"Y\" in '48b4') echo X: GRUB 2 v1.96 ;; 'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 oder höher ;; *) echo X: Kein GRUB Y ;; esac\""
/dev/sda: GRUB 2 v1.97 oder höher
/dev/sda1: Kein GRUB 00
/dev/sda2: Kein GRUB c3eb
/dev/sda5: Kein GRUB 00
/dev/sda6: Kein GRUB 00
/dev/sda7: Kein GRUB 00
/dev/sda8: Kein GRUB 00
/dev/sda9: Kein GRUB 00

$ sudo ./boot_info_script055.sh
Identifying MBRs...
Computing Partition Table of /dev/sda...
Searching sda1 for information...
Searching sda2 for information...
Searching sda5 for information...
Searching sda6 for information...
Searching sda7 for information...
Searching sda8 for information...
Searching sda9 for information...
Finished. The results are in the file RESULTS.txt located in /home/wolle

Revision history for this message
Wolle (onkel-wolle) wrote :

Interesting: unknown boot code (?) on sda2 ??

Revision history for this message
Wolle (onkel-wolle) wrote :

As I just reviewed this, I wanted to add, that the line

"/usr/sbin/grub-setup: info: »/boot/grub/device.map« kann nicht geöffnet werden."

in attachment grub-install.log would be

"/usr/sbin/grub-setup: info: »/boot/grub/device.map« cannot be opened"

in English. Usually the file really doesn't exist, but one time (before this very time) I tried to build that file by invoking grub-mkdevicemap manually. The overall result was just the same. Apart from this the device mapping seems to be correct anyway. The rest of the log should be mostly in English...

Is it possible, that grub-install fails to determine the correct position to write? Maybe it installs in sda2 or sda5 or even worse: somewhere in my data? Is there any risk in invoking grub-install this way regarding the consistency of my data?

PS: While testing this, there was a memory stick (sdc, 3 partitions, including one live system) and another hard disk (sdb, just backupped data, no system, no boot loader) present. I cut those parts out of the RESULTS.txt, but some lines in grub-install.log still give evidence of this... ;)

Revision history for this message
Renate (yollywau) wrote :

grub-pc 1.99~rc1-1ubuntu2 in natty doesn't want to go in PBR, not in a primary partition.
"blocklists are not recommended...." and no grub.

Revision history for this message
Phillip Susi (psusi) wrote :

I'm not able to reproduce this on a current release, are you?

Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]

Changed in grub2 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.