Bug 174597 - kickstart install doesn't read LVM info from disks
kickstart install doesn't read LVM info from disks
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Mike McLean
:
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2005-11-30 11:57 EST by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-14 13:07:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This is the latest one I've been playing with (3.00 KB, text/plain)
2006-02-13 12:06 EST, Alexandre Oliva
no flags Details

  None (edit)
Description Alexandre Oliva 2005-11-30 11:57:34 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20051118 Fedora/1.5-0.5.0.rc3 Firefox/1.5

Description of problem:
It used to be possible to perform kickstart installs in which the kickstart file specified that no partitions should be cleared, and listed only the volume group names and the logical volumes in them, not the specific physical volumes that should belong to each volume group, something like:

clearpart --none
volgroup all --noformat
logvol / --useexisting --fstype ext3 --name=test --vgname=all
...

Unfortunately, this no longer works.  The installer now complains that the volume group is empty and bails out.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Try to ks install to a logical volume in an existing volume group

Actual Results:  Interactive non-kickstart install works, kickstart install fails early.

Expected Results:  It used to work.

Additional info:
Comment 1 Alexandre Oliva 2006-01-13 10:49:38 EST
Still broken in today's rawhide, which means no FC5test2 kickstart installs, I
guess :-(
Comment 2 Chris Lumens 2006-02-01 11:38:51 EST
Try the following:

volgroup all --noformat --useexisting
Comment 3 Alexandre Oliva 2006-02-07 17:27:35 EST
That works.  Was it an intentional change?  I sort of see that it might make
sense to specify --noformat to create a new device (be it volume group, logical
volume, raid device or disk partition) and not format it, but changing the
defaults with such a horrible diagnostic is probably not a good idea.  At the
very least this should be mentioned in the release notes.  If the change was
intentional and is not going to be backed up, please reassign this bug to the
release notes component.

I was also surprised by the need to specify --level for a --noformat
--useexisting raid device.  Was this other, erhm, user-unfriendly regression :-)
intentional?
Comment 4 Chris Lumens 2006-02-08 10:02:32 EST
Kickstart support was rewritten for FC5 as the pykickstart package.  I've tried
to keep all the behavior and defaults exactly as they were, but some things have
been missed.  If you see something that's a change from the way it used to work,
file it as a bug and I will take a look at it.  Error messages of course can be
made better in the future.  We have a much better framework for reporting them
now (including line numbers, what a concept!) so I can fix things as people come
across the problems.

Requiring --level for those other combinations of options is fallout from me
making --level a required option for raid devices in general.  If the way it
worked in the past was that --noformat --useexisting implied a level, I can
correct that.  Again, just file some bugs about what you find.  Unfortunately
there's a whole lot of accumulated weird behavior in kickstart and I haven't
been able to test it all.
Comment 5 Chris Lumens 2006-02-08 10:25:34 EST
Okay, I made the error message you were seeing suggest possible fixes and
removed the required specification from --level.
Comment 6 Alexandre Oliva 2006-02-10 15:32:19 EST
Interactive kickstart install warns it *is* going to format volume groups,
logical volumes and raid devices marked with `--noformat --useexisting'.  I
didn't have the guts to let it proceed, but something definitely needs fixing,
even if it's just the warning printed by the text-mode disk druid.

On the good side, it didn't reject the raid device without --level.
Comment 7 Alexandre Oliva 2006-02-10 21:05:30 EST
Oddly, if I switch from kickstart in text mode to kickstart in graphical mode,
it no longer claims it's going to format the volume group, although all
filesystems (logical volumes and raid devices) marked as --noformat would still
be formatted (according to the warning message, I didn't try it).  This time I
had the guts to proceed to the installation, and it did preserve the volume
group, indeed.

This still means no non-interactive kickstart installs for me, since I have to
go and unmark filesystems I want to preserve. :-(
Comment 8 Alexandre Oliva 2006-02-10 21:22:21 EST
Just tried removing --fstype from the logical volumes and raid devices I didn't
want formatted.  That still didn't work.  And it still figured out the right
type to use.

Having to do the interactive install wouldn't be so bad if it didn't lose track
of the passwords for the boot loader and the root account that are specified in
the ks file, but that someone decided to be too hard to preserve in interactive
ks installs and just CLOSED/WONTFIX the bug I submitted about it several years
ago.  Would it make sense to reopen it now that there are different maintainers?
Comment 9 Chris Lumens 2006-02-13 12:00:17 EST
Could you attach the kickstart file you're using so I've got some more context
for this stuff?
Comment 10 Alexandre Oliva 2006-02-13 12:06:24 EST
Created attachment 124569 [details]
This is the latest one I've been playing with

Not a problem.	Let me know if you need anything else.
Comment 11 Chris Lumens 2006-02-13 15:58:28 EST
Argh, looks like problems with the option parsing in pykickstart yet again -
optparse's ensure_value method wasn't even setting the option value if
--noformat was specified!  Fixed, and should be in test3.
Comment 12 Alexandre Oliva 2006-02-14 13:07:43 EST
Thanks, it's fixed indeed, even without the redundant --useexisting along with
--noformat!  There's still a nit that might or might not be related, filed bug
181504 about it.

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