Re: Fedora Core 2/Windows XP dual boot: selecting Linux doesn't work

On Mon, 19 Dec 2005 21:15:59 +0100, Garmt de Vries <g.devries@xxxxxxxxxx> wrote:

Enrique Perez-Terron wrote: 
I would like to have the output of "fdisk -ul", and even the output of

   echo "x
   d
   q" | fdisk /dev/hdc


Device: /dev/hdc
0x000: EB 48 90 D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C
0x010: BF 1B 06 50 57 B9 E5 01 F3 A4 CB BE BE 07 B1 04
0x020: 38 2C 7C 09 75 15 83 C6 10 E2 F5 CD 18 8B 14 8B
0x030: EE 83 C6 10 49 74 16 38 2C 74 F6 BE 10 07 03 02
0x040: FF 00 00 20 01 00 00 00 00 02 FA 80 CA 80 EA 53
0x050: 7C 00 00 31 C0 8E D8 8E D0 BC 00 20 FB A0 40 7C
0x060: 3C FF 74 02 88 C2 52 BE 79 7D E8 34 01 F6 C2 80
0x070: 74 54 B4 41 BB AA 55 CD 13 5A 52 72 49 81 FB 55
0x080: AA 75 43 A0 41 7C 84 C0 75 05 83 E1 01 74 37 66
0x090: 8B 4C 10 BE 05 7C C6 44 FF 01 66 8B 1E 44 7C C7
0x0A0: 04 10 00 C7 44 02 01 00 66 89 5C 08 C7 44 06 00
0x0B0: 70 66 31 C0 89 44 04 66 89 44 0C B4 42 CD 13 72
0x0C0: 05 BB 00 70 EB 7D B4 08 CD 13 73 0A F6 C2 80 0F
0x0D0: 84 F0 00 E9 8D 00 BE 05 7C C6 44 FF 00 66 31 C0
0x0E0: 88 F0 40 66 89 44 04 31 D2 88 CA C1 E2 02 88 E8
0x0F0: 88 F4 40 89 44 08 31 C0 88 D0 C0 E8 02 66 89 04
0x100: 66 A1 44 7C 66 31 D2 66 F7 34 88 54 0A 66 31 D2
0x110: 66 F7 74 04 88 54 0B 89 44 0C 3B 44 08 7D 3C 8A
0x120: 54 0D C0 E2 06 8A 4C 0A FE C1 08 D1 8A 6C 0C 5A
0x130: 8A 74 0B BB 00 70 8E C3 31 DB B8 01 02 CD 13 72
0x140: 2A 8C C3 8E 06 48 7C 60 1E B9 00 01 8E DB 31 F6
0x150: 31 FF FC F3 A5 1F 61 FF 26 42 7C BE 7F 7D E8 40
0x160: 00 EB 0E BE 84 7D E8 38 00 EB 06 BE 8E 7D E8 30
0x170: 00 BE 93 7D E8 2A 00 EB FE 47 52 55 42 20 00 47
0x180: 65 6F 6D 00 48 61 72 64 20 44 69 73 6B 00 52 65
0x190: 61 64 00 20 45 72 72 6F 72 00 BB 01 00 B4 0E CD
0x1A0: 10 AC 3C 00 75 F4 C3 00 00 00 00 00 00 00 00 00
0x1B0: 00 00 00 00 00 00 00 00 09 EC 06 50 00 00 80 01
0x1C0: 01 00 83 0F 3F CA 3F 00 00 00 11 1F 03 00 00 00
0x1D0: 01 CB 83 0F FF FF 50 1F 03 00 90 71 41 02 00 0F
0x1E0: FF FF 82 0F FF FF E0 90 44 02 40 FE 1B 00 00 00
0x1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA


This is a Grub boot sector, with the partition table embedded.
I see no problem with the partition table. It has no overlaps,
no gaps, and covers the entire disk, except the first track,
as usual.

However, I see here that the Cylinder/Head/Sector part of the
partition table assumes 16 heads.  Yes, now I looked in your
previous post too, fdisk -l says 16 heads in hdc. That leaves
open a possibility that the bios may actually assume 255 heads,
if the Bios is buggy and no longer supports 16 heads configurations.

Since you could not find a setting for disk geometry or lba in
the bios setup, it may be a last ditch effort to try the
--force-lba option to grub or grub-install.  It seems unlikely
to me that it would help, but I may soon be running out of ideas.

What I see in the grub stage 1 code is that force-lba makes it
issue extended int13 bios calls using lba data instead of
C/H/S data, even if the Bios returns an indication that lba
mode is not on.  I give it low probability because I find it
hard to believe that there would still be shipped Bioses that
are buggy in this respect.  However, given that the setup does
not work, *something* must be "unusual" or "not quite as expected".

