|Summary:||[RHEL 5] RHEL5.1 kickstart CD doesn't ask for static ip information|
|Product:||Red Hat Enterprise Linux 5||Reporter:||Issue Tracker <tao>|
|Component:||anaconda||Assignee:||Chris Lumens <clumens>|
|Status:||CLOSED ERRATA||QA Contact:||Alexander Todorov <atodorov>|
|Version:||5.1||CC:||clumens, contactjj, jlaska, pablo.iranzo, rvandolson, tao|
|Target Milestone:||beta||Keywords:||FutureFeature, Reopened|
|Fixed In Version:||RHBA-2008-0397||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-21 15:32:23 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||441837|
Comment 12 James Laska 2007-12-13 15:52:43 UTC
Description of problem: RHEL5.1 kickstart bootdisk with same "working" ks.cfg as used in RHEL5.0 prototype does not prompt for static ip address information How reproducible: Every time Steps to Reproduce: Add ks.cfg, soe.msg and isolinux.cfg to a copy of isolinux, create new boot.iso Actual results: Machine boots off of CD, one chooses FTP as install mechanism, and then it asks for the server and mount path. It then goes back to the same screen whenever you press OK. Virtual console 3 says: need to set up networking/going to pick interface/only have one network device: eth0/going to do getNetConfig/doing kickstart...setting it up/no DNS servers, can't look up hostname Expected results: Should ask for ip address and networking information prior to asking for server name and path information Additional info: Have attached the ks.cfg as an attachment. Here is the isolinux.cfg file: default linux text ks=cdrom timeout 600 display soe.msg F1 boot.msg F2 options.msg F3 general.msg F4 param.msg F5 rescue.msg label linux kernel vmlinuz append initrd=initrd.img label text kernel vmlinuz append initrd=initrd.img text label ks kernel vmlinuz append ks initrd=initrd.img label local localboot 1 label memtest86 kernel memtest append - Summary: If no IP settings are supplied either by kernel cmdline or kickstart, loader is failing to prompt the user after a DHCP timeout for network settings.
Comment 16 Ray Van Dolson 2007-12-18 16:29:49 UTC
I just received a comment that doesn't appear here. It mentions custom initrd's that apparently add back the ability to configure network configuration options during a network installation. Where can I get these initrd's? Should I open a SR with RH?
Comment 17 James Laska 2007-12-18 18:52:07 UTC
Greetings Ray. Please open a support request so that your issue can be properly handled.
Comment 20 James Laska 2008-01-02 16:19:59 UTC
Reopening to address adding support for 5.2 to force a prompt
Comment 21 Ray Van Dolson 2008-01-16 20:04:18 UTC
Created attachment 291881 [details] This patch resolves the issue for me. The initrd provided by RH prompts me for some network information in the stage1 installer. However, I need access to the network information in the stage2 installation process. For whatever reason, the network step is explicitly skipped in kickstart.py. This patch simply removes it from the skip list and gives me access to override network settings
Comment 22 Ray Van Dolson 2008-01-16 20:07:30 UTC
Additional info.. the stage1 network settings box does not allow you to provide a hostname. In our situation we often want to do an interactive kickstart installation with default network settings but allow the installer to provide a hostname (and continue to use DHCP) from within anaconda. This is only possible from the stage2 portion. This is also the behavior of kickstart and anaconda in RHEL4.
Comment 24 Chris Lumens 2008-01-30 22:26:02 UTC
Initial support is now present, though I need to make a very small modification to pykickstart before we can test this any farther than the loader. However, we can at least start testing there.
Comment 26 Chris Lumens 2008-02-19 15:06:54 UTC
*** Bug 428445 has been marked as a duplicate of this bug. ***
Comment 27 J.J. Smith 2008-02-19 15:30:28 UTC
Adding myself to CC as I could really use this feature, too.
Comment 28 Alexander Todorov 2008-02-22 12:50:40 UTC
What is the actual fix here: 1) showing up TCP/IP settings screen in loader after DHCP timeout or 2) using the 'network --bootproto=aks' parameter in kickstart What I've done is: 1) Start a Xen HVM guest to boot off the ISO (incl. ks.cfg without network info) 2) pulled out the network cable on the physical system 3) anaconda says it can't retrieve stage2 4) keeps asking me to provide a correct url for stage 2. No Network configuration screen
Comment 30 Alexander Todorov 2008-02-22 13:24:20 UTC
The correct resolution is "network --bootproto=query" NOT "ask". With the above line in ks.cfg stage1 will aks you to configure networking if DHCP times out. Moving this to VERIFIED
Comment 32 Stephen Beal 2008-04-03 19:42:04 UTC
Created attachment 300321 [details] Hotfix server initrd not working for customer. Workstation version works fine
Comment 35 Jeff Bastian 2008-04-15 20:00:20 UTC
Created attachment 302514 [details] screenshot of anaconda error I haven't figured out what triggers this yet, but sometimes this error appears when using --bootproto=query: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following error was found while parsing your kickstart configuration: The following problem occurred on line 7 of the kickstart file: option --bootproto: invalid choice: 'query' (choose from 'dhcp', 'bootp', 'static') Reboot ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (See screenshot) This can be triggered by booting from RHEL5.2-Server-20080409.0-x86_64-DVD.iso and entering boot: linux ks=nfs:server:/path/to/ks.cfg where the ks.cfg is: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ install cdrom keyboard us lang en_US timezone --utc America/Chicago network --bootproto=query interactive %post ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comment 36 James Laska 2008-04-15 20:15:43 UTC
jbastien: the error you see in comment#35 is being tracked against pykickstart in bug#441837
Comment 37 Jeff Bastian 2008-04-15 20:22:30 UTC
The problem in comment #35 seems to be coming from the pykickstart module. The pykickstart-0.43/pykickstart/parser.py file has this in the doNetwork() procedure: op.add_option("--bootproto", dest="bootProto", default="dhcp", choices=["dhcp", "bootp", "static"]) It looks like 'query' needs to be added to the list of choices. I'll open a new bug for this.
Comment 39 Ray Van Dolson 2008-04-22 15:26:42 UTC
Folks, just to clarify this is addressing the issue I am interested in. This patch will enable the network screen from within the GUI installer regardless of whether or not the stage 1 installer (in kickstart mode) was kicked off with DHCP or static? I will attach a screenshot of the screen I would like to be present from within the installer. Scenario where this comes up: 1. Boot from kickstart using DHCP defined in kicstart file 2. Enter GUI installer 3. Presented with Network screen as shown 4. Leave set as DHCP but choose as hostname (resulting in a DHCP_HOSTNAME param in the network configuration file). 5. All is well. Can we confirm that this is what this patch will do?
Comment 40 Ray Van Dolson 2008-04-22 15:27:18 UTC
Created attachment 303326 [details] Stage 2 Network screen I would like to have enabled in all kickstart scenarios.
Comment 41 Alexander Todorov 2008-04-22 15:56:21 UTC
(In reply to comment #39) > Folks, just to clarify this is addressing the issue I am interested in. > > This patch will enable the network screen from within the GUI installer > regardless of whether or not the stage 1 installer (in kickstart mode) was > kicked off with DHCP or static? > Ray, IIRC this issue is addressing the situation where a DHCP request times out in stage1 and the network settings screen is not shown again. The fix is to show this screen in stage1 whenever --bootproto=query is specified. If you want your feature included please open another bug for it and mark oit as RFE. Thanks.
Comment 42 Ray Van Dolson 2008-04-22 16:04:31 UTC
I do have an RFE open and this is the bz they have been following. I had a sneaky suspicion they were confused. Sigh. I'll open a new one and hopefully be able to make clear what my issue is to them this time. Argh! Thanks for the verification.
Comment 43 Chris Lumens 2008-04-22 16:11:29 UTC
No, please don't. My patch for this issue also included stuff in stage2 to make this screen appear. I'd prefer to use this bug to continue tracking the entire problem rather than split it off into another one that will need whole new flags and everything.
Comment 44 Ray Van Dolson 2008-04-22 16:17:21 UTC
Comment on attachment 291881 [details] This patch resolves the issue for me. This patch does not apply to #401531. See #443633.
Comment 45 Ray Van Dolson 2008-04-22 16:19:37 UTC
Oh. Great... I'll close out the other bug I just opened then. Will your stage2 stuff require any additional flags to activate? Can I test this in the current incarnation of RHEL 5.2 beta? I'm assuming the --bootproto=query flag is not what will be responsible for toggling the GUI network screen. I'll close out my other bz I just opened.
Comment 46 Jeremy Katz 2008-04-22 19:40:25 UTC
*** Bug 443633 has been marked as a duplicate of this bug. ***
Comment 48 errata-xmlrpc 2008-05-21 15:32:23 UTC
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0397.html
Comment 49 Ray Van Dolson 2008-05-28 17:51:31 UTC
FYI, thanks for your work on this. --bootproto=query does indeed trigger the network screen in stage2. However, it also triggers a network configuration screen in stage1 (text mode). This doesn't work well for remote installs via VNC. What I need is just for stage1 to do DHCP automatically (network --device=eth0 --bootproto=dhcp) but still present me with the network configuration screen in stage2 so the installer can override the settings used for stage1. Perhaps another option to network "--stage2override" or something could be used to trigger this. In any case, for the time being I'll continue using my own kickstart.py.
Comment 50 Ryan Thornton 2008-06-03 13:41:51 UTC
I have just the opposite, the network information i enter when I use --bootproto=query in stage1 of a text install, I want to carry over into stage2. The previous version, I left the network keyword out of ks.cfg altogether, and just left it to prompt for permanent IP information. That was my only interaction, picking the device, setting tcp/ip information, and all else was scripted. Here it appears I have to put network --bootproto=query just to keep it from automatically using dhcp and timing out without asking.