Comment 1 for bug 210620

I determined that ubiquity, and particularly os-prober, was leaving partitions mounted and that subsequent mounts would be mounted atop older ones. Ubiquity's components necessarily try to access already mounted partitions through existing mount points. When it does so it makes no attempt to remount the partitions and usually proceeds fine. When it accesses a problem mount point the previous mount is hidden and ubiquity (and any other process on the system) will be fooled into thinking it is looking at the first partition while really looking at the last one (until the bad mounts are corrected).

Testing with just the os-prober component of ubiquity created the same bad mounts. The bad mounts weren't always the same. I believed that something, probably the new nautilus version, was accessing new mounts, sometimes preventing umounts from ubiquity from running successfully.

More information:

os-prober doesn't check the status of umount commands. I also discovered that setting the new gconf property

/apps/nautilus/preferences/media_autorun_never

to *true* allowed proper operation in every subsequent ubiquity test and got rid of the nautilus pop ups. This did not allow os-prober to complete properly every time but was a great help.

Logging off all gnome sessions was successful in getting mount/umount sequences to run on tty1. Logging on created problems with those sequences on tty1.

(I believe that something other than nautilus or gnome volume manager also is probably, very briefly, accessing new mounts).

Adding a test to os-prober's umounts to retry after a short sleep solves the hang and incomplete list problems but doesn't address the pop-ups and obviously slows ubiquity. Setting the above property solved all three problems on my system in my tests, but there still seems to be something to potentially interfere with ubiquity other than nautilus, though much, much, less frequently. I respectfully suggest that you consider applying patches similar to both of those below.