Grub2 grumbles

D. Hugh Redelmeier hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org
Fri Nov 12 23:28:27 UTC 2010


| From: Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>

| On Fri, Nov 12, 2010 at 12:41:15AM -0500, D. Hugh Redelmeier wrote:
| > | From: D. Hugh Redelmeier <hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org>
| > 
| > | Context:
| > | 
| > | Summary: I need to triple boot:
| > |   Ubuntu 10.10
| > |   Ubuntu 10.04
| > |   Windows 7
| > | 
| > | I use 10.10's Grub2 as the bootloader that chooses amongst these
| > | things.
| > 
| > Giving up, I have decided to use 10.04's bootloader as the bootloader.
| > 
| > So: I want to put 10.10's boot sector on 10.10's partition's boot
| > sector (not the Master Boot Record).
| > 
| > Here's grub2 being unwilling:
| > 
| >     $ sudo grub-setup '(hd0,5)'
| >     [sudo] password for hugh: 
| >     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 their use is discouraged..
| >     grub-setup: error: if you really want blocklists, use --force.
| >     $ 

That message isn't clear.  If a clear message won't fit, include a URI
for a reasonable description.

It turns out that with --force this works and is probably (not sure)
as robust as with grub-legacy.

| > I cannot really understand that message.  Installing a boot block on a
| > partition is perfectly normal and reasonable.  If grub2 cannot handle
| > that, it is pathetic.
| 
| No, it really is absolutely correct.
| 
| grub1 had a small stage 1.5 for each filesystem which it would blockmap
| (or embed if it fit) and install stage1 with that blockmap so that grub
| could boot.  If you ever touched those files, grub broke until you
| reinstalled the stage1 in the boot sector.

You are using the same jargon as is confusing in that message.

"Embed", the English word, does not mean "stick in an otherwise
normally unused portion of a disk drive".

"blockmap" means a list of physical block addresses (refinement:
extents) so that the bootloader can find a particular file in a
filesystem without actually understanding the filesystem.

A simple bootloader can be neutral (OS-instance-agnostic).  A complex
one cannot.  Since it is tied to a particular bootable partition, it
ought to be able to live in that bootable partition.  Look at the use
cases that I presented (partially implicitly) in my first message.

If a boot loader must use "embedding", then likely only one can exist
on a disk.  Since I have multiple bootable systems on my disk, each
with different configurations and procedures, I need multiple boot
loaders.  Bzzzt, we have a problem.

LILO needed to have a blockmap, not only for bootstrapping itself in,
but for accessing the kernel image.  This was very inconvenient
because one had to run the lilo installer whenever adding or deleting
a kernel so that the blockmaps could be built.

Grub-legacy only needed a blockmap to bootstrap itself.  The blockmap
would need to be rebuilt only when a new grub was installed.
Grub-legacy understood filesystems sufficiently to load a kernel by
name and not by blockmap.  This was a pretty pleasant tradeoff.  After
all, grub changes rarely and an update package's script could handle
that.

| grub2 is modular instead of being monolithic.  Not to avoid the breakage
| issue, grub2 wants to avoid blockmaps (since those break if the files are
| ever touched without reinstalling grub to the boot sector, just as lilo
| was easily broken, since it too was blockmapped, but lilo was worse in
| that it also blockmapped the kernel and ramdisks).  The way grub usually
| does this, is to make an image with the modules required by the current
| system (so raid, ext2/3/4 filesystem, lvm, msdos partitions, etc) and puts
| that into the first track of the harddisk between the partition table and
| the first partition (there is almost always 62 sectors available there,
| unless you use EFI style GPT partitions in which case there isn't really
| any room, but GPT has a dedicated boot partition type that grub uses
| instead in that case).
| 
| Now as the message says, if you really want to go back to the old
| unreliable way of doing things, go right ahead, but you have to explicitly
| tell it to force that bad idea to happen.

So: is  or is not grub2 with blockmap more fragile than grub-legacy?
It need not be.

| > There is a gap of over 2000 sectors (almost a megabyte) before the first
| > partition starts.
| 
| Exactly 1MB I suspect.  Modern windows versions aligh partitions on 1MB.

1MB less the boot sector (i.e. almost a megabyte).

| > I'm getting seriously annoyed with grub2.
| 
| You are annoyed that they got rid of a major source of breakage?

Because they tell me not to do something that is reasonable to do.
And that I used to be able to do.  And telling me in obscure language.

| Just use that 1MB of space you are wasting anyhow, and it will work much
| better and be much more reliable.  It's not like you can use it for
| anything else useful.

If I can live with a single bootloader.  I cannot.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list