Description of problem: When installing FC2 test1 on a dual boot system, cannot boot to windows patition Version-Release number of selected component (if applicable): How reproducible: always. reinstalled both windows and fc2 test1 2 times and the same Steps to Reproduce: 1.install windows on partition1 2.install fc2 test 1 on remaianing space 3.boot to windows partition and will not Actual results: will not boot to windows partition using grub Expected results: boot to windows partition using grub boot menu Additional info: using dos's fdisk partitions are as follows 1. non dos partition 2. non dos partition 3. extended partition 4. fat32 did not check with linux fdisk to verify dos's fdisk results
Can you attach your grub.conf and the output of fdisk -l in linux?
[root@localhost root]# fdisk -l Disk /dev/hda: 40.0 GB, 40016019456 bytes 16 heads, 63 sectors/track, 77536 cylinders Units = cylinders of 1008 * 512 = 516096 bytes here is what it says in fdisk in fc2 after a nother fresh install of fc2 test1 Device Boot Start End Blocks Id System /dev/hda1 * 1 40641 20482843+ c W95 FAT32 (LBA) /dev/hda2 40642 40844 102312 83 Linux /dev/hda3 40845 77332 18389952 83 Linux /dev/hda4 77333 77536 102816 f W95 Ext'd (LBA) /dev/hda5 77333 77535 102280+ 82 Linux swap and grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,1) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,1)/grub/splash.xpm.gz title Fedora Core (2.6.1-1.65) root (hd0,1) kernel /vmlinuz-2.6.1-1.65 ro root=LABEL=/ rhgb initrd /initrd-2.6.1-1.65.img title Other rootnoverify (hd0,0) chainloader +1 when i try to boot to windows xp all I get is rootnoverify (hd0,0) chainloader +1 and just hangs there when I try to reset the MBR in dos all I get is missing OS then check the partitions and get what I had said earlier.
Did another install from scratch and still the same. this time leaving everything to defaults in first boot. didn't change the kernel to reflect that I have an athlon processor and not an intel. One thing I did not mention, I had a second hard drive this time with a swap partition and a home directory. No changes in partition information though. Disk /dev/hdb: 10.2 GB, 10248118272 bytes 16 heads, 63 sectors/track, 19857 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/hdb1 * 1 1035 521608+ 82 Linux swap /dev/hdb2 1036 19845 9480240 83 Linux Still the same in dos's fdisk info, fat32 on partition 4. Has disk druid screwd up, if so I think you should make this a priority to have fixed.
I am leaving everything to defaults. if you need more info let me know
I have the exact same problem. Here's my fdisk -l and grub.conf. Disk /dev/hda: 163.9 GB, 163928604672 bytes 255 heads, 63 sectors/track, 19929 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 16572 133114558+ 7 HPFS/NTFS /dev/hda2 16573 19930 26963685 f Win95 Ext'd (LBA) Partition 2 does not end on cylinder boundary. /dev/hda5 16573 16704 1048918+ 82 Linux swap /dev/hda6 16704 17748 8388733+ 83 Linux /dev/hda7 17748 19706 15728548+ 83 Linux /dev/hda8 19707 19928 1783183+ 4 FAT16 <32M --- Here's grub.conf. # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0,6) # kernel /boot/vmlinuz-version ro root=/dev/hda7 # initrd /boot/initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,6)/boot/grub/splash.xpm.gz title Fedora Core (2.4.22-1.2115.nptlsmp) root (hd0,6) kernel /boot/vmlinuz-2.4.22-1.2115.nptlsmp ro root=LABEL=/ hdc=ide-scsi initrd /boot/initrd-2.4.22-1.2115.nptlsmp.img title Fedora Core-up (2.4.22-1.2115.nptl) root (hd0,6) kernel /boot/vmlinuz-2.4.22-1.2115.nptl ro root=LABEL=/ hdc=ide-scsi initrd /boot/initrd-2.4.22-1.2115.nptl.img title DOS rootnoverify (hd0,0) chainloader +1
FWIW, my system is a 3GHz P4 HT using the SMP kernel.
I got the same problem when I installed FC2 test1. It did not get it when I did an upgrade, it only happened when I did a normal installation. The good news is that I finally found out what it was. Somehow, the FC2 test1 installation managed to change (or damage if you like) the partition table in such a way that my BIOS started to use CHS mode instead of LBA mode. My BIOS was set to use Auto. Once I changed the BIOS setting to LBA, it worked again. So the question is: What did Fedora do to my partition table?
Ok. I have also had this problem in the last few days and here is what i did: I didn't think it was Fedora Core 2 Test 1. So I re-installed XP. It didnt want to know ? I even erased the MBR and formatted the drive installing a new partition for Windows using both FAT and NTFS, still no joy. In the end, I booted into linux, and in fdisk used option "o" which creates a new MSDOS partition table. I rebooted installed Windows XP and it was fine. I think the partition table has problems after installing Fedora Core 2 Test 1.
I tried several things (FIXBOOT and FIXMBR from the Recovery console; Windows Repair install; clean re-install Windows on a different partition), and nothing I tried would fix it, short of wiping the drive and starting over. It's worth noting in my list above that fdisk did complain about non-cylinder-aligned partitions, *but* fdisk didn't create any partitions--I made them in Windows, and just formatted them swap/ext3 when installing Linux. I tried to reproduce the problem later using a spare 2GB hard drive (since I didn't want to reinstall all my software on the 160GB drive all over again), but the problem did not occur. I suspect it's limited to larger drives, perhaps > 128GB. Re: Tobias's comment on LBA mode--my BIOS doesn't even give me that option, so I can't try that...
I'm running into the same thing. My drives were still LBA in the bios. I'm also on a P4 (2.6GHz HT SMP). Here's my stats: [root@glamdring root]# fdisk -l Disk /dev/hda: 80.0 GB, 80054059008 bytes 16 heads, 63 sectors/track, 155114 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 155088 78164226 7 HPFS/NTFS Disk /dev/hdb: 40.9 GB, 40982151168 bytes 255 heads, 63 sectors/track, 4982 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdb1 * 1 65 522081 82 Linux swap /dev/hdb2 66 77 96390 83 Linux /dev/hdb3 78 2028 15671407+ 83 Linux /dev/hdb4 2029 4982 23728005 83 Linux [root@glamdring root]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd1,1) # kernel /vmlinuz-version ro root=/dev/hdb3 # initrd /initrd-version.img #boot=/dev/hda default=1 timeout=10 splashimage=(hd1,1)/grub/splash.xpm.gz title Fedora Core (2.6.3-1.106) root (hd1,1) kernel /vmlinuz-2.6.3-1.106 ro root=LABEL=/ rhgb initrd /initrd-2.6.3-1.106.img title Fedora Core (2.6.3-1.106smp) root (hd1,1) kernel /vmlinuz-2.6.3-1.106smp ro root=LABEL=/ rhgb initrd /initrd-2.6.3-1.106smp.img title Fedora Core (2.6.3-1.96smp) root (hd1,1) kernel /vmlinuz-2.6.3-1.96smp ro root=LABEL=/ rhgb initrd /initrd-2.6.3-1.96smp.img title Fedora Core (2.6.3-1.96) root (hd1,1) kernel /vmlinuz-2.6.3-1.96 ro root=LABEL=/ rhgb initrd /initrd-2.6.3-1.96.img title Fedora Core (2.6.1-1.65smp) root (hd1,1) kernel /vmlinuz-2.6.1-1.65smp ro root=LABEL=/ rhgb initrd /initrd-2.6.1-1.65smp.img title Fedora Core-up (2.6.1-1.65) root (hd1,1) kernel /vmlinuz-2.6.1-1.65 ro root=LABEL=/ rhgb initrd /initrd-2.6.1-1.65.img title win rootnoverify (hd0,0) chainloader +1 [root@glamdring root]#
Well, time for another chapter in the story. I tried flashing my system's BIOS and the flash erase failed, leaving me with a doorstop. After warranty service from HP, I got the system back with a new motherboard and BIOS. It still wouldn't boot to Windows, which didn't surprise me. I wiped the drive and reinstalled Windows, then backed up the master boot record and partition tables before installing Linux, hoping to diff them and see what broke. However, this time, nothing broke. Windows booted just fine after Linux was installed. Also, a warning message about being unable to "align" partitions did not appear during this Linux install, while it did when installing Linux under the older BIOS earlier. So apparently there was a bug in my system's BIOS that caused the Linux installer (disk druid or grub, one of the two) to hose something, but after installing with a newer BIOS in place, it didn't happen.
Created attachment 98992 [details] Errors produced by Partition Magic
After changing my BIOS settings to LBA, I could boot into Windows. Upon booting, I opened Partition Magic and watched in horror as error after error popped up. In other words, it completely hosed my partition table. I have attached a compilation of the screenshots of the errors because I couldn't highlight the text to copy/paste it.
Just for the record; this bug is still present in Fedora Core 2 test 2
I solved this problem on my computer. FC1 and windows on my comp boot fine both, but if i upgrade to FC2 test1, so windows boot manager dont load. I tried reinstall both systems, repartitioning whole disk - nothing, after i install grub, windows boot loader dont start and this problem dont solve fdisk /mbr. All that you need is set your disk to LBA mode in BIOS. Dont leave there AUTO. Thats all. Linux read BIOS access mode wrong and grub setup something wrong on MBR - its why windows boot manager cant be find in MBR and windows cannt start. Attention. Please, check what access mode you realy normal use to access disk. Changing access mode from Large to LBA for example can lead to lose data from your disk! If you use another access mode than LBA and setting them in BIOS doesnt work, try backup your data and repartitioning disk in LBA mode.
I had the same problem on a machine that had formerly had FC1 and Gentoo running on partition 5. When I installed FC2 test 3 on it I got the partitioning warning mentioned above and then everything seemed to work until I tried to boot back into windows. Now I seem to be hosed....
Once I installed FC2 test 2 it trashed my MBR pretty much the same way. That time I've chosen to install GRUB into MBR. Since it messed up partition table (interestingly though, not entirely, looks like lba offsets were Ok, just CHS values were completely wrong). After that GRUP was able to load to linux, but not to Win2k. However, I managed to boot windows using Win2k boot disk (with ntldr & ntdetect on it). My playing around with MBR didn't help much, though after running recovery console, running fixmbr, fixboot and then MANUALLY editing ntfs bootsector, I was able to boot into Win2k from harddrive (not using grub, though, but native bootloader). Finally, I repartitioned entire harddrive, installed WinXP on it, created partitions for Linux using XP, than run redhat 9.0 install disk in rescue mode to set correct types of partitions. This time I backed up MBR and Windows boot loader (first 16 sectors of partitions). Then installed Fedora again. This time I specified Linux boot partition (/dev/hda3 in my case) as a destination for GRUB, hoping to use ntldr as a primary boot manager, and GRUB as linux boot loader only. Well, not a surprise, but MBR has been trashed again. Windows partition, however, has not been touched (I guess my previous manual edit of ntfs boot sector -head count was incorrect there- was due to some problem in MS fixboot). So I restored my backed up MBR, and lived happily thereafter, with both XP & Fedora working fine. Some info: hard drive 40GB partition table (to the best of my memory): /dev/hda1 <- win xp primary boot (10GB) /dev/hda2 <- extended /dev/hda3 <- linux boot (100MB) /dev/hda4 <- linux root (7GB) extended partition: /dev/hda5 <- ntfs /dev/hda6 <- ntfs /dev/hda7 <- FAt32 /dev/hda8 <- ntfs /dev/hda9 <- linux swap I don't have exact info at hands right away, but if it helps to fix a problem I can supply exact partion table info (out of fdisk or smth. else), both trashed & 'good' mbr versions.
Just got burned by this problem in FC2 test 3! What a nightmare and a complete waste of time. This is the sort of MAJOR ISSUE THAT BELONGS IN RELEASE NOTES, EVEN FOR A TEST RELEASE. Seriously, it's not like it was reported by one guy on a random setup; many people have wasted countless hours due to this, and potentially lost data. Yes, it's a test release, but its the LAST ONE for FC2, and this problem still isn't solved. Pull it together! I'm a little ticked off right now if you can't tell. And yes, my system had a 'large' hard drive on it. (Well, modest by today's standards -- 120GB.) WHERE'S THE FIX?
I have not counted the wasted hours I've spent in the hope to find a solution for this problems that occured on my box after the installation of fedora core 2 test 2. Hardware and software are p4 on asus motherboard, xp on hda and fedora on sda (which is a sata-disk). Initially I've installed grub to the mbr of the hda, which gave the-by now-expected result. I tried about all what we can read up there (also the lba in bios-trick) but nothing worked. Having two harddisks, a supplementary, possible but finally not succeeding solution gently nocked on the door. I've installed grub from scratch using the fedora rescue mode (I needed knoppix before to download it) and I installed grub to the mbr of the sda. In order to make xp accepting this I mapped the disks in grub... The result was zero null nada (in floating point). Is it for sure that only the mbr was affected by this bug. Given the fact that loading boot.ini from the mbr of the other disk didn't work one could think that also the first sector of the xp-partition is touched. I hate wasting my time on windows and now I will have to reinstall it? (housepeace in mind)
This is still happening on FC2 Test3, And the way I solve it is, Fixmbr, fixboot and change the bios setting from CHS to LBA. From My point of view, the grub did "changes" the MBR so that the BIOS change from the default LBA into CHS. I can't even boot using HDD even for a Windows Recovery. But After LBA is selected, I've all problem Fix. This is a Athlon XP 1800+ FYI
After 3 days of hashing out this. From formating and starting with FC1 up throught FC2t3 all I can say is this does not look good. The grub change to the CHS values is the deal. The problem for me went a way if I have xp boot on a different drive and switch at boot in BIOS. Is there any thing anyone would like me to try?
Hmmmmm ... but is FC2 to blame? Here's my experience. Windows XT installed in a 5G partition by vendor (which means that the disks were originally formatted in the XP environment). FC2t2 installed locally, as P4-class (ie no 64-bit opts) . MB is dual Opteron AccelerTech ATO2082-A with Phoenix BIOS, version 6. %fdisk -l Disk /dev/sda: 37.0 GB, 37019566080 bytes 255 heads, 63 sectors/track, 4500 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 637 5116671 7 HPFS/NTFS /dev/sda2 638 650 104422+ 83 Linux /dev/sda3 651 4500 30925125 83 Linux Install worked flawlessly, even detected SATA disks. SMP kernel selected No problem with dual boot.
*** Bug 120128 has been marked as a duplicate of this bug. ***
The MB is a Intel 865 GBF with 512 mb. ram P4 2.4 on board drive controler for SATA 80 gb 7200rpm drive EIDE 13 gb 5200 rpm. The think I have not made work is ; /dev/sda1 NTFS 30 gb /dev/sda2 Linux /boot 100 mb /dev/sda3 Linux / 30 gb What does work. Because the XP boot was not changed. /dev/hdc1 NTFS 13 gb /dev/sda1 NTFS 30 gb /dev/sda2 Linux 100 mb /dev/sda3 Linux 30 gb It does not matter if I write the hdc1 MBR or the sda MBR. IF you look the CHS is blowen. Sometimes the boot repair stuff in XP repair works and somethimgs mot. Anyone want me to try somethimg ?
I think 113201 is this problem too. Off Topic: I'm actually floored the release is happening with this bug still around...
I know people who don't know will say "well it's just open source". But is that not our greatest advanage. We can say it an't ready we an't letting it go yet. We need not only know the problems but the work a rounds so no one has to work thorght the same problem. Remember "Open Source"
Perhaps the developers know some of the following information already, but here is what I found: The way that the kernel reports geometry information has changed from 2.4 to 2.6. Reference here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=1Gjko-6Y1-5%40gated-at.bofh.it&rnum=4 Note that this thread shows that in kernel 2.6.6 there is a way to get the "old" geometry information. This problem has been known since at least last December, reference here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=WJ3h.3dk.1%40gated-at.bofh.it&rnum=4&prev=/groups%3Fq%3Dparted%2520kernel%25202.6%26hl%3Den%26lr%3D%26ie%3DUTF-8%26sa%3DN%26tab%3Dwg and here: http://mail.gnu.org/archive/html/bug-parted/2003-11/msg00051.html I'm not sure if parted has been fixed yet, but this patch appears to try to address this issue: http://mail.gnu.org/archive/html/bug-parted/2004-04/msg00079.html In fact, the common symptom that people complain about is that they can't boot windows. And I agree with comment 25 that bug 113201 is likely the same as this one. Shouldn't this bug be considered a showstopper?
yes in dede
Actually had the same problem.. Had both FC2 (test3 + yum'ed development tree updates) and Windows XP booting fine, 'till at some point XP refused to boot. So the problem sounds the same, however i did experiance this using lilo and this problem still hit me, hence i don't think the problem is limited to grub but infact triggered by the disk geometry differences between kernel 2.4 and 2.6 Completely hosed my access to my windows partition, had to reformat the drive completely.. 2 days of my life wasted by re-setting everything up.. Now i am aware i run this risk when i use FC2-test* versions, but by the sound of it, this bug still exists in the final version to. Sounds to me like this _should_ be a serious show stopper, destroying people's data is often seen as quite a serious issue and might not help redhat/fedora's/linux's reputation one bit
Oh to add to the above. Most of the time i've been using FC2, but with a 2.4 kernel (latest from FC1 updates), and this worked fine for some time. Sounds likely that during some 2.6 experimenting or kernel upgrading this bug hit me.
Okay, can anyone reproduce this with the _final_ FC2 without having installed a test release? If you installed any of the FC2 test releases at any point, you're disqualified from this test (as they didn't necessarily have all of the changes needed and once the different partition table is written, that's always what's going to be believed). I haven't been able to reproduce this myself and reports are somewhat conflicting at best as to whether or not the last batch of changes really fixes things.
Oh goody. I just went through a rebuild-partion-tables fest. My computer has an Adaptec 1200A RAID card which I have setup for RAID1. This is my boot drive (WinXP already there). I did a clean install of FC1 and let it put GRUB on my boot drive(s); Mistake #1. This fried my partion table(s) on the RAID drives. Fedora/Linux does not support this particular card. I unplugged the secondary so I could work fearlessly on the primary. After a lot of research and tool-collection and kicking myself for forgetting to create a PartionMagic emergency boot disk with my current config, I was finally able to get the partion tables repaired. I booted back into the repaired disk and some pending PartionMagic changes kicked in; Mistake #2. I had shuffled my disks around for the FC1 install, and PartitionMagic re-fried my partion tables. I fixed the partion tables, installed WinXP instance on another partion and booted into it so I could remove the PM-exec-on-boot crap. As it stands, when I want to switch between Fedora and my original XP boot, I have to change a bios setting to boot from the IDE drive (which has Fedora) and my RAID drive(s) (which has XP). Fedora boots through grub, ignores my RAID, and lets me boot into the new clean XP installation. BTW, I used PartionMagic to rebuild the part table after the final toasting. It worked faster and better than the semi-manual techniques I was using from Fedora. But I wouldn't have understood how to correctly use PM for this task had I not done it previously using tools on Linux. Given what I have heard, I will be backing up the MBR and all of the partion tables and boot sectors on my Fedora/WinXP IDE drive and turning off my RAID drive(s) _before_ updgrading to FC2. I have learned (the hard way) that paranoia about this stuff can save a lot of time.
I have the partition table too after installing FC2 (fresh install, not upgrade) on a laptop, with the Grub in the Linux partition (not in the mbr). After trying different things, I managed to fix the partitions and restore the original C/H/S configuration. After that everything worked fine again. The steps I took are: - boot using Knoppix - save the starting/ending sector and id for each partition - wipe out the partition table (using dd) - recreate a DOS partition table and the individual partition entries using fdisk - run 'fdisk /bmr' from a DOS floppy This seems to restore the mbr very well: the numbers reported by fdisk are ok and I can boot in XP fine without changing anything in BIOS (like LBA mode). If you need more information, I posted the steps in more detail on the fedora-test-list: http://www.redhat.com/archives/fedora-test-list/2004-May/msg02114.html
I have been trying to reproduce the problem, but so far, FC2 and WinXP both boot fine. Perhaps indeed since I did my installations on a freshly partitioned and formatted disk that had not had a FC2test release on it to mess with its C/H/S settings. Or I've just been lucky so far. Hardware: very old, PII 350 MHZ, ASUS P2B board, 256 MB RAM, Maxtor 32049H2 harddisk 20 GB Yep, didn't want to risk messing up my normal desktop or laptop yet...
Happened with a fresh final here, no test releases whatsoever. FC1 (and grub), however were installed. Of course, I kind of expected it since anaconda spitted a parted error message (as per bug 113201).
What really bothers me is that the partition table is modified even when you do not add, remove or change any paritions. Everyone knows that repartitioning is dangerous, but I thought I was safe when I did not add, remove or change any partitions during the installation. Note that this happend with FC2test3, and it might have been fixed since then.
I don't think it got fixed. I installed over FC1 and used the existing partitions, but still got fried. It also bothers me too have the installer write the partition table when I did not allow it. Probably the bug could be traced in the anaconda code. I am not familiar with it, but the fact that it writes the mbr even when no partitioning is required (and grub is written to the Linux partition) should make it easier to find the culprit.
I have been trying to prove the bug is in the raw code 2.6.5 code for two days with knoppix 3.4's linux 2.6.5 kernal and the latest grub and XP. I have try five differant setups but they all work with a MBR write every time. On an 80 gb. SATA, 13 mb. EIDE, 10 gb. IDE, Intel 865 GBF MB with onboard SATA and IDE controler, P4 2.4, AMI BIOS 4/5/04 and 512 DDR PC3200. The first time I did a FC2test3 date 4/21/04 squigial-de-shit in the MBR tables. Jim Metz
Here is a much easier way to fix the partition problem, as suggested by Alexandre Oliva on fedora-test-list: sfdisk -d /dev/hda | sfdisk --no-reread -H240 /dev/hda The 240 value worked for me, in other cases probably 255 is better. Plus, if this helps finding the bug, the kernel still reports wrong disk geometry in /proc/ide/hda/geometry, even after fixing the partition table with the correct values. My machine is a IBM Thinkpad 600e laptop. If I can do anything to help find the problem, please let me know.
*** Bug 123658 has been marked as a duplicate of this bug. ***
*** Bug 123720 has been marked as a duplicate of this bug. ***
This may or may not be related. I have FC2 test3 installed with Windows 2000. Due to some "creative" layout choices with my partitions, I managed to prevent Windows 2000 from booting, and subsequently repair and boot Windows 2000. Initial layout before installing FC2: 8 gig unpartitioned space, 30 gig Windows 2000 (boot), 60 gig FAT32 storage, 20 gig unpartitioned space. Desired layout chosen during FC2 install: 100mb FC2 "/boot" partition, 7.9 gig unpartitioned space, 30 gig Windows 2000 (boot), 60 gig FAT32 storage, 20 gig FC2 "/" partition. The problem found after choosing this layout is that booting the Windows 2000 partition will either hang as described in the posts above, or proceed to a black screen with the message - "Windows could not start because the following file is missing or corrupt. <Root>\system32\ntoskrnl.exe. Please re-install a copy of the above file." This problem seems to arise from having windows on the first available partition of the hard disk before installing FC2, then when the boot partition for FC2 is inserted prior to the Windows partition in the partition table, Windows can no longer locate its kernel to boot with. I solved this by manually renumbering the partitions using Ranish partition manager, resetting my Windows 2000 boot partition as the first partition in the table, storage as the second, then "/boot", and finally "/" as the fourth partition. In linux terminology, this numbers the partitions as follows: Windows 2000 30gig (boot) --- hda1 FAT32 Storage (60gig) --- hda2 FC2 "/boot" --- hda3 FC2 "/" --- hda4 A possible reason this problem isn't experienced by everyone is that extended partitions seem to be numbered as 5 and above when created during the FC2 installation. This means that despite the "/boot" partition being created prior to the Windows 2000 in terms of physical disk order, the extended partition itself is always numbered greater than the Windows 2000 partition. As I wanted to add a swap partition to my disk, I had to create this kind of partition table on my computer. Again in linux terminology, this it the partition layout: Extended partition --- hda5 - contains "/boot" --- hda6 - contains "swap" --- hda7 Windows 2000 (boot) --- hda1 FAT32 Storage --- hda2 FC2 "/" --- hda3 This problem may stem from the windows installation itself - here are some links to Microsoft Knowledge Base Articles describing similar problems, the first page describing and upgrade from Win98, and the second about a scenario with OS/2 installed on a dual-boot system (which is probably more relevant). http://tinyurl.com/wud0 (Win98 upgrade) http://tinyurl.com/h4k7 (OS/2 Dual Boot) This might explain some of the problems some users have had losing the ability to boot WindowsXP from GRUB after installing Fedora. Hope that helps, Tom
FWIW... I upgraded from FC1 to FC2. Saw the "partition alignment" alert, told the installer _not_ to upgrade the boot loader. It's all working fine. Parition 1: WinXP, partition 2: Fedora FC2, partition 3: swap
WRT comment #43 : Tom, from the looks of Win2K complaining about ntoskernel.exe, it seems like BOOT.INI being found anyway (hence the windows partition was booted correctly). Did you try updating C:\BOOT.INI before changing the partitions' order, e.g. : multi(0)disk(0)rdisk(0)partition(1)\WINNT ... to multi(0)disk(0)rdisk(0)partition(2)\WINNT ... ?
*** Bug 123832 has been marked as a duplicate of this bug. ***
Hi: I did not try the test versions. I got the FC2 final last night. Had the same 'align' message, but I did proceed anyway. I have now dual boot working fine, without troubleshooting. But it is a worry for other users that have come across this one. I was lucky I guess, that I did not trash my XP partition... for this is the company's laptop (toshiba, graphical mode working fine after a little tweek in resolution). I said yes to the 'update mbr' part. Anyone wants to know more details of my partitions, let me know (carlosh[at]linuxservices.co.nz) and I'll post them.
Been through this twice. I had FC1 installed as a second partition and then decided to try FC2 (no test releases). After installing FC2 (final) I couldn't boot WinXP Home. After fiddling with things I reloaded XP Home from the vendor's recovery CD, which also reset the partition table. Then I used ntfsresize from Knoppix, and installed FC2 yet again. Then I got disk errors in FC2 like the following upon boot: Buffer I/O error on device hda4, logical block 0 Buffer I/O error on device hda4, logical block 1 Buffer I/O error on device hda4, logical block 2 I also couldn't boot WinXP Home (again!) I'm in the process of running the recovery CD to start over yet again.
Some experiments I have run suggest that the FC2 dual boot problem is generated by the fact that Windows2K/XP and FC2 with kernel 2.6 are using different values for disk geometry. I have a dual booted Dell C600 laptop with Windows2K and FC1. Partition Magic reports the disk geometry under Windows as 2432/255/63 and FC1 (/proc/ide/hda/settings) reports it as 2432/255/63. I booted FC2 disc1 into rescue/read only mode. FC2 (/proc/ide/hda/settings) reports the disk geometry as (38760/16/63). If you install FC2 so that new partitions are created during the installation, then the FC2 geometry will be used and your will no longer be able to boot to Windows. If you do an upgrade, then no new partitions will be created and you should be OK. If partitions have to be created, they would have to be created on the Windows side so that when you install FC2 you have a Windows compatible partition table. I cannot take a chance on trashing my work computer, so I have not verified these statements. As far as I can tell from user comments, everyone who installed FC2 without creating a new partitions during the FC2 install were OK. You can argue if this is a bug or a feature, but there is no doubt that is has made life a little more difficult for first time dual booters who need to create partitions for Linux. This takes dual booting out of the âeasy installâ category.
I had a similar problem, except that I can't get LILO or Grub to load anymore. Lilo gets as far as L (and with no error message), and Grub does "Loading Stage 1.5\n\nLoading please wait...." (or something similar) - again no error codes here either. I have an Intel D865PERL motherboard which does not allow me to force LBA mode, although I can disable it (which I have not tried - doesn't seem like the smart thing.) I have a 60GB Drive, with a 40Gb Win XP partition at the beginning. I am attempting to install FC2 on the remainder of the disk. This machine used to work with FC1, but since I attempted to install Debian and FC2, things have not been working correctly. (fiid at fiid dot net)
Resolved it. I just did a clean FC2 install (still have my old windows partition.). I did the sfdisk trick mentioned above with -H255. sfdisk moaned that my linux partitions aren't on cylinder boundaries (they were created with the wrong geometry loaded, as hacked by the installer), but I used the --force option, rebooted, and magically, GRUB started working (the FC2 installed grun displayed "GRUB" before, and now works perfectly), and both Windows and FC2 boot perfectly. You may not be able to reproduce this on all systems - I would think it depends on the drive you are using, and which geometry it started off with. Mine got reconfigured from 255 heads down to 16 (guessing here).
I installed FC2 into a pre-existing partition on a system with a recent A7N8X-VM/400 mobo and the latest BIOS which had been running FC1 (installed second), winXP (installed first), Debian and Gentoo. The FC1 grub was being used as bootloader. The LBA access mode was set to [Auto] which is the best you can do, the choices being [Auto] and [Disabled]. Even though I instructed anaconda not to touch the bootloader and created no new partitions, the machine was left completely unbootable. Using sfdisk and reinstalling the FC1 grub restored sanity. Is simply creating a mount point in DiskDruid enough to mess up the MBR?
I have same problem, when installing FC2 grub couldn't boot my WinXP 1) I install WinXP home 2) install Fedora Core 1 everyting works fine 3) install Fedora Core 2 - Final (not test) and make clean installation, not upgrade (format ext3 partitions for Fedora Core 1) my win xp does't boot and error was: NTLDR is missing and after 2 or 3 times making upgrade on Fedora Core 2 to make fresh MBR when start WinXP also following error was reported: Error 13: Invalid or unsupported executable format my conf file is : /etc/grub.conf: # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0,1) # kernel /boot/vmlinuz-version ro root=/dev/hda2 # initrd /boot/initrd-version.img #boot=/dev/hda default=1 timeout=10 splashimage=(hd0,1)/boot/grub/splash.xpm.gz title Fedora Core (2.6.5-1.358custom) root (hd0,1) kernel /boot/vmlinuz-2.6.5-1.358custom ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.5-1.358custom.img title Fedora Core (2.6.5-1.358) root (hd0,1) kernel /boot/vmlinuz-2.6.5-1.358 ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.5-1.358.img title WinXP rootnoverify(hd0,0) chainloader +1 /sbin/fdisk -l Disk /dev/hda: 60.0 GB, 60011642880 bytes 16 heads, 63 sectors/track, 116280 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 20321 10241406 c W95 FAT32 (LBA) /dev/hda2 20321 50793 15358140 83 Linux /dev/hda3 50793 52626 923737+ 82 Linux swap /dev/hda4 52626 116280 32081805 f W95 Ext'd (LBA) /dev/hda5 52706 73616 10538608+ b W95 FAT32 /dev/hda6 73616 116280 21502971 b W95 FAT32 Disk /dev/sda: 200.0 GB, 200049647616 bytes 255 heads, 63 sectors/track, 24321 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 2 24321 195350400 f W95 Ext'd (LBA) /dev/sda5 2 11573 92952058+ 7 HPFS/NTFS /dev/sda6 11574 18075 52227283+ 7 HPFS/NTFS /dev/sda7 18076 24321 50170963+ 7 HPFS/NTFS sda is my USB external HDD hda is 60 GB internal HDD my computer is Fujitsu Siement Amillo D 8830 all win partitions are Fat32 C:\boot.ini [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Home Edition" /fastdetect i have olso files: C:\ntdetect.com and C:\ntldr vi /proc/partitions major minor #blocks name 3 0 58605120 hda 3 1 10241406 hda1 3 2 15358140 hda2 3 3 923737 hda3 3 4 1 hda4 3 5 10538608 hda5 3 6 21502971 hda6 8 0 195360984 sda 8 1 1 sda1 8 5 92952058 sda5 8 6 52227283 sda6 8 7 50170963 sda7 following command doesn't work: sfdisk -d /dev/hda | sfdisk --no-reread -H240 /dev/hda even when --force is present, error output is following: Warning: HDIO_GETGEO says that there are 16 heads Disk /dev/hda: 116280 cylinders, 240 heads, 63 sectors/track Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently. Old situation: Warning: The partition table looks like it was made for C/H/S=*/16/63 (instead of 116280/240/63). For this listing I'll assume that geometry. Units = cylinders of 516096 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hda1 * 0+ 20320- 20321- 10241406 c W95 FAT32 (LBA) /dev/hda2 20320+ 50792- 30473- 15358140 83 Linux /dev/hda3 50792+ 52625- 1833- 923737+ 82 Linux swap /dev/hda4 52625+ 116279 63655- 32081805 f W95 Ext'd (LBA) /dev/hda5 52705+ 73615- 20910- 10538608+ b W95 FAT32 /dev/hda6 73615+ 116279 42665- 21502971 b W95 FAT32 sfdisk: unrecognized input: extended partition does not start at a cylinder boundary. any suggestions ?
I even cann't boot Win XP home CD-ROM disk when press any key to boot from CD-ROM when I hit some key loading from XP CD-ROM disk begin with message "expecting system.." and after that screen come blank (black) and nothing happened and my BIOS have only auto and disable for LBA mode
Re comment #54 I've had the same thing happen to me. Seems the partition table weirdness also causes the XP instalation cd to fail booting (presumably on reading partition info). Work around for me was to nuke all the partitions of my drive (ouwch!) then install XP and FC1 as normal, then use yum to upgrade to FC2.. Only way i could get my system to function properly atm
Hello , i have also the problem , But how can i fix the harddisk ? Thx to this bug my C:/ is not working. I opend parition magic but i cant do anything to fix the disk geometry I'm really a noob about this , so if you could explane in easy language that would be very nice. Here is my parition info artition Information for Disk 3: 78,167.3 Megabytes Volume PartType Status Size MB PartSect # StartSect TotalSects ====================================================================== ===================================== E: NTFS Pri,Boot 53,568.7 0 0 63 109,708,641 ExtendedX Pri 24,592.1 0 1 109,707,885 50,364,531 Error #113: Primary partition starting at 109707885 overlaps previous partition. EPBR Log 24,592.1 None -- 109,707,885 50,364,531 F: FAT32 Log 24,592.0 109,707,885 0 109,707,948 50,364,468 Unallocated Pri 6.9 None -- 160,072,416 14,112 How can i repair that 16 heads into 255 heads , please tell me
>How can i repair that 16 heads into 255 heads , please tell me boot from Fedora Core 1 (not 2) boot CD into linux rescue mode chroot /mnt/sysimage sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda
Thx but can i fix the disk in windows ? because i haven't a Fedora core 1 cd :(
i found solution try this: sfdisk -d /dev/hda > temp.txt vi temp.txt and remove line up to comment line (Exeption explanation message) then: cat temp.txt | sfdisk --no-reread -H255 /dev/hda
Windows XP on hd1 Clean install Fedora Core 2 to hd0 Windows hosed. Why is the install touching my second disk? I was using BIOS to say which hdd to boot. [System: ABIT KT7A, Athlon XP2000+ HDD 0: 40GB WD HDD 1: 40GB Maxtor] Bit me on test 3, and again on Final! (Must be an idiot - but at least I didn't lose any data 2nd time)
I did a fresh install of Fedora Core 2 (final) on my laptop which originally had WinXP and RedHat 9. I didn't modify any partitions but just formatted the RH9 ones and installed Fedora on top. Installed GRUB in MBR (as I've always done previously). Dual booting seemed fine for the first day but one time (all of a sudden), booting into Linux became very very slow. The hard drive light is constantly on and it took me like 10 minutes to boot into Windows. Tried to boot into windows and sat the bootup screen for minutes on end. Then I booted from a PartitionMagic boot disk and fixed the partition table....now Windows can boot but it takes a long time to boot (sitting at bootup screen, HD light constantly on). Linux is also slow (again HD light is on very frequently even when loading a program which takes forever). I've done fixmbr, fixboot in recovery console. Does very little other than kill my GRUB. I've calculated my legacy cylinder, head, sector counts from that EDD patch (3648/255/63) and echoed to /proc/ide/settings, I've done the sfdisk trick above, checked my BIOS (according to LILO, BIOS is using LBA), I've reinstalled GRUB, tried LILO, fixed in PartitionMagic and still booting up into Windows is either slow or doesn't work. :( I just tried Ranish partition manager and to my disbelief, I have overlapping partitions!! In big red letters, it looks like I have 5 or 6 extended partitions?!!? So here I am, backing up all my important stuff and gonna repartition everything again. This is terrible. :(
Microsoft introduced the "Dynamic Disk" disk label to solve these issues. Do the latest GRUB and 2.6 distros support installing and booting on hard drives that have a "Dynamic Disk" disk label? If so, someone should really modify Anaconda so it offers the option to label the disk as a "Dynamic Disk" in addition to just defaulting to the legacy "DOS" disk label. It should also warn that using a "Dynamic Disk" disk label, while recommended when dual-booting with NT 5.x versions (2000, XP, 2003), limits them to running those versions (as well as select BSD and others -- possibly DR-DOS 8.0 too?). HISTORY/LOGIC: I've had a long history of issues with NT and disk geometry, even when running just NT versions. This is no different with even NT 5.x versions (2000, XP, 2003) when you use the legacy "DOS" disk label of primary, extended and logical. There is just no way to make assumptions on what "disk geometry" to use -- the BIOS, the "DOS" disk label (aka partition table), etc... when the "DOS" disk label is used. If another OS is installed (even another version of NT), there can be trouble if the geometry is affected in some fashion. That's why Microsoft introduced the "dynamic disk" disk label with NT 5.x. It does many things, from storing SID info (so a NTFS filesystem can be read by another system that didn't create it, which is typically an issue because SIDs are stored in the registry) to the "assumed" disk geometry. I regularly bring up the "Dynamic Disk" recommendation when people complain about the limitations in the Linux NTFS driver. It's not a Linux issue, but an issue with NTFS and NT SID's themselves. The "Dynamic Disk" disk label solves that as well, because it allows these "NT-installation specific" SIDs to be stored outside of its registry (so other NT 5.x installations can read them too). The "assumed" disk geometry is also stored there too. I really need to research more into GRUB and 2.6. I know even 2.4 supports the "Dynamic Disk" disk label, but can you boot on one with GRUB and Linux? That's my question.
Alright, I did some homework. This sounds like a job for the community (and not any one vendor). I think we really need to "step it up" and start creating some tools for creating volumes in the LDM (Logical Disk Manager) "disk label" (aka the "Dynamic Disk" disk label). Trying to "ass-u-me" what "disk geometry" NT wants with the legacy "DOS" disk label is going to be a continued PITA. Damn, this was so much easier with DOS-based Windows (95, 98, ME) because it wouldn't even boot if the BIOS and DOS disk label geometry didn't match. ;-> Now before someone says otherwise, understand why I recommend this: 1. Microsoft is pushing LDM adoption hard 2. It solves a plethora of issues (from NTFS-SIDs to Disk Geometry) 3. LDM is already well documented, so it can be well supported What I've found out so far ... From the LDM (Logical Disk Manager) support in Linux 2.4: http://linux-ntfs.sourceforge.net/ldm/index.html "When Linux boots, you will see something like: Partition check: hda: [LDM] hda1 hda2 hda3 hda4 hda5 hda6 hda7" So there _is_ LDM support in Linux 2.4. I'm sure it is also in Linux 2.6. But when it comes to booting, that's a whole different ball game ... "Booting ------- If you enable LDM support, then lilo is capable of booting from any of the discovered partitions. However, grub does not understand the LDM partitioning and cannot boot from a Dynamic Disk." That makes sense. LILO boots very "static." That means when you install the LILO MBR/bootstrap, it stores the "raw offset" of the kernel it needs to load. That way, it doesn't matter what the underlying "disk label" is, it will work. GRUB, on the otherhand, boots very "dynamic." That means it inspects the disk at each boot. Since GRUB doesn't support the LDM "disk label," it won't be able to load Linux. Of course, if someone adds LDM support to GRUB, this would change. There is also a great deal of info in the FAQ: http://linux-ntfs.sourceforge.net/info/ldm.html There seems to be a lack of utilities for creating/modifying LDM volumes. I would at least like to see someone create a program that would allow you to create a "simple" volume in a LDM. That way you could create Linux volumes in an installer. Again, sounds like a job for the community. If we just have LDM support, then we can remove the geometry issues algother. Then the distros can just start modifying their installers to use LDM instead of trying to play the DOS disk label "disk geometry guessing game" like we're now seeing. Again, everything was much easier back with DOS-based Windows (95, 98, ME) because it wouldn't even boot if the BIOS and DOS disk label geometry didn't match. NT has always been a PITA in this regard, even when dual-booting different versions of NT itself!
OK, I just nuked all my partitions (and wiped the MBR for safe measure) and installed XP first. Then I used PartitionMagic to make all my ext2 linux partitions (with /boot within the 1024 cylinder limit) in the hope that DiskDruid would not have to touch the partition table. Then I installed Fedora Core 2, only giving the partitions their labels and choosing to format to ext3. I also installed GRUB on the /boot partition rather than MBR and letting ntldr do the booting. Yet when I go to PartitionMagic, it gives me zillions of partition table errors. :( After fixing them, everything seems to be fine. Windows is booting normally and so is linux. I wonder how long till linux messes up my MBR again behind my back. :( Anyway, it seems that the MBR was still touched even though I didn't make any partitions using linux tools. Does formatting or labelling write to MBR?
Steve (s.so.au) it sounds like you have something that might be reproducable. Maybe it would help, if you could take a copy of the partition table (both the MBR and any extended partition tables) before and after an attempt to install of Fedora Core 2, so it can be seen exactly what bytes are changed.
I have read through this thread pretty carefully and do not see any mention of anyone trying to reinstall grub using the --force-lba flag. I would be curious to know if "grub-install --force-lba --recheck /dev/hdX" fixes a broken install. I think there is a variance as to how the force-lba option is offered between the graphical and text mode installers. I think it is on the click-through 'advanced' page on the graphical install while it stares one in the face on the text mode install. I have yet to try FC2 on my FC1/XP-Home production laptop.
I had a problem which seems the same, and I changed the grub.conf entry to something similiar to this. Of course it doesnt fix the faulty auto-setup behaviour. title winxp rootnoverify (hd1,0) chainloader +1 makeactive boot the makeactive selections is required as winxp only boots off an active partition, and you should 'boot' into the partition, rather than load a kernel from it which is the default behaviour.
Some information on the 2.6 kernel changes: http://mail.gnu.org/archive/html/bug-parted/2004-03/msg00094.html
Regarding lba, I have installed lilo before and put in the lba32 option (before I nuked my partitions and reinstalled everything). It didn't seem to make any difference. Windows disk access grinded to a near halt and so was linux as well.
Responding to Kasper Dupont (tmzufqummuxdmcwtxkuijvystqlef.dk), I did make a backup of my MBR after I made my linux partitions in PartitionMagic and before I installed FC2. After I installed FC2, I noticed my MBR was damaged so I restored the backed up MBR. I'm not sure whether that made any difference. But thanks for reminding me. I forgot to mention that step. :)
This is a continuation of comment #49. I have a Dell C600 laptop dual booted with Windows2K and FC1. Partition Magic reports the disk geometry as 2432,255,63. When booted to FC1, the same values are reported by fdisk -l /dev/hda, parted /dev/hda, and by the 2.4 kernel in /proc/ide/hda/settings. When I boot FC2 disc 1 to rescue mode, the 2.6 kernel reports the disk geometry as 38760,16,63, fdisk -1 /dev/hda reports it as 2432,255,63, and parted reports it as 38760,16,63. The reports of other users suggest that if I create new partitions during FC2 installation, Disk Druid will create a new partition table using the geometry 38760,16,63 because Disk Druid uses parted. In this case, I will not be able to boot to Windows. If new partitions are not created during FC2 installation, i.e. I use my current partition table, Disk Druid will not create a new partition table and will continue to use the geometry 2432,255,63. In this case, I will be able to boot to Windows. At least one user has reported that Partition Magic will report and fix errors after the installation. I have noticed the same behavior in past installs but these errors have never caused any problems. Partition Magic is reported to have a restrictive definition of a partition table format. What is needed is a method of overriding the disk geometry that the 2.6 kernel is using during installation and thereafter. This can be done by using a kernel parameter. If I insert FC2 disc 1 and at the boot prompt type linux hda=2432,255,63 rescue, I see that the 2.6 kernel, fdisk, and parted all report the geometry 2432,255,63. Based on this experiment, I believe that I can do a FC2 dual boot install by inserting FC2 disc 1 and at the boot prompt typing linux hda=2432,255,63. During installation, the kernel parameter hda=2432,255,63 can be inserted during grub configuration. This will insure that parted works correctly after installation.
I can verify that the kernel parameter trick works. I just booted with the correct CHS values and did a dmesg. Sure enough, the kernel is reporting them (255 heads rather than 16). So if this is done during install, I'm sure it's gonna avoid this problem. :)
Might be able to add a bit here. For reasons given below, I suspect this may be a Windows bug rather than one in Grub. With ANY multiboot installation, don't EVER use the Windows 2k/XP Disk management utility to change the active partition! On three different machines this completely erased the master boot record - actually corrupted it, since detailed examination revealed nonsense data. I cannot tell you how gutting it was to have a two-day perfected multiboot installation suddenly disappear. After the first disaster I had a countermeasure in place, viz. a floppy disk with a copy of the master boot record; use "dd if=/dev/hda of=/dev/fd0 bs=512 count=1". [If you only want the boot loader backed up, not the MBR, use "dd if=/dev/hda of=/dev/fd0 bs=446 count=1"]. With your MBR floppy to hand it's a simple matter to undo the damage done by XP/2k: "dd if=/dev/fd0 of=/dev/hda bs=512 count=1". Regards, TC
I concur with many people here. In years of dealing with NT, it really prefers your geometry be set to 255/63 heads/sectors (at least as of NT4SP3). Most disks ship with 16/63 for legacy (pre-97) compatibility, and most BIOSes translate to 255/63. But many buggy or otherwise sloppy BIOSes use 240/63, or just stick with the disk default ofo 16/63. And this causes issues with NT period -- regardless of Linux being loaded (let alone another version of NT on the same system), because NT just creates its own disk label -- typically 255/63, but not always (which is part of the problem) -- _irrespective_ of what the BIOS is saying. Again, this was much more simple under DOS/Win, because it didn't even work if the BIOS and disk label didn't match. In prior Linux kernels, it always seemed to detect any issues. It would often read the geometry for the disk label and just use it, instead of what the drive reported. But 2.6 is reading the Extended Int13h, which means its bypassing the BIOS and reading right from the disk. Now understand using Extended Int13h *IS* quite proper, right down to the ATA spec itself. But if NT is dual-booted, then it's going to conflict. This is why people are getting partition tables where volumes end on odd sectors, because NT wrote out an incompatible partition table for the Extended Int13h geometry. But NT doesn't care. So what you need to do is force the geometry that NT wants when you install a 2.6 kernel distro, and make sure GRUB knows about it to for the next boot. That _should_ solve everything. Again, instead of just having NT work proper, Microsoft decided to just create the "LDM" disk label ("dynamic disk"). This was a "cop-out," compared to what the Linux kernel and GRUB teams have been able to support. But given all the various BIOS-geometry issues over the years with the legacy "DOS" disk label, I can't say I blame Microsoft for taking the "easy way out." Of course it might have been better if Microsoft would have followed an existing standard disk label, like Intel's GPT (used in Itanium). But Microsoft always likes to create its own standards, and then not tell anyone about them. But at least now that it is reverse engineered fairly well, it should stay the same for a long time. So, the sooner GRUB and Linux userspace utilities support creating/booting at least "simple" volumes on a LDM, the less geometry issues we'll have. I have to say that leaving the legacy "DOS" disk label is not exactly a "Bad Idea(TM)," even if LDM is far from perfect, it's not bad either.
OK, here are some findings I made. Despite my efforts (as noted above) to prevent the MBR from being written by a linux tool, sfdisk -V is reporting that one of my partitions doesn't start on a cylinder. So I booted the kernel, passing to it hdc=3648,255,63 and ran sfdisk -d /dev/hdc | sfdisk --no-reread -H255 /dev/hdc. Now sfdisk -V is not reporting any problems. But now PartitionMagic is complaining. So I fixed these errors, go back to linux and now sfdisk is complaining again. Anyway, I trust sfdisk this time so...bah, forget about PartitionMagic.
Steve if you still have a copy of both the working and the broken MBR could you attach both of them to this thread?
Although this is a re-iteration of what's already been said here, I'm adding it for clarity. I installed FC2 final into existing partitions; in fact into /dev/sda1 (/boot) and /dev/hda3 (root). My boot disk is /dev/hda, an IDE disk. I didn't change any partition tables, but I did get the warning about partition table conflicts. I chose the supposedly safe option to ignore this "error". After installing FC2 I couldn't boot the Win2K on /dev/hda1 although, oddly I cold boot a Win2K on /dev/hda2. After reading this lot I looked at my system and found several things, some of which enabled me to reboot. Telling the BIOS that hda is "Large" enabled me to boot (it is a fairly large disk); "LBA" has a similar effect on some systems in that it basically side-steps the CHS geometry. Changing the partition type of /dev/hda1 from b -- W95 FAT32 -- to c -- W95 FAT32 (LBA) -- helped although at one stage that merely resulted in a message about not being able to find NTLDR. Basically, changing the partition type here tells W2K to ignore the CHS partitions. Finally, I looked at the partition table. In common with the errors reported in previous comments, the number of heads had changed to 16. Unfortunately, I don't know what from ... I did the "sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda" trick only to be told that sfdisk was ignoring this since the partitions were set up for 16 heads. Someone is not telling the truth :-) I reasoned that since 255 wasn't going to be accepted, and 16 is not acceptable to W2K, perhaps 240 (16*15 = 240) would be. It was. I changed "-H255" to "-H240" and the partition table was suly re-written. I could now flip the BIOS back to "Auto" and change the partition type back to "b". The problem here is that somewhere during the FC2 installation, FC2 is playing fast and loose with the partition table. The partition table on /dev/hda (where only the grub MBR should've been written) had its number of heads changed from 240 (probably) to 16. Yes, it can be put back, but I don't believe that it should've been broken in the first place. It would seem that others have seen the number of heads changed from 255 to 16 (which makes a complete mess of the partition table). I'm staggered that this has made it all the way through to FC2 final, especially considering the discussion here and, it seems to me, the obvious commonality of the various partition tables shown here having 16 heads instead of the expected 240 or 255 on a dual-boot machine.
I've got my IBM R50 to work - I'm not exactly sure what did it, but here's the situation - Like most here, FC2 install after XP would not boot XP. I always create a 'boot' partition at the beginning of the drive (250M). On all of the failed installs, I'd re-format /dev/hda1 as EXT3 and make it /boot. This time, I didn't do that. This time I created the 250M primary partition (FAT) as usual using the XP installer. I then installed XP on a 15G logical drive (the rest of the 60G drive is extended), and create a 1.5G swap file partition. I then installed Partition Magic, and created an EXT3 and Swap partition for Fedora Core 2. I then booted FC2, and didn't let it reformat anything. I did let it install Grub. Amazingly, my XP install will now boot. So I'm not sure if it was a combination of Partition Magic and not reformatting or not using EXT3 on the initial partition that did it. FC2 still reports my physical and logical geometry with 16/63. The IBM apparently likes 240 for whatever reason.
Created attachment 100579 [details] MBR before installing FC2 This is my MBR backup before I installed FC2. I installed XP, made my NTFS partitions in XP, and used PartitionMagic to make my ext2 ones
Created attachment 100580 [details] Current MBR after installing FC2 This is my current MBR. I did restore this right after installing FC2. But sfdisk -V still gave me problems. After the tennis match between sfdisk and PartitionMagic, I decided finally to let sfdisk fix it. Ranish partition manager says I have overlapping partitions (and a couple of extended partitions too, even though I only have one)
I did an sfdisk -V today and while saying that /dev/hdc is OK, there is another message saying something about start=63 and how it supposed to be a partition number? I never got this when I made comment #75 above. Somehow, something went wrong again. And this is just through normal operation too. I didn't do any partitioning and I certainly didn't open PartitionMagic during this time.
Carter Manucy (redhat): The description you gave sounds exactly like mine, though my PartitionMagic only supports ext2 and not ext3, so I had no choice but to let DiskDruid format them to ext3. Apparently this touches the MBR too. If you run PartitionMagic, does it come up with partition errors? Also, in FC2, try running sfdisk -V to let it verify your partition table. Any unusual comments or just a pleasant "OK"?
I'm beginning to think that sfdisk is the root of the problems. On the disk whose partition table I corrected in comment #77, fdisk reports this: Disk /dev/hda: 61.4 GB, 61492838400 bytes 240 heads, 63 sectors/track, 7943 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 812 6138688+ c W95 FAT32 (LBA) /dev/hda2 813 1326 3885840 1c Hidden W95 FAT32 (LBA) /dev/hda3 1327 7943 50024520 f W95 Ext'd (LBA) /dev/hda5 1327 7943 50024488+ 7 HPFS/NTFS Note that my linux install is on another disk. fdisk -v and ParitionMagic are both in agreement that this partition table is just fine. On the other hand: # sfdisk -V /dev/hda end of partition 1 has impossible value for head: 239 (should be in 0-15) I'm willing to believe that "239" is an off-by-one error, but why does it believe that the number of heads should be in the range 0-15? Could this be the source of all the problems?
*** Bug 124350 has been marked as a duplicate of this bug. ***
John the head number 239 for end of partiton is correct assuming 240 heads. Heads are numbered from zero and upwards. Steve the two MBR copies you attached are identical. So either they are not from before and after, or the problem is somewhere else. I'm not sure exactly what the format is. But it looks like this command decodes it correctly: tail +4 <before.128|cut -c-64 |sed -e 's/../\\\\x\0/g'|while read N ; do printf "$N"; done>table One problem I notice with the decoded file is, that I cannot read it with the fdisk command because of the last two bytes being BBBB instead of 55AA. Does this BBBB mean anything to anybody? I tried changing the last two bytes, then made the file larger using dd and tried viewing it with fdisk. The output is below. The partition table looked perfectly fine. The warning is normal, any partition above 1024 cylinders cannot be represented in the CHS geometry. So the cylinder number is always 1023 in that case. (fdisk is counting cylinders from 0 in expert mode and from 1 otherwise, a bit confusing): You must set cylinders. You can do this from the extra functions menu. Warning: invalid flag 0x0000 of partition table 5 will be corrected by w(rite) Command (m for help): p Disk table: 0 MB, 0 bytes 255 heads, 63 sectors/track, 0 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System table1 * 1 382 3068383+ 7 HPFS/NTFS table2 383 3647 26226112+ f Win95 Ext'd (LBA) Partition 2 has different physical/logical endings: phys=(1023, 254, 63) logical=(3646, 254, 63) Command (m for help): x Expert command (m for help): p Disk table: 255 heads, 63 sectors, 0 cylinders Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 80 1 1 0 254 63 381 63 6136767 07 2 00 0 1 382 254 63 1023 6136830 52452225 0f Partition 2 has different physical/logical endings: phys=(1023, 254, 63) logical=(3646, 254, 63) 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00 5 00 0 0 0 0 0 0 0 0 00 Expert command (m for help):
Steve - Partition Magic is happy with the table (PM v.8.0 under Windows XP, not DOS). sfdisk -V is NOT happy, however. It's still complaining (as above comment by John Haxby) about the number of heads being an "impossible number" of 239. I'm happy to post MBR's if anyone cares to see them... or results from outputs, but I won't waste space if it's not going to help anyone!
To determine the proper geometry, load the EDD module ("modprobe edd") and look at /sys/firmware/edd/int13_dev80/legacy_{cylinders,heads,sectors}. Add 1 to the "heads" value, since these files present the raw values returned by the real-mode BIOS call, which are a little screwy. Note that the whole "heads is off by 1" problem crops up often in this context; this is why. Don't let them confuse you. This "legacy INT13" geometry is the one which the Windows boot loader wants to see in the partition table. It is usually 255 heads and 63 sectors, but not always. You can use the /proc/ide/hda/settings control file to correct the kernel's notion of the geometry before you invoke whatever partitioning tool you use. I know because I contributed the "legacy INT13" code to the EDD module specifically so I could deal with this problem. See <http://groups.google.com/groups?selm=1xXh2-850-17%40gated-at.bofh.it> and <http://groups.google.com/groups?selm=1Gjko-6Y1-5%40gated-at.bofh.it>.
John Haxby: Try passing this kernel argument when you boot up hda=7943,240,63 Then run sfdisk -V. sfdisk seems to ask the kernel for the disk geometry (which gives the 16 head version) so setting the above option will make the kernel report the 240 head version. Kasper Dupont: It is what I suspected (them being the same). Right after I installed FC2 (and hoping my MBR wasn't touched), I found it was touched so I restored my original MBR and I guess that hasn't changed since then. Also, I made my MBR backup using mbrtool rather than the dd command (I didn't have linux after XP install so I had to use the mbrtool to do my backup) so perhaps that's why it's a bit difficult to read properly. If they are truly the same (mbrtool also says they are identical), then that is strange since that means the problems that PartitionMagic are picking up has nothing to do with the MBR? I mean, I created all my linux partitions initially using PartitionMagic, then made my MBR backup (before.128). Installed FC2, restored my previous MBR, fixed with sfdisk (booted with the kernel argument hdc=C,H,S), made another MBR backup (after.128), and since before.128 and after.128 are the same, yet PartitionMagic is complaining now, then what's the deal? I'm confused.
P.S. I can do a proper (and more compatible) dump of the MBR in linux (rather than some other tool) and attach it if anyone is interested. So what command do I use to do that?
Steve: My setup was very similar to John's - my 'proper' geometry is 7752,240,63 - and I did try passing on the hda to the installer, to no avail. It didn't make any difference in the behavior of the what happened after the reboot.
Carter: Oh that doesn't sound good. I was hoping that trick would fix everything. Did you put the hda kernel argument in your grub.conf as well for subsequent reboots? Just out of interest, with that kernel argument in grub.conf, this is what sfdisk -l says: --------------- Disk /dev/hdc: 3648 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hdc1 * 0+ 381 382- 3068383+ 7 HPFS/NTFS /dev/hdc2 382 3646 3265 26226112+ f W95 Ext'd (LBA) /dev/hdc3 0 - 0 0 0 Empty /dev/hdc4 0 - 0 0 0 Empty /dev/hdc5 382+ 385 4- 32098+ 83 Linux /dev/hdc6 386+ 1277 892- 7164958+ 7 HPFS/NTFS /dev/hdc7 1278+ 2297 1020- 8193118+ b W95 FAT32 /dev/hdc8 2298+ 2807 510- 4096543+ 83 Linux /dev/hdc9 2808+ 2873 66- 530113+ 82 Linux swap /dev/hdc10 2874+ 3646 773- 6209091 83 Linux ---------------- So sfdisk does know about 255 heads instead of 16.
PS again. This is what parted now says when I print the partition table: ----------- (parted) print Disk geometry for /dev/hdc: 0.000-28615.781 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.031 2996.499 primary ntfs boot 2 2996.499 28607.937 extended lba 5 2996.530 3027.875 logical ext3 6 3027.907 10024.936 logical ntfs 7 10024.967 18026.059 logical fat32 8 18026.090 22026.621 logical ext3 9 22026.652 22544.340 logical linux-swap 10 22544.372 28607.937 logical ext3 ---------------------- And this is fdisk: ---------------------- ---Command (m for help): p Disk /dev/hdc: 30.0 GB, 30005821440 bytes 255 heads, 63 sectors/track, 3648 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdc1 * 1 382 3068383+ 7 HPFS/NTFS /dev/hdc2 383 3647 26226112+ f W95 Ext'd (LBA) /dev/hdc5 383 386 32098+ 83 Linux /dev/hdc6 387 1278 7164958+ 7 HPFS/NTFS /dev/hdc7 1279 2298 8193118+ b W95 FAT32 /dev/hdc8 2299 2808 4096543+ 83 Linux /dev/hdc9 2809 2874 530113+ 82 Linux swap /dev/hdc10 2875 3647 6209091 83 Linux ------------------ Any consistency between sfdisk, parted, and fdisk?
Steve: No, I didn't try putting it in my menu.lst in grub for subsequent boots... didn't think about that... hmmm <fiddles around> ... I'm going to reboot it now and see what happens. If anything different, I'll post the results.
Well well well... that might have made some progress. # cat /proc/ide/hda/geometry physical 16383/16/63 logical 7752/240/63 # sfdisk -V /dev/hda: OK Warning: start=63 - this looks like a partition rather than the entire disk. Using fdisk on it is probably meaningless. [Use the --force option if you really want this] # fdisk -l /dev/hda Disk /dev/hda: 56.4 GB, 56491697152 bytes 240 heads, 63 sectors/track, 7297 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 34 257008+ 6 FAT16 /dev/hda2 35 7297 54908280 f W95 Ext'd (LBA) /dev/hda5 35 237 1534648+ 7 HPFS/NTFS /dev/hda6 238 2066 13827208+ 7 HPFS/NTFS /dev/hda7 2067 4098 15361888+ 83 Linux /dev/hda8 4099 4302 1542208+ 82 Linux swap /me wonders if I can get by with reformatting again and seeing if this works w/o all the Partition Magic crap...
Carter: That looks like the same message I had when I ran sfdisk -V (last night) Warning: start=63 - this looks like a partition rather than the entire disk. Using fdisk on it is probably meaningless. [Use the --force option if you really want this] But when I run it today, it's gone!! Oh the pain.... Anyway, looks like your setup is similar to mine now. PartitionMagic is going to complain at you now :D
Hello all, Same old story as everyone else except that I'm using Windows 2000. I've tried all permutations of the sfdisk command fixes. Didn't work. I tried using the W2K repair console, executed fixmbr, no help. Fixmbr made it worse because I can't get to FC2 anymore now. There is no LBA option that I can see on CMOS. This is on a 2 year old Asus A7V333 Athlon 1800+ with up to date BIOS. Could sure use a fix on this. I got over-confident because I had no problems installing on my older machine with a different mobo but identical software. -- IV
I feel like an idiot now. I just realized what I was doing in the past to make this NOT work for me. I was FORMATTING the BOOT parition ... the one that Windows was looking for! D'oh! Every time I'd format /boot as ext3 (250M parition at the front of the disk), I'd never be able to boot Windows ... well DUH, you just killed off NTDR, MSDOS.SYS and all the other files Windows needs you idiot! Anyway. By leaving the partition FAT16, it's making both Linux and Windows happy now. Since I've alredy re-installed WinXP and FC2 both three times tonight trying various things, I'm not too inclined to test out much more, but I probably will tomorrow. Man alive, if I don't figure out hard drives and CHS, LBA, the CIA and FBI by the time I'm done here, I might as well just give up!
Carter: So your /boot (the one that also will contain the linux kernel, initrd images, grub stages, etc.) is FAT16? Sounds like a strange setup, if you ask me. :) My /boot is a different partition to the Windows c: drive
Steve the two files you atached are truly the same. "diff before.128 AFTER.128" produce not output at all. But the file contains only the MBR. That means if this is the only backup you made, it doesn't contain the logical partitions inside your extended partition. So assuming the same changes were made to all partitions on your disk, restoring the MBR only reverts the changes made to primary partitions, not the changes made to logical partitions. So I guess Partition Magic in your case must be complaining about one of the logical partitions. The command I used to take a copy of my own MBR was: head -c512 /dev/hda >filename Like the file you attached, this only contains the MBR none of the extended partition tables are backed up by this command. But if it really is all about the partitioning tool fixing the CHS fields where Windows expect incorrect values, then the MBR should be enough to verify the theory.
I have managed to install FC2 on my Gericom laptop computer and both Win XP and FC2 are working normal with no problems concerning grub boot loader. My HDD looked something like this: 1. NTFS primary partition (Win XP is installed on it) 2. extended logical NTFS partition 3. logical NTFS partition 4. logical FAT32 partition First I made backup of MBR and rest of crap that have ruined almoust all my documents two days ago. So whatever you do MAKE A BACKUP OF EVERYTHING. I have used RH9 rescue disk. dd if=/dev/hda of=mbr.save bs=512 count=1 sfdisk -d /dev/hdd > part.save fdisk -l -u > fdiskU.save Now all these files mbr.save, part.save, fdiskU.save copy somewhere safe. I have copied them to local FAT32 hard disk and on remote computer just to be safe. To restore values, copy back those files and do this: fdisk if=mbr.img of=/dev/hda sfdisk --force /dev/hdd < part.save if none of this work, you have your old partition configuration in file fdiskU.save and you can rebuild your partions. I think you have to use fixmbr from windows xp recovery console too. Then I made three partitions and formated them with Partition Magic 8.0 so then HDD looked something like this: 1. NTFS primary partition (Win XP is installed on it) 2. extended logical NTFS partition 3. logical NTFS partition 4. logical FAT32 partition 5. logical EXT2 partition (100 MB) 6. logical SWAP partition (900 MB) 7. logical EXT2 partition (5200 MB) Then I booted FC2 installation and in installation choose manul partitioning with Disk Druid (ofcourse I have ignored error message about partition alignment). I have edited partitions 5,6 i 7 only by setting mount points (/boot for 5, / for 7) and when it asked me to format it, I said no. After I continued normally with installation. After FC2 has finished installation, I was able to boot both operatins systems. But Partition Magic was throwing errors and when it asked me should it fix it I said no (don't say yes or it will mess up everything). So then I booted from RH9 installation disk and entered linux rescue mode (It will defenetly not work with FC2 rescue or installation disks). Then I entered this command (note 255 is not correct value for all computers, it represent number of heads): sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda Check with fdisk -l if number of heads had returned from 16 to correct value (255 in my case). Now I have rebooted my co
I installed FC2 on a single partitioned drive with XP on a FAT32 partition. FC has grub on its own partition. I waited about a week after installing to actually boot FC, and in the meantime used XP just fine, rebooting and all. Then last night I decided to try out the new fedora and used partition magic from windows to boot over to grub. Only after actually BOOTING with grub did windows die. So it's not the install per se that got me. I thought I was safe, so i didn't re-backup files lost a week's worth of email and work... annoying.
Before my Win2000/RH9 died after installation of FC2, it DID boot Windows 2000 successfully once. I thought I was in the clear. It was only on the SECOND boot of Windows 2000 that the problem with dual-booting occurred. -- IV
The cases of dual boot setups working for the first boot and only later stop working sounds weird. So is it booting Windows or is it firstboot running under FC2, that is responsible? If anybody are able to reproduce this it would be interesting to see a copy of the MBR at each and every step. So boot from a floppy (or a CD), and take a copy of the MBR. And do this before installing FC2 and after installing FC2. And then try Windows a few time with a backup of the MBR being taken each time, and finally take a backup of the MBR both before and after booting FC2 for the first time.
Well there is one workaround for this thing.. But it would be better getting the kernel fixed rather than this... I have a Compaq Presario with an AMD Athlon XP2400 processor and had initially come across this problem. Now the windows recovery cds they send me are too bad.. They do not even ask for howto do the partitioning.. It just creates a recovery partition and then installs Windows on a single NTFs partition leaving no space for linux.. I installed linux by doing the automatic partitioning it offered and then installed grub on the /boot(/dev/hda3 for me) partition rather than the mbr.. Then I did the following before pressing the reboot button I chroot /mnt/sysimage dd if=/dev/hda3 of=/root/grubforwin.bin bs=512 count=1 Then thankfully I had the recovery partition for me which came to my rescue.. It being a FAT32 filesystem was writable for me... So mkdir /win mount /dev/hda1 /win mv /root/grubforwin.bin /win/ Then I booted into windows and then got a command prompt Changed the permissions of the boot.ini file by using attrib -r -s -h c:\boot.ini Then edited the file using edit c:\boot.ini And added the following to the boot.ini file c:/grubforwin.bin="Linux" And changed the default=0 to default=30 Now saved the file Redid the permissions changing.. one can do it from the Explorer.. And then rebooted the system keeping fingers crossed.. Now the win boot loader showed the linux option too... So pressed linux and everything has been going good for me till now... But I would like linux community to come up with its own way of handling this problem... I did face it for the first time I installed fedora but then after reading this thought it would be better for the moment not to install grub on MBR... Yours, Surhud.
Well I forgot one thing here before editing the boot.ini I had to copy the grubforwin.bin to the C: directory which I did using copy /y /b "d:/grubforwin.bin" /y /b "c:/grubforwin.bin" /v So this seems to be a workaround which is sure to wor till this bug gets resolved.. Yours, Surhud.
This is a followup to comment #71. I have posted two articles at http://www.ces.clemson.edu/linux/. The second one is a report on on two dual boot experiments with an IBM R40, one that obeys the 1024 - /boot rule and one that does not. They both work. I did run into the situation where I could not boot Windows XP the second time. The fix was trivial but took me a while to find. Others have reported it. At the end of the install, I am used to using Partition Magic to switch the active partition from C to /boot. When I tried that, Windows XP would not boot and I got an "autochk program missing" error. What happens is that Partition Magic makes /boot active and at the same time it hides C. What I should have done was make /boot active and then unhide C. The article explains how to work around this situation.
Hi! Maybe it is not realeted with that bug but I repaired my partition table by setting LBA flag on all fat32/ntfs partitions (I used parted). I noticed that resizing extended partition with parted removes that flag from ntfs partition, so I set it on once again (it is not shown in parted). Before that Partition Magic was giving me such a complains: Warning #113: Logical starting at 83345283 overlaps enclosing extended volume. Error #114: Logical starting at 83345283 is not one head away from EPBR. or Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 120776732 1 00 9676 0 63 05 9970 0 62 155445002 4723110 Info: Partition didn't begin on head boundary. ucBeginSector expected to be 1, not 63. Warning #109: Partition ends after end of disk. ucEndCylinder (9970) must be less than 9729. Info: Partition didn't end on cylinder boundary. ucEndHead expected to be 254, not 0. Info: Partition didn't end on cylinder boundary. ucEndSector expected to be 63, not 62. Now everything works fine :-) Sorry for my English :P PS I have made that using http://systemrescuecd.org/ (kernel 2.4)
Not sure if you guys will think this at all relevant, and knowing my luck i'm probably re-posting something that has already been read somewhere, but i'm not as fully technically adept as some of the people here, and this has certainly been helpful to me. http://lwn.net/Articles/86835/ Goes some way to formalising the problem, as well as ways of avoiding the problem, or fixing should it arise. Hope this helps someone. - Stu
Yet another story. A friend of mine was able to boot WinXP again by just changing the BIOS setting from [Auto] to [LBA]. With [Auto] BIOS sees the disk as it sees it with [CHS]. The PC is AMD Athlon XP 1800+, Gigabyte MB with AMD 761 chipset and 80G Seagate Barracuda 7200.7 ST380011A disk. The only strange effect is that now WinXP sees new empty, zero sized, 'RAW' local partition (could this be the LVM PV). BIOS sees the disk this way: [Auto]/[CHS] - 38308/16/255, [LARGE] - 2553/240/255 and [LBA] - 9729/255/63. FC2 boots flawlessly with any setting. Before this BIOS was set to [Auto] and WinXP was booting, now only with [LBA].
I also experienced this problem with a Compaq 6900NX (an AMD64 machine, but I'm installing the x86 FC2). Adding 'makeactive' to the grub config line for XP solved the problem. One attribute of this machine that is different from others I have seen: the XP recovery stuff is in a proper partition, not just hiding at the end of the disk. Not sure if this difference is significant, but thought I would mention it in case it is.
I get the warning that partition table is not aligned in anaconda. Does it mean I will have this problem? Or better said, does it mean my other partitions will become unusable if I go on and install FC2? It's a P4M Vaio laptop. I don't have any choice for LBA/Auto/etc in BIOS...
Please answer the following questions if possible. I am trying to see if there is a way to prevent the problem. 1. Is the disk partition changed by grub if you select to install grub on the root partition of linux on the drive (like hda2) and NOT the MBR? My guess is that it is not. In this case you can use another boot loader like GAG or something to boot to linux and WinXp 2. If you use Partition Majic to create your Ext3 partitions before the install and do not create any partitions during the install will FC2 still change the partition table? If so, WHY would it to this???
There is no problem if you install grub on the root partition I suppose atleast it did not create any problem for me (Comment # 104 & #105).. I did have to resize the windows ntfs partition too it was done automatically by the installer though... Surhud
*** Bug 124797 has been marked as a duplicate of this bug. ***
Many thanks for the excellent advice here and on http://lwn.net/Articles/86835/ I installed FC2 on my system (Asus P4R800-VM motherboard, Win XP Home on /dev/hda1, and linux partitions on hdb). In my case anaconda changed the partition data on hdb (where /boot and the rest of linux resided), but not /hda which held my windows installation. Booting the computer was stopped with a plain "GRUB" message. I had performed a clean install from CDs and reformatted (but did not re-create) /boot and / on hdb. As I had two hard discs, and linux was to go on the second, I did not try the suggestion of telling the installer what my hard drive geometry was ("linux hda=14593,255,63"). The installation went smoothly, but on reboot I got a screen with the word "GRUB" on it only. I booted the rescue CD and looked at the partition tables with "fdisk -l /dev/hda" (and hdb). The partition table for hda was unchanged, but hdb was now shown to have 16 heads (instead of 255). I corrected this with sfdisk in the manner described in http://lwn.net/Articles/86835/ via a text file to remove the error message contained in the first few lines of the sfdisk output. # sfdisk -d /dev/hdb > MyPartitionTable.txt (this file was edited to remove the initial error messages) # cat MyPartitionTable.txt | sfdisk --no-reread -H255 /dev/hdb Both windows and fedora core 2 booted successfully then! I hope this helps the troubleshooting process. I definitely benefited from all the earlier posts. Keith
*** Bug 125252 has been marked as a duplicate of this bug. ***
Please forgive a somewhat off topic post here. But, does this bug also affect SCSI drives? I have a big (well, big for me) project coming up with both Windows and FC2 on a SCSI drive. It would be really nice to know if I need to take precautions before starting. Many thanks, --Tony aewell
Ok folks. I install stuff ALL THE TIME. This is the forst time i have ever had a linux install ruin a windows XP install. Soooo... I brought my system down to the college and we started tearing it apart. For the benefeit of all of you this is what we figured out. When Grub is installed it uses what the kernel sees for hard drive geometry, unlike LILO that just sort of points to the devices. Well... needless to say Grub is more advanced and therefore requires you to do a little extra tuning on the HARDWARE level. Note I said Hardware. The system when set to auto for the detection of hard drives uses a workaround for very large drives instead of actually reporting the geometry correctly. Setting your drives to LBA mode with the default detected values SHOULD fix any problems with Grub since linux has figured out the geometry already, it just keeps getting the bad values from the bios when it goes to load windows. I fixed it with just that change in the bios. believe it or not windows and linux BOTH actually booted faster and without a single hiccup. The interesting thing is that Grub didn;t do ANYTHING to the partition tables, it just got confused with what the BIOS was saying versus what the linux system told it should be there. Basic Fix... Use LILO in the MBR... or... enter bios and set HDD's to LBA mode instead of auto. Happy Computing.
Hi Thomas Shea, not to be nit-picky, but did you read this bug? The crux is in parted, it rewrites the partition table, not grub.. Hence your advice to use LILO instead of Grub is nonsense.. It's not the boot loader that causes this problem. However your sugestion of setting the bios to lba mode (if the bios allows it)is indeed valid See comment #27 for a good explination
*** Bug 124090 has been marked as a duplicate of this bug. ***
Should not this bug be reassigned to parted? It seems that grub has nothing to do with it. The same with the Platform, is not athlon - this happends with Intel CPUs too (i386?).
Hi folks I had the same terrible experince with fedora tests core 2 and also with mandrake 10 so the problem is with the kernel 2.6 . I fixed it by : I left one GIG of the beginning of my harddisk empty i installed XP in the first partition and fedora 2 in the second partition and it works with me fine and i installed the grub in my mbr really i do not why it works
I think it'd be better if further discussion, examples, anecdotes, horror stories, etc., be moved to the mailing lists, and this reserved for absolutely new information (and hopefully fixes).
I'd just like to add what solved my problem. Previously I had FC1 (WinXP booted then) installed. I made a new install of FC2 without altering the old FC1 partitions (just had them reformatted), this shouldn't change the partition tables. After the install, XP couldn't boot, as for many others. I followed the instructions given on http://lwn.net/Articles/86835/ but still no windows boot. Reading this thread it was clear that switching to LBA mode in the BIOS have solved some problems, but it did not cure mine. Then I switched to LARGE in the BIOS. To my surprise Windows booted after this. Hope someone else could make things work this way.
*** Bug 126270 has been marked as a duplicate of this bug. ***
I hope this provides some new information as well as old as I wonder if there is perhaps more to this than just a difference in reading disk geometry. Original state â 15Gb Maxtor 31536U2 HDD with XP installed across the entire disk ie no previous partitioning. After noting the original disk geometry settings (1868,255,63) using fdisk via SuSE Live Eval 9.0 (Knoppix 3.3 hangs on install for some reason), booted FC2 disk 1 to rescue and used parted to resize the XP partition down to end at 10000Mb, leaving start point at original value (0.031Mb). After this, XP continued to boot with no problems, despite fdisk reporting the revised geometry figures with 16 heads (BIOS set to Auto at this point)! Installed FC2 following the lwn.net guidelines (http://lwn.net/Articles/86835/), typing the original hda geometry at boot and allowing the installer to do its thing with the free space after the Windows partition. Once installed, XP then failed to boot from GRUB. Tried correcting the geometry with the sfdisk solution using SuSE Live Eval 9.0 but wouldn't work even with --force, as follows: Disk /dev/hda: 1868 cylinders, 255 heads, 63 sectors/track Old situation: Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hda1 * 0+ 1274- 1275- 10239736+ c W95 FAT32 (LBA) /dev/hda2 1275 1287 13 104422+ 83 Linux /dev/hda3 1288 1786 499 4008217+ 83 Linux /dev/hda4 1787 1867 81 650632+ f W95 Ext'd (LBA) /dev/hda5 1787+ 1867 81- 650601 82 Linux swap New situation: Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/hda1 * 63 20479535 20479473 c W95 FAT32 (LBA) /dev/hda2 20482875 20691719 208845 83 Linux /dev/hda3 20691720 28708154 8016435 83 Linux /dev/hda4 28708155 30009419 1301265 f W95 Ext'd (LBA) /dev/hda5 28708218 30009419 1301202 82 Linux swap Warning: partition 1 does not end at a cylinder boundary sfdisk: I don't like these partitions - nothing changed. (If you really want this, use the --force option.) [root@localhost chris]# sfdisk -d /dev/hda | sfdisk --no-reread --force -H255 /dev/hda Disk /dev/hda: 1868 cylinders, 255 heads, 63 sectors/track Old situation: Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hda1 * 0+ 1274- 1275- 10239736+ c W95 FAT32 (LBA) /dev/hda2 1275 1287 13 104422+ 83 Linux /dev/hda3 1288 1786 499 4008217+ 83 Linux /dev/hda4 1787 1867 81 650632+ f W95 Ext'd (LBA) /dev/hda5 1787+ 1867 81- 650601 82 Linux swap New situation: Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/hda1 * 63 20479535 20479473 c W95 FAT32 (LBA) /dev/hda2 20482875 20691719 208845 83 Linux /dev/hda3 20691720 28708154 8016435 83 Linux /dev/hda4 28708155 30009419 1301265 f W95 Ext'd (LBA) /dev/hda5 28708218 30009419 1301202 82 Linux swap Warning: partition 1 does not end at a cylinder boundary Successfully wrote the new partition table Re-reading the partition table ... BLKRRPART: Device or resource busy The command to re-read the partition table failed Reboot your system now, before using mkfs So I then changed BIOS to LBA mode, which showed me the original geometry values on screen â still didn't work. (Even tried it selecting LARGE but not happy!) Tried fixboot and then fixmbr from XP install disk â no joy with either. Re-installed FC2 as above but added hda=1868,255,63 at GRUB installer as well. No joy from XP selection in GRUB. Tried correcting the geometry again with the sfdisk solution using SuSE Live Eval 9.0 with same error message, then realised that it was telling me that the drive was ALREADY 1868,255,63! In FC2, the hardware browser also tells me the 'correct' geometry! So my first question is, if the BIOS, GRUB and the Linux kernel are all reading the drive the same way, why do I still get the following when I try to boot into XP? rootnoverify (hd0,0) chainloader +1 NTLDR is missing Press any key to restart And my second is, if Mandrake and SuSE have issued patches to correct this (I see that the NTLDR message has been mentioned in the Mandrake forum at www.linuxquestions.org), why isn't there a patch for FC2 (modified as appropriate from on of the above)?? I sincerely apologise if there is not an ounce of new info here as far as the rest of you are concernedâ my last 3 weeks of researching this problem and how to prevent it still leaves me with these unanswered questions. (Being an utter novice probably doesn't help either!)
*** Bug 118268 has been marked as a duplicate of this bug. ***
Hello there, some days ago i installed FC2 on a second partition of my harddrive and first i got the rootnoverify (hd0,0) chainloader +1 message. Tried fixmbr.... Did lowlevel format of the harddrive... Now, i have an unused partition at the beginning of my harddrive which i figured out by chance works, then i have switched to using LBA instead of Auto as mentioned by Radek Vendelberger above(in additional comment #15) and mentioned later on as well. Now everything seems to work fine. However, yesterday i installed Partition Magic 8 and it complained that CHS-values are not corresponding to LBA-values and asked if it should correct this. I am not sure but i think that i answered with yes and i had to reinstall both WindowsXPProfessional FC2 one more time. Now, Partition Magic still complains so i have uninstalled Partition Magic. (Partition Magic also would exit with an Error Message that it was unable to read the correct Drive Letters in case i do not let it correct the CHS-LBA-thing on startup). So i have finally got something that is working but i am not sure how long it is going to stay up that way as there still must be a bug. In some newsgroup-article i have read that somebody wrote a new partition-table using "the real" fdisk-programm after he had installed everything and using an -o option and this fixed things (even without the Auto-to-LBA-change). I am not aware of what is "the real" fdisk-program nor what is the -o option. Maybe someone who understands this can give further explanations here. regards :-)) Jens
*** Bug 112299 has been marked as a duplicate of this bug. ***
*** Bug 113201 has been marked as a duplicate of this bug. ***
*** Bug 122247 has been marked as a duplicate of this bug. ***
In response to Comment #128. Concerning fdisk and option o: I booted from a SuperRescue CD, 2.0.1. Ran fdisk, deleted all partitions and then created that MS-DOS partition using the forementioned o option. I also changed my Bios to LBA, not sure that was necessary. But it all started to work again after I did all this. Here you can get (buy) the latest SuperRescue disk if you don't want to make one yourself: http://www.edmunds- enterprises.com/linux/cart.php/ba/pdtl/product/191
Please help - Recovery from http://lwn.net/Articles/86835/ doesn't work! (sfdisk -d /dev/hda | sfdisk --no-reread -H255 (alt. -H240) /dev/hda (optional --force)) This is my disk, after numerous attempts of recovery from booted RHFC1 Installation CD (linux rescue) and working RHFC2 installation. Note that the disk still has got 255 heads.. isn't that supposed to be 16 by now? # sfdisk -l /dev/hda Disk /dev/hda: 19457 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hda1 0+ 1019 1020- 8193118+ 7 HPFS/NTFS /dev/hda2 1033 19456 18424 147990780 f W95 Ext'd (LBA) /dev/hda3 * 1020 1032 13 104422+ 83 Linux /dev/hda4 0 - 0 0 0 Empty /dev/hda5 1033+ 1096 64- 514048+ 82 Linux swap /dev/hda6 1097+ 2039 943- 7574616 83 Linux /dev/hda7 2040+ 14787 12748- 102398278+ 7 HPFS/NTFS /dev/hda8 14788+ 19456 4669- 37503711 7 HPFS/NTFS hda1 is my WinXP installation that doesn't boot. hda3 is my /boot with GRUB on it, no GRUB on the MBR. GRUB and RHFC2 boots just fine. From the Windows NT bootloader I'm even able to boot back to GRUB (as configured in boot.ini during previous RHFC1 installation). But, WinXP is not booting further than Windows\System32\drivers\Mup.sys when in Safe Mode. hda7 and hda8 contains work that I do not want to loose. I've tried both -H240 and -H255 but neither of them work. I've tried it with --force, in case an error message somewhere was missed or supressed. I've tried switching from AUTO to LBA and LARGE, without luck. Running a Samsung SP1614N 160 GB on a Shuttle motherboard with nForce2 chipset. No third party software has been used. No other ways attempted for recovery, apart from the sfdisk operations mentioned, so I hope everything is still intact.
I encountered a similar problem as #126 above: - hda1 is FAT32 containing Windows XP SP1 - legacy heads 255 (per EDD) - default heads 16 (as reported by 2.6 kernel) - no control of geometry in the BIOS (Acer Travelmate 800) - after Fedora 2 install, partition table used 16 heads - fixed partition table to 255 heads using sfdisk - still got "NTLDR is missing" when trying to boot Windows XP It turns out that the problem was caused by a bad heads value in the FAT32 BPB. See http://support.microsoft.com/?id=314057 http://www.win.tue.nl/~aeb/linux/lk/lk-7.html Somewhat to my surprise, I succcessfully fixed the problem simply by changing byte #26 (0-indexed) of /dev/hda1 from 16 to 255, e.g. umount /dev/hda1 dd if=/dev/hda1 of=/tmp/sect1 bs=512 count=1 edit /tmp/sect1 to change byte #26 from 16 to 255 (I used emacs) dd if=/tmp/sect1 of=/dev/hda1 bs=512 count=1 What I don't understand is how my BPB heads value got to be 16. I had been using FC2 for sometime before I tried to boot Windows (hey, I don't use Windows often). In particular, I had mounted by windows partition rw under FC2. I also remember that at one point I used parted to resize hda1, but I think that was before I installed FC2. In any case, I think there's an important point to take away from this: there's more to this problem than just the legacy BIOS geometry and the partition table. When the Windows XP partion uses FAT32, the geometry in the FAT32 BPB also needs to be in sync.
I can reproduce this bug without ever having installed any test-versions, i didn't use Partition Magic either, instead, i put a extra hard-drive in over a year ago, installed RH9 with a working dual boot grub configuration on it. 1 month ago, I installed FC2 over the root partition (reformatting the / drive ( /dev/hdb1 ) while doing this if I can remember correctly). Then I got the problem which can be fixed with: sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda my setup: Disk /dev/hda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 7296 58605088+ 7 HPFS/NTFS /dev/hda2 7297 14593 58613152+ f W95 Ext'd (LBA) /dev/hda5 7297 13414 49142803+ 7 HPFS/NTFS /dev/hda6 13415 14593 9470286 b W95 FAT32 Disk /dev/hdb: 20.4 GB, 20490559488 bytes 255 heads, 63 sectors/track, 2491 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdb1 * 1 1020 8193118+ 83 Linux /dev/hdb2 1021 1152 1060290 82 Linux swap /dev/hdb3 1153 2491 10755517+ 83 Linux [root@localhost bas]# my grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd1,0) # kernel /boot/vmlinuz-version ro root=/dev/hdb1 # initrd /boot/initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd1,0)/boot/grub/splash.xpm.gz title Fedora Core (2.6.5-1.358) root (hd1,0) kernel /boot/vmlinuz-2.6.5-1.358 ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.5-1.358.img title Other rootnoverify (hd0,0) chainloader +1
Anyone having that very annoying problem with Fedora Core 3 test 1? Hereby I mean a default installation at a system, that was affected before. As long as this bug isn't closed, I interpret, that this problem also exists for the current Fedora Core test versions...
I'd just add thatI have just had a brand-new machine without any Windows on it fail in the same way - it wouldn't even boot Linux *OR* Grub. FC2 full install produced the BIOS message about Invalid Disk - please insert a valid one and press any key. The Foxconn BIOS/motherboard obviously tries to be clever and pre-check the partition table/geometry before letting the MBR have control :-( Doing the sfdisk -H255 trick solved the problem and it booted fine.
Building parted 1.6.12 now which changes it's handling of C/H/S to fix this. If you can reliably reproduce this problem, verifying that installs after tomorrow-ish work fine would be helpful.
Jeremy, maybe a stupid question, but: Is parted 1.6.12 able to handle kernel 2.4 and 2.6 correctly or was parted 1.6.12 only modified to work fine with kernel 2.6...I can't really take that from the parted changelog, sorry.
I've been alerted to this discussion thread in a current LINUX Format article. Also, see linuxformat.co.uk. I'm having the same problem with SUSE LINUX 9.1, an install of the 2.6.5-7.75 contain in the distribution box. Windows 98 on a test system will not boot. The drive geometries are "inconsistent" according to parted. I'm using an ASUS A7N8X-E Deluxe systemboard with the IDE Primary Master/Slave set to AUTO and the Acess Mode set to AUTO. I was using Partition Commander to copy partitions to a blank drive of identical Maxtor model and from the same production lot. One drive has come up with LBA like geometry parameters the other CHS. Now I can't seem to change that with normal measures like changing the BIOS settings. I'll give the MBR edit a try and see if booting is still working after that. Since this bug crosses distributions it must be related to how the drives are partitioned. SUSE LINUX 9.1 uses parted and supplies library named /usr/lib/libparted-16.so.0.0.6, its numbering does not appear to match the version numbering I've seen for parted in this thread. It is starting to look as though parted has some problems. Is RedHat's DiskDruid making similar mistakes as parted?
According to "http://lwn.net/Articles/86835/", "Warnings pose a problem because they interfere with the use of this data as input. Output containing a warning may look like the example below:". This suggests to me that sfdisk needs to be patches so that all warnings go to stderr (not stdout), with an fflush(stdout) before the warning and fflush(stderr) after the warning so that the output looks correct when using it interactively. That way, sfdisk can easily handle its input, even with warnings. Reasonable? I think this bug (at least, not changing the CHS values of the partition) needs to be "priority high". This can cause a newly-installed system to become completely unusable, and gives a really bad first impression to new users. The risk of this will stop many from even trying the system out. Hopefully the newly-edited parted 1.6.12 fixes this. Change the priority, so that verifying this fix is a top priority.
Fedora 2 on an E-Machines 1.5 ghz P4 with 256 MB installed within an 8Gb partition. The remainder of the 40 Gb drive is two NTFS partitions which I have been locked out of for two weeks. My long term goal is to wean of Windows; short term is to get back to the data and apps for now. First, I have installed parted-1.6.12. I would like to know if a reinstall is necessary after this or if some other step is needed that I have missed? Wouldn't a reinstall return to the previous version? Sfdisk reports 16 heads, 63 sectors and 77545 cylinders. When I run the Cat for the partition table output, I get: Disk /dev/hda: 77545 cylinders, 16 heads, 63 sectors/track Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently. Old situation: Units = cylinders of 516096 bytes, blocks of 1024 bytes, counting from 0 And then: Warning: partition 1 does not end at a cylinder boundary sfdisk: I don't like these partitions - nothing changed. (If you really want this, use the --force option.) So I run Force and the ouput is: Warning: partition 1 does not end at a cylinder boundary Successfully wrote the new partition table Re-reading the partition table ... BLKRRPART: Device or resource busy The command to re-read the partition table failed Reboot your system now, before using mkfs If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).) I have the entire output in bloody details if needed. I hope someone can analyze this and get me the steps to get the old DOS boot back that Grub gave me with Fedora 1. I'll add my vote to those that say this should be an out-front show stopper bug. Even though there is no apparent data loss, getting into a no-boot situation is perceived as on by lots of users.
Created attachment 103017 [details] Patch to sfdisk so all warnings go to stderr FYI, I've submitted to Andries Brouwer (maintainer of util-linux) and Jeremy Katz a small patch to sfdisk in util-linux. This patch does NOT solve the serious underlying problem, but it DOES make it easier to apply the fix that appears to work for many people. The patch makes all warning messages go to stderr, instead of stdout. This way, the output of sfdisk can be fed back into sfdisk with more reliable results. The patch is against sfdisk version 3.07, dated 19990908, which is part of util-linux-2.12a, downloaded August 24, 2004 from ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/util-linux-2.12a.tar.gz The article at http://lwn.net/Articles/86835/ notes that many can solve the problem by running: sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda But that sometimes fails. The problem is that if there are warnings in the sfdisk output, the warnings get interspersed with the output and cause sfdisk to be unable to read back its own output. Which is unnecessary; stderr was created for just that reason, and the tool does use stderr - just not consistently. Here's what the LWN article says about this problem: "You will want to check to check for warnings in the output. Warnings pose a problem because they interfere with the use of this data as input. Output containing a warning may look like the example below:... For reasons unknown, using the option -- quiet does not suppress all warnings so it becomes the task of the user to discover a way to still use the output as input. The simplest way is to write the output to a plain text file, editing out the warning in that text file, and using the edited text file as the input..." I don't have a scratch disk to easily test out the horrific things that trigger these warning messages. However, this patch is quite conservative in what it changes. Basically, all printf'ed warning messages have been replaced to a call to a new always_warn() function, and stderr is flushed after each output. Please review, but I think you'll find it easy to believe. It works for me...! This patch does NOT solve the serious problem of "installing Linux 2.6 on dual-boot Windows causes Windows to stop working". That's still a critical bug, and still needs fixing elsewhere. However, this patch DOES mean that, if you get stuck in that (or siimilar) situation, this patched sfdisk is MUCH more likely to be able to fix it without manual intervention. This is because solutions where sfdisk reads its own output will be more reliable, e.g., in commands like: sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda Hopefully, the dual-boot bug will be squashed, but in case something like it resurfaces, it'd be good if tools like sfdisk were able to easily and automatically apply a fix.
[ Feel free to remove this post from Bugzilla, but I feel I have to write this. ] I'm sorry, and this may seem elitist, but I think until people stop pointing the finger at Linux (as well as Red Hat), this WHOLE Bugzilla track is turning into a waste. As someone who has tracked partitioning issues with NT and DOS kernels, this is *MINOR* to what can go on, and would go on if you tried to dual-boot DOS and NT on the same system with a buggy Extended Int13h BIOS. Here's the deal ... it requires ... 1) Buggy Extended Int13 BIOS, things select OEMs *COUGH*IBM*COUGH* shouldn't be shipping anymore. It is because BIOSes like these are so old/legacy that ATA disks sold today still come pre-set to 16 heads (instead of 255)! Why oh why? 2) It requires another OS on the disk, namely NT 5.x (or even NT 4.0 SP4 or later), to write out an *CONFLICTING* partition table, totally *IGNORING* the buggy BIOS and *ASS-U-ME* 255 heads aka "LBA." This would also cause a dual-boot issue with DOS-based Windows (95, 98, Me) as well -- or worse, DOS-based fdisk would "blow the partition table away" without a prompt. 3) A 100% Extended Int13h Services standards-compliant Linux kernel and GRUB, which re-write the partition table "proper." The workaround is for the Linux kernel to completely ignore the BIOS, read from the raw partition, which may or may cause boot-time issues. In other words, Linux has to "guess" what the partition table geometry is and hope it works (sometimes, it doesn't and causes errors!). I've seen this year in and year out (going back 7+ years), so I'm sure the 2.6 kernel shipped with full Extended Int13h Service complaince by default because any BIOS in the last 5-7 years should *NOT* be buggy. Why? Because dual-booting just causes problem after problem after problem. Ultimately, the "final workaround" from the Linux standpoint is to get away from the legacy PC BIOS / DOS "disk label" (partition table) with primary/extended and built support for the "LDM disk label" (aka Dynamic Disks). The support for the LDM disk label is already in the Linux kernel, we just need GRUB support and user-space tools. Why is this a good idea? Because we can read the *ASS-U-ME* geometry from the LDM disk label. Not perfect, but far better than and more well defined than with the legacy PC BIOS / DOS disk label. Linux didn't create the issues, it's just trying to survive in them. I tire of seeing people demonize Linux 2.6 (and Red Hat) in a PC BIOS / NT 5.x world of non-compliance, broken implementations and Microsoft OS "we assume this so this is the standard, even if we break our own, previous implementation." I mean, if you dual-boot multiple Linux versions even on one of these systems, you have *0* issues. The problem isn't Linux.
The problem is Linux's because Linux is not the dominant OS, and until it is, it has to play by everybody else's rules, no matter how stupid and broken it is. My first thought about this was "Well, yet another example of the stupid kludgery surrounding PCs.". But, that still doesn't change my opinion that this is a killer problem for people who just want to get Linux running on their systems at home alongside Windows, and don't want to know about disk geometries, partitions tables and the like.
Does this bug also exist in FC3, Test 1? I have an analouge problem there, in any case. See bug 131911...
Unfortunately Eric, NT has a problem with itself. Dual-booting different versions of DOS and/or NT based Windows with itself are problematic as well! I.e., Linux is not even required. Linux cannot solve issues with NT, even if it accommodates them better than NT itself can. That was my point. But to be more constructive, I will again re-iterate that: A) Microsoft's LDM disk label solves the PC/BIOS geometry issue B) The Linux kernel supports reading LDM disk labels As such, the community first needs to do the following: 1) Create the user-space tools to support creating Linux filesystems in LDM disk labels 2) Modify GRUB so it can boot a filesystem in the LDM disk label Once that occurs, then distributions like Fedora Core can: 3) Modify the installer (Anaconda) to create filesytems in LDM disk labels Thus far, when I bring up the idea of supporting LDM disk labels (i.e., "dynamic disks"), I am met with a rash that "LDM is MS proprietary and designed to kill Linux" from many. A few others can't seem to separate the fact that the LDM disk label is not NTFS filesystem (even if they are governed under the same project). The LDM disk label solves a lot of issues with NT itself. As such, supporting LDM disk labels as the "default" disk label for dual-NT (Windows) and Linux installations should be the ultimate goal. It removes the entire issue of PC/BIOS geometry. I've posted enough on this matter. I've not only fully explained the problem (buggy BIOSes), but I've offered the most constructive suggestion and future solution I can. Until the user-space utilities are there, which should be the #1 goal of the community (to develop this support), distros will NEVER guarantee compatibility with buggy BIOSes, a stubborn NT kernel and the fact that you couldn't even dual-boot DOS/Windows or some versions of NT/Windows on the same setup.
The last set of comments notwithstanding, I've installed every version of Red Hat Linux from 5.0 onwards on a dual-boot machine (Win98, NT4, Win2k and WinXP being the other OS) and only the FC2 installation trashed the partition table so as to make the other OS unbootable. In my case it was a simple matter of changing the number of heads back to 255 (I think) instead of 16. It's no good saying that the existing scheme is irretrievably broken when it's worked fine for countless users for quite a few years: I think I saw a message to the effect that it's parted that's broken and it should be being fixed. If that's the case, then this bug needs closing. After 148 comments it needs closing.
I have about 15 dual boot machines at work with Fedora Core 2 i386 release and Windows XP Pro (32 bit) installed. They all work flawlessly (well, as far as booting is concerned). However, I have recently built a new system (at home) with AMD64 3500, MSI Neo2 Platinum 939 pin, and 4 SATA drives (0 PATA drives). I installed Windows XP Pro SP1 (32 bit) no problem. I installed Fedora Core 2 amd64 version and ran into the issue with grub not booting windows. After fixing all of the problems FIXMBR caused (Windows tools leave much to be desired) using the drive manufacturers utilities, I wiped all drives and reinstalled Windows and then installed Fedora Core 2 i386 (thinking it could be the 64 bit version which had an issue) resulting in the same problem. The problem is likely that grub being installed in MBR of master boot record is only a symptom of the true problem - faulty SATA drivers (though I did see only a few mentions of SATA above). However, five (5) of the dual boot machines at work are Athlon XPs and the others are Xeons and P4s all using PATA IDE hard drives and none had install or boot problems. As a test, I will add a PATA drive as my primary boot drive, reinstall Windows XP on that drive and FC2 on SATA and see if it corrects the problem. I will post here again and give the results if anyone is interested. It would be nice if this can be fixed for FC3 and if similar information were provided above I do apologize as I got tired of reading half way through as it didn't appear the problem has been resolved. Hopefully my little test will prove useful. Thanks
I also had to cope with this kind of problem. First, my configuration is as follows : - CPU : Athlon XP 2500+ - Motherboard : KG7 (bios award) - HDD : Maxtor DiamondMax9 120 Go (Bus : IDE), Primary slave Partitionning : hdb1 1 203172 NTFS (WinXP) hdb2 203173 238216 ext3 (FC2) I've solved this boot issue in a quite simple way. (at least now i can access my data and use Windows) So I only need to change one parameter in BIOS : Standard CMOS features > IDE Primary Master/Slave > Access Mode The default setting is : 'Auto', and I've noticed that the number of heads is 16, instead of 255. So I've changed this setting to 'LBA', in order to display the corect number of heads. Then I save changes and reboot. At grub menu, i can now boot WinXP and FC2 as well. The main point is that your data are only inaccessible, and in no way destroyed ;) PS : At one point I used the 'fixboot' tool on Windows recovery CD, but I ignore if it had any influence on the process. PS2 : As my PC runs with an Athlon XP, I don't think this problem is specific to the HyperThreading technology.
*** Bug 123937 has been marked as a duplicate of this bug. ***
Hi, I just solved this some other after effects of this problem using Partition Magic PTedit. Since I've solved it, I can no longer reproduce the errors, so the error texts are *aproximate*. I'd been having intermittent partitoning-related problems after installing Fedora Core 2, made worse by a hard disk controller which doesn't work properly in summer. :-( I needed to re-partition for a clean install of Fedora Core 3 (or maybe test3 if I get impatient), but Partition Magic was unhappy ... Leaving a problem like this alone is *asking* for trouble when you can least afford it, but re-installing all those systems ... It finally nerved me enough to *really* investigate. What I found was that there were were duplicate EPBR (Extended Partition Boot Records) chains for the logical partitions above 8G - Cylinder 1023, head 255, Sector 63, or maximum CHS. I've been partitioning with Partition Magic *only* for ages, after proving that no two partitioning programs are *really* compatible if you make changes with both. It's convenient if you often re-partititon, which I do since I've mostly done clean installs in parallel instead of updates. It refused to display the disk, even after allowing it to "repair" the errors it saw. I googled a bit, and came up with the following on: http://www.cgsecurity.org/testdisk_doc/TechnicalNotes.html Partition Magic uses the DOS/W32 Method for CHS entries in the EPBRs above 8G: - Cylinder 1023, Head (unchanged), Sector (unchanged) Linux uses this method: - Cylinder 1023, Head (max head), Sector (max sector) To complicate matters, sfdisk warns that Bios reports the disk as: - Cylinders (x) Heads 16, Sectors 63 but it that is was partitioned with: - Cylinders (y) Heads 255, Sectors 63, Since Linux for all practical purposes uses LBA over CHS, I wasn't worried about warnings from sfdisk: "start CHS = 1023/1/1, expected = 1023/255/63" What this all means is that DOS / Partition Magic expect an EPBR above 8G to look like this (ntfs partition): ****start***** ******End***** Type Cyl Head Sect Cyl Head Sect 07 1023 1 1 1023 254 63 05 1023 0 1 1023 254 63 Linux expects the same EPBR to look like this: ****start***** ******End***** Type Cyl Head Sect Cyl Head Sect 07 1023 254 63 1023 254 63 05 1023 254 63 1023 254 63 Partition Magic was complaining: "Partition table error #114" PartInfo.exe was reporting, for each partition above 8G: "Partition table error #114: EPBR ist not one head away from start of logical partition" Partition Magic was expection the EPBR to be at sector 1, 62 sectors below where it was. I thought - what if I create an EPBR at sector 1, and point to it in the EPBR above it in the chain? I backed up everything ... ;-) ... and started with the last EPBR in the chain. This is how it looked in PTedit: ****start***** ******End***** Sectors Type Cyl Head Sect Cyl Head Sect Before Sectors 07 1023 254 63 1023 254 63 1 len(n) The one above it looked like this: ****start***** ******End***** Sectors Type Cyl Head Sect Cyl Head Sect Before Sectors 07 1023 254 63 1023 254 63 1 len(n-1) 05 1023 254 63 1023 254 63 Offset(m) len(m) DOS / Partition Magic are expecting these: ****start***** ******End***** Sectors Type Cyl Head Sect Cyl Head Sect Before Sectors 07 1023 1 1 1023 254 63 1 + 62 = 63 len(n) ****start***** ******End***** Sectors Type Cyl Head Sect Cyl Head Sect Before Sectors 07 1023 1 1 1023 254 63 1 + 62 = 63 len(n-1) 05 1023 0 1 1023 254 63 (Offset(m)) - 62 len(m) + 62 I started by writing down the values for the last EPBR, and editing only the values for the extended partition in the one above it: ****start***** ******End***** Sectors Type Cyl Head Sect Cyl Head Sect Before Sectors 07 1023 254 63 1023 254 63 1 len(n-1) 05 1023 0 1 1023 254 63 (Offset(m)) - 62 len(m) + 62 I saved the changes and navigated to where I expected to have to create the new last EBPR from scratch - It was there already, and looked the way Partiton Magic expected it to: !!! ****start***** ******End***** Sectors Type Cyl Head Sect Cyl Head Sect Before Sectors 07 1023 1 1 1023 254 63 63 len(n) I exited PTedit, and re-ran PartInfo - the last of the errors was gone. I repeated the process for all of the partitions (starting?) above 8G, with the same result: - there was already a "DOS-correct" EPBR in "sector 1", or 62 sectors below the "Linux-correct" one. PartInfo reports no errors, and Partition Magic shows the partitions again, I assume it can resize, move and copy them as usual. There is still a problem with the Fedora Core 2 partiton: - Partition Magic under DOS doesn't see it's ext2 label, all others are shown - Partition Magic under XP, shows all ext2 labels - e2label sees all ext2 labels (I have a script using sfdisk etc.) I think the filesystem was created according to the "Linux-correct" EPBR, and that all others were created according to their "DOS-correct" EPBRs. At this point I'm just going make sure this curious effect is gone: - reformat the Fedora Core 2 partiton with the EPBR in it's "DOS-correct" state, and restore from backup. I'm over the moon about not having to: 1. delete all partitions 2. re-partition from scratch 3. restore all the Linux partitions 4. reinstall grub in each Linux root partition except the emergency Boot-Linux, which controls grub in the MBR 5. reinstall XP and XP-Home - WPA sucks, XP too - *no* thanks to CANON for keeping the protocol for my USB-Scanner secret - *@&$!!! 6. reinstall grub in the MBR Fred.
Created attachment 104985 [details] (OpenOffice.org Calc) table to calculate partition table entries you may find this useful to see how things *ought* to be
Sorry for the extra post - I forgot to CC myself, and to explain the "table to calculate partition table entries" attachment - just enter: - disk geometry (cells C2-E2) - partition sizes (D7-D10, D12, D15, D18, ...) - it doesn't do the adding / subtracting of 62 sectors
*** Bug 136974 has been marked as a duplicate of this bug. ***
After Installation of Fedora the WinXP entry in GRUB isn´t working. GRUB still crashes the Partitions. This Problem is known by Fedora till last Year. Some other Distributors (MDK, SUSE) had the same Problem. They fixed it one Year ago. Every Distribution with Anaconda & GRUB still has the Error that seems to be a "Blocker" for me. Why isn´t Fedora switching to LILO and everything will be ok ? The Problem still exists on Fedora TEST 3 - can someone change this please ?
Regarding comment 157: Can you explain better what is happening? Try adding some usefull info (specially about disk geometry). My machine was one of the machines where the dual boot problem happened always (since FC2T2)... And I installed FC3T3 and FC3T1 with no aditional parameters (except for the one necessary to use JFS or XFS) and my windows still works the way it should...
Hi, sorry i don´t want to and i cant test it until it is officially fixed ! I need my Client and can´t get more Experiments on my Windows Installation.
Is this still a problem in FC3?
Yes, still exists in FC3. My installation of FC3 booted perfectly, but rendered XP un-bootable, even XP recovery disk hung! See FC3 bug 138866.
Anybody working on it ?
I wanted FC2 (Tettnang) as dualboot with existing WinXP. Using 120GB Seagate disk. I had 10gb primary ntfs partition for XP and 90gb logical fat32 for data. about 10gb in the end I reserved for linux. Installation of FC2 was fine but then after reboot I didnt see grub but "Operating system not found" I went to Fedora thru bootdiskette and there I see all my partitions, looking uncorrupted. !!BUT CHS has changed, from 240h to 16! Repair console in XP - fixboot and fixmbr doest't work (writes "structure is strange or invalid..." even after "Fixing")
How to fix it easily- REALLY- Just change in BIOS and problem is over: First, BIOS reported 16heads when set to Auto. Windows XP reported the Large 240heads and formatted the drive with these values. Installer of Fedora Core used the BIOS settings and changed number of heads in MBR to 16. Windows XP didn't booted then because of the mismatch BIOS/FATs The only thing I made was that I set sector adressing mode in BIOS to Large (so BIOS immediately reported 240heads) and then Windows booted without any problems. Partition magic just fixed the rest of problems and everything is fine now. THUS: Before installing FC2, set in BIOS the sector adressing as you really have in Windows. For me, it was Large.
I just upgraded from fc1 to fc3, accepted the defaults (with the grub setup settings, I choose the best option) and suddenly I got SMART errors. I started to investigate and trying to repair the errors, I found out that I have 2 new partitions : /dev/hda1 W95 Fat16 (LBA) eand /dev/hda4 W95 Ext'd (LBA), which are both not mountable from fc3. I have never had a windows install on this machine, it was fc1 from the start, so this problem has NOTHING to do with windows. Just saw some comments that this must be a windows a problem. Btw my system works fine, but just in case I started to make an extra full backup so I can reinstall fc3 in case I need it.
Hmm probably deliberately created those partitions and forgot about them (10 gig of discspace reallocated seems a bit to weird to me). The weird part is that some SMART errors turned up after the installation of fc3 and those errors are exactly located on the w95 partitions. Dos partitions were created from druid afaik when installing fc1 when I got my portable (which was uninstalled). Good thing about it all : My hd is 10 Gigs bigger than anticipated and I have a full backup.
I have tried all the fixes that I could find for this problem and non of them worked. Did nothing to help. Didn't even affect my system. But now I think I've found a small little fix for this issue... Atleast I think. I haven't tried this out yet but I'm just thinking. Try following the instructions over at: http://www.geocities.com/epark/linux/grub-w2k-HOWTO.html Which should let you use the Windows Boot Loader instead (but choosing Linux boots with GRUB). When you hit the part where you need to boot into Windows, try using the Windows Recovery Console which comes with Windows 2000/XP (Not too sure about NT though...), to rebuild the MBR to boot into Windows. From there follow the website to change the Windows Boot Loader to also start GRUB.
I'm seeing the exact type of error and I'm not even loading windows on the system. I went through a clean install with Fedora C3 and everything appeared to work ok, but after the system booted I just got a black screen with a flashing cursor in the upper left corner after POST. I've tried various suggestions with no luck as of yet. This is a brand new system that I just built: 2.8 Celeron MSI 865 platinum 2 x 200mb Maxtor drives 1 gig ram I originally thought it was the way I partitioned the drives so I made the / partition 20 mb and a /data partition with the remaining space (not including the swap). This configuration is RAID1. My bios says the drives are in LBA mode already. I'm not using SATA either. I'm going on my 4th install. I'll continue to hack it out on my side.
What's the status of this for FC3 and later? Are the workarounds still required or should work out of the box? I've installed FC3 on a fresh system, leaving 1 partition vfat for windows. I booted install with CHS workaround. Then I installed Win XP, then booted to FC3 and ran grub-install. Win XP won't boot after that (tried several variations, including running sfdisk again) Thanks
I can not boot to windows after installing FC3 on my new DELL Precision M70 laptop. I believe it is the same problem as reported in Bugzilla Bug 115980, that I came across while searching redhat.com. Has this been fixed? How do I fix this problem so I can dual boot into windows? Best regards, Robert McCullough
I think there may be a couple of issues here. Furthermore, I believe the dual-boot aspect may be a bit of a red herring, as I have ended up with a non-booting FC3-only system after a series of upgrades (RH9, FC1, FC2, FC3) using yum on a machine that was never set up for dual-boot. In my case, the symtpom was after updating to FC3/2.6.11 (without stopping to use any of the intermediate FC1 or FC2 versions - I only did that because a direct upgrade path proved difficult due to python/yum and other dependency issues), rebooting hung with the text "GRUB Loading stage2". Now, I can boot from a rescue floppy (http://www.ibiblio.org/pub/Linux/system/recovery/ramf-120.img.bin) that has the command-line grub on it: root (hd0,0) configfile /grub/grub.conf Which boots my machine as usual. This isn't exactly how I want to boot the machine, so I tried a number of things to fix it. One thing I tried, which sent me a step backwards, was to run grub after doing this floppy->hd boot, and then: setup (hd0) After rebooting, the machine no longer even printed out "Grub Loading Stage2". Fortunately, the floppy approach still worked, so I checked the drive geometry, and the number of heads had been changed to 16 from 255. Notice again that there is no Windows XP/2000/NT/3.1 involved here. Aftre this, I tried the sfdisk hack to set the drive back to 255 heads. I'll have to experiment with it some more, because it still hasn't taken. Probably because I was doing it on a mounted partition or some such. I created another floppy with my existing grub, ("cat stage1 stage2 > /dev/fd0" I think) and that now prints something about Grub loading and then BadGeom. Now what might be interesting about my setup is that my hd0 is /dev/hde. (It's a Soyo 6BA+IV from the era when mobo chipsets didn't support UDMA66, so they strapped on an hpt366 UDMA controller which does.) I checked grub/device.map to make sure hd0 is mapped to /dev/hde, and it is. My cdrom drive is /dev/hda because it is the primary on the first controller. I'm sure I'll figure out a way to get the MBR and such fixed. Just thought this might prove to be useful for other people trying to fix their own prooblems.
the error as far as I can tell is caused by the detection of the partition geometry. Burn the fedora rescue ISO to disk, and boot from it. Get the CHS values from fdisk. Then, when you come to install fedora, add the argument chs=x,y,z to the boot line. This will give anaconda the correct values, and will make windows and fedora boot happily. For those that have already fallen foul of this bug, get a windows 9X bootdisk, and use the command fdisk /mbr to make windows bootable, then reinstall fedora. Corrupted files are caused by the incorrect values making diskdruid create overlapping partitions. very little can be done about that, once it's happened, except fdisking and starting again. Hope this helps a little.
The same error here Fedora Core 4 test 3 and i can't solve it. When i reboot i see : "GRUB GRUB" , but neither of my OS (WinXP and Fedora) run.
can someone please explain why this bug (with severity high) doesnt get solved. it's well over a year now. is it not important or something? i had a lot of trouble with this bug and apparently a lot of other people as well judging from the enormous amounts of replies to this entry. lots of work arounds get mentioned here but the ones i tried didnt solve anything. fc4 is on the brink of being released and it seems this still isn't solved. or is it? could anyone of the developers please comment on this?
My understanding is that the basic problem *has* been solved by updating to a newer version of GNU parted. However, I'm unclear on exactly what version the problem is fixed in -- it may be something later than FC3's 1.6.15. (Comment #161 indicates that the problem is still there in FC3, so I assume it's something later.) However, it *should* be fixed in FC4, which is up to 1.6.22 or so. I think many problems here are different and unrelated, like comment #168 or comment #174. Those should be filed as different bugs in the cases where repeatable, deterministic behavior can be found.
And in fact, with 176 comments on the bug, it's impossible to separate one issue from any other. So I'm going to close this, and if people continue to see problems, they can each open a new bug regarding their individual problems.