When installing Red-Hat 6.2 (or 6.1 for that matter) native partitions on a
hard disk already containing a bootable Windows 98 FAT 32 partition (about
8Gb on a 20Gb disk in a DELL Optiplex workstation), the partition table was
affected in a subtle manner, undetectable by fdisk and most other
diagnostic tools. Lilo then managed to boot Linux, but Windows was
completely unbootable (it hang up) from Lilo (installed on the MBR) or from
a Windows floppy or a CD. I could finally fix this by using the Linux
cfdisk to rewrite the partition table without changing anything from what
it read. I would suggest you try recreating the scenario and see what is
changed in the partition table before and after the cfdisk procedure.
What is the original state of the partition table?
The original partition table had just one 8Gb partition (I set it with fdisk,
then installed Windows 98 into it). With the Red-Hat installation I added one
physical partition (/boot; about 32Mb if I remember correctly), and two logical
ones (a 512Mb swap and the rest of the hardisk went to root); all this done
through the Red-Hat installation program (custom installation mode). Lilo was
also installed updating the mbr by the installation program.
Could you please give the original partition table state as the linux command
'fdisk -l' would output it?
What is the geometry of your drive?
The information I got from fdisk:
255 heads, 63 sectors, 2482 cylinders.
The original partition table had one line. I think it was
/dev/hda1 (bootable), start:1, end:1020, blocks:8193118+, id:b, system:Win95
(actually this is the first line of the table now). The installer added one
physical partition (/boot from 1021 to 1023) and two logical ones (root and
Important note: I have just heard that the problem has to do with the
installation of LILO on the mbr (Windows seems to have stringent demands from
the mbr); it probably wouldn't occur if LILO is installed elsewhere.
Brock can you reproduce this problem with Pinstripe?
reassigning these to email@example.com for further review ...
I don't have this exact disk, but with a similar 20 gig disk I could not
reproduce this. If you have any more information on this please feel free to
reopen this bug.