Red Hat Bugzilla – Bug 456110
cmdline kickstart option not honored
Last modified: 2008-09-29 07:43:24 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061017 Firefox/3.0 Description of problem: My kickstart file includes the 'cmdline' option to select non-ncurses installation output; I'm streaming this to the serial port (console=ttyS0) to allow an external system to monitor installation status. However, anaconda still uses the ncurses interface during installation. Version-Release number of selected component (if applicable): anaconda-10.1.1.81 How reproducible: Always Steps to Reproduce: Boot a system against a kickstart file similar to the following: auth --useshadow --enablemd5 bootloader --location=mbr zerombr clearpart --all --initlabel --drives=sda cmdline firewall --disabled firstboot --disable keyboard us lang en_US.UTF-8 langsupport --default=en_US.UTF-8 en_US.UTF-8 url --url=http://169.254.0.1/cblr/links/CentOS-4.6-i386 # start off on the provisioning network (via DHCP); will be reconfigured later network --bootproto=dhcp --hostname ems-worker2 reboot rootpw --iscrypted REDACTED selinux --disabled skipx timezone US/Central install clearpart --all --initlabel part /boot --size=256 part pv.01 --size=500 --grow volgroup vg01 pv.01 logvol / --vgname=vg01 --size=1000 --name=root logvol /usr --vgname=vg01 --size=2048 --name=usr logvol /var --vgname=vg01 --size=6000 --name=var logvol /opt --vgname=vg01 --size=4096 --name=opt Actual Results: anaconda installs the system according to the directives given in the kickstart file, but uses its ncurses interface to show status Expected Results: Updates on the ongoing operations taken by anaconda should have been printed to the console in a non-curses-based (highly parsable) manner. Additional info:
Also filed at http://bugs.centos.org/view.php?id=3008
This is not a bug in anaconda: text is being chosen over cmdline as cobbler is adding 'text' to the kernel command line. There doesn't appear to be a mechanism to prevent this, which I'm taking up with the Cobbler team; in any event, it's quite certainly not an anaconda issue.
I closed this ticket in error; there is in fact a bug in anaconda head which prevents cmdline from being respected if X is not being installed on the target. Attaching patches against RHEL4 and RHEL5.
Created attachment 312386 [details] rhel4 fix for cmdline being overridden by text when graphical install is detected as unworkable
Created attachment 312387 [details] rhel5 fix for cmdline being overridden by text when graphical install is detected as unworkable
please also add the patch listed at https://www.redhat.com/archives/anaconda-devel-list/2008-July/msg00029.html, thanks
Charles, can you please clarify what's the problem here? In comment #1 you say it's not a bug and then you say it is. From what I know boot cmd line parameters will override kickstart options so if you have 'text' passed from Cobbler as boot argument I don't see a bug here. Please clarify and add consistent steps to reproduce. Thanks!
To reproduce: Install a minimal configuration (no X server) with the "cmdline" flag in the kickstart file, or on a host with less than 18MB of RAM. The "cmdline" flag will not be honored; instead, a curses-based ("text"-style) installation will be done. (This happens even if "text" is not passed on the kernel command line; I closed the ticket in error on finding that I had that argument in my cobbler configuration, and reopened it on finding that removing the argument did not fix the problem).
I believe the first sentence of my last comment may have been open to misconstruction. To clarify: (cmdline & (<18MB RAM)) || (cmdline & (no X server)) => text ...because code intended to switch from graphics to text in the event that the system is unable to run an X server (due to either not having one installed or having insufficient RAM) switches to text unconditionally, without checking whether the previously selected installer is, in fact, the graphical one. The attached patches (and the one attached to the mailing list post in comment #6) should clarify this behavior further.
Less than 18MB of RAM? Not sure what you're doing, but that's certainly not a supported configuration for running RHEL4 under. I don't even know if you'll be able to do dependency solving and package installation with that little.
The low-RAM case isn't mine -- it's the one addressed by Tru Huynh's related patch; I haven't encountered or tested it (as opposed to the no-X-server case, which I've personally encountered).
Charles, I still don't understand how do you get a "no X" server situation? The X binary is on the stage2 image, there's no such thing as "X is not installed" when talking about the installation media. The only way you can trigger this is if anaconda tries to execute X but fails (due to missing hardware of drivers or whatever) and you have cmdline in the kickstart. Now having cmdline in your kickstart tells me that your machine probably doesn't have video hardware at all. Is this the case? Please let me know how you reproduced the problem in your environment, what hardware, install environment you used?
xdriver=notfound doesn't seem to help simulate X not starting
I'm working on a script to reproduce this issue inside a qemu/kvm virtual machine.
Created attachment 315822 [details] script which reproduces this bug within a virtual machine with 128MB of RAM isys.MIN_GUI_RAM is 192MB, not 19MB; my apologies for the earlier error. I am unable to reproduce the "Graphical installation not available" codepath when booting off an ISO; I'm looking into the set of codepaths which select minstg2.img rather than stage2.img to explain this. However, I *do* have a reliable standalone reproducer for the low-memory codepath ready immediately; see attachment. Note that qemu-0.9.1-1.el5.rf does not work correctly when running this (the kernel simply fails to boot), but current releases of KVM run cleanly.
In RHEL4, netstg2.img was used for HTTP and FTP installs. In RHEL5, minstg2.img was used for HTTP and FTP installs. Neither of these includes an X server, which is how the "Graphical installation not available" codepath is hit.
Charles, thanks for the details, I was able to reproduce the low-memory case. Steps to reproduce: 1. Start a virtual guest with less than 125MB RAM (120MB, PV Xen guest) * 2. Provide a complete kickstart file which contains 'cmdline' command 3. Proceed with install 4. X can't start (not enough memory, X not on netstg2.img) - anaconda falls back to curses based text mode instead of going to cmdline mode. * - in the code the memory is compared to 128000 != 128*1024 Happens in RHEL5 as well.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.