Bug 23431

Summary:	DHCP installation with --onpart fails
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <mike>
Component:	anaconda	Assignee:	Michael Fulbright <msf>
Status:	CLOSED DUPLICATE	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-01-09 21:38:05 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:

Description Need Real Name 2001-01-05 18:17:29 UTC

Attempting a DHCP installation with a kickstart file specifying partitions
with --onpart fails with internal error in:

todo.lilo.allowLiloConfiguration(todo.fstab)

if bootDevice[0:2] == "md":
TypeError: unsliceable object

This is the ks.cfg:

lang en_US
network --bootproto dhcp

mouse generic3ps/2
nfs --server k-el0 --dir /export/software-source-3/dsl-nm/linux/7.0/
keyboard uk

part swap  --size 64 --grow --onpart /dev/hda5
part /     --size 2000 --grow --onpart /dev/hda6
part /boot --size 100 --grow --onpart /dev/hda2

lilo --location partition

install

mouse generic3ps/2
rootpw root
timezone --utc GB
auth --useshadow --enablemd5 --enablenis --nisdomain foo

skipx

%post

There are 2 ext2 fs, 1 fat fs and a swap fs on the /dev/hda.
These are all mountable.

It seems that the partitions are read from the kickstart file
prior to the call to:

'self.fstab = None' in todo.py

Then when getBootDevice is called in fstab.py, there are no
entries in the mount list and bang.

Comment 1 Michael Fulbright 2001-01-09 21:38:01 UTC


*** This bug has been marked as a duplicate of 19384 ***

Comment 2 Need Real Name 2001-01-10 13:26:24 UTC

I have discovered the error in my ks.cfg file.

I had specified --onpart /dev/hda2 rather than --onpart hda2.
Since all parts were specified in such a way, then none of
the part lines were valid. Hence anaconda not being able to
find the /boot device.

It would be useful if such a configuration error was spotted by
the kickstart parser and notified to the installer. There's
probably more idiots like myself out there !