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:
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):
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.
Still broken in today's rawhide, which means no FC5test2 kickstart installs, I
Try the following:
volgroup all --noformat --useexisting
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 :-)
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.
Okay, I made the error message you were seeing suggest possible fixes and
removed the required specification from --level.
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.
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
This still means no non-interactive kickstart installs for me, since I have to
go and unmark filesystems I want to preserve. :-(
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?
Could you attach the kickstart file you're using so I've got some more context
for this stuff?
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.
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.
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.