[26252] in Athena Bugs
Linux-Athena installer improperly created partitions
daemon@ATHENA.MIT.EDU (Kevin Chen)
Wed Dec 15 20:52:28 2004
Message-ID: <41C0EA12.60800@mit.edu>
Date: Wed, 15 Dec 2004 20:51:14 -0500
From: Kevin Chen <kchen@mit.edu>
MIME-Version: 1.0
To: bugs@mit.edu
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Errors-To: bugs-bounces@mit.edu
I helped a user install Athena today. His network card was unsupported
by the version 4 installer, so I used the version 4.99a installer that
amb had previously referred me to since it has support for newer network
cards.
The user told the installer to install Athena in unused free space, so
the installer partitioned the disk automatically.
After not doing anything at "Installing RPMs" for about 15 minutes, we
rebooted.
(The following paragraph may not be relevant, but I'm including it in
what we did for completeness.)
Unsure whether this was related to the version 5 image, I again used the
version 5 CD, but specified tae-kwon-leap.mit.edu and
/linux/rhlinux4.img. This gave a bunch of AFS errors and the system
automatically rebooted.
Using the version 5 CD once again, I asked the user to delete the
partitions that the previous attempted install had created. This is
where the problem lies:
Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 7650 9729 16707600 5 Extended
/dev/hda5 7650 7715 530113+ 82 Linux swap
/dev/hda6 7716 7781 530113+ 83 Linux
/dev/hda7 7782 9729 15647278+ 83 Linux
The user previously had a Windows partition. It however, is not listed
here, and indeed, the machine was unbootable at this point. However,
note that /dev/hda1 does not start at the beginning of the disk.
Also, the installer seems to have created an insufficient number of
partitions. /dev/hda5 is swap, /dev/had6 looks like AFS cache, and
/dev/hda7 looks like root, but there's no /boot partition. (My guesses
here are based on the number of blocks in the partitions.)
We solved the problem by creating a new partition over the beginning of
the disk, and this once again made Windows bootable.
For reference, here's what /proc/partitions showed (before recreating
the Windows partition -- same point as the fdisk output above):
major minor #blocks name
22 64 6144 hdd
3 0 78150744 hda
3 1 1 hda1
3 5 530113 hda5
3 6 530113 hda6
3 7 15647278 hda7
--
Kevin Chen
http://www.sneswhiz.com/
