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 [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
