Bug 115980 - will not boot to windows partition using grub menu
Summary: will not boot to windows partition using grub menu
Alias: None
Product: Fedora
Classification: Fedora
Component: grub
Version: rawhide
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact:
: 112299 113201 118268 120128 122247 123658 123720 123832 123937 124090 124350 124797 125252 126270 136974 (view as bug list)
Depends On:
Blocks: FC2Target FC3Target FC3BugWeekQA
TreeView+ depends on / blocked
Reported: 2004-02-17 13:41 UTC by Mike Lurk
Modified: 2007-11-30 22:10 UTC (History)
56 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-18 18:57:00 UTC
Type: ---

Attachments (Terms of Use)
Errors produced by Partition Magic (11.29 KB, image/png)
2004-03-31 11:28 UTC, Vardyr
no flags Details
MBR before installing FC2 (1.12 KB, application/octet-stream)
2004-05-26 12:07 UTC, Stephen So
no flags Details
Current MBR after installing FC2 (1.12 KB, application/octet-stream)
2004-05-26 12:11 UTC, Stephen So
no flags Details
Patch to sfdisk so all warnings go to stderr (9.97 KB, patch)
2004-08-24 06:18 UTC, David A. Wheeler
no flags Details | Diff
(OpenOffice.org Calc) table to calculate partition table entries (12.55 KB, text/plain)
2004-10-10 15:27 UTC, Fred
no flags Details

Description Mike Lurk 2004-02-17 13:41:21 UTC
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

Comment 1 Jeremy Katz 2004-02-17 17:13:29 UTC
Can you attach your grub.conf and the output of fdisk -l in linux?

Comment 2 Mike Lurk 2004-02-17 21:21:50 UTC
[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
# 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
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.

Comment 3 Mike Lurk 2004-02-17 21:34:53 UTC
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.

Comment 4 Mike Lurk 2004-02-17 21:42:56 UTC
I am leaving everything to defaults. if you need more info let
me know

Comment 5 Jeremy Stanley 2004-02-21 03:27:58 UTC
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
# 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
title Fedora Core (2.4.22-1.2115.nptlsmp)
        root (hd0,6)
        kernel /boot/vmlinuz-2.4.22-1.2115.nptlsmp ro root=LABEL=/
        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=/
        initrd /boot/initrd-2.4.22-1.2115.nptl.img
title DOS
        rootnoverify (hd0,0)
        chainloader +1

Comment 6 Jeremy Stanley 2004-02-21 03:28:50 UTC
FWIW, my system is a 3GHz P4 HT using the SMP kernel.

Comment 7 Tobias Ringstrom 2004-02-22 22:40:05 UTC
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?

Comment 8 Martyn Russell 2004-02-23 21:40:50 UTC

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.

Comment 9 Jeremy Stanley 2004-02-23 22:35:02 UTC
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...

Comment 10 orion 2004-02-28 09:08:45 UTC
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  
#          initrd /initrd-version.img  
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]#  

Comment 11 Jeremy Stanley 2004-03-10 16:21:43 UTC
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.

Comment 12 Vardyr 2004-03-31 11:28:10 UTC
Created attachment 98992 [details]
Errors produced by Partition Magic

Comment 13 Vardyr 2004-03-31 11:29:04 UTC
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.

Comment 14 Geir-Tore Lindsve 2004-04-06 17:29:50 UTC
Just for the record; this bug is still present in Fedora Core 2 test 2

Comment 15 Radek Vendelberger 2004-04-27 15:59:30 UTC
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.

Comment 16 Need Real Name 2004-04-29 23:01:04 UTC
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.... 

Comment 17 Aleks Gorelov 2004-05-07 19:07:09 UTC
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.

Comment 18 Confushion 2004-05-10 02:01:54 UTC
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.)  


Comment 19 laurent dene 2004-05-10 15:23:55 UTC
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
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)

Comment 20 Chan Min Wai 2004-05-17 08:43:39 UTC
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

Comment 21 Jim 2004-05-17 16:33:18 UTC
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?

Comment 22 GeoffLeach 2004-05-17 20:14:23 UTC
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.

