Re: Disk mapping confusion with the device command

[Molle Bestefich]

Phillip Susi wrote:
> Molle Bestefich wrote:
> > AFAIR, there's a nasty bug in Grub regarding the ordering of these commands.
> > Doing the above in opposite order may give you radically different results.
> >
> > I ran into the same problem when I installed on my fakeraid.
> > Considered fixing it, but then didn't :-).
>
> The bug seems to be that grub treats device (hd0) and device (hd0,4) as
> the same command.  If you try to use the hd0,4 syntax in the devices.map
> file, it throws up a syntax error, but if you issue this command
> interactively, it accepts it, but incorrectly.  If you issue the (hd0)
> command first, then the (hd0,4) one, the latter replaces the former so
> grub uses the wrong device.  If you reverse the order, then grub uses
> the (hd0) command as it should, and the (hd0,4) command is replaced.
> Because of that simply leaving out the (hd0,4) command entirely works
> just as well.
>
> It looks to me that grub only needs to be told the block device for the
> raw disk and it does all it's IO through that.  It seems that there is a
> lot of confusion though as a lot of people believe that you can/should
> tell grub about each partition block device.  This false belief is
> reinforced by the fact that grub accepts the command to map the
> partition, but interprets it as a command to map the entire disk.

Ah!  Thanks for the analysis and explanation.


> > Oh, there's a bug I actually fixed.  Easy too.
> > Problem is that HDIO_GETGEO won't work for device-mapper devices.
> >
> > My patch could use a bit of TLC, for example it would be nice if it
> > worked with CHS mode too:
> >  * modprobe edd
> >  * match the device to /sys/firmware/edd/int13_??? and find BIOS idea
> > of correct nr. of heads (instead of defaulting to 255)
> >
> > There's a couple of other nits too.
> > Doesn't seem like my fix is going to get into Grub anyway, so I
> > stopped working on it, heh.
>
> Why isn't grub using the geometry contained in the MBR?  Or guessing it
> the same way that fdisk did?  Any disk that is over what? 2 gigs, is
> going to be using fake geometry anyhow, which means 255 heads, 63
> sectors, and however many cylinders it takes to map the full length of
> the disk.

That's not correct.  BIOSs use a variety of LBA<->CHS algorithms, and
using the wrong one will cause Grub to load the wrong sectors upon
reboot, obviously.

My Compaq here fx. uses an algorithm called Bit Shifting, which with
my current disk results in 240 heads, not 255.  I've seen documented
somewhere that other BIOSs adjust their decision on the number of
heads depending on the exact size of the disk.   The motivation for
doing this is that it will give you a few extra MBs when the actual
LBA<->CHS math is done, due to rounding.

[side note]
For some reason, I've never seen a BIOS adjust the sectors/track
number.  I haven't done the math, but one could suspect that there's
no gain in adjusting the s/t number, at least when already adjusting
the head numbers?  Could probably be easily determined - find out how
many divisions are involved in the calculation, for each division
there's a rounding error which can be minimized if you fiddle with the
numbers.  (One would have to trust that all BIOS manufacturers
actually chose the equation with the least number of divisions.....)
[/side note]

The discussion is a bit moot when it comes to actually booting new
systems, however.  They all support LBA extensions to int13 anyway. 
The only thing that matters with new systems is to make sure that the
CHS numbers in MBR cause the partitions to _land on cylinder
boundaries_ - otherwise neither DOS nor Win9x/ME will boot.  I suspect
that Win2000/XP/2003 will not either, though it will take some testing
before I'm 100% sure.
[side note] Not a particular hard feature to implement, but for some
reason neither FDISK nor Partition Magic can do this.  Guess neither
tool expects that people move disks from one BIOS to another or fiddle
with BIOS settings or 'dd' from a smaller drive to a larger one.
[/side note]

I've never understood why the Grub command line interface should care
about CHS numbers.  As far as I can see, that's an implementation
detail which can safely be forgotten about until the system is
actually about to boot.  At that time, if the BIOS that the disk is
plugged into at the time does not support int13 LBA extensions, it's a
simple matter of asking the BIOS for disk geometry (also through
int13) and converting the LBA numbers embedded in the Grub boot sector
to CHS numbers, then loading the correct sectors.

Oh, wait.  I can conceive one possible use for knowing the CHS
numbers:  Making sure that none of the sectors that your kernel file
occupies lies at the very end of the disk, on one of the sectors that
is "discarded by the BIOS" due to rounding error.  In case the BIOS
only supports CHS, that would leave one with a non-bootable system.  I
suspect that currently, Grub just ignores this factor and relies on
being lucky - there's a quite good chance that the kernel file won't
land on one of those sectors.

I think the easier solution to this problem is to do the math in FDISK
- just don't allow partitions that occupy the space at the very far
end of the disk.  As far as I can see, at most 1 fake-cylinder can be
lost, so excluding 1*255*63 sectors = 7.8 MBs should do.  Seems it's
both easier to do it at FDISK time, and also you actually *do*
something about the problem, instead of just being able to tell the
user that it won't be bootable unless (s)he moves the boot files.

The above is also a Good Thing for another reason, which is that
Windows/Veritas systems might leave special metadata at end-of-disk,
outside a partition.

(FDISK should probably have a --force option to manually include the
last sectors, for the freaks out there that run Linux-only on a
LBA-int13-enabled system and are pissed about loosing 7 MB :-))...