Bug 11918 - Kickstart install dies if /dev/hda4 does not end on cylinder boundary
Summary: Kickstart install dies if /dev/hda4 does not end on cylinder boundary
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2000-06-06 01:13 UTC by Mark Allen
Modified: 2007-03-27 03:31 UTC (History)
0 users

Clone Of:
Last Closed: 2001-09-14 16:40:12 UTC

Attachments (Terms of Use)

Description Mark Allen 2000-06-06 01:13:53 UTC
We install laptops with RedHat Linux, and we're working on a 6.2 version.
The 6.2 kickstart works fine on a completely blank hard drive or on any
hard drive where pre-existing partitions end on a cylinder boundary -- but
if a partition does not end on a cylinder boundary, anaconda attempts to
install a swap partition at /dev/hda3(!! Why does it choose /dev/hda3?!)
and throws up the following error traceback:

File "/usr/bin/anaconda" line 342 in ?
   intf.run(todo, test = test)
File "/usr/lib/anaconda/text.py" line 1165 in run
   rc = apply (step[1](), step[2])
File "/usr/lib/anaconda/text.py" line 702 in __call__
   if todo.doInstall():
  File "/usr/lib/anaconda/todo.py", line 1116 in doInstall
  File "/usr/lib/anaconda/fstab.py", line 246 in turnOnSwap
    isys.swapon (file)
  File "/usr/lib/anaconda/isys.py" line 74, in swapon
    return _isys.swapon (path)

System Error: (22, 'Invalid argument')

Any ideas on a quick fix?   I'm not very good at python, and although I
tried following the code, it quickly made my novice eyes cross.

The device file does exist in /tmp/swap/hda3.

To reproduce this problem:
Create a partition of type "a0" "IBM hibernation", and then do not end the
partition on a cylinder boundary, or try using the DOS utility "phdisk",
then run a kickstart install with at least one swap partition defined.

I've tried using the "stock" 6.2 anaconda and the updated anaconda
versions. Both exhibit the same behavior.  Interestingly, the 6.1 anaconda
installer doesn't seem to have this problem -- it behaves itself normally
regardless of what's in the disk partition table.

Comment 1 Mark Allen 2000-06-06 01:35:18 UTC
OK. I've investigated this further and it looks like anaconda is miscalculating
the available cylinders on the hard drive:  

From fdisk /tmp/hda:
Disk /tmp/hda: 240 heads, 63 sectors, (***IMPORTANT:***) 1559 cylinders
Device       Start    End    Blocks   Id  System
/tmp/hda1        1      2    15088+   83  Linux
/tmp/hda2        3   1540 11627280     5  DOS extended
/tmp/hda3     1561   1594    257040   82  Linux swap
/tmp/hda4     1541   1560    139860   a0  IBM Thinkpad hibernation

It looks like anaconda is trying to allocate the swap space in cylinders that
don't exist (they're past the physical end of the disk!!) instead of inside the
extended disk space like it should. fdisk shows that there are 40 cylinders free
inside of the extended partition after the other disk space in the extended
partition has been allocated.

Comment 2 Michael Fulbright 2000-06-09 20:13:03 UTC
Could you give an example of the partition table BEFORE and AFTER the kickstart
install, as well as attach a copy of your ks.cfg file?

Comment 3 Mark Allen 2000-06-09 22:40:09 UTC
Before kickstart, partition table. I obtained this output by installing a
new-from-the-shrinkwrap 12GB toshiba 2.5mm slim line hard drive into the laptop,
booting into MS-DOS from a floppy disk, running the 3.4.1 version of phdisk.exe
and then booting the LinuxCare bootable business card and running fdisk.

From fdisk /dev/hda:
Disk /dev/hda: 240 heads, 63 sectors, 1559 cylinders
Units = cylinders of 15120 * 512 bytes

Device Boot      Start      End       Blocks     Id      System
/dev/hda4        1541       1560      139860     a0      IBM hibernation
Partition 4 does not end on a cylinder boundary:
  phys(1023, 14,61) should be (1023, 239, 63)

After kickstart partition table:
Disk: /tmp/hda: 240 heads, 63 sectors, 1559 cylinders
Units = cylinders of 15120 * 512 bytes

Device Boot      Start      End       Blocks    Id       System
/tmp/hda1        1            2        15808+   83       Linux
/tmp/hda2        3          1540    11627280     5       Extended
/tmp/hda3        1561       1594       257040   82       Linux swap
/tmp/hda4        1541       1560       139680   a0       Ibm hibernation
Partition 4 does not end on a cylinder boundary:
   phys(1023,104,63) should be (1023,239, 63)
/tmp/hda5        3          1195      9019048+  83       Linux
/tmp/hda6        1196       1466      2048728+  83       Linux
/tmp/hda7        1467       1507       309928+  83       Linux

Example of ks.cfg file:
lang en_US
keyboard "us"
zerombr no
clearpart --linux
part / --size 300
part /boot --size 10
part /usr --size 2000
part /home --size 2001 --grow
part swap --size 250
mouse genericps/2 --emulthree
timezone US/Pacific
xconfig --server "Mach64" --monitor "generic multisync" --startxonboot
rootpw foobar
auth --useshadow --enablemd5
lilo --location mbr
@ Base

I fully admit the phdisk.exe program is causing major disk partition table dain
bramage (turns out the newer versions of phdisk are faster and more well behaved
unsurprisingly -- and we're working on reverse engineering the hibernation
partition file spec so we can build a program to format this partition in Linux
with free software), but I just thought anaconda should hold its marbles
together better. Maybe do a sanity check on the disk geometry before it goes to
allocate disk space?



Comment 4 Mark Allen 2000-06-09 22:52:24 UTC
Almost forgot. anaconda seems to behave itself if the HD in question is 6 GB or
smaller.  It's only on the 12GB and 18GB drives we've seen this error occur.

Comment 5 Brock Organ 2000-06-10 03:24:30 UTC
thanks for your report ... this has been added to our bug list ...

there is some confusion whether not ending on a cylinder is a valid DOS
partition type table under linux (except for the first partition)

from the fdisk man page:

"In  a DOS type partition table the starting offset and the size of each
partition is stored in two ways ... Whenever  a  partition  table is printed
out, a consistency check is performed on the partition table entries.  This
check verifies that the physical  and  logical start  and  end points are
identical, and that the partition starts and ends on a cylinder boundary (except
for the first partition)."

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