More Fedora Core 4 Anaconda fun
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
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
/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.
mkswap -L didn't work, I now have the sinking feeling that
this problem is going to reappear next upgrade.