I see that byte 0x40 if 0xff, and that reminds me, when you tried
to install grub in hdc - not hdc1 - did you remember to patch this
byte and make it 0x81 ?  Moving the sector into a file on hde
and letting ntloader load it from there means it is necessary to
force this byte to (hd1).

I also see that the bytes at 0x44 points at sector 1. This confirms
my expectation that in this case (grub-install hdc) stage1_5 will
be embedded there.

I will still study the other data at the start of this sector. Notice
how there are a lot of zeros in the start of the hdc1 sector,
while here there are other data.  I'm not very versed in reading
assembly, and the gas idiosyncrasies makes it a bit harder for me
to be sure that I read it right. It is not a huge amount of data, though
so it should be possible with a little patience to make sure I am reading
it right, one opcode at a time.


And the same for hdc1:

Device: /dev/hdc1
0x000: EB 48 90 00 00 00 00 00 00 00 00 00 00 00 00 00
0x010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 02
0x040: FF 00 00 80 41 B0 01 00 00 08 FA 80 CA 80 EA 53
0x050: 7C 00 00 31 C0 8E D8 8E D0 BC 00 20 FB A0 40 7C
0x060: 3C FF 74 02 88 C2 52 BE 79 7D E8 34 01 F6 C2 80
0x070: 74 54 B4 41 BB AA 55 CD 13 5A 52 72 49 81 FB 55
0x080: AA 75 43 A0 41 7C 84 C0 75 05 83 E1 01 74 37 66
0x090: 8B 4C 10 BE 05 7C C6 44 FF 01 66 8B 1E 44 7C C7
0x0A0: 04 10 00 C7 44 02 01 00 66 89 5C 08 C7 44 06 00
0x0B0: 70 66 31 C0 89 44 04 66 89 44 0C B4 42 CD 13 72
0x0C0: 05 BB 00 70 EB 7D B4 08 CD 13 73 0A F6 C2 80 0F
0x0D0: 84 F0 00 E9 8D 00 BE 05 7C C6 44 FF 00 66 31 C0
0x0E0: 88 F0 40 66 89 44 04 31 D2 88 CA C1 E2 02 88 E8
0x0F0: 88 F4 40 89 44 08 31 C0 88 D0 C0 E8 02 66 89 04
0x100: 66 A1 44 7C 66 31 D2 66 F7 34 88 54 0A 66 31 D2
0x110: 66 F7 74 04 88 54 0B 89 44 0C 3B 44 08 7D 3C 8A
0x120: 54 0D C0 E2 06 8A 4C 0A FE C1 08 D1 8A 6C 0C 5A
0x130: 8A 74 0B BB 00 70 8E C3 31 DB B8 01 02 CD 13 72
0x140: 2A 8C C3 8E 06 48 7C 60 1E B9 00 01 8E DB 31 F6
0x150: 31 FF FC F3 A5 1F 61 FF 26 42 7C BE 7F 7D E8 40
0x160: 00 EB 0E BE 84 7D E8 38 00 EB 06 BE 8E 7D E8 30
0x170: 00 BE 93 7D E8 2A 00 EB FE 47 52 55 42 20 00 47
0x180: 65 6F 6D 00 48 61 72 64 20 44 69 73 6B 00 52 65
0x190: 61 64 00 20 45 72 72 6F 72 00 BB 01 00 B4 0E CD
0x1A0: 10 AC 3C 00 75 F4 C3 00 00 00 00 00 00 00 00 00
0x1B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA


