Bug 230948 - anaconda fails to logical volumes not in /dev/VolGroup00
anaconda fails to logical volumes not in /dev/VolGroup00
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
Depends On:
Blocks: FC7Blocker
  Show dependency treegraph
Reported: 2007-03-04 18:49 EST by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-18 14:20:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda log (19.47 KB, text/plain)
2007-03-04 18:49 EST, Michal Jaegermann
no flags Details
anaconda log of failure with VG not being VolGroup00 (3.67 KB, text/plain)
2007-05-05 04:30 EDT, Kai Blin
no flags Details

  None (edit)
Description Michal Jaegermann 2007-03-04 18:49:28 EST
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
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):

How reproducible:
Comment 1 Michal Jaegermann 2007-03-04 18:49:28 EST
Created attachment 149227 [details]
anaconda log
Comment 2 Jeremy Katz 2007-03-05 15:47:15 EST
What filesystem type are the volumes that aren't mounting?
Comment 3 Michal Jaegermann 2007-03-05 15:58:47 EST
> 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.
Comment 4 Michal Jaegermann 2007-03-05 20:24:32 EST
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.
Comment 5 Michal Jaegermann 2007-03-07 01:15:43 EST
One more observation (although this was with 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.  
Comment 6 Jeremy Katz 2007-03-07 11:18:21 EST
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
Comment 7 Michal Jaegermann 2007-03-07 11:51:35 EST
> 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".

Comment 8 Michal Jaegermann 2007-03-12 16:35:43 EDT
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'.
Comment 9 Kai Blin 2007-05-05 04:30:38 EDT
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
Comment 10 Kai Blin 2007-05-05 05:33:43 EDT
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.
Comment 11 Chris Lumens 2007-05-09 13:18:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.