Another day, another Fedora Core 4 Anaconda bug stumbled over. This time it is #160911, where if your system has any bind mounts, Anaconda can't upgrade it and aborts. (Some other systems call bind mounts 'loopback mounts'.) From the error message that I remember, it seems that Anaconda was trying to treat the source directory as a disk device and not getting very far.

Naturally I was in too much of a hurry to actually get our central fileserver upgraded to remember to save any debugging logs that Anaconda might have written. (Suggestion to the Anaconda people: make Anaconda automatically save its logs any time it aborts an installation. Disk space is cheap, you can put a message in about it, and it will save everyone a bunch of effort.)

Workaround: assuming that the bind mount is not for anything vital, temporarily comment it out of your /etc/fstab. Remember to comment it back in before you bring the system up, or things may explode. (If the bind mount is for something vital, I believe you are up the creek. Watch #160911 for updates.)

The thing that really irritates me is that this is a new Anaconda bug; the Fedora Core 2 Anaconda did this right. And I know that because we upgraded this very central fileserver, with this very bind mount, from Red Hat 7.3 to Fedora Core 2 without problems.

It is depressing to think that perhaps the best advice for the future is 'don't do anything on a new Fedora Core without reading the Anaconda buglist front to back'. Or maybe the entire bug list, given the (finally fixed) X bugs mentioned in FC4FirstIrritations.

An update on the unlabeled swap partitions bug

Since I managed to get our central fileserver upgraded, clearly I worked around the 'Multiple devices are labelled' bug I covered in AnotherFC4AnacondaBug. Unfortunately, mkswap -L didn't do it, either with the FC4 source code recompiled on FC2 and run while the system was up, or in the FC4 installer environment itself.

Eventual workaround: totally zeroing out both swap partitions with dd from /dev/zero. This meant that our Fedora Core 4 install came up without swap partitions (since they did not have valid signatures), but fortunately the server has enough memory that it doesn't need swap to boot. After it came up I used mkswap -L on both partitions.

Since mkswap -L didn't work, I now have the sinking feeling that this problem is going to reappear next upgrade.