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
Steps to Reproduce:
Add ks.cfg, soe.msg and isolinux.cfg to a copy of isolinux, create new boot.iso
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
Should ask for ip address and networking information prior to asking for server
name and path information
Have attached the ks.cfg as an attachment. Here is the isolinux.cfg file:
default linux text ks=cdrom
append initrd=initrd.img text
append ks initrd=initrd.img
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.
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
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
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
Additional info.. the stage1 network settings box does not allow you to provide
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
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
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
The following problem occurred on line 7 of the kickstart file:
option --bootproto: invalid choice: 'query' (choose from
'dhcp', 'bootp', 'static')
This can be triggered by booting from RHEL5.2-Server-20080409.0-x86_64-DVD.iso
boot: linux ks=nfs:server:/path/to/ks.cfg
where the ks.cfg is:
timezone --utc America/Chicago
jbastien: the error you see in comment#35 is being tracked against pykickstart
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?
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
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
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.
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
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
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.