Bug 38909 - RFE: anaconda crashes on wrong entry in %packages section of kickstart file
RFE: anaconda crashes on wrong entry in %packages section of kickstart file
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
Brock Organ
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-03 06:06 EDT by Dimitri Papadopoulos
Modified: 2007-04-18 12:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-03 18:03:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
kickstart file, crashes anaconda (3.60 KB, text/plain)
2001-05-03 11:49 EDT, Dimitri Papadopoulos
no flags Details
Comment (419.75 KB, text/plain)
2001-05-03 06:06 EDT, Dimitri Papadopoulos
no flags Details

  None (edit)
Description Dimitri Papadopoulos 2001-05-03 06:06:45 EDT
Created attachment 915079 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Comment 1 Brent Fox 2001-05-03 11:28:15 EDT
Can you attach your kickstart file so that we can have a look?

We don't currently do any sanity checking for kickstart files.  This is
something we will consider for a future release.
Comment 2 Dimitri Papadopoulos 2001-05-03 11:49:33 EDT
Created attachment 17246 [details]
kickstart file, crashes anaconda
Comment 3 Dimitri Papadopoulos 2001-05-03 11:54:32 EDT
The above kickstart should crash anaconda although I don't have the original one
anynore. Also passwords and IP addresses are scrambled.

I suspect the error will also happen if you specify a package that does not
exist,
such as 'xemaaacs' - not only when you add a comment after the package.
Comment 4 Brent Fox 2001-05-09 12:11:34 EDT
I have verified the problem.
Comment 5 Need Real Name 2001-05-20 15:28:34 EDT
I encountered the same problem. Although not with additional text after a '#' character.

I use a modified RedHat os CD with a modified comps file. For installation I use kickstart from floppy.

Upgrading from 7.0 to 7.1 getty_ps is no longer on the distribution CD.

When I created the installation set of CD and floppy for 7.1, genhdlist did not complain that it could not find the package 'getty_ps' while building
the hdlist-files. It would be nice if it did. On the first test anaconda crashed as soon as in went into the stage of package dependencies.

Looking at this it would be posible that anaconda also crashes in a 'handcontroled' installation when in comps there is a component that is 
not in the RPM dir. I haven't tested this though.

An error message or ignoring the package is a nicer way to handle this.
Comment 6 Brent Fox 2001-05-21 13:58:31 EDT
I'm more concerned with the installer crashing over '#' chars rather than bogus
packages.  A certain level of experience is assumed with kickstart installs, so
we assume that the user won't put packages that don't exist (such as emaaaaacs)
in the kickstart file.  Just skipping the package can be dangerous, though.  For
example, if the user misspelled glibc as 'gliibc', and the installer just
ignores the packages because there's no 'gliibc' package in the RPMS directory,
then what happens is that the real glibc never gets installed and the user is
left with a broken system.  I think that crashing is more desirable than that. 
Perhaps the installer should display a dialog saying "This package cannot be
found.  Installation aborting." or something like that.

Comment 7 Dimitri Papadopoulos 2001-05-22 02:14:12 EDT
Yes, a dialog displaying the incriminated line would be just fine.
This way we don't have to look for the error in strack traces or log files.
Comment 8 Greg Morgan 2001-06-24 21:05:06 EDT
Ok. If # is illegal in the $packages section, then would you please state that 
in the redhat 7.1 customization guide?  Depending on what you decide about the 
# in or not in the %packages, I'd say that this is also a documentation bug.  
Perhaps a few more examples in section 2.6.x would also help.
Comment 9 Brent Fox 2001-06-26 14:19:20 EDT
Yeah, I agree.  Although it would be easier to change the docs, I think that the
installer *ought* to allow for '#'s in the packages section.  I can see where
people would want to make comments beside certain packages so that other people
can know why they need to be installed.
Comment 10 Brent Fox 2001-07-03 18:03:51 EDT
Committed a fix for this in cvs.  The installer should scan the %packages
section and chop off any "#" chars and everything after it.

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