grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea.

Bug #445416 reported by philinux on 2009-10-07
54
This bug affects 10 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: grub2

This error message gets spitted out everytime grub gets updated. Similar message from installer when installing grub2 to a partition.

Setting up grub-common (1.97~beta3-1ubuntu8) ...
Installing new version of config file /etc/init.d/grub-common ...

Setting up grub-pc (1.97~beta3-1ubuntu8) ...
grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea.
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.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

ProblemType: Bug
Architecture: amd64
Date: Wed Oct 7 14:05:55 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: grub2 (not installed)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-12.40-generic
SourcePackage: grub2
Uname: Linux 2.6.31-12-generic x86_64

philinux (philcb) wrote :

On Wed, Oct 07, 2009 at 01:09:01PM -0000, philinux wrote:
> This error message gets spitted out everytime grub gets updated. Similar
> message from installer when installing grub2 to a partition.
>
> Setting up grub-common (1.97~beta3-1ubuntu8) ...
> Installing new version of config file /etc/init.d/grub-common ...
>
> Setting up grub-pc (1.97~beta3-1ubuntu8) ...
> grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea.
> 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.

Well, it's correct - I think the warning is justified. Does GRUB work
for you for the meantime? If so, I don't really consider the warning a
bug since it points to a genuine unreliability in your setup that can
only be fixed by not doing this (for example, many kinds of filesystem
changes will make your system unbootable unlelss you run grub-install
again afterwards).

philinux (philcb) wrote :

Yes I'm chainloading fine from Jaunty on disk 1 to grub2 on disk2.

Never got a warning from grub legacy.

Tim Besard (maleadt) wrote :

I've come across the error as well, when attempting to move my setup (which includes a "master boot partition" which chainloads partition-based grub setups) from -legacy to grub2; where -legacy functioned perfectly. I however chickened out and reverted to -legacy, so I cannot comment the fact if grub2 does work at all when booting from a partition boot record.

mikeXYZ (qmikeq) wrote :

Just a general comment as I stumble on this "bug" report:
I have routinely installed GRUB 2 to various partition boot sectors
(as with sudo grub-install /dev/sdxn), and never had a problem using that to
chainload the partition. I do, however, get that Warning message
(This is a Bad Idea, etc.). During installation of Kubuntu 9.10, using
Manual partitioning option, Summary Step, Advanced button (at lower
right), I have also had the installer put GRUB 2 into a partition (sdxn)
rather than a MBR (sdx). Again, no problems doing that or using it afterwards
(e.g., to chainloader that partition). I do find that warning message to
be confusing; never had such with GRUB legacy.
-- Just an fyi.

Stephen Warren (srwarren) wrote :

This setup has also worked for me for many years with both LILO and grub-legacy.

Does the filesystem (or even block device?) typically reserve the first "track" of any partition specifically for this purpose? That's certainly the way it works when installing grub to the MBR; it uses the space reserved before the first partition on the disk, which seems just as dicey in the presence of non-standard partitioning...

khitschler (klaus-hitschler) wrote :

I did'nt manage to put the boot into the partition's boot sector during a normal kubuntu installation. With grub-legacy I've done this multiple times. It was my standard setup to use the MS-Windows boot manager to choose what OS to boot. You know it: 'dd if=/dev/sda6 of=sda6.bin count=1 bs=512', move sda6.bin to Windows and adapt the Windows boot manager's settings. But I recognized that my sda6.bin did'nt contain what I'm expecting. So -after installing the boot into the MBR - I tried to 'sudo grub-install /dev/sda6' and got this messages:

xxxx@xxx:~$ sudo grub-install /dev/sda6
[sudo] password for xxxx:
grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea.
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.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

(hd0) /dev/sda

Here are the contents of the first 512 bytes of /dev/sda6:
xxxx@xxx:~$ sudo dd if=/dev/sda6 count=1 bs=512 | hexdump
1+0 Datensätze ein
1+0 Datensätze aus
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
512 Bytes (512 B) kopiert0000200
, 5,5616e-05 s, 9,2 MB/s

My hard disk's partions, fetched with parted:
(parted) print list
Modell: ATA SAMSUNG HD502HI (scsi)
Festplatte /dev/sda: 500GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos

Anzahl Beginn Ende Größe Typ Dateisystem Flags
 1 1049kB 106MB 105MB primary ntfs boot
 2 106MB 100GB 99,9GB primary ntfs
 3 100GB 308GB 208GB extended
 5 100GB 108GB 8192MB logical linux-swap(v1)
 6 108GB 308GB 200GB logical ext4

