Description of problem: Installing Fedora on one drive of a two drive system causes the partition table of the second drive to be changed. The first drive contains a Windows partition and partitions for the and I install FC to that drive. There are no linux partitions on this second drive and I donât create any during the install. After the FC4 installation the geometry on the second hard drive is changed. One side effect is that the partition table changes written by Fedora are seen as errors by partition magic (under windows). Version-Release number of selected component (if applicable): Final production release of FC4 How reproducible: Always Steps to Reproduce: 1. Record partition table info on both hard drives 2. Install Fedora Core 4 to the first hard drive 3. Recheck partition table info on both hard drives Actual results: After each install, the start head/sectors values were changed in the partition table on the second hard drive. Expected results: Fedora to not touch the second hard drives partition table at all. Additional info: Back in 2004 I tried FC2 and it gave the same problem (albeit using a different hard drive). I waited until FC4 before trying again â but it seems the problem is still present. I thought that this may be related to the CHS bug (http://lwn.net/Articles/86835/ ) but (a) this bug is supposed to be closed and (b) the partition table is still changed even when I specify the CHS geometry. The problem seems to be limited to Fedora - I have tried a minimal Ubuntu (5.1) install and a SuSE 10.0 installation - neither modified the partition table on either drive (other than changing the currently bootable partition). My Setup I have two drives, one is a small (1.5Gb) HD connected to the motherboards IDE second channel as a slave. This is formatted with a small primary FAT partition and an extended partition containing a small Linux swap partition and the rest is formatted as Ext2. The BIOS is set for LBA for this drive. The second drive is a 160Gb drive with multiple partitions (a FAT16 pri (DOS), a FAT32 pri (Win98), an NTFS logical, three FAT and several FAT32 logical partitions). This is connected to an ATA PCI card (Highpoint driverocket 133SB). This has no way to set/change LBA access - the manufactures documentation says it supports LBA48. Both drives have XOSL on the MBR and were formatted with Partition Magic. I installed Fedora (minimal install), selecting manual partitioning & selecting the preformatted Ext2 as the root mount point & told it not to reformat. I put GRUB in the root partition (except for the test when I omitted installing GRUB) Results After the install and adding Fedora to the XOSL menu, Fedora booted up ok. The installation of FC4 does not change the partition table of the (small) drive to which FC4 was installed (/dev/hdd). However, it changed the partition table of the large (160Gb) hard drive (/dev/hdg). (As checked by running the partinfo tool under DOS from a floppy). The changes to the large hard drive started at the first EPBR (extended partition boot record in partition magic terminology â itâs the second partition table entry for each logical partition, the pointer to the next logical partition) in the extended partition - that and all subsequent EPBRs had the start head/sector entries changed from [Head 0, Sector 1] to [Head 254, Sector 63]. Booting into Windows (or DOS) and running Partition magic gave error 116 (LBA and CHS values not equal). I have tried this several times: ⢠without specifying the disk geometry; ⢠specifying geometry as reported by fdisk -l for both drives (viz. "linux hdd=787,64,63 hdg=19457,255,63"); ⢠specified geometry as "linux hdd=787,64,64 hdg=19457,255,64â ⢠specified the 1.5Gb drive as reported by fdisk -l and specified 160Gb drive as its true physical geometry as determined by the drive manufacturers (Western Digital) s/w (viz. "linux hdd=787,64,63 hdg=310101,16,63") ⢠Without installing GRUB and specifying geometry as reported by fdisk âl ("linux hdd=787,64,63 hdg=19457,255,63â) After each install, the start head/sectors were changed on the large hard drive as described above. Iâve attached 3 files showing the partition tables: Initial.txt â The initial state before each linux installation. FC4_4.txt â The state of the partitions after installing FC4 and Specifying CHS parameters for BOTH drives as reported by fdisk -l. i.e. "linux hdd=787,64,63 hdg=19457,255,63" Ubu.txt â The state of the partitions after installing Ubuntu 5.1
Created attachment 128324 [details] The initial state of both drives partition tables before each linux installation.
Created attachment 128325 [details] FC4_4.txt – The state of the partitions after installing FC4
Created attachment 128326 [details] Ubu.txt – The state of the partitions after installing Ubuntu 5.1 Just FYI for comparison purposes.
Does this still occur with Fedora Core 5?
Sorry for the delay - it took me a while to get a copy of FC5 and then my previous reply appears to have been lost. Yes, the same problem still occurs with FC5. Install: I didn't specify the drive geometry. I performed a minimal install, deselecting all packages and did NOT install GRUB to any partition. At partitioning screen I left the 1.5Gb drive (/dev/hdd) selected and deselected the 160Gb (/dev/hdg) & selected custom. I told it to use existing ext2 partition for root and NOT to reformat it. Same for swap. After the install I didn't even run Linux. Result: the 160Gb drive was modified - all EPBRs in the extended partition had Head/Sector changed from 0,1 to 254,63. I don't understand why the CHS values are being changed at all as I gather that Linux only uses LBA and doesnt even use CHS.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
This is still a bug with FC5 (comment 5). I've changed the version in the bug header. I'm unable to try it with FC6 at the moment. I'll try to test it on FC7 as soon as I can. Thanks for the interest.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
Tested this on current Rawhide and did not see the behavior. You can either deselect the drive from the initial drive list in the gui install. or you can --ignoredisk in the kickstart.