Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
If you're getting a traceback, please attach the complete file to this bug report. Otherwise, there's really nothing we can do since there's no information to go on here.
Sorry! Fighting with a "user-friendly" interface. Description of problem: With bind-mounted devices presend in /etc/fstab anaconda fails to mount file systems. This happens both during upgrades and when attempting to perform a "rescue" boot. An error, or errors, in storage.log look like follows: ERROR: FSError: device /mnt/sysimag/...<whatever>... Note this "/mnt/sysimag/" instead of "/mnt/sysimage/". Corresponding alerts will pop up on a "main" screen telling that this is fatal (when upgrading) and that the only option is to reboot. Swell! A workaround is as follows: - once a shell is already available but before allowing anaconda to try to mount or search for _any_ filesystems - switch to a shell on vt2 - cd /mnt ; ln -s sysimage sysimag At that point /mnt/sysimage will be not there yet but it does not matter. With such symlink in place go back to a "main" anaconda screen and continue as usual. Now in anaconda.log something like that will show up DEBUG : isys.py:mount()- going to mount /mnt/sysimag/...<whatever>... and things will continue as normal. Version-Release number of selected component (if applicable): anaconda version 12.46 as used on installation images for F12 How reproducible: always when bind-mounts are used Expected results: Guess!
re comment #1: No, I am not getting a traceback. I think that all needed information is already described but if you want some logs (not too much relevant see there over what is already above) then I can provide.
Your /etc/fstab would be handy to help track this down. There's a couple tricky things about bind mounted filesystems that might be screwing it up, like what kind of filesystem you use, the order things are listed, etc. Thanks.
Created attachment 373903 [details] a sample /etc/fstab which give hiccups to anaconda > Your /etc/fstab would be handy to help track this down. Sure! This is really from a test system which I "rigged" by moving a whole content of /usr/share/emacs/site-lisp/ to /usr/local/share/emacs/site-lisp/ and by adding a corresponding mount to /etc/fstab as attached. So in some sense this is rather "minimal". I checked that a modified system works as expected. I have "real life" examples more involved than that. After I did this I tried to run an F11->F12 upgrade with described results. A failing rescue boot was checked on an already upgraded system (which was upgraded with a help of a described workaround).
*** Bug 541990 has been marked as a duplicate of this bug. ***
Please attach the /tmp/anaconda.log and /tmp/storage.log files -- partial error messages are not very useful in comparison with complete log files.
Created attachment 374833 [details] anaconda.log from a failing "rescue" boot > Please attach the /tmp/anaconda.log and /tmp/storage.log files Be my guest although I doubt if you will see very much above what was already reported. Note that these files are from a test machine which has a long roster of distributions installed on it and a vast majority of a reported storage is completely irrelevant to the issue in question. You can easily reproduce the problem in much "cleaner" environment.
Created attachment 374834 [details] storage.log from a failed "rescue" boot
[2009-11-26 01:05:31,956] DEBUG: failed to resolve '/usr/local/share/emacs/site-lisp/' [2009-11-26 01:05:31,956] DEBUG: getFormat('None') returning DeviceFormat instance [2009-11-26 01:05:31,960] DEBUG: getFormat('bind') returning BindFS instance [2009-11-26 01:05:31,964] DEBUG: getFormat('bind') returning BindFS instance [2009-11-26 01:05:31,969] DEBUG: added directory /usr/local/share/emacs/site-lisp/ (id 44) to device tree Well, so that is where newLV is getting called and "mountpoint" is getting trimmed.
Well, the real error is as reported originally FSError: device /mnt/sysimag/usr/local/share/emacs/site-lisp does not exist and because "sysimage" was mangled to "sysimag" then such thing indeed does not exist. If before hitting that point you will make "sysimag" symlink pointing to "sysimage" then a device above does exist and everything is happy. LVM in my example is purely coincidental.
*** Bug 527274 has been marked as a duplicate of this bug. ***
This should be fixed (in rawhide) in anaconda-13.10-1. The problem was related to handling of chroot that ends with '/' for file or directory "devices" in /etc/fstab, so affects swap files and bind mounts, probably among others.