Bug 23431 - DHCP installation with --onpart fails
DHCP installation with --onpart fails
Status: CLOSED DUPLICATE of bug 19384
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Fulbright
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-05 13:17 EST by Need Real Name
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-09 16:38:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-01-05 13:17:29 EST
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 16:38:01 EST

*** This bug has been marked as a duplicate of 19384 ***
Comment 2 Need Real Name 2001-01-10 08:26:24 EST
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.