Comment 23 Nils Philippsen 2004-05-17 20:42:40 UTC
*** Bug 120128 has been marked as a duplicate of this bug. ***

Comment 24 Jim 2004-05-17 20:57:40 UTC
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 ?

Comment 25 Need Real Name 2004-05-17 21:44:26 UTC
I think 113201 is this problem too.  Off Topic: I'm actually floored 
the release is happening with this bug still around...

Comment 26 Jim 2004-05-18 00:43:21 UTC
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" 

Comment 27 Need Real Name 2004-05-18 00:50:24 UTC
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:

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:
and here:

I'm not sure if parted has been fixed yet, but this patch appears to
try to address this issue:

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

Comment 28 Jim 2004-05-18 00:54:29 UTC
yes in dede

Comment 29 Chris Chabot 2004-05-18 17:42:36 UTC
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

Comment 30 Chris Chabot 2004-05-18 17:45:02 UTC
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.

Comment 31 Jeremy Katz 2004-05-18 23:11:28 UTC
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

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.

Comment 32 xbytor 2004-05-19 01:35:24 UTC
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.

Comment 33 Radu Cornea 2004-05-19 05:53:05 UTC
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


Comment 34 David Jansen 2004-05-19 07:11:40 UTC
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...

Comment 35 Juha Sahakangas 2004-05-19 13:06:01 UTC
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).

Comment 36 Tobias Ringstrom 2004-05-19 13:19:30 UTC
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.

Comment 37 Radu Cornea 2004-05-19 15:40:22 UTC
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.

Comment 38 Jim 2004-05-19 16:18:34 UTC
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

Comment 39 Radu Cornea 2004-05-19 16:35:48 UTC
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.

Comment 40 Jim 2004-05-19 16:52:36 UTC
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

Comment 41 Jeremy Katz 2004-05-20 02:41:11 UTC
*** Bug 123658 has been marked as a duplicate of this bug. ***

Comment 42 Miloslav Trmac 2004-05-20 12:02:30 UTC
*** Bug 123720 has been marked as a duplicate of this bug. ***

Comment 43 tomfin 2004-05-20 18:34:38 UTC
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 

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,


Comment 44 Steve Allen 2004-05-20 20:25:30 UTC
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

Comment 45 Didier 2004-05-20 20:42:04 UTC
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 ... ?

Comment 46 Jeremy Katz 2004-05-20 22:37:41 UTC
*** Bug 123832 has been marked as a duplicate of this bug. ***

Comment 47 Carlos Hernandez 2004-05-20 22:39:37 UTC
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.

Comment 48 Greg Bailey 2004-05-21 02:01:32 UTC
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.

Comment 49 Bill Moss 2004-05-21 02:18:21 UTC
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.

Comment 50 Fiid Williams 2004-05-21 07:13:40 UTC
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

(fiid at fiid dot net)

Comment 51 Fiid Williams 2004-05-21 07:36:31 UTC
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

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

Comment 52 des johnston 2004-05-21 11:09:23 UTC
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

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?

Comment 53 Zhelyazko Chobantonov 2004-05-21 13:54:36 UTC
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 :

# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this
# 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
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
        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


