Comment 28 for bug 554718

OK, I think I finally have a reasonably good idea of what's going on with this now. I had been focused on udev and udisks, but it turns out that the bug appears to actually be in devicekit-disks. Here's a rough timeline of what happens:

1. During the Karmic->Lucid upgrade, devicekit-disks package is removed, which includes its udev rules (/lib/udev/rules.d/95-devkit-disks.rules). The daemon (devkit-disks-daemon) is still hanging around, however.
2. Later on, during the upgrade, the command 'udevadm trigger --subsystem-match=block --action=change' is issued (it happens to be in udisks). When this happens, devicekit-disks' data items (e.g. DKD_*) are removed from the udev database.
3. The devkit-disks-daemon gets notified that 'sda' has changed. During the change processing, it discovers that 'sda' is a 'removable' device and because the DKD_* udev entries are no longer present, it determines that 'sda' has no media present and then proceeds to perform a force unmount on /dev/sda1. This unsurprisingly results in a broken system.

Since devicekit-disks is deprecated, I am thinking that perhaps the simplest fix would be to add a devicekit-disks.prerm that simply stops the daemon before removing the package. I've run the upgrade with the attached devicekit-disks.prerm file and the upgrade completed successfully.

Note that udisks does not appear to exhibit this same issue because the media_available logic has been changed. See this change: http://cgit.freedesktop.org/udisks/commit/?id=c8d02e0cc26a7559063b98de05f8a4ee07f1de2b. Perhaps a safer fix would be to backport this change to devicekit-disks (and not rely on the daemon not being running).