Bug 164776

Summary:	PXE boot config file for PXE install clients unusable if kickstart file has not been specified
Product:	Red Hat Enterprise Linux 3	Reporter:	bastiaan
Component:	redhat-config-netboot	Assignee:	Jason Vas Dias <jvdias>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	3.0
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHBA-2005-486	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-09-28 19:38:47 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:
Bug Blocks:	156320

Description bastiaan 2005-08-01 11:33:17 UTC

Description of problem:
If you configure a client for 'Network OS install' and leave the 'Kickstart
File' field empty, the installation of the client will fail because it cannot
find a kickstart file named "". 

Version-Release number of selected component (if applicable):
redhat-config-netboot-0.1.20-1_EL3

How reproducible:
Always

Steps to Reproduce:
1. start redhat-config-netboot
2. configure a Network Installation profile
3. configure a client with this profile and leave the 'kickstart file' field empty.
4. boot the client
  
Actual results:
The installation will fail at the point where it tries to download the kickstart
file, complaining it cannot find it.

Expected results:
The install should continue interactively.

Additional info:
Doing kickstart-less network installs may sound unusual, but it is very
convenient for systems where you cannot boot from CD/DVD.
In redhat-config-netboot the problem can be solved easily by checking whether a
kickstart file has been specified and ommitting the 'ks=' parameter if it hasn't.
But maybe the proper solution would be if the installer compononent (anaconda?)
would interpret an empty ks parameter as equivalent to no kickstart file at all.

Comment 1 Jason Vas Dias 2005-08-01 14:03:18 UTC

I think later versions of anaconda will ignore the empty 'ks=' parameter,
which is why this bug was not found during testing. This bug will be fixed
with subsequent releases of redhat-config-bind .
Workaround : edit /tftpboot/linux.install/pxelinux.cfg/${NET} configuration
file for $NET to remove the 'ks=' option .

Comment 2 Jason Vas Dias 2005-08-05 22:49:33 UTC

This is now fixed with redhat-config-netboot-0.1.24-1_EL3 - pxeboot.py will no
longer generate an empty 'ks=' syslinux.cfg file boot parameter string.

When no kickstart file is specified for a network install, then the 
install method ( the protocol, server and location ) specified in 
the network dialog would be lost;  the client user would have to specify
these manually for each install in anaconda, as well as the network 
configuration method and interface .

redhat-config-netboot was writing a default 'ks.cfg' file to 
/tftpboot/linux-install/${OS}/ks.cfg , containing just the network 
method install parameters, eg:
' nfs --server ${SERVER} --dir ${LOCATION} 
'
But unless users put this into the initrd manually, or specified
this as an NFS, HTTP, or FTP URL kickstart file in the network
installation dialog (requiring a server for the protocol to be run),
it could never be used from this location, and r-c-n never told
users about this file.

Now, if no kickstart file is specified in the network installation dialog,
r-c-n will write the parameters to the pxelinux.cfg/${net|default} syslinux.cfg
file, eg:
'
label 1
    kernel ${OS}/vmlinuz
    append initrd=${OS}/initrd.img ramdisk_size=10000 \
method=${PROTOCOL}:${SERVER}:${LOCATION} ip=dhcp
'
So install client users will now have to specify only the language and 
keyboard before the NFS location is mounted and anaconda kicks off in
graphical X mode by default .

This version is available from:
   http://people.redhat.com/~jvdias/redhat-config-netboot/
Please try out this version and let me know of any issues - thank you.

Comment 9 Red Hat Bugzilla 2005-09-28 19:38:47 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-2005-486.html