Grub2 grumbles

[Lennart Sorensen]

On Fri, Nov 12, 2010 at 06:28:27PM -0500, D. Hugh Redelmeier wrote:
> 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.
> 
> 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.

Well grub2 on efi systems and on powerpc systems in fact uses a dedicated
boot partition to be embedded in.  It does NOT install in any way to a
partition that contains the OS to boot.  So in fact it should usually
NOT install on the partition where the OS is.

You can in fact have multiple boot partitions on those setups, so you
have a boot partition per OS with a bootloader installed. You could use
GPT and use that setup.  Works quite well apparently.

> 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.

See GPT option above.

> 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.

But still fragile.  Any changes to the filesystem (resizing, moving,
etc) could break the blockmap.  It was fragile, although much less so
than lilo.

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

No grub2 with a blockmap is exactly the same as grub-legacy.

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

True.

> | > 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.

It was not that obscure, and just because they used to do it doesn't
mean it was a good idea, it was just the best they had at the time
(and a vast improvement over lilo).  They are trying to make things
better, and they are trying to not silently do a suboptimal install,
by telling you that what you are about to do has consequences and making
you confirm your intent.

> If I can live with a single bootloader.  I cannot.

I honestly can't imagine wanting more than one bootloader on a machine.

If I ever want to play with other linux distributions than the one on
my machine, I will use a virtual machine.  My machine only has the OS
installed that I use.

-- 
Len Sorensen
--
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