Description of problem:
Appears this is just seen under TUI mode.
If I do a manual install and choose the "customize" checkbox for the packages
the packages I select there do not show up in the generated anaconda-ks.cfg. It
does appear that the packages get installed however. But this prevents using
the anaconda-ks.cfg to reproduce the same configuration.
This _might_ be related to BZ 226758.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. do a text mode install
2. choose to customize the packages to be installed
3. select all boxes in the customize screen
the anaconda-ks.cfg contains the same set of packages as if you had not added
packages on the customize screen.
Is it possible for you to test for this same behavior on Rawhide? I committed
something late last week that makes anaconda do a better job of writing out the
%packages section so it's possible fixing this is a simple matter of porting a
patch. In particular, if you could test F7 test 1 to see that it is broken in
the same way, and then test the latest Rawhide tree with an updates.img I can
supply to see if it's fixed.
If you can't do that, perhaps I can just port the patch to RHEL5 anaconda and
you can see if that fixes it up. Thanks.
It appears that rawhide works just fine even without an updates.img. This was
What installation method were you using?
1) perform a http (unified tree) installation
2) Select optional packages (dasher, epic, and aide)
3) packages are installed by anaconda
# rpm -q dasher epic aide
4) However, /root/anaconda-ks.cfg does not contain the selected optional packages
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Does booting with updates=http://people.redhat.com/clumens/235881.img fix things?
ACKing, as I think I have this figured out even without reporter verification.
All looks good when testing against RHEL-5-Server using the updates image noted
*** Bug 247550 has been marked as a duplicate of this bug. ***
247550 is not a precise dupe, if A) the Text-mode-ness is an actual variable (my
install's done with the gui) and B) my output was even less than described in
the original report or in update 4:
[root@suffolk rhn]# tail -4 /root/anaconda-ks.cfg
#logvol /tmp --fstype ext3 --name=LogVol01 --vgname=VolGroup00 --size=5120
[root@revere yum]# tail -4 /root/anaconda-ks.cfg
#logvol /var --fstype ext3 --name=LogVol03 --vgname=VolGroup00 --size=10240
*** Bug 237700 has been marked as a duplicate of this bug. ***
Verified with RHEL5.1-Server-20070904.nightly
Using the following scenario still hits this issue:
produces anaconda-ks.cfg containing @core, @base and some other packages,
which doesn't recreate the same system. Number of installed packages is 2098.
Performing manual install and customizing the packages selection in GUI works as
expected (but a bit strange). Right clicking with the mouse and selecting "All
optional packages" for every group leads to 1456 installed packages (less than
@everything ?!?). The generated anaconda-ks.cfg file recreates the same system
when used for subsequent install.
All installs are with latest RHEL5.1-Server-20070905.nightly tree, not using
installation key (Server repo only).
can you answer these questions:
1) Is using @Everything the same issue or I should file it separately?
2) Why there is a difference between @Everything and "All optional packages"?
Created attachment 187291 [details]
anaconda-ks.cfg generated when using @Everything
Created attachment 187311 [details]
anaconda-ks.cfg generated from "Select all optional packages"
Reusing a kickstart file and seeing what sort of %packages section gets
generated is sort of an odd corner case. In the normal case, we key off what is
selected in the UI to know which lines to write out in anaconda-ks.cfg. In
kickstart cases, none of this UI stuff is involved so we are probably just not
handling things correctly.
I've committed code to rawhide that simply copies the input kickstart file's
%packages section into the output kickstart file. That seems like the most
reasonable thing to do here. Can we open a new bug against 5.2 for that case
and use this bug just for the original issue? I can attach a patch to a new bug
and get that moving for the next release.
Kickstart use case reported as Bug #280101.
Moving back to VERIFIED as per comment #15
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.