Bug 401531
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> |
Severity: | high | Docs Contact: | |
Priority: | urgent | ||
Version: | 5.1 | CC: | clumens, contactjj, jlaska, pablo.iranzo, rvandolson, tao |
Target Milestone: | beta | Keywords: | FutureFeature, Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHBA-2008-0397 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-21 15:32:23 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: | |||
Bug Depends On: | 441837 | ||
Bug Blocks: | |||
Attachments: |
Comment 12
James Laska
2007-12-13 15:52:43 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? Greetings Ray. Please open a support request so that your issue can be properly handled. Reopening to address adding support for 5.2 to force a prompt 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
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. 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. *** Bug 428445 has been marked as a duplicate of this bug. *** Adding myself to CC as I could really use this feature, too. 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 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 Created attachment 300321 [details]
Hotfix server initrd not working for customer. Workstation version works fine
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jbastien: the error you see in comment#35 is being tracked against pykickstart in bug#441837 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. Ignore comment #37 :) Thanks jlaska! 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? Created attachment 303326 [details]
Stage 2 Network screen I would like to have enabled in all kickstart scenarios.
(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. 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. 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 on attachment 291881 [details]
This patch resolves the issue for me.
This patch does not apply to #401531. See #443633.
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. *** Bug 443633 has been marked as a duplicate of this bug. *** 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 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. 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. (In reply to comment #50) > 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. I've opened bug 453863 about this problem. |