Red Hat Bugzilla – Bug 586533
kickstart bootloader kernel line issue
Last modified: 2010-04-28 13:38:47 EDT
Description of problem: When PXE booting with an answer file "rhgb quiet" is always appended to the kernel line. This is present in the i386 & x86_64 installer (I don't have the hardware to test the others) How reproducible: /tftpboot/pxelinux.cfg/default entry: label rhel6-64-nopart kernel kernels/vmlinuz-rhel60-64 append ksdevice=eth0 ip=dhcp initrd=kernels/initrd-rhel60-64.img network noipv6 ks=http://xxxx.XXXXXXXX.xxx/ks-files/rhel6-64-nopart.ks ------------------------------ ============================== ------------------------------ The rhel6-64-nopart.ks file: url --url http://xxxxx.XXXXXXXXXX.xxx/rhel/6/os/x86_64 install reboot text skipx lang en_US.UTF-8 keyboard us network --device eth0 --bootproto=dhcp rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxxxx firewall --disabled selinux --disabled authconfig --enableshadow --passalgo=sha512 timezone US/Central bootloader --location=mbr --append="" zerombr yes clearpart --all --initlabel part /boot --fstype "ext4" --size=1024 part swap --size=2048 part / --fstype "ext4" --size=1 --grow %packages @base @core -Red_Hat_Enterprise_Linux-Release_Notes-6-en-US %end ------------------------------ ============================== ------------------------------ For reference: The kickstart file generated by a default minimal install that i used as a base: install cdrom lang en_US.UTF-8 keyboard us rootpw --iscrypted xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx firewall --service=ssh authconfig --enableshadow --passalgo=sha512 --enablefingerprint selinux --enforcing timezone --utc America/Chicago bootloader --location=mbr --driveorder=sda --append="rhgb quiet" # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work #clearpart --all --drives=sda #volgroup VolGroup --pesize=4096 pv.6Tbknx-Za4C-5PQk-Sa81-vgdl-tcCQ-Q7KxAc #logvol / --fstype=ext4 --name=lv_root --vgname=VolGroup --grow --size=1024 --maxsize=51200 #logvol swap --name=lv_swap --vgname=VolGroup --grow --size=1008 --maxsize=2016 #part /boot --fstype=ext4 --size=500 #part pv.6Tbknx-Za4C-5PQk-Sa81-vgdl-tcCQ-Q7KxAc --grow --size=1 %packages @core %end ------------------------------ ============================== ------------------------------ Steps to Reproduce: 1. Use the line from the default file above in your favorite linux PXE server 2. Copy over the kernel files from the pxeboot directory on the DVD to the kernels folder on your favorite PXE server and name them like above. 3. Put the .ks file somewhere web-available 4. mount the DVD and put it in a web-available directory 5. Sub out the xxxx.XXXXX.xxx portions in the ks and default entries 6. put in your favorite password in the rootpw line 7. pxeboot Actual results: The kernel line in grub is always appended with "rhgb quiet" -| This happens if --append="" is present or omitted. --| Including a partition scheme for the default drive does not change the results. Expected results: When --append="rhgb quiet" is omitted or changed to --append="" rhgb quiet should not be appended to the kernel line in grub. Additional info: This is a concern mainly because we want to see what the server is actually doing while it boots, as that greatly aids in troubleshooting problems. Since sometimes a keyboard is not immediately available, is not working or the esc key is not captured correctly via the KVM this is a concern.
bootloader --append does exactly what you'd think it does: it appends the text you provide to the default bootloader argument list. For most machines and most install configurations, the default list is "rhgb quiet". This has been how it's worked for as long as I can remember. If you need to modify this default list, you'll need to do some mangling in a %post script. I'm not going to overload the meaning of --append to also sometimes mean "set".
(In reply to comment #1) > bootloader --append does exactly what you'd think it does: it appends the text > you provide to the default bootloader argument list. For most machines and > most install configurations, the default list is "rhgb quiet". This has been > how it's worked for as long as I can remember. > > If you need to modify this default list, you'll need to do some mangling in a > %post script. I'm not going to overload the meaning of --append to also > sometimes mean "set". I think you misunderstood: The default anaconda-ks.cfg file created when one installs RHEL 6 contains the line: bootloader --location=mbr --driveorder=sda --append="rhgb quiet" if one changes that line to: bootloader --location=mbr --append="" or: bootloader --location=mbr And then does a new install with the modified anaconda-ks.cfg file passed to it: "rhgb quiet" is _still_ appended to the kernel line in grub.conf This is not the expected behavior nor is it the default behavior of RHEL in the past (neither RHEL 5 or RHEL 4 will do this). The kernel line generated for grub in when "bootloader --location=mbr" is passed in RHEL 5 is: kernel /vmlinuz-2.6.18-194.el5 ro root=LABEL=/
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.
> I think you misunderstood: Nope. > if one changes that line to: > bootloader --location=mbr --append="" > or: > bootloader --location=mbr > > And then does a new install with the modified anaconda-ks.cfg file passed to > it: > "rhgb quiet" is _still_ appended to the kernel line in grub.conf Right. "rhgb quiet" are the anaconda defaults. You always get these. It's part of setting up the post-installation environment. bootloader --append only appends arguments to the default list. It does not set the bootloader argument list. That's why it's called --append. Therefore using bootloader --append="" will still get you the string "rhgb quiet". Similarly if you remove it entirely. > This is not the expected behavior nor is it the default behavior of RHEL in the > past (neither RHEL 5 or RHEL 4 will do this). It is the expected behavior, as documented here: http://fedoraproject.org/wiki/Anaconda/Kickstart#bootloader
Another thing to note is that since anaconda determines if it should add "rhgb quiet" to the default arguments based on whether or not have packages installed that provide 'rhgb' or 'plymouth', you could remove those packages from your transaction set. Adding the following to your %packages section would prevent 'rhgb quiet' being added to your boot argument list (rhgb has been deprecated in favor of plymouth in RHEL-6): -plymouth In the case where you do want plymouth installed, but don't want to use it for the boot up screen, you'll have to modify the boot loader configuration file in a %post script or by hand.
Thanks for the hint on plymouth, unfortunately that doesn't work. What I mean is, even though -plymouth is there in the kickstart file, it doesn't remove the package. So i tried removing anything with plymouth in the name, and all the dependencies of said packages: -kexec-tools -dracut-kernel -dracut -plymouth-core-libs -plymouth-scripts -plymouth The only one out of that entire list that was actually removed was: kexec-tools dracut-kernel, dracut, plymouth-core-libs, plymouth-scripts, & plymouth were all still installed, even though they were in the kickstart file to be removed. They are all also listed in the anaconda-ks.cfg file that is saved in root after the install finished. My entire packages section consisted of: %packages @base @core -Red_Hat_Enterprise_Linux-Release_Notes-6-en-US -kexec-tools -dracut-kernel -dracut -plymouth-core-libs -plymouth-scripts -plymouth Is there some unknown dependency I'm missing here? --thanks
plymouth probably still gets pulled in due to kernel dependencies, though. I bet it's needed for the kernel's install scriptlet Really if you need to mangle the bootloader args, you're going to have to do something in a %post script.