Bug 401531 - [RHEL 5] RHEL5.1 kickstart CD doesn't ask for static ip information
[RHEL 5] RHEL5.1 kickstart CD doesn't ask for static ip information
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.1
All Linux
urgent Severity high
: beta
: ---
Assigned To: Chris Lumens
Alexander Todorov
: FutureFeature, Reopened
: 428445 443633 (view as bug list)
Depends On: 441837
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-27 12:43 EST by Issue Tracker
Modified: 2010-10-22 16:46 EDT (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2008-0397
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 11:32:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This patch resolves the issue for me. (571 bytes, patch)
2008-01-16 15:04 EST, Ray Van Dolson
no flags Details | Diff
Hotfix server initrd not working for customer. Workstation version works fine (5.00 MB, application/x-gzip)
2008-04-03 15:42 EDT, Stephen Beal
no flags Details
Stage 2 Network screen I would like to have enabled in all kickstart scenarios. (83.51 KB, image/png)
2008-04-22 11:27 EDT, Ray Van Dolson
no flags Details

  None (edit)
Comment 12 James Laska 2007-12-13 10:52:43 EST
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 11:29:49 EST
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 13:52:07 EST
Greetings Ray.  Please open a support request so that your issue can be properly
handled.
Comment 20 James Laska 2008-01-02 11:19:59 EST
Reopening to address adding support for 5.2 to force a prompt
Comment 21 Ray Van Dolson 2008-01-16 15:04:18 EST
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 15:07:30 EST
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 17:26:02 EST
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 10:06:54 EST
*** Bug 428445 has been marked as a duplicate of this bug. ***
Comment 27 J.J. Smith 2008-02-19 10:30:28 EST
     Adding myself to CC as I could really use this feature, too.
Comment 28 Alexander Todorov 2008-02-22 07:50:40 EST
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 08:24:20 EST
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 15:42:04 EDT
Created attachment 300321 [details]
Hotfix server initrd not working for customer.  Workstation version works fine
Comment 35 Jeff Bastian 2008-04-15 16:00:20 EDT
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 16:15:43 EDT
jbastien: the error you see in comment#35 is being tracked against pykickstart
in bug#441837
Comment 37 Jeff Bastian 2008-04-15 16:22:30 EDT
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 38 Jeff Bastian 2008-04-15 16:23:30 EDT
Ignore comment #37 :)  Thanks jlaska!
Comment 39 Ray Van Dolson 2008-04-22 11:26:42 EDT
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 11:27:18 EDT
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 11:56:21 EDT
(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 12:04:31 EDT
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 12:11:29 EDT
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 12:17:21 EDT
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 12:19:37 EDT
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 15:40:25 EDT
*** Bug 443633 has been marked as a duplicate of this bug. ***
Comment 48 errata-xmlrpc 2008-05-21 11:32:23 EDT
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 13:51:31 EDT
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 09:41:51 EDT
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.
Comment 55 Jeff Bastian 2008-07-02 18:54:18 EDT
(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.


Note You need to log in before you can comment on or make changes to this bug.