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

On Fri, 16 Dec 2005 21:35:21 +0100, Garmt de Vries <g.devries@xxxxxxxxxx> wrote:


I copied the file stage1, and the first 512 bytes of /dev/hdc1 for
future reference,


Very good!

and ran "grub-install --debug /dev/hdc1". This was
the output:

grub> root (hd1,0)
Filesystem type is extfs, partition type 0x83
grub> setup --stage2=/boot/grub/stage2 --prefix=/grub (hd1,0)
Checking if"/grub/stage1" exists...yes
Checking if"/grub/stage2" exists...yes
Checking if"/grub/e2fs_stage1_5" exists...yes
Running "embed /grub/e2fs_stage1_5 (hd1,0)"...failed (this is not
fatal)
Running "embed /grub/e2fs_stage1_5 (hd1,0)"...failed (this is not
fatal)


Oh, I am dying to find out what that failrure could be. I will try to
read the source code.  I am a bit disappointed that Grub did not
tell what it means to "embed", where exactly it wants to put the
thing.

I suspect that it is not critical because then grub will point stage1
directly to stage2.  I don't know how that works, perhaps grub checks
that the current placement of stage2 satisfies certain constraints.

In the mean time, if you want to help us further, could you
run the command

  strace -f -o /tmp/grub.strace /sbin/grub << EOF
  root (hd1,0)
  setup --stage2=/boot/grub/stage2 --prefix=/grub (hd1,0)
  quit
  EOF

and post or mail me the output file /tmp/grub.strace ?

Running "install --stage2=/boot/grub/stage2 /grub/stage1 (hd1,0)
grub/stage2 p /grub/grub.conf "...succeeded
Done.
grub> quit

That failed embedding worries me a bit, but it's not supposed to be
fatal...
I copied the first 512 bytes of /dev/hdc1 again and rebooted to XP.

Hey, could you do "od -t x1 linuxboot.bin" ? I want the byte at
offset 0x40 into the file, that is 0100 octal. This byte is initialized
to  0xff in the stage1 file, but patched to 0x81 in your setup, to
say "we are booting from disk (hd1)."


I use WinHex for this kind of work. Very convenient, allows you to
compare files, search for stuff, etc.

Indeed, in stage1 the 0x40 byte is 0xff. In the boot record as Fedora
had created it, the 0x40 byte is 0x80. That makes sense, because it had
the idea that hdc was (hd0). In the boot record as it was created with
my modified device.map and grub.conf, the 0x40 had changed back to
0xff. That at least explains why I can't boot, but it remains to find
out why this happens.


Ah!!! That was strange! (But something had to be strange here, since it
isn't working...)

Also, the four bytes starting
at offset 0x44 should be the (little-endian) 32-bit number indicating
what sector to read off said drive. It should point suitably into
the first partition. I would expect something like 64 (0x40),
since the first partition starts in sector 63 (1-based).


In the original BR these bytes were 0x41, 0xa8, 0x01, 0x00. In the BR
created with my device.map and grub.conf they are 0x41, 0xb0, 0x01,
0x00. Not quite the 0x40 you were expecting.


I was expecting 0x40 in combination with an "embedded" stage1_5, which
I had guessed would go at the start of the partition right after the
"boot sector".  Given that the "embedding" failed, I expect the number
to point at the location of either stage1_5 or stage2 in /boot.

Now I need to judge the value 0x1b041 = 110657, or 56656384 bytes,
unlikely to be beyond any 1024-cylinder limit.  But is it the first
sector of any file in /boot/grub?

Could you try this?

  debugfs /dev/hdc1
  stat /grub/stage1
  stat /grub/e2fs_stage1_5
  stat /grub/stage2
  quit

With regard to Peter's comment

No idea. I also messed around with LILO, but without more success than
I had with grub (all I got was "LI 99 99 99 ..." on my screen). So I

But that's definitive. That is a bios error saying "I cannot boot from
there". Apparently your bios cannot boot from hdc (or at least the place on
hdc where the boot stuff is).


