2.6.x partition breakage and dual booting

2.6.x partition breakage and dual booting

[Jeff Garzik]

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.

	Jeff

Re: 2.6.x partition breakage and dual booting

[Andries Brouwer]

On Sun, May 30, 2004 at 02:04:03PM -0400, Jeff Garzik wrote:

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

Hi Jeff,

The link you give describes a user space problem.
The fdisk versions that I maintain all work fine - apparently
Fedora Core uses something else to change partition tables,
and that something else makes assumptions that are invalid.
(Maybe it uses parted?)

I can tell you in great detail all about disk geometry,
and the 2.4 situation and the 2.6 situation.

Andries
aeb@cwi.nl

Re: 2.6.x partition breakage and dual booting

[Jeff Garzik]

Andries Brouwer wrote:
> The link you give describes a user space problem.
> The fdisk versions that I maintain all work fine - apparently
> Fedora Core uses something else to change partition tables,
> and that something else makes assumptions that are invalid.
> (Maybe it uses parted?)
> 
> I can tell you in great detail all about disk geometry,
> and the 2.4 situation and the 2.6 situation.


Please educate me :)  Brutally, and in public :)

	Jeff

Re: 2.6.x partition breakage and dual booting

[Andries Brouwer]

On Sun, May 30, 2004 at 02:56:30PM -0400, Jeff Garzik wrote:

> Please educate me :)  Brutally, and in public :)

Hmm. It is easier if you ask questions.
I already wrote several many-page texts on this stuff.
See, e.g., http://www.win.tue.nl/~aeb/linux/Large-Disk.html

Attempt at a brief summary:

(i) Hardware:

In the ancient past a disk (MFM or RLL) had a geometry
describing how many sectors per track, how many tracks (cylinders),
and how many heads the thing had.

With the advent of IDE it no longer was true that a disk has a
well-determined geometry: the ATA command INITIALIZE DRIVE PARAMETERS
will tell the disk what geometry it is supposed to have today.

An IDE disk can be accessed in CHS and in LBA mode, and the
geometry specified, or read via the ATA IDENTIFY command,
defines the meaning of a CHS command. With LBA access
no geometry plays a role.

SCSI disks never had this geometry nonsense.

Linux uses LBA and does not need to concern itself with geometry.

(ii) DOS / Windows:

The DOS disk interface used CHS. If the disk uses LBA the driver
has to convert CHS to LBA and hence needs a geometry (at least H, S).

Because DOS (BIOS INT 13) had 10 bits for C, and 6- bits for S,
while ATA uses 4 bits for H, this scheme could address only
somewhat less than 2^20 sectors. The 528 MB limit.

All kinds of translation schemes were invented to give the
BIOS interface a geometry different from that used at the ATA
interface. The user chooses a translation scheme in the BIOS setup.
The geometry is now unrelated to the disk, but is known to the BIOS.

Various BIOS calls exist that report on various versions of the
geometry.

(iii) Partition tables:

A DOS-type partition table (see, e.g.,
http://www.win.tue.nl/~aeb/partitions/partition_tables.html)
gives the location of a partition in two ways.
One is the way used by Linux (the starting sector and length,
both given in 32 bits). The other, used by DOS, given CHS
for the first and for the last sector (both in 24 bits).

Even when nobody cares about geometry any longer, is it still
necessary to fill these CHS fields.

If the filesystem living in the partition is a FAT filesystem,
then the boot sector of the FAT filesystem again gives information
on the size of the partition.

(iv) Linux:

There is an ioctl HDIO_GETGEO that returns the geometry of a disk
and the starting sector (offset) of a partition.
There is an ioctl BLKGETSIZE that returns the size (in 512-byte sectors)
of a block device in 32 bits.
There is an ioctl BLKGETSIZE64 that returns the size (in bytes)
of a block device in 64 bits.

Clearly, BLKGETSIZE is obsolescent - it should be replaced by
BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.

The HDIO_GETGEO ioctl gives heads, sectors and cylinders -
fields of 1, 1, 2 bytes. On the one hand that is reasonable -
no interface exists that can use more than 16 bits for the
number of cylinders. On the other hand there is still some
broken software that computes the size of a disk as C*H*S,
and obtains C, H, S by HDIO_GETGEO. Of course this is broken,
and introducing a new ioctl is no good - such software must
be fixed to use BLKGETSIZE64.

(v) Geometry use under Linux:

Roughly speaking geometry was needed under Linux for two
purposes: LILO (and similar bootloaders) and *fdisk.
Of course, also programs that tried to emulate aspects
of DOS/Windows are interested in a geometry.

The LILO aspect has disappeared - with options like linear, or lba32,
lilo uses linear sector numbers at install time, and converts them
to CHS, when needed, at boot time.

The fdisk aspect has also disappeared - after this geometry business
had become infinitely complicated, nobody any longer tried to
understand geometry, but just inferred from the partition table
what geometry was used by the program that last wrote it.

How did the kernel find a geometry?
Mainly in three ways: (i) from boot parameters, (ii) by looking
at the partition table, (iii) by asking the BIOS at boot time,
before switching to protected mode.

Information (i) - explicit specification - and (ii) - partition table -
is also available to user space, no kernel needed.
Remains the question whether (iii) is a good idea.

It didnt always work, but often it worked. (And only on i386 of course.)
Examples of failure: The code we had only asked the BIOS for info
on the first two disks. An often-posed question was: I have two
identical disks, how come they get different geometries?
Also, the code we had failed when the system had SCSI disks.
Also, the code we had assumed that the first two BIOS disks
were hda and hdb. But there is no reason why that would be
the case. For example, many people kept their large disks out of the
BIOS since it would crash upon seeing big disks.

So, this (iii) was a bit messy stuff with many problems, but
OK for most people.

(vi) The present

Linux no longer makes any attempt to invent a geometry.
If someone needs a geometry, he is responsible himself
for choosing one of the many concepts of geometry, and
determining a value. What most software does is looking
at the partition table, and that works.

Maybe parted has not yet been updated to do this,
that is why I conjectured that Fedora problems might be
due to the use of parted.

Was this a loss? I don't think so, but there is at least
one use of the old situation that fails today:
the installation of Windows systems from Linux media
on a completely blank disk.

Andries

Re: 2.6.x partition breakage and dual booting

[viro]

On Sun, May 30, 2004 at 10:03:00PM +0200, Andries Brouwer wrote:
> Clearly, BLKGETSIZE is obsolescent - it should be replaced by
> BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.

ITYM "it should be replaced to lseek(fd, SEEK_END, 0) everywhere".

Re: 2.6.x partition breakage and dual booting

[Andries Brouwer]

On Sun, May 30, 2004 at 09:47:15PM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:

> > Clearly, BLKGETSIZE is obsolescent - it should be replaced by
> > BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.
> 
> ITYM "it should be replaced to lseek(fd, SEEK_END, 0) everywhere".

Roughly speaking, I agree (if you change that to lseek(fd, 0, SEEK_END)).

But in practice, now that we have BLKGETSIZE64, that is much more
convenient. How many bits does one get out of lseek? What is the size
of off_t? Is perhaps llseek needed? Or lseek64? Complications.

Andries

Re: 2.6.x partition breakage and dual booting

[Andreas Schwab]

viro@parcelfarce.linux.theplanet.co.uk writes:

> On Sun, May 30, 2004 at 10:03:00PM +0200, Andries Brouwer wrote:
>> Clearly, BLKGETSIZE is obsolescent - it should be replaced by
>> BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.
>
> ITYM "it should be replaced to lseek(fd, SEEK_END, 0) everywhere".
ITYM                             lseek(fd, 0, SEEK_END)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 2.6.x partition breakage and dual booting

[viro]

On Sun, May 30, 2004 at 11:08:27PM +0200, Andreas Schwab wrote:
> viro@parcelfarce.linux.theplanet.co.uk writes:
> 
> > On Sun, May 30, 2004 at 10:03:00PM +0200, Andries Brouwer wrote:
> >> Clearly, BLKGETSIZE is obsolescent - it should be replaced by
> >> BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.
> >
> > ITYM "it should be replaced to lseek(fd, SEEK_END, 0) everywhere".
> ITYM                             lseek(fd, 0, SEEK_END)

Sorry, braino.

Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

Andries Brouwer <Andries.Brouwer@cwi.nl> writes:

> (i) Hardware:

[snip]

> SCSI disks never had this geometry nonsense.

Not in hardware, no.  But they very much have a geometry in the BIOS.
So do RAID controllers.  And all of this matters for a dual boot
system.

> All kinds of translation schemes were invented to give the BIOS
> interface a geometry different from that used at the ATA
> interface. The user chooses a translation scheme in the BIOS setup.
> The geometry is now unrelated to the disk, but is known to the BIOS.

But you better not change it, because it shows up in the partition
table.  And if the partition table geometry does not match the BIOS,
Windows will not boot.  (Perhaps there is a way to convince the
Windows boot loader to use LBA mode and ignore the partition table
geometry completely.  But I have not found it.)

> Various BIOS calls exist that report on various versions of the
> geometry.

"Various"?  I know of two, the legacy INT13 interface and the extended
INT13 interface.  Are there others?

> The fdisk aspect has also disappeared - after this geometry business
> had become infinitely complicated, nobody any longer tried to
> understand geometry, but just inferred from the partition table
> what geometry was used by the program that last wrote it.

Which is a terrible idea, because it does not work at all on blank
disks and it gives the wrong answer if you move a disk between
machines.  I may have mentioned this before.

> It didnt always work, but often it worked. (And only on i386 of
> course.)  Examples of failure: The code we had only asked the BIOS
> for info on the first two disks.

Today, right now, the kernel invokes both the legacy and the extended
INT13 interfaces for all disks which are visible to the BIOS.  The EDD
module makes all of these data available.

> Linux no longer makes any attempt to invent a geometry.
> If someone needs a geometry, he is responsible himself
> for choosing one of the many concepts of geometry, and
> determining a value. What most software does is looking
> at the partition table, and that works.

No, that does not work.  Not all the time, anyway.  And when it fails,
the failure is ugly.

> Maybe parted has not yet been updated to do this,
> that is why I conjectured that Fedora problems might be
> due to the use of parted.

Actually, Parted DOES infer geometry from the partition table.
Perhaps Disk Druid does not use Parted, or perhaps it uses distinct
invocations of Parted to 1) erase the old partition table and 2)
replace it with a new one?

