Bug 594474
| Summary: | Kernel Options Post: not populating grub.conf following system install | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | PaulB <pbunyan> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED WONTFIX | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.0 | CC: | bpeck, emcnabb, hdegoede, jburke, jvillalo, pbunyan, peterm, sassmann |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-12-08 17:22:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
PaulB
2010-05-20 19:19:08 UTC
From "man grubby":
--default-kernel
Display the full path to the current default kernel and exit.
--args=kernel-args
When a new kernel is added, this specifies the command line
arguments which should be passed to the kernel by default (note
they are merged with the arguments from the template if --copy-
default is used). When --update-kernel is used, this specifies
new arguments to add to the argument list. Multiple, space sepa-
rated arguments may be used. If an argument already exists the
new value replaces the old values. The root= kernel argument
gets special handling if the configuration file has special han-
dling for specifying the root filesystem (like lilo.conf does).
IOW the grubby invocation in the %post script is wrong. But you really should not be using grubby for this in the first place.
To get the desired result simple change the bootloader line in the kickstart script from:
bootloader --location=mbr
To:
bootloader --location=mbr --append="nointremap agp=off"
Updating/reopening BZ: Description of problem: I had previously reported that the Beaker Kernel Options Post was not populating grub.conf following RHEL6 system install. At that time, none of the Kernel Options Post were added to /etc/grub.conf following a RHEL6 install. However, it seems that Anaconda automagically added the console lines to /etc/grub.conf. Following the Beaker upgrade to 0.5.40-0.el5, I retested a RHEL6 install on my system. All the Beaker Kernel Options Post are now successfully populating. However, there are now dual console entries added to /etc/grub.conf: Those added by the Kernel Options Post and those automagically added by Anaconda. Yes, I can remove the console lines from Kernel Options Post, as a work around. However, this is a functionality issue. There are numerous systems added to Beaker with console lines in the Kernel Options Post. Developers reserving these systems to debug RHEL6 issues will not be capable of logging in via serial console unless they ssh in and edit /etc/grub.conf following the RHEL6 install. Version-Release number of selected component (if applicable): Beaker upgrade to 0.5.40-0.el5 How reproducible: Add console lines to Kernel Options Post, install RHEL6, and try to log i via console. Steps to Reproduce: 1. Add console lines to Kernel Options Post 2. Install RHEL6 3. Try to log in via console. Actual results: The serial data is all truncated and the user is not able to log in via serial console. Expected results: The user should be able to log in visa serial console. Additional info: ================================================================ Here is the required install configuration from Beaker: Kickstart Metadata grubport=0x03f8 Kernel Options console=tty0 console=ttyS0,115200n81 ksdevice=00:1B:21:4C:EE:2B nointremap agp=off vnc Kernel Options Post console=ttyS0,115200n81 nointremap agp=off ================================================================ -pbunyan When you do an installation which uses a serial console during the install, we add a console= argument to grub.conf so that the serial console will work with the installed system too. This is a feature not a bug. Moreover the post script which you run is using grubby to modify the kernel parameters so anaconda is not even involved in the adding of the duplicate console= argument, other then that it executes the instructions in the post script. The proper thing to do here is to fix-up the involved installation scripts, not to keep re-opening this bug. Okay, I'm confused. Why does anaconda choose to take some of the kernel command line options given during the install and put them into the grub.conf, but not do all of the command line options? Is there a list of which options are considered special case options and thus transferred to the grub.conf? What are the downsides to having anaconda transfer all the options that were specified and putting them in the grub.conf? It was annoying to me that when I installed this system from DVD and specified the nointremap option (in F12) and after the install that option was not in the grub.conf and then the system crashed on boot. I agree 100% with John here. What are the rules for anaconda passing on boot options to the installed kernel? It should be all or none, not some arbitrary unknown list. btw - I switched the kickstarts to using --append="$KERNEL_OPTIONS_POST" so were not using grubby anymore like you suggested. The problem now is its unclear which options we need to duplicate between kernel_options and kernel_options_post. As you mentioned console gets automatically added but other command line options don't. Its very confusing for a user. Expected results: anaconda should pop all anaconda specific options off the cmdline stack and pass the rest of the cmdline to the installed kernel. The list is roughly this:
# look for kernel arguments we know should be preserved and add them
ourargs = ["speakup_synth", "apic", "noapic", "apm", "ide", "noht",
"acpi", "video", "pci", "nodmraid", "nompath", "nomodeset",
"noiswmd", "fips"]
Plus some other stuff like s390-specific parameters and serial console. I'd guess it's this way so that grub.conf doesn't end up with ks= and other anaconda-specific parameters. Still, it seems there's got to be a better way here and I'd support looking for what that way might be.
Hi Chris, so do you think removing the anaconda args would work? you obviously know what args you understand and only apply to anaconda. just pass the command line through minus your args. +1 to Bill's idea I think a "black list" would be better than a "white list". Since it is impossible to know all the kernel arguments that are valid. Of course the same thing could be said of the ones to remove, unless all you remove are anaconda specific parameters. But I think it will work better to have a black list to remove things like ks= and other anaconda specific parameters. Then if the user puts options on the command line during the install, it will also show up in the grub.conf. Of course I don't know what the negatives are with this kind of solution. It's not likely to be that simple. First, anaconda option processing is scattered across loader and stage2 so doing this processing in booty would require some duplication. Second, it's likely that the bootloader is passing some special arguments when the install media is booted up that we would not want to include in the final configs. I'm thinking things like "root=", "livecd", and so forth. So that gets us to having a blacklist of anaconda options that we can probably do a reasonable (if sometimes slightly out-of-date) job of maintaining, and a blacklist of installation bootloader options that we can probably do a pretty terrible job of maintaining. In summary, good idea but harder than it ought to be. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. |