Are there any ideas?

Leo (leorolla) wrote :

There are two different bugs:

* This warning is not clarifying and does not explain the danger, nor does it point to a stable URL for further references.

* Grub2 became so greedy that finally we have the only booting scheme that cannot fit decently and politely inside its own partition, leaving to the owner of the computer the decision of whatever he wants to put inside MBR. This is more arrogant than Windows overriding MBR during install, as for the latter there is at least the reliable circumvention of reinstalling to the MBR whatever was there before.

The second is a severe bug but it should be filed separately.

Changed in grub2 (Ubuntu):
status: New → Confirmed
Jeremy Dawson (jeremy-rsise) wrote :

The warning doesn't explain why blocklists are a bad idea, or how putting grub in the mbr avoids using blocklists. But installing GRUB2 into the MBR is obviously a bad idea. The fact that in the install program, the only way to avoid it is to click on "Advanced" at some point, is quite scary. If you don't know that you have to do this your MBR will be trashed, as I understand it, without warning.

Reasons why putting GRUB2 into the MBR (especially as a default, with no warning, as in the installation program)

(1) If you already have another boot loader into the MBR, it will be trashed.

(2) If you ever install another OS which works the same way, your GRUB2 will be trashed.

(3) Point (1) may be OK if GRUB2 can boot every other OS which now exists or ever will exist. I can't imagine how anyone could believe this, but, specifically, update-grub produces a grub.cfg which has found, but fails to boot, RedHat 9. This might be fixable if GRUB2 had documentation present, but (in Ununtu10.04 it doesn't), so it's not. (By contrast, I can use GRUB as installed by Fedora to chainload to an Ubuntu partition or to boot Ubuntu direct. Even so, I have Fedora's GRUB in it's own partition, because I can't trust that some other OS which I might install in future - such as Ubuntu - will trash it without warning, as would be the case if I had it in the MBR).

(4) If you have suffered from (1) and (3), but your other OS was set up right, ie, it has its own bootloader in its own partition, so you want to chainload to that partition, from GRUB2, the documentation telling you how to do it seems to be missing. Certainly "info grub" seems to point to a very incomplete set of documentation, in Ubuntu 10.04.

Alberto (alberto-torricelli) wrote :

I don't know if this is the right place for my comment.
Anyway, my problem is that every time I make an update that involves the re-installation of grub, it is installed on MBR (instead of /dev/sdaxx, as I have previously done with dev-install /dev/sdaxx --f).
So my favourite bootloader is cancelled after such an update.

I think that it is necessary to find a way to tell the update process to install grub on boot partition, if the user has already decided that.

Alberto (alberto-torricelli) wrote :

Just one point: when I change the drive where grub is installed, it will be remain the same (even after - for istance - a kernel upgrade that (I guess) runs "grub-install"?

Colin Watson (cjwatson) wrote :

If you do it with 'sudo dpkg-reconfigure grub-pc', then yes.

(An error in your question, though: note that kernel upgrades run
update-grub, not grub-install; that only regenerates the menu file.
Only upgrades of grub-pc run grub-install.)

Alberto (alberto-torricelli) wrote :

OK, I'll try.
You are right: I made a mistake.... :) :)
Many thanks.

mathew (meta23) wrote :

I just got this error during upgrade to Ubuntu 10.10, even though I explicitly deselected all partitions and only selected /dev/sdb1.

mathew (meta23) wrote :

D'ohh! Ignore that, I got the sense of the message backwards.

Does having a biosgrub partition (A.K.A bios_grub in GNU parted "set 1 bios_grub ...") prevent the "grub-setup: warn: Embedding is not possible. ..." issue?

See this thread:
https://bbs.archlinux.org/viewtopic.php?id=74740

Jussi (jussi-lahtinen-gmail) wrote :

Is this bug really still unfixed? Should we close this?

Jeremy Dawson (jeremy-rsise) wrote :

There's no indication in any of the messages that the bug is fixed. And I can't see that any of them address my own comments in #9.

As #8 points out there are two issues - (1) the warning itself, which doesn't contain (or point to) a clear explanation of the issue, and (2) the fact that GRUB2 seems to expect to be the only OS present (or that all other OSes present provide boot code within their own partitions).

As it is I use Grub Legacy (having worked out the errors in its documentation) and the IT support folk here (ANU) seem to do the same on the machine they have just installed for me.

Phillip Susi (psusi) wrote :

This isn't a bug: as Colin said, it is warning you that you are using a configuration that is not recommended.

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

Other bug subscribers