> Was this a loss? I don't think so, but there is at least
> one use of the old situation that fails today:
> the installation of Windows systems from Linux media
> on a completely blank disk.

Actually, *any* attempt to install Windows after installing Linux will
run into this problem.

This is really very simple.  If you move a disk from a machine with a
different BIOS and you preserve the partition table geometry, you will
NEVER be able to install Windows on the drive.  If you partition a
blank drive and use the wrong geometry, you will NEVER be able to
install Windows on the drive.

The correct solution is to use the legacy INT13 geometry when
partitioning the disk, regardless of what you already find there.
(For partition table purposes, the cylinder count is irrelevant; only
"heads" and "sectors" matter.)

Yes, this means you have to map between BIOS disk numbers and Linux
devices, which may require heuristics.  But those heuristics can be
improved over time, whereas relying on the existing partition table
will always be just plain wrong.

 - Pat

Re: 2.6.x partition breakage and dual booting

[Andries Brouwer]

On Sun, May 30, 2004 at 05:02:59PM -0400, Patrick J. LoPresti wrote:

> > Various BIOS calls exist that report on various versions of the
> > geometry.
> 
> "Various"?  I know of two, the legacy INT13 interface and the extended
> INT13 interface.  Are there others?

Five years ago I made an attempt to get at the "true" geometry,
collecting all possible information from disk and BIOS.
I forgot all details, but among the sources were:

CMOS. INT 13, AH = 8, 15, 48. Tables pointed at by INT 41, INT 46.
Sometimes one finds data past the pointer given by INT 41.
IBM and Phoenix extensions.

The details depend on the brand of BIOS, which version of Phoenix
extensions is supported, whether the support is bugfree, etc.

The result in 1999 was that it is impossible to get at geometries
in a reliable way. I could not even come up with reasonable heuristics
that worked on the majority of the machines I had at home.

> Today, right now, the kernel invokes both the legacy and the extended
> INT13 interfaces for all disks which are visible to the BIOS.  The EDD
> module makes all of these data available.

Yes, I am happy with that.

(Much better than the old situation where HDIO_GETGEO gave
answers for one disk that belonged to some other disk.
Of course, EDD is not always available.)


Andries

Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

Andries Brouwer <Andries.Brouwer@cwi.nl> writes:

> CMOS. INT 13, AH = 8, 15, 48. Tables pointed at by INT 41, INT 46.
> Sometimes one finds data past the pointer given by INT 41.
> IBM and Phoenix extensions.
> 
> The details depend on the brand of BIOS, which version of Phoenix
> extensions is supported, whether the support is bugfree, etc.
> 
> The result in 1999 was that it is impossible to get at geometries
> in a reliable way. I could not even come up with reasonable heuristics
> that worked on the majority of the machines I had at home.

Fair enough.

The old DOS fdisk uses INT13/AH=08h exclusively.  And I have used DOS
fdisk many times on many machines to partition a drive and then
install Windows.  So I am fairly confident that the geometry provided
by INT13/AH=08h (the "legacy INT13 interface") is the one the Windows
boot loader likes to see in the partition table.  This is the geometry
I use in my project, and my users have reported zero failures so far.

> Yes, I am happy with that.

Cool.  Sorry if my earlier tone was overly harsh.

> (Much better than the old situation where HDIO_GETGEO gave
> answers for one disk that belonged to some other disk.
> Of course, EDD is not always available.)

