Comment 3 for bug 314004

Revision history for this message
Colin Watson (cjwatson) wrote :

Andy's working install was an upgrade from hardy, and so not affected by this bug.

<cjwatson> so it's true that the order of the kernel recommends is what caused this, but really, accident ...
<cjwatson> let me give you a potted summary of what happened, then
<cjwatson> in intrepid, we enabled recommends by default; this had some speedbumps but largely appeared to be working OK
<cjwatson> (therefore any installs from earlier than intrepid are entirely unaffected by this)
<cjwatson> the alternate/server CD (d-i) installs as I described above, by explicitly choosing whether to install grub or lilo depending on installation parameters; no problem there
<cjwatson> however, the desktop installer works quite differently
<cjwatson> we put a "live filesystem" onto the desktop CD, a preinstalled filesystem image with lots of packages on it that's then copied to the target system
<cjwatson> obviously, there are some things on this image that shouldn't end up on the target system, such as the installer itself
<cjwatson> so we copy the filesystem image file-by-file, and then remove unwanted packages using apt (this is still a lot quicker than installing them all from scratch, and allows us to fit an installable live system onto a single CD)
<cjwatson> the set of packages we remove is computed by taking the set-difference between a "desktop install" and the full live filesystem package list, plus one or two other tweaks
<cjwatson> (things like language packs, removing unused kernels if there's more than one available, etc.)
<cjwatson> for various reasons, the script that builds the live filesystem (in the livecd-rootfs package) installs the kernel before it says "right, that's it, what I've got now is a desktop install"
<cjwatson> and, due to the kernel's Recommends, the bootloader (in this case lilo) is considered as part of the desktop install, and not removed by the installer
<cjwatson> the installer notices that it needs grub, and therefore arranges for it to stay installed as well
<cjwatson> and voila, two bootloaders
<cjwatson> I recommend three fixes for this, and will update the bug accordingly:
<cjwatson> 1) ubiquity should arrange to remove all bootloaders except for the one it's installing
<cjwatson> 2) linux should switch the order of its recommends to suit the modern age (not required given 1, but probably sensible anyway, and I think there may well be other bugs about this)
<cjwatson> 3) update-manager should clean up this mess on upgrade