Bug#239111: Grub is shockingly bad code

[Robert Millan]

On Mon, Jan 12, 2009 at 06:15:52PM +0000, Robert McQueen wrote:
> severity 239111 grave
> thanks
> 
> Robert Millan wrote:
> > The whole approach is wrong, so maybe it makes sense to avoid it, or maybe
> > it's too late for that, and we should issue a critical debconf warning when
> > XFS is detected.
> >
> > I will have to think about it.
> 
> The problem is that Debian's patch to try and make it work on XFS makes
> it /worse/. It turns "grub-install fails" into "grub-install fucks my
> system". There's no question we should just fix that ASAP by applying a
> patch which just does freeze immediately followed by unfreeze. That's
> why I raised the severity, and I still consider this RC for lenny
> because the upgrade instructions in NEWS.Debian encouraged me to do
> something which bricked my system.
> 
> (Note that although I didn't try it yet, I'm almost certain that Ben's
> approach with a helper binary to run FIBMAP ioctl won't help any more
> than calling sync() will. sync is /not/ broken in XFS - if you call it
> then it does flush the data to disk - the "problem" is that it considers
> metadata synced to the journal as safely sync()'d, so calling it isn't
> sufficient to udate the dentry's for grub to read directly.)
> 
> Given even xfs_freeze is broken in etch's kernel, we can't make
> grub-install work reliably there, but if we put freeze/unfreeze between
> copying the files and invoking grub then it will a) not hose people's
> systems under etch, and b) will work with lenny's kernel. There's also
> no need for a critical warning, because grub-install has to be done by
> the user manually anyway. We should just include the correct advice.
> 
> If you'd answer my question about which kernel / grub versions are
> actually incompatible, then we can choose between the two behaviours.
> If etch's grub can boot lenny's kernel, we can tell XFS users to just
> update grub after rebooting, otherwise we can direct them at some manual
> install instruction and say "please freeze and unfreeze the filesystem,
> run sync a few times, and then have a cup of tea, between copying the
> stage* files and running the grub shell".

Hi Rob,

You just convinced me that this is completely fucked up.  This is not the
first time someone claims to have fixed this problem, only to discover that
it wasn't, and I'm not going to gamble with ioctls, freeze/unfreeze combos
or Linux version checks.

I (and upstream in general) believe that the only right way to rely on a
hardcoded list of blocks that live inside a filesystem is _not to_.

I'll see if it's feasible to make it use embedding, and if not, XFS support
in GRUB Legacy will be terminated, and users will be advised to either
leave /boot/grub untouched or upgrade to GRUB 2.

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