It is true that EDD 3.0, which allows you to map reliably between BIOS
disk numbers and physical hardware devices, is not always available
(see http://linux.dell.com/edd/results.html).  But the legacy geometry
is always around, and the EDD module will make it available even if
full EDD support is not present.

The only tricky part is doing the BIOS->Linux disk device mapping.  It
sure would be nice to have that written well once so that each of the
installation systems could re-use it...

 - Pat

Re: 2.6.x partition breakage and dual booting

[Tomas Szepe]

> This is really very simple.  If you move a disk from a machine with a
> different BIOS and you preserve the partition table geometry, you will
> NEVER be able to install Windows on the drive.  If you partition a
> blank drive and use the wrong geometry, you will NEVER be able to
> install Windows on the drive.

I don't quite believe this.  AFAICT the Windows 2000/XP install program will
succeed no matter what, the only problem is with getting the dirty thing to
boot AFTER install has completed.  If it craps out, boot off the install
CD to the repair console prompt, run fixboot/fixmbr and all should be swell.
If you need dual boot, you can go ahead and reinstall lilo/grub at this point.
The one scenario unfixable without a hex editor that I know of is installing
Windows on a partition that was created using mkdosfs -F 32 (and even that
will sometimes work).

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: 2.6.x partition breakage and dual booting

[Frediano Ziglio]

Il lun, 2004-05-31 alle 20:08, Tomas Szepe ha scritto:
> > This is really very simple.  If you move a disk from a machine with
a
> > different BIOS and you preserve the partition table geometry, you
will
> > NEVER be able to install Windows on the drive.  If you partition a
> > blank drive and use the wrong geometry, you will NEVER be able to
> > install Windows on the drive.
> 
> I don't quite believe this.  AFAICT the Windows 2000/XP install
program will
> succeed no matter what, the only problem is with getting the dirty
thing to
> boot AFTER install has completed.  If it craps out, boot off the
install
> CD to the repair console prompt, run fixboot/fixmbr and all should be
swell.
> If you need dual boot, you can go ahead and reinstall lilo/grub at
this point.
> The one scenario unfixable without a hex editor that I know of is
installing
> Windows on a partition that was created using mkdosfs -F 32 (and even
that
> will sometimes work).

Let me explain my point of view

I encountered the problem trying to install Fedora Core 2. Using Fedora
Core 2 and fdisk do not works (it return bad head count), so it's not
only an anaconda problem.

I analyzed 2.4.22 code and 2.6.5 code (both from Fedora kernels)
In 2.4 when an IDE drive is detected it looks in CMOS to see if a HD is
configured, then fetch BIOS data from int 41h / int 46h. If this is not
possible it try to compute heads number (the number that allow you to
access most data) (drivers/ide/ide-geometry.c). Another hint is to check
partition table (fs/partitions/msdos.c). In 2.6 this code just
disappeared...

I think it's important to know BIOS point of view. Linux provide these
information so we have two choices to solve the problem:
- correct the informations we return
- do not return anything and let user space programs do the job!

How to match Linux view with BIOS view? We have some unimplemented mode
I'll explain below (I just want to fix this problem).

Mainly the problem raise cause we have a lot of choices and different
configurations:
- SCSI. BIOS can see SCSI disks before IDE disks, see the first SCSI
disk then IDEs then others SCSIs;
- BIOS settings. Some BIOS always minimize cylinder count (maximizing
head count), others no, others allow you to select geometry (in my BIOS
I have three choices: LBA, CHS and Large)
- BIOS boot sequence. Newer BIOS let you choice what's is the first
disks. Also I tried to plug a USB disks and select as first disk but
BIOS put it always as second (even if I boot from floppy)... perhaps it
check MBR???

How to match BIOS with Linux?
There are some infos that can helps:
- if we have only a disks it's easy
- we can use dimensions (int13h/8h, int 41h/46h)
- MBR signature. I don't even know this before yesterday!!! We save only
this information for first BIOS disk (80h), we can improve saving this
information (and provide in sysfs)
- EDD 1.0. Use physical dimensions to match
- EDD 2.0. I don't understand why Linux code int 41h/46h and ignore
these informations. My BIOSes do not support EDD 3.0 but support EDD
2.0. EDD 2.0 provide informations like command port and if slave or not
(see Ralph Brown's interrupt list, int 13h/48h). If a disk is IDE we can
match _exactly_ the disk!
- EDD 3.0. Here we have disk type and path (like LUN/ID on SCSI), very
easy to match but not very widely implemented.
IMHO we should try to use these informations as best that we can.

There are also some informations in EDD that should be detected like
removable disks. It would be useful if Linux can provide a mapping
between BIOS and Linux disks to user-space programs.

I can try to code some implementation but I'm not an Linux kernel
hacker... for example I don't know if IDE is detected before SCSI
(something suggests me that there isn't an order).

freddy77

Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

Tomas Szepe <szepe@pinerecords.com> writes:

> > This is really very simple.  If you move a disk from a machine with a
> > different BIOS and you preserve the partition table geometry, you will
> > NEVER be able to install Windows on the drive.  If you partition a
> > blank drive and use the wrong geometry, you will NEVER be able to
> > install Windows on the drive.
> 
> I don't quite believe this.  AFAICT the Windows 2000/XP install
> program will succeed no matter what, the only problem is with
> getting the dirty thing to boot AFTER install has completed.  If it
> craps out, boot off the install CD to the repair console prompt, run
> fixboot/fixmbr and all should be swell.  If you need dual boot, you
> can go ahead and reinstall lilo/grub at this point.

Well, sure.  You could also erase the entire disk and start over.  I
did not literally mean "never"; sorry if that was not obvious.

The point is, if you use the wrong geometry in the partition table,
Windows will not boot.  You could always fix it later, either from
Linux (sfdisk hack) or from the Windows recovery console or with a hex
editor or whatever.  The topic of discussion was how to get it right
to begin with.

 - Pat

Re: 2.6.x partition breakage and dual booting

[Sean Estabrooks]

On 31 May 2004 16:06:54 -0400
"Patrick J. LoPresti" <patl@users.sourceforge.net> wrote:

> The point is, if you use the wrong geometry in the partition table,
> Windows will not boot.  You could always fix it later, either from
> Linux (sfdisk hack) or from the Windows recovery console or with a hex
> editor or whatever.  The topic of discussion was how to get it right
> to begin with.

Just don't alter partition table entries of non Linux partitions?  

Cheers,
Sean

Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

Sean Estabrooks <seanlkml@sympatico.ca> writes:

> Just don't alter partition table entries of non Linux partitions?  

I have not been very clear, so let me try once more.

Yes, using the existing partition table geometry will work if you
install Windows before you install Linux.  But it will fail if you do
things the other way around.

I am suggesting an approach which will work either way; namely,
determine the Windows-compatible geometry and use it.

The Windows-compatible geometry is the one reported by the "legacy
INT13 BIOS interface"; i.e., INT13/AH=08h.

Because this legacy BIOS interface can only be invoked from real mode,
Linux 2.2.x and 2.4.x tried to infer the legacy geometry by parsing
CMOS tables.  This did not always work, both because the tables are
poorly specified and buggy and vendor-specific, and because it
requires mapping between BIOS disk numbers and Linux devices, which is
tricky.  So the old code was gutted for 2.6.x, and now the kernel
simply reports the geometry as reported by the disk controller.
(Linux itself does not care about the geometry, because it does
everything in "linear" mode.)

This means partitions created under Linux are incompatible with
Windows, unless you get lucky and your BIOS uses (or can be configured
to use) the geometry reported by the controller.

Now, starting with 2.6.5 Linux actually invokes INT13/AH=08h during
real-mode startup and stashes the values away.  They are available via
Dell's EDD module.  So, to find the Windows-compatible geometry, you
simply:

  modprobe edd
  cat /sys/firmware/edd/int13_dev80/{legacy_heads,legacy_sectors}

(And add 1 to the "heads" value because the legacy BIOS interface is
freaky.)

There is just one catch.  This assumes BIOS device 80h (the boot
device) is the disk you care about.  If not, you need to figure out
which BIOS device corresponds to the disk you do care about.  This is
the hard part, but it is not THAT hard, because the /sys/firmware/edd
interface exposes lots of information which will help you deduce this
correspondence.  It exports the extended (controller) geometry, the
disk size, and the MBR signature (see
http://seclists.org/lists/linux-kernel/2004/Jan/5257.html).  For a
sufficiently modern (EDD 3.0) BIOS, it will even include the exact
information (PCI device etc.) identifying the disk.

This is not surprising, because the EDD module was specifically
designed with this mapping goal in mind; one of Dell's interests is
automatically finding the boot disk on systems with lots of drives.

So, if we write a decent library routine to map between BIOS device
numbers and Linux devices, then we will be finished, and everything
will work fine no matter which OS the user installs first.

 - Pat

Re: 2.6.x partition breakage and dual booting

[Andries Brouwer]

On Tue, Jun 01, 2004 at 11:10:27AM -0400, Patrick J. LoPresti wrote:

> Now, starting with 2.6.5 Linux actually invokes INT13/AH=08h during
> real-mode startup and stashes the values away.  They are available via
> Dell's EDD module.  So, to find the Windows-compatible geometry, you
> simply:
> 
>   modprobe edd
>   cat /sys/firmware/edd/int13_dev80/{legacy_heads,legacy_sectors}
> 
> (And add 1 to the "heads" value because the legacy BIOS interface is
> freaky.)

Now that we are discussing this stuff anyway:
The names chosen are really bad, they are an invitation for
confusion and bugs.

We have "sectors" and it gives a count of sectors, like 0x7280b80
(yecch - why in hex??).
But "legacy_sectors" is not a number of sectors, but a number of
sectors per track, just like "default_sectors_per_track".

We have "default_heads" and it is a number of heads, like 0xff
(yecch - why in hex??).
But "legacy_heads" is not a number of heads, it is the largest
head number, that is, one less than the number of heads.

Please, now that this is still unused, fix your names and/or
your code. Names could be legacy_max_head (etc.) if you want
to keep the values, or otherwise add 1 to the values.

Note that sectors are counted from 1 here, so by some coincidence
legacy_max_sectors_per_track is the same as legacy_sectors_per_track.

Also - people will try to match the 0x7280b80 for int13_dev83 with
the 120064896 sectors that dmesg or hdparm -g reports for /dev/hdf.
Life would be easier with values given in decimal, as they are
everywhere else.

Andries


> There is just one catch.  This assumes BIOS device 80h (the boot
> device) is the disk you care about.  If not, you need to figure out
> which BIOS device corresponds to the disk you do care about.  This is
> the hard part, but it is not THAT hard, because the /sys/firmware/edd
> interface exposes lots of information which will help you deduce this
> correspondence.

It is basically impossible, but it is easy to give heuristics
that very often work. Very good that that now is a job left
to user space.

Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

Andries Brouwer <Andries.Brouwer@cwi.nl> writes:

> We have "sectors" and it gives a count of sectors, like 0x7280b80
> (yecch - why in hex??).
> But "legacy_sectors" is not a number of sectors, but a number of
> sectors per track, just like "default_sectors_per_track".
> 
> We have "default_heads" and it is a number of heads, like 0xff
> (yecch - why in hex??).
> But "legacy_heads" is not a number of heads, it is the largest
> head number, that is, one less than the number of heads.
> 
> Please, now that this is still unused, fix your names and/or
> your code. Names could be legacy_max_head (etc.) if you want
> to keep the values, or otherwise add 1 to the values.

Well, the EDD module belongs to Matt Domsch.  I only contributed the
"legacy_*" code and names.

If it is OK with Matt, I agree we should rename legacy_heads to
legacy_max_head and legacy_sectors to legacy_sectors_per_track.  I
doubt anybody other than myself is using these yet anyway.

> Also - people will try to match the 0x7280b80 for int13_dev83 with
> the 120064896 sectors that dmesg or hdparm -g reports for /dev/hdf.
> Life would be easier with values given in decimal, as they are
> everywhere else.

I used hex for legacy_* because that is what all the other fields
already used.  It was not my decision, and I have no opinion either
way.  Convince Matt.

 - Pat

Re: 2.6.x partition breakage and dual booting

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On Wed, Jun 02, 2004 at 09:02:23AM -0400, Patrick J. LoPresti wrote:
> Andries Brouwer <Andries.Brouwer@cwi.nl> writes:
> > Please, now that this is still unused, fix your names and/or
> > your code. Names could be legacy_max_head (etc.) if you want
> > to keep the values, or otherwise add 1 to the values.
> 
> Well, the EDD module belongs to Matt Domsch.  I only contributed the
> "legacy_*" code and names.
> 
> If it is OK with Matt, I agree we should rename legacy_heads to
> legacy_max_head and legacy_sectors to legacy_sectors_per_track.  I
> doubt anybody other than myself is using these yet anyway.

Yes, please submit a patch now to Andrew, cc: me and linux-kernel at
least.   I've confirmed that our internal tools are not using these
fields yet.
 
> > Also - people will try to match the 0x7280b80 for int13_dev83 with
> > the 120064896 sectors that dmesg or hdparm -g reports for /dev/hdf.
> > Life would be easier with values given in decimal, as they are
> > everywhere else.
> 
> I used hex for legacy_* because that is what all the other fields
> already used.  It was not my decision, and I have no opinion either
> way.  Convince Matt.

Whatever, scanf works with either representation.  Patrick, if you're
changing the above, feel free to submit a second patch to switch these
all to %u instead.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[PATCH] Better names for EDD legacy_* fields

[Patrick J. LoPresti]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

Matt Domsch <Matt_Domsch@dell.com> writes:

> On Wed, Jun 02, 2004 at 09:02:23AM -0400, Patrick J. LoPresti wrote:
> > Andries Brouwer <Andries.Brouwer@cwi.nl> writes:
> > > Please, now that this is still unused, fix your names and/or
> > > your code. Names could be legacy_max_head (etc.) if you want
> > > to keep the values, or otherwise add 1 to the values.
> > 
> > Well, the EDD module belongs to Matt Domsch.  I only contributed the
> > "legacy_*" code and names.
> > 
> > If it is OK with Matt, I agree we should rename legacy_heads to
> > legacy_max_head and legacy_sectors to legacy_sectors_per_track.  I
> > doubt anybody other than myself is using these yet anyway.
> 
> Yes, please submit a patch now to Andrew, cc: me and linux-kernel at
> least.   I've confirmed that our internal tools are not using these
> fields yet.

Trivial (search & replace) patch against 2.6.6 is attached.  This
renames legacy_heads to legacy_max_head legacy_sectors to
legacy_sectors_per_track.

 - Pat


[-- Attachment #2: rename_edd_legacy.txt --]
[-- Type: text/plain, Size: 3451 bytes --]

diff -u -r linux-2.6.6-orig/drivers/firmware/edd.c linux-2.6.6/drivers/firmware/edd.c
--- linux-2.6.6-orig/drivers/firmware/edd.c	2004-05-09 22:32:27.000000000 -0400
+++ linux-2.6.6/drivers/firmware/edd.c	2004-06-02 16:15:11.000000000 -0400
@@ -349,7 +349,7 @@
 }
 
 static ssize_t
-edd_show_legacy_heads(struct edd_device *edev, char *buf)
+edd_show_legacy_max_head(struct edd_device *edev, char *buf)
 {
 	struct edd_info *info;
 	char *p = buf;
@@ -359,12 +359,12 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += snprintf(p, left, "0x%x\n", info->legacy_heads);
+	p += snprintf(p, left, "0x%x\n", info->legacy_max_head);
 	return (p - buf);
 }
 
 static ssize_t
-edd_show_legacy_sectors(struct edd_device *edev, char *buf)
+edd_show_legacy_sectors_per_track(struct edd_device *edev, char *buf)
 {
 	struct edd_info *info;
 	char *p = buf;
@@ -374,7 +374,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += snprintf(p, left, "0x%x\n", info->legacy_sectors);
+	p += snprintf(p, left, "0x%x\n", info->legacy_sectors_per_track);
 	return (p - buf);
 }
 
@@ -462,7 +462,7 @@
 }
 
 static int
-edd_has_legacy_heads(struct edd_device *edev)
+edd_has_legacy_max_head(struct edd_device *edev)
 {
 	struct edd_info *info;
 	if (!edev)
@@ -470,11 +470,11 @@
 	info = edd_dev_get_info(edev);
 	if (!info)
 		return -EINVAL;
-	return info->legacy_heads > 0;
+	return info->legacy_max_head > 0;
 }
 
 static int
-edd_has_legacy_sectors(struct edd_device *edev)
+edd_has_legacy_sectors_per_track(struct edd_device *edev)
 {
 	struct edd_info *info;
 	if (!edev)
@@ -482,7 +482,7 @@
 	info = edd_dev_get_info(edev);
 	if (!info)
 		return -EINVAL;
-	return info->legacy_sectors > 0;
+	return info->legacy_sectors_per_track > 0;
 }
 
 static int
@@ -571,10 +571,11 @@
 static EDD_DEVICE_ATTR(sectors, 0444, edd_show_sectors, NULL);
 static EDD_DEVICE_ATTR(legacy_cylinders, 0444, edd_show_legacy_cylinders,
 		       edd_has_legacy_cylinders);
-static EDD_DEVICE_ATTR(legacy_heads, 0444, edd_show_legacy_heads,
-		       edd_has_legacy_heads);
-static EDD_DEVICE_ATTR(legacy_sectors, 0444, edd_show_legacy_sectors,
-		       edd_has_legacy_sectors);
+static EDD_DEVICE_ATTR(legacy_max_head, 0444, edd_show_legacy_max_head,
+		       edd_has_legacy_max_head);
+static EDD_DEVICE_ATTR(legacy_sectors_per_track, 0444,
+                       edd_show_legacy_sectors_per_track,
+		       edd_has_legacy_sectors_per_track);
 static EDD_DEVICE_ATTR(default_cylinders, 0444, edd_show_default_cylinders,
 		       edd_has_default_cylinders);
 static EDD_DEVICE_ATTR(default_heads, 0444, edd_show_default_heads,
@@ -602,8 +603,8 @@
 /* These attributes are conditional and only added for some devices. */
 static struct edd_attribute * edd_attrs[] = {
 	&edd_attr_legacy_cylinders,
-	&edd_attr_legacy_heads,
-	&edd_attr_legacy_sectors,
+	&edd_attr_legacy_max_head,
+	&edd_attr_legacy_sectors_per_track,
 	&edd_attr_default_cylinders,
 	&edd_attr_default_heads,
 	&edd_attr_default_sectors_per_track,
diff -u -r linux-2.6.6-orig/include/linux/edd.h linux-2.6.6/include/linux/edd.h
--- linux-2.6.6-orig/include/linux/edd.h	2004-06-02 16:12:17.000000000 -0400
+++ linux-2.6.6/include/linux/edd.h	2004-06-02 16:12:49.000000000 -0400
@@ -167,8 +167,8 @@
 	u8 version;
 	u16 interface_support;
 	u16 legacy_cylinders;
-	u8 legacy_heads;
-	u8 legacy_sectors;
+	u8 legacy_max_head;
+	u8 legacy_sectors_per_track;
 	struct edd_device_params params;
 } __attribute__ ((packed));

Re: [PATCH] Better names for EDD legacy_* fields

[Andries Brouwer]

On Wed, Jun 02, 2004 at 05:22:50PM -0400, Patrick J. LoPresti wrote:

> > > > Please, now that this is still unused, fix your names and/or
> > > > your code. Names could be legacy_max_head (etc.)
> 
> Trivial (search & replace) patch against 2.6.6 is attached.  This
> renames legacy_heads to legacy_max_head legacy_sectors to
> legacy_sectors_per_track.

Ach - I should have been more explicit instead of saying (etc.).
Also legacy_cylinders is really legacy_max_cylinder
(one less than the number of cylinders).

Andries

Re: [PATCH] Better names for EDD legacy_* fields

[Patrick J. LoPresti]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

Andries Brouwer <Andries.Brouwer@cwi.nl> writes:

> Ach - I should have been more explicit instead of saying (etc.).
> Also legacy_cylinders is really legacy_max_cylinder (one less than
> the number of cylinders).

In my defense, I barely even thought about the cylinder count.  I only
included it for completeness...  It is meaningless on drives larger
than 8G, and even on older/smaller drives, it is kind of bogus.
According to <http://www.ctyme.com/intr/rb-0621.htm>:

    The maximum cylinder number reported in CX is usually two less
    than the total cylinder count reported in the fixed disk parameter
    table (see INT 41h,INT 46h) because early hard disks used the last
    cylinder for testing purposes; however, on some Zenith machines,
    the maximum cylinder number reportedly is three less than the
    count in the fixed disk parameter table.

So it is not "one less", but often two or three...

Nevertheless, you are correct.  Revised trivial search&replace patch
attached.

 - Pat


[-- Attachment #2: rename_edd_legacy.txt --]
[-- Type: text/plain, Size: 4542 bytes --]

diff -u -r linux-2.6.6-orig/drivers/firmware/edd.c linux-2.6.6/drivers/firmware/edd.c
--- linux-2.6.6-orig/drivers/firmware/edd.c	2004-05-09 22:32:27.000000000 -0400
+++ linux-2.6.6/drivers/firmware/edd.c	2004-06-02 19:17:26.000000000 -0400
@@ -334,7 +334,7 @@
 }
 
 static ssize_t
-edd_show_legacy_cylinders(struct edd_device *edev, char *buf)
+edd_show_legacy_max_cylinder(struct edd_device *edev, char *buf)
 {
 	struct edd_info *info;
 	char *p = buf;
@@ -344,12 +344,12 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += snprintf(p, left, "0x%x\n", info->legacy_cylinders);
+	p += snprintf(p, left, "0x%x\n", info->legacy_max_cylinder);
 	return (p - buf);
 }
 
 static ssize_t
-edd_show_legacy_heads(struct edd_device *edev, char *buf)
+edd_show_legacy_max_head(struct edd_device *edev, char *buf)
 {
 	struct edd_info *info;
 	char *p = buf;
@@ -359,12 +359,12 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += snprintf(p, left, "0x%x\n", info->legacy_heads);
+	p += snprintf(p, left, "0x%x\n", info->legacy_max_head);
 	return (p - buf);
 }
 
 static ssize_t
-edd_show_legacy_sectors(struct edd_device *edev, char *buf)
+edd_show_legacy_sectors_per_track(struct edd_device *edev, char *buf)
 {
 	struct edd_info *info;
 	char *p = buf;
@@ -374,7 +374,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += snprintf(p, left, "0x%x\n", info->legacy_sectors);
+	p += snprintf(p, left, "0x%x\n", info->legacy_sectors_per_track);
 	return (p - buf);
 }
 
@@ -450,7 +450,7 @@
  */
 
 static int
-edd_has_legacy_cylinders(struct edd_device *edev)
+edd_has_legacy_max_cylinder(struct edd_device *edev)
 {
 	struct edd_info *info;
 	if (!edev)
@@ -458,11 +458,11 @@
 	info = edd_dev_get_info(edev);
 	if (!info)
 		return -EINVAL;
-	return info->legacy_cylinders > 0;
+	return info->legacy_max_cylinder > 0;
 }
 
 static int
-edd_has_legacy_heads(struct edd_device *edev)
+edd_has_legacy_max_head(struct edd_device *edev)
 {
 	struct edd_info *info;
 	if (!edev)
@@ -470,11 +470,11 @@
 	info = edd_dev_get_info(edev);
 	if (!info)
 		return -EINVAL;
-	return info->legacy_heads > 0;
+	return info->legacy_max_head > 0;
 }
 
 static int
-edd_has_legacy_sectors(struct edd_device *edev)
+edd_has_legacy_sectors_per_track(struct edd_device *edev)
 {
 	struct edd_info *info;
 	if (!edev)
@@ -482,7 +482,7 @@
 	info = edd_dev_get_info(edev);
 	if (!info)
 		return -EINVAL;
-	return info->legacy_sectors > 0;
+	return info->legacy_sectors_per_track > 0;
 }
 
 static int
@@ -569,12 +569,14 @@
 static EDD_DEVICE_ATTR(extensions, 0444, edd_show_extensions, NULL);
 static EDD_DEVICE_ATTR(info_flags, 0444, edd_show_info_flags, NULL);
 static EDD_DEVICE_ATTR(sectors, 0444, edd_show_sectors, NULL);
-static EDD_DEVICE_ATTR(legacy_cylinders, 0444, edd_show_legacy_cylinders,
-		       edd_has_legacy_cylinders);
-static EDD_DEVICE_ATTR(legacy_heads, 0444, edd_show_legacy_heads,
-		       edd_has_legacy_heads);
-static EDD_DEVICE_ATTR(legacy_sectors, 0444, edd_show_legacy_sectors,
-		       edd_has_legacy_sectors);
+static EDD_DEVICE_ATTR(legacy_max_cylinder, 0444,
+                       edd_show_legacy_max_cylinder,
+		       edd_has_legacy_max_cylinder);
+static EDD_DEVICE_ATTR(legacy_max_head, 0444, edd_show_legacy_max_head,
+		       edd_has_legacy_max_head);
+static EDD_DEVICE_ATTR(legacy_sectors_per_track, 0444,
+                       edd_show_legacy_sectors_per_track,
+		       edd_has_legacy_sectors_per_track);
 static EDD_DEVICE_ATTR(default_cylinders, 0444, edd_show_default_cylinders,
 		       edd_has_default_cylinders);
 static EDD_DEVICE_ATTR(default_heads, 0444, edd_show_default_heads,
@@ -601,9 +603,9 @@
 
 /* These attributes are conditional and only added for some devices. */
 static struct edd_attribute * edd_attrs[] = {
-	&edd_attr_legacy_cylinders,
-	&edd_attr_legacy_heads,
-	&edd_attr_legacy_sectors,
+	&edd_attr_legacy_max_cylinder,
+	&edd_attr_legacy_max_head,
+	&edd_attr_legacy_sectors_per_track,
 	&edd_attr_default_cylinders,
 	&edd_attr_default_heads,
 	&edd_attr_default_sectors_per_track,
diff -u -r linux-2.6.6-orig/include/linux/edd.h linux-2.6.6/include/linux/edd.h
--- linux-2.6.6-orig/include/linux/edd.h	2004-06-02 16:12:17.000000000 -0400
+++ linux-2.6.6/include/linux/edd.h	2004-06-02 19:16:57.000000000 -0400
@@ -166,9 +166,9 @@
 	u8 device;
 	u8 version;
 	u16 interface_support;
-	u16 legacy_cylinders;
-	u8 legacy_heads;
-	u8 legacy_sectors;
+	u16 legacy_max_cylinder;
+	u8 legacy_max_head;
+	u8 legacy_sectors_per_track;
 	struct edd_device_params params;
 } __attribute__ ((packed));

[PATCH] Use decimal instead of hex for EDD values

[Patrick J. LoPresti]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

Matt Domsch <Matt_Domsch@dell.com> writes:

> Whatever, scanf works with either representation.  Patrick, if
> you're changing the above, feel free to submit a second patch to
> switch these all to %u instead.

OK, the attached patch causes the EDD module to export numeric values
as decimal instead of hex, with two exceptions.  I left "version"
alone since 0x21 (for example) actually means version 2.1.  And I left
"mbr_signature" alone since hex seems the more natural representation
for something which is literally just a sequence of four bytes.

So this patch changes default_cylinders, default_heads,
default_sectors_per_track, legacy_max_cylinder, legacy_max_head,
legacy_sectors_per_track, and sectors to decimal.  It depends upon the
other patch I just sent (renaming the three legacy_* fields).

 - Pat


[-- Attachment #2: edd_decimal.txt --]
[-- Type: text/plain, Size: 1697 bytes --]

--- linux-2.6.6-renamed/drivers/firmware/edd.c	2004-06-02 19:17:26.000000000 -0400
+++ linux-2.6.6/drivers/firmware/edd.c	2004-06-02 19:42:25.000000000 -0400
@@ -344,7 +344,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += snprintf(p, left, "0x%x\n", info->legacy_max_cylinder);
+	p += snprintf(p, left, "%u\n", info->legacy_max_cylinder);
 	return (p - buf);
 }
 
@@ -359,7 +359,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += snprintf(p, left, "0x%x\n", info->legacy_max_head);
+	p += snprintf(p, left, "%u\n", info->legacy_max_head);
 	return (p - buf);
 }
 
@@ -374,7 +374,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += snprintf(p, left, "0x%x\n", info->legacy_sectors_per_track);
+	p += snprintf(p, left, "%u\n", info->legacy_sectors_per_track);
 	return (p - buf);
 }
 
@@ -389,7 +389,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += scnprintf(p, left, "0x%x\n", info->params.num_default_cylinders);
+	p += scnprintf(p, left, "%u\n", info->params.num_default_cylinders);
 	return (p - buf);
 }
 
@@ -404,7 +404,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += scnprintf(p, left, "0x%x\n", info->params.num_default_heads);
+	p += scnprintf(p, left, "%u\n", info->params.num_default_heads);
 	return (p - buf);
 }
 
@@ -419,7 +419,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += scnprintf(p, left, "0x%x\n", info->params.sectors_per_track);
+	p += scnprintf(p, left, "%u\n", info->params.sectors_per_track);
 	return (p - buf);
 }
 
