grub2 status

[Colin Watson]

I thought you might like some idea of what's going on with grub2, since
it's one of the RC bug hotspots.

You could be forgiven for looking at the RC bug activity over the last
couple of days and thinking that it's all gone to hell in a handbasket
with recent uploads.  In fact, aside from an interesting case which
turned out to be due to botched handling of the GRUB Legacy -> GRUB 2
chainloading setup (which prompted me to fix three other RC bugs along
the way), all the recent problems people have been having have been
duplicates of one of these bugs which have existed essentially forever:

  #554790 - grub-pc/install_devices uses unstable device names
  #583271 - device.map uses unstable device names

The reason why there was a massive flood of problems with
1.98+20100614-1 is that the interface between the core image (usually
embedded in the MBR gap) and /boot/grub/*.mod changed on 2010-06-10.
This is an internal interface and not something GRUB upstream even keeps
track of - the core image and modules must be in sync in order for GRUB
to work properly.  However, since this interface only changes every so
often, it's common enough for people to not notice configuration
problems for a while, but then we get massive spikes of bug reports any
time the interface changes.  It doesn't mean the bugs are really new,
but they get interpreted as regressions from the version in testing.
Any problem that causes the core image to be installed to a disk other
than the one actually being booted from, or not to be installed at all,
will show up this way.

I've been playing whack-a-mole for a while, but I think the only way I'm
going to get a new grub2 into testing is to fix these two general
problems in a general way.  I'd hoped to defer #554790 until I'd got a
reasonably current snapshot into testing, since I know from experience
in Ubuntu that this is a very delicate business and I expect new
problems to arise from it to start with, but absent release team
intervention (which I think, on balance, would be unjustified) I don't
think I have a lot of choice.


The other outstanding RC bugs mostly now relate to LVM snapshots and to
RAID.  I still intend to defer these until after I've got something more
recent into testing; most of these are not particularly new problems.
The exception is the lack of support for mdadm 1.x superblocks, which
got much more severe recently when that became mdadm's default.
However, I don't have a quick fix for this bug.  There is an upstream
branch, which I've been working on updating, which should give us
support for 1.x superblocks, so the situation is certainly not hopeless
for squeeze.


The main thing that worries me is that apparently testing has now moved
to using symlinks in /dev/mapper/, and the version of grub2 in testing
breaks with this setup (#550704).  Even though I fixed this in unstable
three weeks ago, I'm pretty certain now that it's going to be at least
two more weeks before we can get a fix in by the normal mechanisms, and
in the meantime everyone using LVM and grub2 in testing is hosed (e.g.
#586330, #586447).  I'm concerned that this is going to lead to a bunch
of testing users switching away from grub2, which is going to impair my
ability to get good feedback.

I'm not entirely impressed with testing switching over to this new
scheme in advance of the default boot loader supporting it, but I guess
that's just how things work out sometimes and I realise there was a long
delay between Bastian filing that bug and us fixing it.  Rather than
stamping my feet and demanding that this be reverted, I think a better
approach is to get a new grub2 version into testing that fixes just this
one bug, and doesn't introduce any core/module interface changes so we
won't trip over any of that class of regressions in the process.  The
patch is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550704#37;
it would need a bit of adjustment to apply to 1.98-1, but that's quite
straightforward.

Would it be possible for me to upload such a change to
testing-proposed-updates, or whatever the side channel for testing is
these days?  I might need a reminder as to the right process, but I'm
happy to put all the bits together.  This would make it easier to see
the wood for the trees in other bug reports.

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]