Re: 2.6.x partition breakage and dual booting

Patrick J. LoPresti
2004-05-30T19:35:23Z

Jeff Garzik <jgarzik@pobox.com> writes:

> So it seems that the 2.6.x geometry code breaks dual booting, since
> Windows wants "sane" CHS values. See the thread on slashdot, or
> http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html
>
> Although Fedora Core is current taking grief for this, it's really a
> 2.6.x kernel problem AFAICT.
>
> Has anybody taken the time to hunt down the csets that cause this
> massive partition table breakage? If so, it will save me some time
> tracking this down.

Here are my contributions to the discussion:

http://groups.google.com/groups?selm=1xXh2-850-17%40gated-at.bofh.it

http://groups.google.com/groups?selm=1Gjko-6Y1-5%40gated-at.bofh.it

http://groups.google.com/groups?selm=1Gju8-7bd-29%40gated-at.bofh.it

In short, starting with kernel 2.6.5, Linux invokes the real-mode
"legacy INT13" interface (INT13/AH=08) at boot time and stashes the
results away. The EDD module exports them via sysfs.

Userspace can read these values and issue a command to
/proc/ide/hda/settings to "fix" the kernel's concept of the geometry
before running partitioning tools.

Because the legacy geometry is purely a BIOS concept, there is no way
to obtain it by talking to the disk directly. (Sure, there may be
hints in the existing partition table. I believe 2.4.x would use such
hints. But this is unreliable, since it does not work if the disk is
blank or if it has been moved from a different machine.)

The reason to do this work in userspace is that there is no certain
way to map between BIOS disk numbers (80h etc.) and Linux devices.
You can make a pretty good guess, but such guessing probably does not
belong in the kernel.

I first encountered this problem while trying to install Windows using
Linux. I contributed the "legacy geometry" support to the EDD module
specifically to deal with this issue, and it is working fine for me.

- Pat