@@ -434,7 +434,7 @@
 	if (!info || !buf)
 		return -EINVAL;
 
-	p += scnprintf(p, left, "0x%llx\n", info->params.number_of_sectors);
+	p += scnprintf(p, left, "%llu\n", info->params.number_of_sectors);
 	return (p - buf);
 }
 

Re: 2.6.x partition breakage and dual booting

[Stephen Hemminger]

On Mon, 31 May 2004 20:08:21 +0200
Tomas Szepe <szepe@pinerecords.com> wrote:

> > This is really very simple.  If you move a disk from a machine with a
> > different BIOS and you preserve the partition table geometry, you will
> > NEVER be able to install Windows on the drive.  If you partition a
> > blank drive and use the wrong geometry, you will NEVER be able to
> > install Windows on the drive.
> 
> I don't quite believe this.  AFAICT the Windows 2000/XP install program will
> succeed no matter what, the only problem is with getting the dirty thing to
> boot AFTER install has completed.  If it craps out, boot off the install
> CD to the repair console prompt, run fixboot/fixmbr and all should be swell.
> If you need dual boot, you can go ahead and reinstall lilo/grub at this point.
> The one scenario unfixable without a hex editor that I know of is installing
> Windows on a partition that was created using mkdosfs -F 32 (and even that
> will sometimes work)

