From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: After installing FC1 above an existing 4 GB W2k system partition /dev/sda1, it is not possible to boot FC1. The system is a pure SCSI dual Pentium Pro PR440FX system, and the system disk is a Quantum Atlas II 10k 18.3 GB drive. The W2k boot loader is used to chainload FC1 in the usual way by means of a copy of the boot sector stripped off from /dev/sda2 (FC1 root partition). The system hangs at GRUB stage2 and needs a hard reset. Version-Release number of selected component (if applicable): 9.2-2 How reproducible: Always Steps to Reproduce: 1. Install FC1 above some existing W2k partition with LBA32 mode enforced (or not). 2. Strip off boot sector and install it for use with W2k boot loader. 3. Reboot system and choose FC1 from the W2k boot loader menu. Actual Results: System hangs after issuing the message: "Grub loading stage2...". Expected Results: The W2k boot loader should chainload GRUB and boot FC1. Additional info: This issue was observed after increasing the W2k partition size from 2 GB to 4 GB. After the failure described above, I tried a new install checkmarking the LBA32 option (which is rather relevant for IDE drives though). Actually, there was no change whatsoever. However, *even* for the bigger W2k partition size, a test installation of Red Hat Linux 7.3 worked out of the box on the same system without any special options! I finally figured out that I had to execute 'grub-install --force-lba' after booting into rescue mode to install a valid boot sector that I could strip off afterwards for use by the W2k boot loader. It seems that if a user checkmarks LBA32 during installation, GRUB is not forced to use LBA mode when writing the boot sector (possibly even necessary for SCSI disks). It appears logical to apply LBA mode *already* when writing the boot sector if this option was chosen by the user. I guess all of this is no issue when GRUB is using the MBR directly.
I have just finished a fresh install of Fedora Core 2 Test 3. Here, everything works out of the box. No special tweaking for "big" SCSI disks required. This observation should help to nail down the problem in Fedora Core 1. Thanks!