Bug#239111: Grub is shockingly bad code

[Robert Millan]

On Mon, Jan 12, 2009 at 08:28:19PM +0100, Robert Millan wrote:
> 
> It's not the log file.  Joeyh tried that (see the bug log).
> 
> I'm almost certain it's the fwrite() call in install_func.  I could be
> wrong, but I still don't see why we would want to use xfs_freeze anyway.
> 
> And if we _really_ need xfs_freeze, it means we're doing something wrong.

Ah, I remember.  There was a sanity check.  The GRUB shell tries to read the
file using its own filesystem driver, to make sure real GRUB will be able to
do it as well.  At least, that's what we do in GRUB 2.

It would seem that running sync would suffice for that.  Unfortunately, it
seems that:

  - sync is not enough
    (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#53)

  - xfs_freeze could hang even if you don't write anything
    (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239111#194)

This is odd.  I think I'm going to assume sync does what is expected from
it.  If it doesn't maybe it's a bug in Linux, which maybe got fixed already,
or maybe it's a (lesser) bug in GRUB which we can't find untill it's
exposed.

In any case, we're better off not using xfs_freeze untill we know for sure
why it is needed, and are certain it won't cause hangs.

I'm waiting for Ron's confirmation that this works for him, and then I'll
remove the patch & upload.

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