Having suffered through this "Daddy, why did you break the computer?".
I can say that fixboot/fixmbr will not work. 

What did work on my machine was changing the BIOS setting on the boot disk
from "Auto" to "Large disk".  As I remember there were several possible settings
and it took trying all of them till one worked. Still not sure why it worked
though.

Re: 2.6.x partition breakage and dual booting

[Frediano Ziglio]

Il lun, 2004-05-31 alle 20:08, Tomas Szepe ha scritto:
> > This is really very simple.  If you move a disk from a machine with a
> > different BIOS and you preserve the partition table geometry, you will
> > NEVER be able to install Windows on the drive.  If you partition a
> > blank drive and use the wrong geometry, you will NEVER be able to
> > install Windows on the drive.
> 
> I don't quite believe this.  AFAICT the Windows 2000/XP install program will
> succeed no matter what, the only problem is with getting the dirty thing to
> boot AFTER install has completed.  If it craps out, boot off the install
> CD to the repair console prompt, run fixboot/fixmbr and all should be swell.
> If you need dual boot, you can go ahead and reinstall lilo/grub at this point.
> The one scenario unfixable without a hex editor that I know of is installing
> Windows on a partition that was created using mkdosfs -F 32 (and even that
> will sometimes work).

Sorry to have to post again this message, I'm new to this ML so I forgot
to CC Andries.