I would like to have the output of "fdisk -ul", and even the output of

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

The only reason I know about that an area of a disk could be unaccessible
(apart from hard errors) is the infamous cylinder 1024 limitation, but
since, 1) your computer as a SATA disk -> it must be  a recent (i.e. post
2002) computer, and should support extended int 13 Bios calls, and 2) you
are having a separate /boot partition in /hdc1, I suppose you have given
that partition the lowest-numbered sectors on the disk, then I can't
imagine the 1024-cylinder thing could be an issue.

Thinking a little more, what about some geometry weirdness?

Can you check in the Bios setup if there is a setting like "enable LBA"
for the disk? It should be enabled, then sectors are numbered consecutively
without regard to geometry; the only geometry translation should be the one
inside the disk electronics.

We could see problems if grub computes sector numbers based on file system
block numbers, which are translated to sector numbers by the kernel when
accessing the disk through Linux, while the booting grub code sends the
sector numbers through a Bios that insist on using a translation to
cylinder/head/sector numbers according to a geometry different from the
one the disk electronics uses.  Well that is just a fantasy I have, I
don't know that much about Bioses and disks.  Anyone who knows more,
please correct me.

I made a bold dash and manually changed that 0xff at offset 0x40 to
0x81. But of course, this didn't help: "GRUB Hard Disk Error".


Weird, weird.  It seems to confirm Peter's interpretation, although
we don't know what Lilo tried to do, if it tried to read the same
sectors as Grub is trying to read.  Even if we were to find that there
are geometry translation errors, should we not just get the contents
of the wrong sectors loaded, with subsequent hangs or weirdness when
the boot loader tries to run the code - rather than direct "Hard Disk
Error"?

Or, is Grub doing extended int13 calls with cylinder/head/sector
numbers that are impossible according to the Bios' notion of the disk
geometry?  Like "head 244" when there are 26 heads?

Does the Bios setup have a function to display the disk geometry?
Linux' fdisk -ul also outputs disk geometry data, are there
differences?

See above. I hope it's of some use to you! 

I find this veery interesting, I have no way to learn from such cases
without your assistance. I don't have similar hardware either.

-Enrique
.

Relevant Pages

  • Re: Fedora Core 2/Windows XP dual boot: selecting Linux doesnt work
    ... grub is installed on the /root partition, which is the first partition on hdc: hdc1, or in grub notation. ... Stage1 is the unpatched 512-byte file, that is patched and copied to the boot record during setup. ... This byte is initialized to 0xff in the stage1 file, but patched to 0x81 in your setup, to say "we are booting from disk." ...
    (comp.os.linux.setup)
  • RE: Change Tracks Per Sector on system Partition
    ... mirroring system partitions of a cluster to an offsite SAN due to differing ... We cannot physically read the file system boot sector usually at ... If your software mirror a Windows NT/2000/2003 operating system partition ... another disk that is translated as 32spt, ...
    (microsoft.public.windows.server.setup)
  • Re: master boot record
    ... is it possible to edit boot record so during boot choice the Windows Xp are on top, ... There's no such thing as a master boot record, MBR, or a boot sector, but there is a PLACE on every disk that is THE root sector (every partition has one too). ... If grub is installed it can be run to write boot code to the part of the disk root sector reserved for it. ...
    (alt.os.linux)
  • Re: Grub doesnt offer menu
    ... help to explain why Feisty doesn't boot. ... forget that GRUB uses the BIOS for disk access and if the BIOS can't see ... the partition than GRUB can't either. ...
    (uk.comp.os.linux)
  • Re: Grub doesnt offer menu
    ... help to explain why Feisty doesn't boot. ... forget that GRUB uses the BIOS for disk access and if the BIOS can't see ... the partition than GRUB can't either. ...
    (uk.comp.os.linux)