Description of problem: With boot images using kernel-2.6.20-1.2962.fc7 anaconda does see that there are two volume groups with file systems to mount but after mounting volumes from the first group it bails out with 22:14:20 DEBUG : isys.py:mount()- going to mount /dev/VolGroup01/LogVol00 on /mnt/sysimage/opt 22:14:20 ERROR : 0 and does not even try remainig ones. After that in /dev/mapper/ one can find only volues which already got mounted so remaining ones are inaccessible. It does not matter if selinux is active. Version-Release number of selected component (if applicable): anaconda-11.2.0.28-1 How reproducible: always
Created attachment 149227 [details] anaconda log
What filesystem type are the volumes that aren't mounting?
> What filesystem type are the volumes that aren't mounting? All these happen to be ext3. BTW - anaconda from FC6 does see filesystems from multiple volume groups although I will have to repeat that experiment with the same system on which I got this failure.
I tried anaconda from FC6 and the same system. All file systems which should be mounted are mounted even if an "error" notification pops out. I think that the last thing happens because from logs it looks like that anaconda attempts to create various mount points which already exist in already mounted filesystems (like, say, /boot). In any case I asked for mounts read-only.
One more observation (although this was with 11.2.0.29). If after a failed mount of logical volumes I will do lvm vgchange -a y then missing entries in /dev/ do show up and I can now mount all remaining ext3 file systems.
We do an vgchange -an after the failure, so I'd expect them to be unavailable there. I'm wondering if this is (somehow) related to the ext2 support dropping out.
> I'm wondering if this is (somehow) related to the ext2 support > dropping out. If an error on some file system is forcing a dropout of all other outstanding mounts that would be conceivable although surprising in a concept. Note that if after mount failures I will peek into /dev/mapper/ then I do not see any entries for all those MIAs. Following that with 'lvm vgchange -a y' fills out /dev/ as expected and now I can mount all these file systems - either using '/dev/....' or by label (with /mnt/sysimage/bin/mount and if a label is present). Again - anaconda from FC6 is somehow able to cope without a "helping hand".
Re comment #6. I did try (another system, but I rigged something similar) with bug 230946 fixed on new images. ext2 filesystem indeed mounted fine but I got the same "ERROR : 0" and no remaining volumes. This is even worse. After 'lvm vgchange -a y' volumes which happen to reside on the disk as a volume which was mounted on / are found. But a volume located on another physical device is still not there even after multiple runs of 'lvm vgchange -a y'.
Created attachment 154197 [details] anaconda log of failure with VG not being VolGroup00 I'm getting a similar problem when changing the default names of the volume group and logical volumes. Anaconda fails with an error message about failing to format the logical volume.
Actually, this seems to fail even with the default names. I created the volume group on a preformatted disk, I'm not sure if that has anything to do with that.
I believe this should be fixed now. We were deactivating LVM at certain points which was causing the device nodes to disappear. That should be taken care of. Please try a rawhide tree when they start showing up again and verify that this is working for you. Thanks.