Actually I'm writing two patch:
 - extending EDD code to provide DPTE informations and signature for all
drives
 - modify IDE code to match BIOS disks.

Original post follows
***************************

Let me explain my point of view

I encountered the problem trying to install Fedora Core 2. Using Fedora
Core 2 and fdisk do not works (it return bad head count), so it's not
only an anaconda problem.

I analyzed 2.4.22 code and 2.6.5 code (both from Fedora kernels)
In 2.4 when an IDE drive is detected it looks in CMOS to see if a HD is
configured, then fetch BIOS data from int 41h / int 46h. If this is not
possible it try to compute heads number (the number that allow you to
access most data) (drivers/ide/ide-geometry.c). Another hint is to check
partition table (fs/partitions/msdos.c). In 2.6 this code just
disappeared...

I think it's important to know BIOS point of view. Linux provide these
information so we have two choices to solve the problem:
- correct the informations we return
- do not return anything and let user space programs do the job!

How to match Linux view with BIOS view? We have some unimplemented mode
I'll explain below (I just want to fix this problem).

Mainly the problem raise cause we have a lot of choices and different
configurations:
- SCSI. BIOS can see SCSI disks before IDE disks, see the first SCSI
disk then IDEs then others SCSIs;
- BIOS settings. Some BIOS always minimize cylinder count (maximizing
head count), others no, others allow you to select geometry (in my BIOS
I have three choices: LBA, CHS and Large)
- BIOS boot sequence. Newer BIOS let you choice what's is the first
disks. Also I tried to plug a USB disks and select as first disk but
BIOS put it always as second (even if I boot from floppy)... perhaps it
check MBR???

