[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fix for the XP dual boot problem



Greg Miller wrote:
It looks like I may have a similar but different problem.

I wiped FC2test3 and winXP. I then re-installed XP (to solve other problems), then re-installed FC2. It looks like GRUB is screwed up and can not boot linux, but Win XP boots fine. I get an error message that indicates it can't find the partition abd to press a key to continue. The screen is barely readable and I can just select other to go to the XP/dos boot selection.

I'm thinking I need to re-install grub from a rescue boot.

AMD3200
K8T800 chipset
SATA drive
Radeon 9200 Video

Greg.

----- Original Message -----
From: Radu Cornea <ccradu yahoo com>
Date: Wednesday, May 19, 2004 5:25 pm
Subject: Re: Fix for the XP dual boot problem


Michal Jaegermann wrote:


The problem is that there is no "wrong geometry".  For quite a while
these "geometries" are just inventions and illusions.  Many years
ago hard disks indeed had all these head and cylinder geometries,
physical ones, but this is a bygone era.  The trouble here is that
here XP invents one geometry and your kernel another and XP refuses
to work with what it decided it likes.  Linux kernel is more
forgiving than that and anaconda should just read what an existing
partition table said and do not bother with any alerts.


Well, not exactly. What I call "wrong geometry" is when the two values (physical and logical) don't match. I know the same disk can be seen as having different geometries (e.g. 16 heads vs 255) but in the final C*H*S should be the same. As I mentioned in another post I get very different values from the 2.6 kernel, while 2.4 returns the correct ones:


These are examples from FC2:
$ more /proc/ide/hda/geometry
physical     16383/16/63
logical      19841/16/63

On another FC2 machine:
$ more /proc/ide/hda/geometry
physical     16383/16/63
logical      16383/255/63

On a FC1 machine (2.4 kernel) the numbers are ok:
$ more /proc/ide/hda/geometry
physical     155009/16/63
logical      9726/255/63

The product C*H*S should be the same (or close at least)...
But they are different (even for the same OS, not even talking about XP here).



Strictly speaking the bug is on an XP side but you are not likely
fare that well pursuing that.

I agree this may be fixed on the XP side too. But still the installer has a problem. Why will it otherwise offer without any warning to change the mbr, when I did not select any partitioning and I chose to put Grub in the Linux partition. This reminds me of another OS (guess:)) which overwrites mbr on install again without asking.
Plus, there are report on bugzilla of people that did run partition magic after installing FC2 and got a lot of errors (mismatch) in the partition table.
From the fdisk manual, the mbr stores the info in two ways: as an absolute number of sectors and as C/H/S. Windows uses both, while Linux never uses C/H/S. That's why I think Linux can still boot, and Windows not. Only C/H/S are changed during installation. That's why it is also possible to restore the original aprtition table.
Fedora 2 is not the only one affected by it, but also Mandrake 10 and Suse 9.1. See:


https://qa.mandrakesoft.com/show_bug.cgi?id=7959
http://www.eweek.com/article2/0,1759,1585840,00.asp

So far this post by Alan Cox seems to be the best explanation why this problem occurs with 2.6 kernels:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113201#c13

"This seems to be a bug in the FC2 tools. The Linux kernel no longer
does partition guessing (its a heuristic and policy at best), as a
result the  parted tools should be honouring existing partition table
claims when they are present. Failure to do so causes very bad things
to happen.

Previously these situations the kernel itself would report the
partition table or BIOS guess it made, now its firmly in userspace."


-- Radu


--
fedora-test-list mailing list
fedora-test-list redhat com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list





I had a similar thing happen and discovered with fdisk that the partition it couldn't find was now labled as type 93 (amoeba) instead of 83 (linux). Check it out. I was able to correct it with the t command in fdisk.

Gerry Tool



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]