(At this point, I have also tried installing grub on the MBR, but of
course this gives the same problems as I had before.


The embedded sector address at 0x44 is you noted earlier, 0x1B041.
I forgot to ask you to check the block size when you were in
debugfs /dev/hdc1. (command show_super_stats, there is a line
"Block size:               1024"
or so. I too have a boot partition of near 100 MBytes, and I have
block size 1024. Then, doing the math, (0x1B041 - 63) * 512 / 1024
gives 55297. Look at the block numbers of stage2, 55297. Exactly
the same. Good. Further look at the blocks allocated to the
file, they are perfectly contiguous. The twelfth block is an
"indirect block" containing the block pointers to the rest of
the file, since only the first 11 block pointers fit in the
inode.  I must presume that if the grub/bios combo manages to
read the right sectors at all, it should work as for all other
systems.  There must be something preventing it from getting the
right sectors.  My pet theory is still that, on some occations
it has loaded data off sector 0x1B041 on hde, on other occasions
it has translated the number 0x1B041 into Cylinder/Head/Sector
assuming 16 heads, i.e. 1008 sectors per cylinder, and then
asked the bios to read that, and the bios/ide has translated that
back to a sector number assuming e.g., 255 heads, and so has read
a sector much higher up on the disk.

I have not yet found the time to look at what stage1_5 actually
does. I therefore don't know if there is any reason to think
the boot would work any better with grub installed in hdc's mbr.
With stage1_5 embedded in sectors 1 through 8, the number
of heads do not influence the c/h/s address, the c and h numbers
are zero both ways, but if stage1_5 is successfully loaded,
and it then uses the same buggy/incompatible bios to load stage2,
the failure should be there all the same.

Now I wonder, is it possible to set the Bios to boot directly
off hdc?  Just as an experiment, nothing should need to change
on disk, especially not on hde.  At this point I am taking
advantage of the fact that the boot sector still has 0xff in the
disk specification byte.  My theory is that it should fail
because the disk geometry is still different. I can imagine
that the bios has several sets of calls that can be used, the older
calls that only allow up to 1024 cylinders, the newer that uses
32-bit numbers (if I recall correctly) for the cylinder number,
the lba function that just uses a single 32-bit number for the
sector, and who knows, there may even be (given my ignorance) other
calls, e.g. one that closely matches the ide/ata specification.
It is therefore possible that Windows would manage to boot off
hdc if it just happens to use another interface.  It has happened
before that things have been sent out to the market with interfaces
that have been tested to work with Windows and nothing else.

In the end, you may perhaps tire of all this fruitless experimentation.
When you do, perhaps you will try to shrink your hde windows partition,
and make room for a small partition that can be used to boot Linux
from. Assuming that there is no geometry mess with that disk,
it may work better. It has officially 255 heads not?

Oh, something occurs to me:  A common software technique involves
redirecting bios calls, and it is not impossible (again, given
my ignorance) that ntloader does intercept the bios calls made by
grub, in a way that turns out to be buggy for our purposes.  In
that case, it would be quite possible that setting the bios to
boot off hdc will work.

Hey, yet another idea pops up:  The Bios is not just one monolithic
piece of code.  There is a protocol by which PCI cards and other
hardware can have pieces of a bios implementation, and these pieces
get combined in some way, with the main bios "installing" pointers
to the device-specific parts of the bios. I have never looked at
how that is done, and again that ignorance prevents me from excluding
a theory:  Could it be a buggy bios accompanying the sata hardware
(I presume it is built in on the motherboard, but that does not make
a lot of a difference.  Motherboard integrators do play Lego with
"off the shelf" components and chipsets) - intercepts a little to
much, and so imposes the 255 heads on the hdc?  The bad thing about
this theory is that I cannot see how to test/falsify it. It would
only predict that there is no way to ... Hey, there is, Grub does have
commands to force a different geometry too! put that on the list
of things to try! :)

Just a last comment: you did not have strace, but that is no longer
so interesting, since I found that Grub will say it "fails" to embed
stage1_5 as long the fs type is ext3.  The plan I had was to learn
more about what exactly failed, but that is now clear.

-Enrique
.

Relevant Pages

  • Re: RFC: disk geometry via sysfs
    ... A "lower head" than allowed would be 0xff so the BIOS wouldn't ... if there is an 0xaa55 as the last word in the sector. ... If the disk has 16 sectors and 8 heads, then the maximum value allowed for any valid address is 16 in the sector field and 7 in the heads field. ...
    (Linux-Kernel)
  • Re: 200GB IDE disk on old system
    ... the disk so biosroutines can load the kernel? ... Figures below won't work with BIOS for partitions not in cyl 1 ... BIOS sector numbering starts with sector 1 ...
    (comp.unix.bsd.freebsd.misc)
  • Re: backup drive bootabel
    ... Figures below won't work with BIOS for partitions not in cyl 1 ... BIOS sector numbering starts with sector 1 ... >> the disk is a little bit of a different size with different partition sizes. ...
    (freebsd-questions)
  • Re: Disk Boot Failure, but Hard Drive is fine.
    ... suggest you use that WD setup tool to identify that BIOS ... Windows parameters in the boot program that are not same as in CMOS. ... manual disk setting for LBA, etc - and carefully verify the cylinder, ... BIOS executes and loads Boot program from disk boot sector ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: RFC: disk geometry via sysfs
    ... A "lower head" than allowed would be 0xff so the BIOS wouldn't ... if there is an 0xaa55 as the last word in the sector. ... I'm talking about the geometry of the disk. ... in the sector field and 7 in the heads field. ...
    (Linux-Kernel)