How to match BIOS with Linux?
There are some infos that can helps:
- if we have only a disks it's easy
- we can use dimensions (int13h/8h, int 41h/46h)
- MBR signature. I don't even know this before yesterday!!! We save only
this information for first BIOS disk (80h), we can improve saving this
information (and provide in sysfs)
- EDD 1.0. Use physical dimensions to match
- EDD 2.0. I don't understand why Linux code int 41h/46h and ignore
these informations. My BIOSes do not support EDD 3.0 but support EDD
2.0. EDD 2.0 provide informations like command port and if slave or not
(see Ralph Brown's interrupt list, int 13h/48h). If a disk is IDE we can
match _exactly_ the disk!
- EDD 3.0. Here we have disk type and path (like LUN/ID on SCSI), very
easy to match but not very widely implemented.
IMHO we should try to use these informations as best that we can.

There are also some informations in EDD that should be detected like
removable disks. It would be useful if Linux can provide a mapping
between BIOS and Linux disks to user-space programs.

I can try to code some implementation but I'm not an Linux kernel
hacker... for example I don't know if IDE is detected before SCSI
(something suggests me that there isn't an order).

freddy77

Re: 2.6.x partition breakage and dual booting

[Andries Brouwer]

On Thu, Jun 03, 2004 at 08:51:35AM +0200, Frediano Ziglio wrote:

> Actually I'm writing two patch:
>  - extending EDD code to provide DPTE informations and signature for all
> drives
>  - modify IDE code to match BIOS disks.

That second part is undesirable.
The Linux IDE code is not interested in getting a conjecture about
how other operating systems would name or number the disks.

> How to match BIOS with Linux?

It is impossible. But you can easily do a 95% job.

> I think it's important to know BIOS point of view. Linux provide these
> information so we have two choices to solve the problem:
> - correct the informations we return
> - do not return anything and let user space programs do the job!

Yes, leave it to user space. That is what we do today.

> - EDD 2.0. I don't understand why Linux code int 41h/46h and ignore
> these informations.

Long ago, long before EDD, disks actually had a geometry, and it was
necessary to find it in order to do I/O to e.g. MFM disks.
Today disk geometry is not related to the disk, but to the BIOS.
The kernel has no need to know it.

Andries

Re: 2.6.x partition breakage and dual booting

[Frediano Ziglio]

Il gio, 2004-06-03 alle 12:39, Andries Brouwer ha scritto:
> On Thu, Jun 03, 2004 at 08:51:35AM +0200, Frediano Ziglio wrote:
> 
> > Actually I'm writing two patch:
> >  - extending EDD code to provide DPTE informations and signature for all
> > drives
> >  - modify IDE code to match BIOS disks.
> 
> That second part is undesirable.
> The Linux IDE code is not interested in getting a conjecture about
> how other operating systems would name or number the disks.
> 
> > How to match BIOS with Linux?
> 
> It is impossible. But you can easily do a 95% job.
> 
> > I think it's important to know BIOS point of view. Linux provide these
> > information so we have two choices to solve the problem:
> > - correct the informations we return
> > - do not return anything and let user space programs do the job!
> 
> Yes, leave it to user space. That is what we do today.
> 

Yes and not... HDIO_GETGEO still exists and report inconsistent
informations. IMHO should be removed. I know this breaks some existing
programs however these programs do not actually works correctly.

> > - EDD 2.0. I don't understand why Linux code int 41h/46h and ignore
> > these informations.
> 
> Long ago, long before EDD, disks actually had a geometry, and it was
> necessary to find it in order to do I/O to e.g. MFM disks.
> Today disk geometry is not related to the disk, but to the BIOS.
> The kernel has no need to know it.
> 

EDD 2.0 information consists of
- base port 
- control port
- flags (slave or not)
- others (DMA, etc)
In order to be able (for user space programs) to match these
informations user space programs should be able to read at last base
port of hdX disks.

freddy77

Re: 2.6.x partition breakage and dual booting

[Bartlomiej Zolnierkiewicz]

[ please at least cc: linux-ide@ on IDE related mails ]

On Thursday 03 of June 2004 14:30, Frediano Ziglio wrote:
> Il gio, 2004-06-03 alle 12:39, Andries Brouwer ha scritto:
> > On Thu, Jun 03, 2004 at 08:51:35AM +0200, Frediano Ziglio wrote:
> > > Actually I'm writing two patch:
> > >  - extending EDD code to provide DPTE informations and signature for
> > > all drives
> > >  - modify IDE code to match BIOS disks.
> >
> > That second part is undesirable.
> > The Linux IDE code is not interested in getting a conjecture about
> > how other operating systems would name or number the disks.

Exactly.

> > > How to match BIOS with Linux?
> >
> > It is impossible. But you can easily do a 95% job.
> >
> > > I think it's important to know BIOS point of view. Linux provide these
> > > information so we have two choices to solve the problem:
> > > - correct the informations we return
> > > - do not return anything and let user space programs do the job!
> >
> > Yes, leave it to user space. That is what we do today.
>
> Yes and not... HDIO_GETGEO still exists and report inconsistent
> informations. IMHO should be removed. I know this breaks some existing
> programs however these programs do not actually works correctly.

Hm, you are right - HDIO_GETGEO returns different information in 2.4 and 2.6.

Andries, what is your opinion?

> > > - EDD 2.0. I don't understand why Linux code int 41h/46h and ignore
> > > these informations.
> >
> > Long ago, long before EDD, disks actually had a geometry, and it was
> > necessary to find it in order to do I/O to e.g. MFM disks.
> > Today disk geometry is not related to the disk, but to the BIOS.
> > The kernel has no need to know it.
>
> EDD 2.0 information consists of
> - base port
> - control port
> - flags (slave or not)
> - others (DMA, etc)
> In order to be able (for user space programs) to match these
> informations user space programs should be able to read at last base
> port of hdX disks.

You can export needed information through /proc/ide/.

Cheers,
Bartlomiej

Re: 2.6.x partition breakage and dual booting

[Andries Brouwer]

On Thu, Jun 03, 2004 at 04:35:38PM +0200, Bartlomiej Zolnierkiewicz wrote:

> > Yes and not... HDIO_GETGEO still exists and report inconsistent
> > informations. IMHO should be removed. I know this breaks some existing
> > programs however these programs do not actually works correctly.
> 
> Hm, you are right - HDIO_GETGEO returns different information in 2.4 and 2.6.
> 
> Andries, what is your opinion?

HDIO_GETGEO returns 4 fields.

There is unsigned long start; giving the starting cylinder
of a partition. It is valid, and there is some software that
uses it. It will work until the disks get larger than 2 TB
(that is, today).
And there are heads, sectors, cylinders.
This is mostly garbage. Naive use is not recommended.
Semantics in 2.0 / 2.2 / 2.4 / 2.6 all different.

> You can export needed information through /proc/ide/.

Not recommended.

Andries

Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

Frediano Ziglio <freddyz77@tin.it> writes:

> Yes and not... HDIO_GETGEO still exists and report inconsistent
> informations. IMHO should be removed. I know this breaks some
> existing programs however these programs do not actually works
> correctly.

Existing programs work fine if you do something like this first:

    echo bios_head:255 > /proc/ide/hda/settings

I know this works because it is how I convince Parted to prep a blank
drive for installing Windows.  In fact, it is the only way for me to
communicate the geometry to Parted, as far as I know.  (Other tools
usually have command-line switches or "expert" settings to control the
geometry; Parted does not.)

SCSI and RAID devices already return a suitable geometry in
HDIO_GETGEO on all of the systems that I or my users have tried.

So one approach is to leave HDIO_GETGEO alone, and to have a userspace
gadget run early to "fix" the kernel's notion of the geometry.  This
would avoid the need to rewrite every partitioning tool.

 - Pat

Re: 2.6.x partition breakage and dual booting

[Bartlomiej Zolnierkiewicz]

On Thursday 03 of June 2004 16:46, Patrick J. LoPresti wrote:
> Frediano Ziglio <freddyz77@tin.it> writes:
> > Yes and not... HDIO_GETGEO still exists and report inconsistent
> > informations. IMHO should be removed. I know this breaks some
> > existing programs however these programs do not actually works
> > correctly.
>
> Existing programs work fine if you do something like this first:
>
>     echo bios_head:255 > /proc/ide/hda/settings
>
> I know this works because it is how I convince Parted to prep a blank
> drive for installing Windows.  In fact, it is the only way for me to
> communicate the geometry to Parted, as far as I know.  (Other tools
> usually have command-line switches or "expert" settings to control the
> geometry; Parted does not.)
>
> SCSI and RAID devices already return a suitable geometry in
> HDIO_GETGEO on all of the systems that I or my users have tried.
>
> So one approach is to leave HDIO_GETGEO alone, and to have a userspace
> gadget run early to "fix" the kernel's notion of the geometry.  This
> would avoid the need to rewrite every partitioning tool.

This is a bandaid not a solution and it is just silly (you push
some values into kernel just to read them back by user-space).

Also what if kernel is compiled with CONFIG_PROC_FS=n
or if I decide to pull out /proc/ide/hdx/settings one day?

[ I'm counting days. 8) ]

Cheers,
Bartlomiej

Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> writes:

> > So one approach is to leave HDIO_GETGEO alone, and to have a
> > userspace gadget run early to "fix" the kernel's notion of the
> > geometry.  This would avoid the need to rewrite every partitioning
> > tool.
> 
> This is a bandaid not a solution and it is just silly (you push
> some values into kernel just to read them back by user-space).

It might be silly if we were designing all this from scratch.  But in
the context of current practice and current tools, it is not so
obvious, at least to me.  HDIO_GETGEO has existed forever, and it is
used by all current partitioning tools (and some non-partitioning
tools, such as dosemu).

> Also what if kernel is compiled with CONFIG_PROC_FS=n
> or if I decide to pull out /proc/ide/hdx/settings one day?

Then my code will break.  :-)

I have no theoretical objection to eliminating HDIO_GETGEO and
/proc/ide/hdx/settings.  But it would be polite to have a nice long
deprecation period because these interfaces ARE in use.  It is the
only way to use Parted for my application, for example.

 - Pat

Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

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
   http://unattended.sourceforge.net/