Bug 652417

Please attach /tmp/anaconda.log and /tmp/storage.log to this bug report.  A copy of your kickstart file (free of any sensitive information, of course) would also be handy.  Thanks.

Created attachment 459847 [details]
anaconda.log

Created attachment 459848 [details]
storage.log

Created attachment 459849 [details]
minimal kickstart (for use in KVM host, change "vda" if other)

Created attachment 459850 [details]
program.log (shows vgchange -a n rhel6)

Note that "logvol / ... --noformat" is not a good idea anyway.  This leaves open the possibility that / has a previous install on it, which means you are asking anaconda to potentially do an install on top of an already installed system.  So you could end up with crud from two installations overlapping.  Future builds of anaconda will prevent you from doing that.

Still, it's worth investigating if there's a more general problem with --noformat here.

I can confirm this bug exists, it's also in Fedora 14.

This feature works in RHEL 5.5 and Fedora 12.

I suggest updating the documentation to explain it's not recommended but it's a potentially useful and important feature to system administrators in business environments.  I haven't found documentation saying it was purposefully removed.

I'm creating the setup in %pre myself, to get the desired layout/options.  Preventing that would be rather irritating, to say the least, unless anaconda is going to provide much more control.  When I asked about passing options through to mdadm or lvcreate before, the answer was to just do it myself in %pre.

> I'm creating the setup in %pre myself, to get the desired layout/options. 
> Preventing that would be rather irritating, to say the least, unless anaconda
> is going to provide much more control.  When I asked about passing options
> through to mdadm or lvcreate before, the answer was to just do it myself in
> %pre.

Hmm, yes, this is an interesting case I had not considered.  We definitely need to find a way to allow this level of customization while at the same time preventing people from attempting to install on top of an existing installation without formatting.  I hope you can see how the latter case does result in pretty strange situations.  We do get bugs on that from time to time.

I do understand those crazy system administrators do weird things. :)

How would dropping --noformat work with kickstart upgrades?  I've personally never done that, but it is in some cases legitimate to be mounting existing filesystems.  Even on a new install, you might want to go ahead and mount a previous /home during install.

My reasons for manual FS setup in %pre and using --noformat have been to pass options to the setup commands:

- mdadm to change RAID striping and add bitmap
- lvcreate to use LVM striping
- mke2fs to change block size and inode count

Also, in some cases, I have wanted filesystems in a particular order, or have left empty space between LVs (for filesystem snapshots for backups).  These are all pretty custom and I doubt you'd want to try to make anaconda cover all those cases.

Maybe instead of dropping --noformat, some tests could be done after mounting filesystems when in "install" mode, like checking for a pre-existing /var/lib/rpm, and then giving a big warning (or just fail) if the tests fail.

> How would dropping --noformat work with kickstart upgrades?  I've personally
> never done that, but it is in some cases legitimate to be mounting existing
> filesystems.  Even on a new install, you might want to go ahead and mount a
> previous /home during install.

Partitioning is completely ignored on upgrade, so there's nothing to worry about here.  anaconda looks at your /etc/fstab and mounts whatever that says to.

> My reasons for manual FS setup in %pre and using --noformat have been to pass
> options to the setup commands:
> 
> - mdadm to change RAID striping and add bitmap
> - lvcreate to use LVM striping
> - mke2fs to change block size and inode count
> 
> Also, in some cases, I have wanted filesystems in a particular order, or have
> left empty space between LVs (for filesystem snapshots for backups).  These are
> all pretty custom and I doubt you'd want to try to make anaconda cover all
> those cases.

Right, there are valid reasons for wanting to do what you're doing.  We just need to figure out how to make anaconda happy with it and prevent the other crazy situations at the same time.

> Maybe instead of dropping --noformat, some tests could be done after mounting
> filesystems when in "install" mode, like checking for a pre-existing
> /var/lib/rpm, and then giving a big warning (or just fail) if the tests fail.

Just to be clear - we're not dropping --noformat.  There are two separate things going on here:

(1) For some reason, things marked as --noformat are not getting mounted during installation.  This is a bug, and I need to take a look at it.

(2) / --noformat is currently not recommended and is an error condition in Rawhide (so, you should be safe on RHEL6 as long as #1 gets fixed).  That's where this bug discussion has veered off to.  That's fine.

We're not yet sure what kind of checks we can perform, or whether we should bring back expert mode, or what.  That discussion is ongoing.  We might be able to check to see if there's something installed on the volume you specify with --noformat, but that'd get very tricky with the more advanced storage mechanisms.

Thanks.

As to #2, I did not get the distinction of --noformat not being supported specifically on the root filesystem.  I have done the same thing in some Fedora kickstart scripts, so that is still an issue for me, but not for this BZ bug.

Chris, you should deactivate the vg yourself after setting it up. I expect this will resolve the issue for you.

Meanwhile, I am going to patch anaconda to be a little better at detecting setups that are already active when anaconda starts.

The VG and all LVs are active at the end of the %pre; it is anaconda that deactivates them and then doesn't find them.

If you create a VG and LVs, they are active immediately by default; that's the only way I was able to run mke2fs on them in %pre.

(In reply to comment #15)
> The VG and all LVs are active at the end of the %pre; it is anaconda that
> deactivates them and then doesn't find them.
> 
> If you create a VG and LVs, they are active immediately by default; that's the
> only way I was able to run mke2fs on them in %pre.

What I said is that you should DEactivate them in your %pre. Create them, do whatever you want to them, but then DEactivate them. Try that and see if it works for you.

    lvm vgchange -an

Sorry; missed the "de" (read what I was thinking, not what you wrote).  That does indeed make it work.

There is no supported scenario that would lead to anaconda encountering already-active lvm during the storage device detection process. Adding support for that would be more work (complex backport from patches still under review for rawhide) than is warranted by a good margin.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

I'm satisfied with "lvm vgchange -an" as a solution.  However, it would be good to document this requirement, as it is a behavior change from RHEL 5.