[boot loader]
[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 ?

Comment 54 Zhelyazko Chobantonov 2004-05-21 14:07:07 UTC
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

Comment 55 Chris Chabot 2004-05-21 14:14:36 UTC
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 

Comment 56 mitch 2004-05-21 15:23:22 UTC
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 
               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 

Comment 57 des johnston 2004-05-21 15:28:29 UTC
>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

Comment 58 mitch 2004-05-21 15:31:09 UTC
Thx but can i fix the disk in windows ? because i haven't a Fedora 
core 1 cd :( 

Comment 59 Zhelyazko Chobantonov 2004-05-21 15:39:28 UTC
i found solution try this:
sfdisk -d /dev/hda > temp.txt
vi temp.txt and remove line up to comment line (Exeption explanation 
cat temp.txt | sfdisk --no-reread -H255 /dev/hda

Comment 60 Jolyon Forsyth 2004-05-22 07:03:02 UTC
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)

Comment 61 Stephen So 2004-05-23 02:41:11 UTC
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. :(

Comment 62 Bryan J. Smith 2004-05-23 05:09:20 UTC
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?).


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.

Comment 63 Bryan J. Smith 2004-05-23 05:37:41 UTC
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: 

"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 ...

 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 

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: 

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!

Comment 64 Stephen So 2004-05-23 10:54:43 UTC
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?

Comment 65 Kasper Dupont 2004-05-23 12:45:21 UTC
Steve (s.so@griffith.edu.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.

Comment 66 Bennett Feitell 2004-05-23 17:17:41 UTC
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.

Comment 67 daniel mann 2004-05-23 17:32:13 UTC
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

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.

Comment 68 Kurt Kaiser 2004-05-23 19:14:58 UTC
Some information on the 2.6 kernel changes:


Comment 69 Stephen So 2004-05-23 23:57:18 UTC
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.

Comment 70 Stephen So 2004-05-24 00:02:12 UTC
Responding to Kasper Dupont
(tmzufqummuxdmcwtxkuijvystqlef@skrammel.yaboo.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. :)

Comment 71 Bill Moss 2004-05-24 02:33:56 UTC
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.

Comment 72 Stephen So 2004-05-24 03:03:01 UTC
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. :)

Comment 73 Greg Trounson 2004-05-24 03:19:20 UTC
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 

Comment 74 Bryan J. Smith 2004-05-24 05:03:55 UTC
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

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.

Comment 75 Stephen So 2004-05-24 10:52:10 UTC
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

Comment 76 Kasper Dupont 2004-05-24 18:50:03 UTC
Steve if you still have a copy of both the working and the broken MBR
could you attach both of them to this thread?

Comment 77 John Haxby 2004-05-24 21:29:07 UTC
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

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.

Comment 78 Carter Manucy 2004-05-25 03:53:33 UTC
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.

Comment 79 Stephen So 2004-05-26 12:07:51 UTC
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

Comment 80 Stephen So 2004-05-26 12:11:09 UTC
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)

Comment 81 Stephen So 2004-05-26 12:18:25 UTC
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.

Comment 82 Stephen So 2004-05-26 12:26:42 UTC
Carter Manucy (redhat@carter.cc):

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

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"?

Comment 83 John Haxby 2004-05-26 12:43:23 UTC
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
/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?

Comment 84 Jeremy Katz 2004-05-26 14:44:23 UTC
*** Bug 124350 has been marked as a duplicate of this bug. ***

Comment 85 Kasper Dupont 2004-05-26 17:21:20 UTC
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

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): 

Comment 86 Carter Manucy 2004-05-26 19:41:10 UTC
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 

Comment 87 Patrick J. LoPresti 2004-05-26 22:51:52 UTC
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 
and <http://groups.google.com/groups?selm=1Gjko-6Y1-5%40gated-at.bofh.it>.

Comment 88 Stephen So 2004-05-27 00:04:44 UTC
John Haxby:

Try passing this kernel argument when you boot up 


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.

Comment 89 Stephen So 2004-05-27 00:11:25 UTC
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?

Comment 90 Carter Manucy 2004-05-27 00:20:28 UTC

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.

Comment 91 Stephen So 2004-05-27 00:33:20 UTC

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.

Comment 92 Stephen So 2004-05-27 00:36:03 UTC
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?

Comment 93 Carter Manucy 2004-05-27 00:46:49 UTC

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.

Comment 94 Carter Manucy 2004-05-27 00:53:04 UTC
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...

Comment 95 Stephen So 2004-05-27 00:58:29 UTC

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

Comment 96 Ignacio Valdes 2004-05-27 02:20:43 UTC
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

Comment 97 Carter Manucy 2004-05-27 03:24:22 UTC
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!

Comment 98 Stephen So 2004-05-27 03:36:06 UTC

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

Comment 99 Kasper Dupont 2004-05-27 18:34:08 UTC
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.

Comment 100 Ivan Andrijic 2004-05-27 20:15:43 UTC
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

Comment 101 CodyTaylor 2004-05-29 00:04:40 UTC
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... 

