Bug 23431 - DHCP installation with --onpart fails
Summary: DHCP installation with --onpart fails
Keywords:
Status: CLOSED DUPLICATE of bug 19384
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-05 18:17 UTC by Need Real Name
Modified: 2007-04-18 16:30 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-01-09 21:38:05 UTC
Embargoed:


Attachments (Terms of Use)

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 !


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