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 :-))... _______________________________________________ Bug-grub mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-grub