Comment 102 Ignacio Valdes 2004-05-29 05:04:48 UTC
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

Comment 103 Kasper Dupont 2004-05-29 09:06:26 UTC
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.

Comment 104 Surhud More 2004-05-29 11:02:58 UTC
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


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...


Comment 105 Surhud More 2004-05-29 11:07:11 UTC
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..


Comment 106 Bill Moss 2004-05-29 14:27:16 UTC
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.

Comment 107 Dawid Gajownik 2004-05-29 16:31:47 UTC

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
Error #114: Logical starting at 83345283 is not one head away from EPBR.


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)

Comment 108 Stuart Passe 2004-05-29 22:10:30 UTC
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.


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

Comment 109 Doncho Gunchev 2004-05-29 23:36:00 UTC
    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].

Comment 110 Jonathan S. Shapiro 2004-05-30 19:25:43 UTC
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.

Comment 111 Behdad Esfahbod 2004-05-31 03:40:04 UTC
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

Comment 112 cliff rogers 2004-05-31 06:20:43 UTC
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???

Comment 113 Surhud More 2004-05-31 06:41:38 UTC
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...


Comment 114 Jeremy Katz 2004-06-01 20:15:33 UTC
*** Bug 124797 has been marked as a duplicate of this bug. ***

Comment 115 Keith Wong 2004-06-02 11:14:20 UTC
Many thanks for the excellent advice here and on

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
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.


Comment 116 Jeremy Katz 2004-06-04 06:11:29 UTC
*** Bug 125252 has been marked as a duplicate of this bug. ***

Comment 117 Need Real Name 2004-06-07 00:02:04 UTC
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,

Comment 118 Thomas Shea 2004-06-07 07:30:23 UTC
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.

Comment 119 Chris Chabot 2004-06-07 11:56:11 UTC
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

Comment 120 Jeremy Katz 2004-06-08 19:15:23 UTC
*** Bug 124090 has been marked as a duplicate of this bug. ***

Comment 121 Doncho Gunchev 2004-06-10 08:12:51 UTC
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?).

Comment 122 salah salameh 2004-06-15 02:39:36 UTC
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 

Comment 123 Matthew Miller 2004-06-15 02:56:15 UTC
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).

Comment 124 Magnus Juntti 2004-06-18 07:42:11 UTC
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.

Comment 125 Jeremy Katz 2004-06-18 21:47:00 UTC
*** Bug 126270 has been marked as a duplicate of this bug. ***

Comment 126 Chris Halls 2004-06-21 15:36:39 UTC
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!)

Comment 127 Jeremy Katz 2004-06-21 23:07:58 UTC
*** Bug 118268 has been marked as a duplicate of this bug. ***

Comment 128 Jens Einsmann 2004-06-22 07:47:53 UTC
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 :-))

Comment 129 Jeremy Katz 2004-06-25 19:33:38 UTC
*** Bug 112299 has been marked as a duplicate of this bug. ***

Comment 130 Jeremy Katz 2004-06-25 19:43:47 UTC
*** Bug 113201 has been marked as a duplicate of this bug. ***

Comment 131 Jeremy Katz 2004-06-25 19:47:03 UTC
*** Bug 122247 has been marked as a duplicate of this bug. ***

Comment 132 Paul Claessen 2004-06-28 16:40:59 UTC
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-

Comment 133 Mikael Konttinen 2004-07-06 20:53:06 UTC
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.

Comment 134 James Clark 2004-07-14 01:12:27 UTC
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


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.

Comment 135 Bas Simons 2004-07-15 17:22:33 UTC
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
# 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
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

Comment 136 Robert Scheck 2004-08-06 17:20:56 UTC
Anyone having that very annoying problem with Fedora Core 3 test 1? 
Hereby I mean a default installation at a system, that was affected 

As long as this bug isn't closed, I interpret, that this problem also
exists for the current Fedora Core test versions...

Comment 137 Jonathan Allen 2004-08-16 11:26:50 UTC
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.

Comment 138 Jeremy Katz 2004-08-16 19:38:28 UTC
Building parted 1.6.12 now which changes it's handling of C/H/S to fix

