Hide Forgot
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. Yours Truly, Eldar.
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 Fat32 (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 swap). 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 dale@redhat.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.