Created attachment 915079 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
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.
Created attachment 17246 [details] kickstart file, crashes anaconda
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.
I have verified the problem.
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.
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.
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.
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.
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.
Committed a fix for this in cvs. The installer should scan the %packages section and chop off any "#" chars and everything after it.