If you can reliably reproduce this problem, verifying that installs
after tomorrow-ish work fine would be helpful.

Comment 139 Robert Scheck 2004-08-17 13:22:53 UTC
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.

Comment 140 John S. P. U. Wolter 2004-08-20 20:33:41 UTC
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?

Comment 141 David A. Wheeler 2004-08-23 20:53:41 UTC
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.

Comment 142 Bob Salsbirg 2004-08-23 22:04:04 UTC
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.

Comment 143 David A. Wheeler 2004-08-24 06:18:10 UTC
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

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
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.

Comment 144 Bryan J. Smith 2004-08-24 06:53:49 UTC
[ 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

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.

Comment 145 Eric Hopper 2004-08-24 15:34:10 UTC
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.

Comment 146 Søren Andersen 2004-09-07 04:24:13 UTC
Does this bug also exist in FC3, Test 1?
I have an analouge problem there, in any case.
See bug 131911...

Comment 147 Bryan J. Smith 2004-09-15 23:15:10 UTC
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.

Comment 148 John Haxby 2004-09-16 08:24:35 UTC
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.

Comment 149 Patrick Shinpaugh 2004-09-23 03:28:01 UTC
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

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.


Comment 150 Norbert Savary 2004-09-23 21:44:05 UTC
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.

Comment 151 Norbert Savary 2004-09-23 21:47:25 UTC
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.

Comment 152 Jeremy Katz 2004-10-07 18:22:08 UTC
*** Bug 123937 has been marked as a duplicate of this bug. ***

Comment 153 Fred 2004-10-10 15:04:58 UTC

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:

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


Comment 154 Fred 2004-10-10 15:27:20 UTC
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

Comment 155 Fred 2004-10-10 15:40:50 UTC
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

Comment 156 Jeremy Katz 2004-10-24 22:09:24 UTC
*** Bug 136974 has been marked as a duplicate of this bug. ***

Comment 157 André Mondri 2004-11-04 11:37:21 UTC
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 ?

Comment 158 Pedro Fernandes Macedo 2004-11-04 15:02:39 UTC
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...

Comment 159 André Mondri 2004-11-04 15:09:57 UTC

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 

Comment 160 rh 2004-11-11 14:06:37 UTC
Is this still a problem in FC3?

Comment 161 John Cooper 2004-11-12 12:52:08 UTC
Yes, still exists in FC3. My installation of FC3 booted perfectly, 
but rendered XP un-bootable, even XP recovery disk hung! See FC3 bug 

Comment 162 André Mondri 2005-01-03 11:54:09 UTC
Anybody working on it ?

Comment 163 martin maalec 2005-01-10 14:00:51 UTC
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 
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") 

Comment 164 martin maalec 2005-01-11 20:35:26 UTC
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.

Comment 165 Martin van den Bemt 2005-01-23 01:15:01 UTC
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.

Comment 166 Martin van den Bemt 2005-01-23 02:33:32 UTC
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.

Comment 167 Alan Ly 2005-01-25 01:17:06 UTC
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:


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.

Comment 168 Scott 2005-02-28 04:14:05 UTC
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 

I'm going on my 4th install.

I'll continue to hack it out on my side.

Comment 169 Marius Andreiana 2005-03-02 13:01:29 UTC
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)


Comment 170 Robert McCullough 2005-04-18 18:23:44 UTC
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

Comment 171 Mike White 2005-05-05 19:44:20 UTC
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
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.

Comment 172 tmx 2005-05-08 20:52:17 UTC
the error as far as I can tell is caused by the detection of the partition 

Burn the fedora rescue ISO to disk, and boot from it.  Get the CHS values from 

Then, when you come to install fedora, add the argument chs=x,y,z to the boot 

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.

Comment 173 John 2005-05-14 22:49:18 UTC
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.

Comment 174 John 2005-05-14 22:49:56 UTC
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.

Comment 175 dilbert 2005-05-18 10:36:29 UTC
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?

Comment 176 Matthew Miller 2005-05-18 12:30:12 UTC
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.

Comment 177 Peter Jones 2005-05-18 18:57:00 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.