[conspire] booting squeeze with grub2

Tue May 8 11:48:41 PDT 2012

Quoting Bruce Coston (jane_ikari at yahoo.com):

> Is the debian project still active ?  Grub2 seems unable to boot
> squeeze on my amd64bit hardware with sata drive no matter what . I'd
> file a bug report but others already did that , back in January of
> 2011 .

I've just never particularly liked GRUB2, but... d00d!  If you are
seeking help and information, you need to give more diagnostic data than
the impossibly vague phrase 'unable to boot', which leaves readers with
absolutely nothing to work with.

Honest to god, Bruce, do you _want_ to ensure that you cannot be helped?
Surely you know how this works, by now.  You attempt the thing that
failed _again_, and this time take contemporaneous, detailed notes,
writing down exactly what relevant screen output there is, in
chronological order, so you can then include it in your trouble report
rather than just being limited to useless handwaves like 'unable to
boot'.

I can try to take a stab in the dark, following about fifteen seconds of
Web-searching on 'squeeze grub2 amd64' and quote this on a wild surmise
that it might be relevant to your problem:

  Nowadays, with GRUB 2, attempting to install GRUB in a partition boot
  sector in the usual way with grub-install will fail, warn about
  "Embedding not possible", and instruct you to use --force if you want
  to do it anyway. It's nothing to worry about. It's not a new issue.
  And legacy GRUB has always had the same exact issue. But it never
  bothered to stop and warn about it. Now GRUB 2's grub-install command
  won't do it unless you use --force. I guess it's possible for someone in
  a hurry not to notice the new output of grub-install in GRUB 2 and only
  think GRUB got installed in a designated partition boot sector. Just a
  theory.

http://forums.debian.net/viewtopic.php?f=17&t=59981

Reading further, it seems that the authors of GRUB2 are attempting to be
conservative in not relying by default on something called 'Blocklist
mode', thus echoing to screen in such cases a warning that 

  /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 their use is discouraged..
  /usr/sbin/grub-setup: error: if you really want blocklists, use --force.

I.e., grub-install --force

Here's a page that partially explains the problem with blocklists:

  It is also possible to specify files to GRUB that do not actually
  appear in the file system, such as a chain loader that appears in the
  first few blocks of a partition. To load such files, provide a blocklist
  that specifies block by block where the file is located in the
  partition. Since a file is often comprised of several different sets of
  blocks, blocklists use a special syntax. Each block containing the file
  is specified by an offset number of blocks, followed by the number of
  blocks from that offset point. Block offsets are listed sequentially in
  a comma-delimited list.

  The following is a sample blocklist:

            0+50,100+25,200+1

  This sample blocklist specifies a file that starts at the first block on
  the partition and uses blocks 0 through 49, 100 through 124, and 200. 

This page from Arch Linux is a little better:

  The reason why grub-setup does not by default allow this [blocklist
  reliance] is because in case of partition or a partitionless disk is
  that grub2-bios relies on embedded blocklists in the partition
  bootsector to locate the /boot/grub/i386-pc/core.img file and the
  prefix dir /boot/grub. The sector locations of core.img may change
  whenever the filesystem in the partition is being altered (files
  copied, deleted etc.). For more info see
  https://bugzilla.redhat.com/show_bug.cgi?id=728742 and
  https://bugzilla.redhat.com/show_bug.cgi?id=730915.

  The workaround for this is to set the immutable flag on
  /boot/grub/i386-pc/core.img (using chattr command as mentioned above)
  so that the sector locations of the core.img file in the disk is not
  altered. The immutable flag on /boot/grub/i386-pc/core.img needs to be
  set only if grub2-bios is installed to a partition boot sector or a
  partitionless disk, not in case of installtion to MBR or simple
  generation of core.img without embedding any bootsector (mentioned
  above). 

https://wiki.archlinux.org/index.php/GRUB2

So, basically (1) you're (probably) having a problem because you 
ignored grub-install's warning about its default reluctance to install a
setup it knows is going to be unreliable because the blocklists by which
it'll be finding core.img may become invalid if the file later gets moved.

(2) You can fix this problem by either:

  2a running grub-install with the '--force' flag, and then ideally
hammering core.img into place by running 'chattr +i /path/to/core.img'
as the root user, or

  2b installing your bootloader to the MBR an making the whole issue
with blocklists go away.

(3) GRUB2 is an overengineered piece of bloated rubbish.  Here's an
idea:  How about using something simple and reliable?  If nothing else,
lilo is still fine for old-style IBM/Microsoft partition tables, and
elilo is likewise for EPT partition tables.  And anyway, y'know, make
life simple for yourself and put your bootloader in the MBR already.

https://www.centos.org/docs/5/html/Installation_Guide-en-US/s1-grub-terminology.html

 I guess I'll download GUJIN and superGRUB2 as the buntu ppa's that might help with this didn't do anything on my live discs . 
>  - Immensely Confused - Bruce
> 
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire