Description of problem: An attempted upgrade of a running system to F11 ends up with "fatal errors" because anaconda is unable to mount existing file systems. Actually the following entries in /etc/fstab: /data/home /home bind bind 0 0 /data/usr.share /usr/share bind bind 0 0 trigger that because anaconda attempts to mount /mnt/sysimage/data/data/home, and similar with the other file system, and fails to find those. Luckily a hack of temporary providing 'ln -s . data' in a /data directory of the original installation does not conflict with anything and is enough to placate anaconda. With that in place one can indeed find later in anaconda.log: 19:48:01 DEBUG : isys.py:mount()- going to mount /mnt/sysimage/data/data/home on /mnt/sysimage/home as bind with options bind,bind 19:48:01 DEBUG : isys.py:mount()- going to mount /mnt/sysimage/data/data/usr.share on /mnt/sysimage/usr/share as bind with options bind,bind and an update proceeds like it was supposed to in the first place. Version-Release number of selected component (if applicable): "anaconda version 11.5.0.59 on i386" as used on F11 distro DVDs How reproducible: so far on all tries Expected results: anaconda does not double the first term of a path before prepending result with "/mnt/sysimage"
This should be fixed in the next build of anaconda. Thanks for the bug report.
*** Bug 508932 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > This should be fixed in the next build of anaconda. Thanks for the bug report. I regret having to say so, but this is insufficient as response to https://bugzilla.redhat.com/show_bug.cgi?id=508932 because it leaves the F11-CDs/DVDs in its broken, mostly unusable, shape. An appropriate response would be to ship a "rescue"-iso, rsp. to update Fedora 11's CDs/DVDs.
We do not release updated media for reasons that have been explained at length in a variety of forums. I'm not going to rehash them here. If this bug affects a large number of users, we can release an updates.img and explain it in the common bugs wiki page. That would need to be discussed with QA. However, this is not all that critical of an issue given the easy nature of a workaround - simply temporarily comment out the bind mount line in your /etc/fstab before performing an upgrade.
> simply temporarily comment out the bind mount line in your > /etc/fstab before performing an upgrade. I am afraid that this is not that simple - contrary to a claim in comment #4. Following that advice in a case of a system which caused the original bug report would result in something really seriously hosed. I agree that a workaround is indeed "simple" although it may be not that obvious for many users.
Reopening. Bug is still present in FC12 In my case, anaconda (as on the DVDs) is not able to handle an fstab containing this: /srv/cvs /var/cvs none bind This causes "upgrading" from FC11 to FC12 to abort.
What if you s/none/bind?
(In reply to comment #7) > What if you s/none/bind? How to test this? This machine meanwhile is running FC12 :) I worked-around by temporarily replacing the bind mount with a relative symlink, upgraded and readded the bind mount. Also, c.f. man 8 mount: ... The bind mounts. ... or fstab entry is: /olddir /newdir none bind ...
> > What if you s/none/bind? > How to test this? This machine meanwhile is running FC12 :) I would propose to boot your current installation "rescue" from whatever media you were using while upgrading and observe if anaconda is able or not to mount all your file systems depending on a content of /etc/fstab.
Re: comment #6 This is entirely new bug. The only thing in common with this one is that it happens for "bind" mounted file systems. It affects also, not that surprisingly, attempts to boot "rescue". See bug 541473 for details and a workaround. Bug 506396 was indeed fixed and replaced by a new surprise.