Bug#239111: Grub is shockingly bad code

[Robert Millan]

On Mon, Jan 12, 2009 at 07:57:44PM +0000, Robert McQueen wrote:
> I didn't test that, I was basing on my experiences of installing GRUB
> manually. I usually do:
> 
> mkdir /boot/grub
> cp -a /usr/lib/grub/i386-pc/* /boot/grub
> vi /boot/grub/device.map
> grub --device-map=/boot/grub/device.map
> # doesn't work because XFS hasn't put /boot/grub onto disk ...
> # swear a bit
> xfs_freeze -f /
> xfs_freeze -u /
> grub --device-map=/boot/grub/device.map
> # works
> update-grub
> # makes me a menu.lst file
> 
> This never froze for me.

I wasn't aware you were running xfs_freeze by hand.

But I don't trust that this won't hang the kernel.  See the link I pasted in
the previous mail.

This situation is very unfortunate.  If we call xfs_freeze, we risk hanging
Linux.  If we don't, we risk the file being inaccesible.  As you point
out, an error message is preferable to hanging the kernel, but it's a
certain error message against a possible but unlikely hang.  Maybe we should
go with the latter then?

In any case, both are better than a certain hang which is what we have now.

> > And if we _really_ need xfs_freeze, it means we're doing something wrong.
> 
> I thought the wrongness was well known: the GRUB shell tries to read the
> block device directly and traverse the filesystem directories itself to
> to find which blocks on the disk are where the stage* files are located.

No, this is a missunderstanding (which I got misled with, too).  GRUB only
tries to verify that the file will be readable later on (that is, when
Linux isn't running).

stage1 is the MBR.  stage1.5 is supposed to be embedded after the MBR.
stage2 is in the filesystem, and only accessed using the filesystem driver
in stage1.5.

> XFS considers putting the metadata into the journal an acceptable
> implementation of sync(), but grub's filesystem reading code ignores the
> journal, so can't find the files. If the shell used FIBMAP ioctl to find
> the blocks when running under the OS, it'd always find them and all
> would be sweetness and light.

We can't do that.  Using kernel facilities to find the blocks would defeat
the point of verifiing that GRUB can read the file.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."