Fedora Core 2/Windows XP dual boot: selecting Linux doesn't work
g.de...@phys.uu.nl
need to do any installing etc. Now I try to set it up at home, and I've
run into a problem.
I have a new computer with Windows XP/Pro installed on it. As I would
like to have Linux available as well, and as I still had my old 19 GB
hard disk, I decided to install Fedora on the old disk, and make a dual
boot system.
Installing Fedora (FC2) worked fine, apart from a warning about the
alignment of partitions. Removing all partitions on the disk solved
that problem. Using BootPart, I created an image of the boot sector,
placed it on my Windows C: volume, and added the appropriate line to
boot.ini.
Now when I restart the computer, I get a screen where I can choose
between XP (default) and Linux. Booting XP gives no problem, but when I
choose Linux, the screen goes black for a second, and then returns to
the same "choose OS" screen. No matter how many times I try, even if I
make Linux the default choice, I always return to that same screen, and
the only way out is to boot XP.
I also tried booting from the Fedora CD in rescue mode, and using dd to
create a boot image (dd if=/dev/hdc1 of=linux.bin bs=512 count=1), but
for some reason I can't mount my floppy drive or get access to the
network, so I have no way to copy linux.bin to my Win drive...
Any suggestions on how I can make Linux boot?
Thanks in advance.
--
Garmt de Vries.
Peter T. Breuer
> Now when I restart the computer, I get a screen where I can choose
> between XP (default) and Linux. Booting XP gives no problem, but when I
> choose Linux, the screen goes black for a second, and then returns to
> the same "choose OS" screen. No matter how many times I try, even if I
Fix the boot loader config - that menu entry is pointing to the mbr
instead of to the linux kernel.
> I also tried booting from the Fedora CD in rescue mode, and using dd to
> create a boot image (dd if=/dev/hdc1 of=linux.bin bs=512 count=1), but
What for? Why are you copying the boot record of hdc1? Did you put one
there? If so, why? How are you chaining to that boot record from the
mbr on hda?
> for some reason I can't mount my floppy drive or get access to the
> network, so I have no way to copy linux.bin to my Win drive...
You can make a small fat partition somewhere and put the file there and
then copy it from windows. And you really want to load a floppy or
network driver!
Tell us about your boot loader and its config.
Peter
g.de...@phys.uu.nl
Peter T. Breuer wrote:
> g.de...@phys.uu.nl wrote:
> > Now when I restart the computer, I get a screen where I can choose
> > between XP (default) and Linux. Booting XP gives no problem, but when I
> > choose Linux, the screen goes black for a second, and then returns to
> > the same "choose OS" screen. No matter how many times I try, even if I
>
> Fix the boot loader config - that menu entry is pointing to the mbr
> instead of to the linux kernel.
I tried to fix that, but I'm not sure I did it right.
My /boot partition is on /dev/hdc1, the / partition is on /dev/hdc2.
When I run the installer, it automatically sees Linux on /dev/hdc2, and
sets it as a default. That's fine. In the "advanced options" dialog, I
set the boot loader to be installed on the first sector of the boot
partition, rather than on the MBR. But this way, I can't boot.
I added a pointer to /dev/hdc1 to the boot loader config, and set that
as default -- still no luck.
> > I also tried booting from the Fedora CD in rescue mode, and using dd to
> > create a boot image (dd if=/dev/hdc1 of=linux.bin bs=512 count=1), but
>
> What for? Why are you copying the boot record of hdc1? Did you put one
> there? If so, why? How are you chaining to that boot record from the
> mbr on hda?
I'm afraid you lost me there.
Since I'm not at all knowledgeable on these issues, I have to go with
what info I find on the web. I followed the steps outlined at
http://enterprise.linux.com/article.pl?sid=05/02/16/1919205&tid=129&tid=49
(http://tinyurl.com/5hw5g):
"The next step in the process is to save a copy of the Linux boot
partition. This can be done either with dd in Linux or with the free
Bootpart utility under Windows. Either program simply takes the first
512 bytes on the disk and puts them into a file. The dd command to do
this is dd if=/dev/hdb1 of=bootsect.lnx size=512 count=1. Once you have
this file, copy it to a diskette or some other removable media so you
can then copy it to the Windows drive for NTLDR."
As to why I copy from hdc1, that's where the /boot partition is, as far
as I can tell from using the df command.
> You can make a small fat partition somewhere and put the file there and
> then copy it from windows.
I'll try that, sounds useful.
> And you really want to load a floppy or
> network driver!
I hope I'll be able to do that once I get the thing running...
> Tell us about your boot loader and its config.
I use GRUB (the default loader on the installation CD). As I said, it's
installed on the first sector of the boot partition, hdc1, and the
entry for "Fedora Core 2" points to hdc2, where my / is.
I guess I must be doing something completely wrong, but I can't figure
out what it is.
--
Garmt de Vries.
g.de...@phys.uu.nl
Peter T. Breuer wrote:
> > I also tried booting from the Fedora CD in rescue mode, and using dd to
> > create a boot image (dd if=/dev/hdc1 of=linux.bin bs=512 count=1), but
>
> What for? Why are you copying the boot record of hdc1? Did you put one
> there? If so, why? How are you chaining to that boot record from the
> mbr on hda?
I should perhaps also explain that hdc is the old hard disk, which I
installed as second disk on my machine. The main disk is called hde.
I'm not sure why this is the case. Does it mean that hdc is really the
primary disk and hde the secondary disk? But XP doesn't complain about
anything. And what happened to hda and hdb? I'm quite puzzled...
--
Garmt de Vries.
Peter T. Breuer
> Thanks for a quick reply.
> Peter T. Breuer wrote:
>> g.de...@phys.uu.nl wrote:
>> > Now when I restart the computer, I get a screen where I can choose
>> > between XP (default) and Linux. Booting XP gives no problem, but when I
>> > choose Linux, the screen goes black for a second, and then returns to
>> > the same "choose OS" screen. No matter how many times I try, even if I
>>
>> Fix the boot loader config - that menu entry is pointing to the mbr
>> instead of to the linux kernel.
> I tried to fix that, but I'm not sure I did it right.
Better become sure!
> My /boot partition is on /dev/hdc1, the / partition is on /dev/hdc2.
Doesn't matter.
> When I run the installer,
What is an "installer"? Please fix your boot loader, whatever it is ...
> sets it as a default. That's fine. In the "advanced options" dialog, I
> set the boot loader to be installed on the first sector of the boot
> partition, rather than on the MBR. But this way, I can't boot.
I don't know what you are talking about. Please deal with the boot
loader, not with an "installer"!
> I added a pointer to /dev/hdc1 to the boot loader config, and set that
> as default -- still no luck.
I don't understand what you mean. Please be EXACT: state what is your
boot loader, what is the config file, what you have done to it (before
and after pics please), and why you think yur mds shuld be effective,
and what yu have done to embed that ew config int the MBR, or whatever
other BR is pertinent. I don't know what your boot sequence is and you
are not describing it!
>> What for? Why are you copying the boot record of hdc1? Did you put one
>> there? If so, why? How are you chaining to that boot record from the
>> mbr on hda?
> I'm afraid you lost me there.
What do you mean? Answering the questions would provide us with the
reasoning behind the (seeming random) things you are doing and thus
allow us to check the correctness.
> Since I'm not at all knowledgeable on these issues, I have to go with
> what info I find on the web. I followed the steps outlined at
> http://enterprise.linux.com/article.pl?sid=05/02/16/1919205&tid=129&tid=49
> (http://tinyurl.com/5hw5g):
> "The next step in the process is to save a copy of the Linux boot
> partition.
No no no. Boot RECORD. And you haven't made one, so you can't ""save
it"!
> As to why I copy from hdc1, that's where the /boot partition is, as far
> as I can tell from using the df command.
The /boot partition has nothing to do with anything. It has no
sigificance to you in this respect. IF you were to put a boot RECORD on
the boot partition (and you can put it anywhere you have a fancy to),
THEN you could copy it to msdos and use the win boot lader to chain to
it via boot.ini.
But why? DO you have the win boot loader in the MBR?
>> Tell us about your boot loader and its config.
> I use GRUB (the default loader on the installation CD).
Ahhhhhhh. Well, in that case it has a command line shell. When you boot
enter the shell and edit the entries. You should be able to locate the
kernel (on the boot partition) and root partition (not boot) via tab
completion.
> As I said, it's
> installed on the first sector of the boot partition, hdc1, and the
> entry for "Fedora Core 2" points to hdc2, where my / is.
Please be EXACT. Show the config. And no, it should not "point to"
hdc2 if I understand you correctly. The ROOT device should be
configured as /dev/hdc2, but there should be no indirection. Showing
us the config would allow us to say.
Peter
Peter T. Breuer
> I should perhaps also explain that hdc is the old hard disk, which I
That's the master on the secondary controller.
> installed as second disk on my machine. The main disk is called hde.
That's the master on the tertiary controller (usually fast ide).
It is possible that your bios cannot boot from the secondary
controller, but showing us the config would allow many doubts to be
resolved.
Peter
g.de...@phys.uu.nl
> g.de...@phys.uu.nl wrote:
> > When I run the installer,
>
> What is an "installer"? Please fix your boot loader, whatever it is ...
I meant the Fedora Core installation program, which I ran from the CD.
I had the idea that this installation program would install and
configure GRUB for me.
> Please be EXACT: state what is your
> boot loader, what is the config file, what you have done to it (before
> and after pics please), and why you think yur mds shuld be effective,
> and what yu have done to embed that ew config int the MBR, or whatever
> other BR is pertinent. I don't know what your boot sequence is and you
> are not describing it!
I'll give you an exact account of what I did.
* I have 4 CD's for installing Fedora Core 2. I insert the 1st one in
the CD drive, and boot from there. This takes me to a graphical
installation program.
* I choose to install Fedora on hdc, keeping hde for XP.
* I choose automatic partitioning, which gives the following result:
Device Mount point Type Size (MB)
/dev/hdc1 /boot ext3 100
/dev/hdc2 / ext3 18478
/dev/hdc3 swap 896
* I choose to have GRUB installed on hdc1 (the first sector of the boot
partition). The other option is to have it installed on the MBR, but I
don't want to mess with my XP installation.
* The default OS to be booted by GRUB is "Fedora Core" on hdc2. The
other OS is "Other" on hde1.
* I choose to install a minimum of components, and let the installation
program do its work.
* I then have to reboot. I boot from the CD again, and go to linux
rescue mode.
* When I give the command df, I see that, as I expected, /boot
corresponds to /dev/hdc1 and / corresponds to /dev/hdc2. I found
vmlinuz-2.6.5-1.358 and initrd-2.6.5-1.358.img in /boot.
* In /boot/grub/, the config file grub.conf looks as follows:
# (some comments)
# boot=/dev/hdc
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.6.5-1.358)
root(hd0,0)
kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
initrd /initrd-2.6.5-1.358.img
title Other
rootnoverify(hd1,0)
chainloader +1
* I don't touch grub.conf, or any other files created during the
installation of Fedora.
* I restart my computer, and go to XP.
> IF you were to put a boot RECORD on the boot partition (and you can put it
> anywhere you have a fancy to), THEN you could copy it to msdos and use the win
> boot lader to chain to it via boot.ini.
> But why? DO you have the win boot loader in the MBR?
Yes, I have. I chose not to touch the MBR, so this will still contain
the Windows boot loader, whichever it may be. This means I have to tell
that boot loader about Fedora and/or GRUB, right?
>From what I understand, I can do this with the program BootPart. This
copies the first 512 bytes of the /boot partition to a file, say
C:\linux.bin, and adds a line to boot.ini:
C:\linux.bin="Linux"
I checked boot.ini with a text editor, and it looks good.
Is this the same as creating a boot record? If not, how do I create
one? Or don't I need one at all? I have the idea that on the Linux side
everything is fine, but that my problem lies in getting GRUB to fire
up. But I have no clue where to go from here.
Thanks for your patience, I hope the info I've provided now is
sufficient.
--
Garmt de Vries.
Eric Moors
> I'll give you an exact account of what I did.
>
> * I have 4 CD's for installing Fedora Core 2. I insert the 1st one in
> the CD drive, and boot from there. This takes me to a graphical
> installation program.
>
> * I choose to install Fedora on hdc, keeping hde for XP.
>
> * I choose automatic partitioning, which gives the following result:
> Device Mount point Type Size (MB)
> /dev/hdc1 /boot ext3 100
> /dev/hdc2 / ext3 18478
> /dev/hdc3 swap 896
>
> * I choose to have GRUB installed on hdc1 (the first sector of the boot
> partition). The other option is to have it installed on the MBR, but I
> don't want to mess with my XP installation.
>
Your grub.conf looks like this you say:
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.6.5-1.358)
root(hd0,0)
kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
initrd /initrd-2.6.5-1.358.img
title Other
rootnoverify(hd1,0)
chainloader +1
I am not sure this is correct, but it most likely depends on your BIOS
settings. I suspect that hdc is hd1 whereas hde is hd0.
Try changing them.
If that doesn't help, try the alternative way: booting from hdc.
You can probably select this is in the BIOS. It does however require
that a bootloader is present in the MBR of hdc.
You can then boot XP through grub, which is far easier.
Or even easier: use lilo instead of grub.
Eric
PS. er is ook een groep nl.comp.os.linux.installatie, dat is misschien
handiger
g.de...@phys.uu.nl
> Your grub.conf looks like this you say:
>
> default=0
> timeout=10
> splashimage=(hd0,0)/grub/splash.xpm.gz
> title Fedora Core (2.6.5-1.358)
> root(hd0,0)
> kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
> initrd /initrd-2.6.5-1.358.img
> title Other
> rootnoverify(hd1,0)
> chainloader +1
>
>
> I am not sure this is correct, but it most likely depends on your BIOS
> settings. I suspect that hdc is hd1 whereas hde is hd0.
> Try changing them.
Yes, it's odd that the hard disk I installed later should be hdc/hd0.
But I checked in device.map, and there it says hd0 is hdc, and hd1 is
hde. I still tried to change them, but to no avail (as expected).
I wonder if I should change the cables that attach the two disks to the
motherboard?
> If that doesn't help, try the alternative way: booting from hdc.
> You can probably select this is in the BIOS. It does however require
> that a bootloader is present in the MBR of hdc.
>
> You can then boot XP through grub, which is far easier.
Yes, that's an option. I tried to mess as little as possible with the
Win disk, but I may have to give up.
> PS. er is ook een groep nl.comp.os.linux.installatie, dat is misschien
> handiger
Ik zal er eens gaan kijken, bedankt.
--
Garmt de Vries.
Peter T. Breuer
> Eric Moors wrote:
>> Your grub.conf looks like this you say:
>>
>> default=0
>> timeout=10
>> splashimage=(hd0,0)/grub/splash.xpm.gz
>> title Fedora Core (2.6.5-1.358)
>> root(hd0,0)
>> kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
>> initrd /initrd-2.6.5-1.358.img
>> title Other
>> rootnoverify(hd1,0)
>> chainloader +1
>>
>>
>> I am not sure this is correct, but it most likely depends on your BIOS
>> settings. I suspect that hdc is hd1 whereas hde is hd0.
He is correct (I thought I posted all this earlier, but the goblins
must have eaten it).
>> Try changing them.
> Yes, it's odd that the hard disk I installed later should be hdc/hd0.
It's false - hd0 is your boot device. Look in your bios and tell us
which your boot device is. I suspect you have got them the wrong way
round.
> But I checked in device.map, and there it says hd0 is hdc, and hd1 is
> hde. I still tried to change them, but to no avail (as expected).
Try harder. (Don't say "try", tell us what you DID). I would imagine
that hd0 is hde from your symptoms, so you need to install grub again.
Editing a file will do nothing.
> I wonder if I should change the cables that attach the two disks to the
> motherboard?
Stop wondering. The answer is "don' be daf', mon". If you have your bios
set to boot from hde, then that is hd0 to grub, I believe. And you WANT
to boot from hde, don't you? You WANT the windows bootloader tobe
first.
Peter
g.de...@phys.uu.nl
> g.de...@phys.uu.nl wrote:
> > Yes, it's odd that the hard disk I installed later should be hdc/hd0.
>
> It's false - hd0 is your boot device. Look in your bios and tell us
> which your boot device is. I suspect you have got them the wrong way
> round.
The boot devices are:
1: floppy drive
2: Maxtor 6L080M0
3: CD-ROM
This Maxtor 6L080M0 is an SCSI Disk Device, under Sata RAID Controller.
The other hard disk is a Maxtor 92040U6, at the secondary IDE Channel.
> If you have your bios
> set to boot from hde, then that is hd0 to grub, I believe. And you WANT
> to boot from hde, don't you? You WANT the windows bootloader tobe
> first.
The 92040U6 is hdc and the 6L080M0 is hde, right? In that case, yes, I
want to boot from hde.
> > But I checked in device.map, and there it says hd0 is hdc, and hd1 is
> > hde. I still tried to change them, but to no avail (as expected).
>
> Try harder. (Don't say "try", tell us what you DID). I would imagine
> that hd0 is hde from your symptoms, so you need to install grub again.
> Editing a file will do nothing.
In grub.conf, I changed every occurrence of "hd0" to "hd1" and vice
versa. But if the mapping is still wrong in device.map, that won't be
of much help, I guess.
If I change device.map to
(hd0) /dev/hde
(hd1) /dev/hdc
and then change grub.conf to
title Fedora Core (2.6.5-1.358)
root(hd1,0)
kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
initrd /initrd-2.6.5-1.358.img
title Other
rootnoverify(hd0,0)
chainloader +1
will that be enough? Will these settings be used the next time I try to
boot?
I'm glad you put up with my stupid questions...
--
Garmt de Vries.
Peter T. Breuer
>> > Yes, it's odd that the hard disk I installed later should be hdc/hd0.
>>
>> It's false - hd0 is your boot device. Look in your bios and tell us
>> which your boot device is. I suspect you have got them the wrong way
>> round.
> The boot devices are:
> 1: floppy drive
> 2: Maxtor 6L080M0
> 3: CD-ROM
> This Maxtor 6L080M0 is an SCSI Disk Device, under Sata RAID Controller.
Eh? What? Is it scsi or isn't it? SATA is serial-ATA, which is not
scsi!
You'll have to make a bit more sense for me there, I'm afraid.
I'm going to work on the supposition that that is IDE, not scsi, and
that the "raid" is some software raid which doesn't exist at the
moment (only one disk anyway). So that is your hde?
Anyway, it'll be hd0, for the little I know of grub's weird
numbering system.
All I can see in the grub info file is:
Note that GRUB does _not_ distinguish IDE from SCSI - it simply counts
the drive numbers from zero, regardless of their type. Normally, any
IDE drive number is less than any SCSI drive number, although that is
not true if you change the boot sequence by swapping IDE and SCSI
drives in your BIOS.
Which seems to me to confirm my impression that they count in bios bot
order.
Why don't you check the info out?
Then you can send a LART for this:
That was easy, admit it. Do read the next chapter, to find out how to
actually install GRUB on your drive.
No - it was incredibly unclear, like all the grub documentation. Rumor
has that it is written originally in dutch by a blind monkey.
> The other hard disk is a Maxtor 92040U6, at the secondary IDE Channel.
That is your hdc? I suppose that would be hd1 to grub.
>> If you have your bios
>> set to boot from hde, then that is hd0 to grub, I believe. And you WANT
>> to boot from hde, don't you? You WANT the windows bootloader tobe
>> first.
> The 92040U6 is hdc and the 6L080M0 is hde, right? In that case, yes, I
> want to boot from hde.
So that's the way yu have your bios set? Then hde is hd0.
>> Try harder. (Don't say "try", tell us what you DID). I would imagine
>> that hd0 is hde from your symptoms, so you need to install grub again.
>> Editing a file will do nothing.
> In grub.conf, I changed every occurrence of "hd0" to "hd1" and vice
> versa. But if the mapping is still wrong in device.map, that won't be
I don't know what "device.map" is. I've never heard of it. Oh - it's
some grub thing. yes, now THERE you can see what the mapping is! DON'T
CHANGE IT.
> of much help, I guess.
> If I change device.map to
> (hd0) /dev/hde
> (hd1) /dev/hdc
DON'T. Why, in heavens name, why? What's wrong with the mapping you
had? You only have to TELL us about it!
Well, anyway, I suppose this changes things to match the probable
facts. But you will have to tell grub to use that mapping file. Why
bother?
> and then change grub.conf to
> title Fedora Core (2.6.5-1.358)
> root(hd1,0)
This points at grub's boot code area on hdc1. I've forgotten
where you said everything was. This should be pointing at the /boot
partition. Does it?
> kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
PLEASE DO NOT USE LABELS! Be specifc. Say "root=/dev/hdc2" (or
whatever).
> initrd /initrd-2.6.5-1.358.img
And please do not use ramdisks. Why? Oh why. Is your kernel so
crippled?
> will that be enough? Will these settings be used the next time I try to
> boot?
No. You have done nothing to make it so! Install grub on a boot record,
copy that boot record to windows, and point windows boot.ini at the
copy.
Peter
g.de...@phys.uu.nl
> g.de...@phys.uu.nl wrote:
>
> > This Maxtor 6L080M0 is an SCSI Disk Device, under Sata RAID Controller.
>
> Eh? What? Is it scsi or isn't it? SATA is serial-ATA, which is not
> scsi!
This is what I saw in the device manager under XP. I must confess I
don't know what exactly SATA and SCSI are.
> I'm going to work on the supposition that that is IDE, not scsi, and
> that the "raid" is some software raid which doesn't exist at the
> moment (only one disk anyway). So that is your hde?
Apparently. I have, as you suggested, made a FAT partition on that
disk, which I could successfully access from Linux (mount /dev/hde5
/foo, and then at /foo I could see all the files on that partition).
> Anyway, it'll be hd0, for the little I know of grub's weird
> numbering system.
OK, hd0 it is.
> No - it was incredibly unclear, like all the grub documentation. Rumor
> has that it is written originally in dutch by a blind monkey.
Well, in that case it should be easy for me to read. I'm Dutch (but not
a blind monkey).
> > The other hard disk is a Maxtor 92040U6, at the secondary IDE Channel.
>
> That is your hdc? I suppose that would be hd1 to grub.
That makes sense.
> > In grub.conf, I changed every occurrence of "hd0" to "hd1" and vice
> > versa. But if the mapping is still wrong in device.map, that won't be
>
> I don't know what "device.map" is. I've never heard of it. Oh - it's
> some grub thing. yes, now THERE you can see what the mapping is! DON'T
> CHANGE IT.
From
http://www.gnu.org/software/grub/manual/html_node/Device-map.html#Device-map:
"If the device map file exists, the grub shell reads it to map BIOS
drives to OS devices. This file consists of lines like this:
device file
The reason why the grub shell gives you the device map file is that it
cannot guess the map between BIOS drives and OS devices correctly in
some environments. For example, if you exchange the boot sequence
between IDE and SCSI in your BIOS, it gets the order wrong.
Thus, edit the file if the grub shell makes a mistake."
> > If I change device.map to
> > (hd0) /dev/hde
> > (hd1) /dev/hdc
>
> DON'T. Why, in heavens name, why?
Because from your earlier post, I deduced that hd0 should be hde, and
not hdc, as it said in that file. And the grub docs say that you have
to edit the file if grub makes a mistake in guessing the mapping.
> Well, anyway, I suppose this changes things to match the probable
> facts. But you will have to tell grub to use that mapping file. Why
> bother?
>From the info I quoted, I seemed to understand that grub always reads
that file if it exists.
> > and then change grub.conf to
> > title Fedora Core (2.6.5-1.358)
> > root(hd1,0)
>
> This points at grub's boot code area on hdc1. I've forgotten
> where you said everything was. This should be pointing at the /boot
> partition. Does it?
The /boot partition is at hdc1. But as things are now, hd1 is not hdc,
but hde.
> > kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
>
> PLEASE DO NOT USE LABELS! Be specifc. Say "root=/dev/hdc2" (or
> whatever).
>
> > initrd /initrd-2.6.5-1.358.img
>
> And please do not use ramdisks. Why? Oh why. Is your kernel so
> crippled?
I installed it from the Fedora Core 2 CDs. Would you care to explain
how I can avoid the .img?
> > will that be enough? Will these settings be used the next time I try to
> > boot?
>
> No. You have done nothing to make it so! Install grub on a boot record,
> copy that boot record to windows, and point windows boot.ini at the
> copy.
I have grub installed at /root/grub (/root being the first partition of
hdc), and done
dd if=/dev/hdc1 of=linux.boot bs=512 count=1
Then I copied linux.boot to C:\ and added
C:\linux.boot="Linux"
to boot.ini.
The question is, after changing grub.conf, do I need to reinstall grub,
or will a reinstall remove all my changes?
--
Garmt de Vries.
Peter T. Breuer
> From
> http://www.gnu.org/software/grub/manual/html_node/Device-map.html#Device-map:
> "If the device map file exists, the grub shell reads it to map BIOS
> drives to OS devices. This file consists of lines like this:
> device file
Yes - but you're too late. Your whole grub BR needs to be reinstalled,
becaue you are changing the definition of where the parts of itself
(that will eventually read that config file) are to be found.
So please don't! Not without reinstalling a grub BR anyway!
>> > If I change device.map to
>> > (hd0) /dev/hde
>> > (hd1) /dev/hdc
>>
>> DON'T. Why, in heavens name, why?
> Because from your earlier post, I deduced that hd0 should be hde,
It IS.
> and
> not hdc, as it said in that file. And the grub docs say that you have
> to edit the file if grub makes a mistake in guessing the mapping.
But not NOW. BEFORE you install a grub BR.
>>From the info I quoted, I seemed to understand that grub always reads
> that file if it exists.
Sure - and how exactly do you propose it is going to FIND that file?
Peter
imotgm
> The question is, after changing grub.conf, do I need to reinstall grub,
> or will a reinstall remove all my changes?
At this stage, If your BIOS lets you choose which device to boot from, why
not just install grub to the MBR of /dev/hdc, and point the BIOS at it? Or
if you can't change the boot device, use the method you are using, and
chainload from boot.ini to a "C:\linux.boot" derived from a "dd" of the
/dev/hdc MBR.
--
imotgm
"Lost? Lost? I've never been lost... Been a tad confused for a
month or two, but never lost."
Enrique Perez-Terron
> No - it was incredibly unclear, like all the grub documentation. Rumor
> has that it is written originally in dutch by a blind monkey.
It was written originally in Japanese but with English words.
True! :)
-Enrique
Enrique Perez-Terron
Oh, yes sir! It has to change.
> From
> http://www.gnu.org/software/grub/manual/html_node/Device-map.html#Device-map:
>
> "If the device map file exists, the grub shell reads it to map BIOS
> drives to OS devices. This file consists of lines like this:
> device file
> The reason why the grub shell gives you the device map file is that it
> cannot guess the map between BIOS drives and OS devices correctly in
> some environments. For example, if you exchange the boot sequence
> between IDE and SCSI in your BIOS, it gets the order wrong.
> Thus, edit the file if the grub shell makes a mistake."
Exactly. Grub was tripped up because it could not know about the
bios boot setting. It guessed correctly the order that the bios
would have numbered the disks, in the absense of a boot setup.
>
>> > If I change device.map to
>> > (hd0) /dev/hde
>> > (hd1) /dev/hdc
>>
>> DON'T. Why, in heavens name, why?
>
> Because from your earlier post, I deduced that hd0 should be hde, and
> not hdc, as it said in that file. And the grub docs say that you have
> to edit the file if grub makes a mistake in guessing the mapping.
>
>> Well, anyway, I suppose this changes things to match the probable
>> facts. But you will have to tell grub to use that mapping file. Why
>> bother?
>
>> From the info I quoted, I seemed to understand that grub always reads
> that file if it exists.
>
>> > and then change grub.conf to
>> > title Fedora Core (2.6.5-1.358)
>> > root(hd1,0)
>>
>> This points at grub's boot code area on hdc1. I've forgotten
>> where you said everything was. This should be pointing at the /boot
>> partition. Does it?
>
> The /boot partition is at hdc1. But as things are now, hd1 is not hdc,
> but hde.
>
There are *two* grubs. One runs under Linux, and is used to setup
a boot record, and one runs under the bios during the boot.
The grub.conf file is read by the latter, so it needs (hd1,0) to
access the first partition. The "root" directive in grub.conf
is used to specify the partition that will hold the files named
in the "kernel" and "initrd" commands.
>> > kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
>>
>> PLEASE DO NOT USE LABELS! Be specifc. Say "root=/dev/hdc2" (or
>> whatever).
>>
oh, it's not that bad... But actually, I too prefer that people
use specific devices, so I don't have to ask them to use some
commands to list the labels of all partitions in order to figure
out what is going on. Yes, /dev/hdc2 must be right, according
to what you said earlier.
>> > initrd /initrd-2.6.5-1.358.img
>>
>> And please do not use ramdisks. Why? Oh why. Is your kernel so
>> crippled?
>
> I installed it from the Fedora Core 2 CDs. Would you care to explain
> how I can avoid the .img?
>
Hehe. In a year or two perhaps you will say: Oh, today I feel
like making my own kernel with just the right stuff in it.
Then you can make a kernel that doesn't need an init-ramdisk
to hold the modules required to access an ext3 file system
(or whatever it is that Fedora leaves out of the kernel...)
But for now, I suggest you just let this initrd command sit
where it sits. Among other things, it mounts a /dev ramfs
for you. Peter surely prefers to have /dev in a regular disk
directory, not, Peter? Hm, thinking about it, I would not
be too surprised if it actually could work to drop the initrd...
>> > will that be enough? Will these settings be used the next time I try to
>> > boot?
>>
>> No. You have done nothing to make it so! Install grub on a boot record,
>> copy that boot record to windows, and point windows boot.ini at the
>> copy.
>
> I have grub installed at /root/grub (/root being the first partition of
> hdc), and done
> dd if=/dev/hdc1 of=linux.boot bs=512 count=1
> Then I copied linux.boot to C:\ and added
> C:\linux.boot="Linux"
> to boot.ini.
>
> The question is, after changing grub.conf, do I need to reinstall grub,
> or will a reinstall remove all my changes?
No.
But your *original* setup of grub got hosed because the devices.map
file was wrong. Once the devices.map is right, just run the command
grub-install /dev/hdc1
This is a shell script that will run the *former* "grub" (remember the
two grubs, right?) - the one that runs under Linux, and is used to
setup the boot sector. It figures out most messy details, very
conveniently, except that it does not know how to reboot and hit
the F2 or F10 or whatever it is on your computer, to enter the
Bios setup and check the boot device order.
Then boot back into XP and run, what was it, BootPart? get that
boot sector from the start of /dev/hdc1 (how is it called in
that BootPart program?) into the file you specified in boot.ini.
C:\Linux.bin, was it?
-Enrique
Oh, yes, tell us if it works, I recently heard of this technique,
with the boot sector copied to a file and specified in boot.ini,
but I have not tried it myself. Mm, just in case, do not confuse
the sector at the start of /dev/hdc and the sector at the start
of /dev/hdc1. Both places can hold a Grub boot sector, you
specify which in "grub-install /dev/hdc1". I just don't know
how clever the BootPart is. :)
g.de...@phys.uu.nl
> >> I don't know what "device.map" is. I've never heard of it. Oh - it's
> >> some grub thing. yes, now THERE you can see what the mapping is! DON'T
> >> CHANGE IT.
>
> Oh, yes sir! It has to change.
[snip]
> But your *original* setup of grub got hosed because the devices.map
> file was wrong. Once the devices.map is right, just run the command
>
> grub-install /dev/hdc1
Thanks. To recap:
* The HD with Windows on it is definitely hde, since I can access the
FAT partition on that disk at /dev/hde6.
* The HD with Linux on it is definitely hdc, as I can see with mount or
df.
* The BIOS boots from the Win HD.
* As grub numbers HDs in boot order, the Win HD is (hd0) and the Linux
HD is (hd1).
* Hence, (hd0) should be hde, and (hd1) should be hdc.
* The original installation of grub, as performed by anaconda, the
Fedora Core installer, gets it wrong. In the device.map file created by
anaconda, (hd0) is mapped to hdc, and (hd1) is mapped to hde.
* As per the grub documentation, as well as your post, I changed
device.map:
(fd0) /dev/fd0
(hd0) /dev/hde
(hd1) /dev/hdc
* grub is installed on the /root partition, which is the first
partition on hdc: hdc1, or (hd1,0) in grub notation.
* I make sure that in grub.conf, I use the correct references. Also, I
get rid of the LABEL:
title Fedora Core
root (hd1,0)
kernel /vmlinuz-2.6.5-1.358 ro root=/dev/hdc2
initrd /initrd-2.6.5-1.358.img
title Windows XP
rootnoverify (hd0,0)
chainloader +1
* I run "grub-install /dev/hdc1".
* I copy the boot record to a file: "dd if=/dev/hdc1 of=linuxboot.bin
bs=512 count=1".
* I boot to XP, put this linuxboot.bin on C: and add the line
"C:\linuxboot.bin="Linux" to boot.ini.
Now when I boot the machine, and choose "Linux", I get a black screen
with the word "GRUB" in the upper left corner, followed by a blinking
cursor. Nothing else happens...
> Then boot back into XP and run, what was it, BootPart? get that
> boot sector from the start of /dev/hdc1 (how is it called in
> that BootPart program?) into the file you specified in boot.ini.
> C:\Linux.bin, was it?
Now that I have a FAT partition on my Win HD, I don't need BootPart
anymore. In BootPart, I used to give the command "bootpart", which
lists all the partitions, giving each an ID, after which I'd say
"bootpart 0 C:\linuxboot.bit "Linux"" (if 0 was the ID of the /boot
partition).
> Oh, yes, tell us if it works, I recently heard of this technique,
> with the boot sector copied to a file and specified in boot.ini,
> but I have not tried it myself.
No luck so far...
> Mm, just in case, do not confuse
> the sector at the start of /dev/hdc and the sector at the start
> of /dev/hdc1. Both places can hold a Grub boot sector, you
> specify which in "grub-install /dev/hdc1".
I got that right. There must be something else that's wrong.
--
Garmt de Vries.
g.de...@phys.uu.nl
>
> At this stage, If your BIOS lets you choose which device to boot from, why
> not just install grub to the MBR of /dev/hdc, and point the BIOS at it?
To install grub on the MBR, can I just do "grub-install /dev/hdc"? Will
it end up in the MBR this way?
> Or
> if you can't change the boot device, use the method you are using, and
> chainload from boot.ini to a "C:\linux.boot" derived from a "dd" of the
> /dev/hdc MBR.
No, I can't change the boot device, so I'd have to take the boot.ini
road. But that shouldn't be a problem, should it?
--
Garmt de Vries.
Eric Moors
>> file was wrong. Once the devices.map is right, just run the command
>>
>> grub-install /dev/hdc1
>
> Thanks. To recap:
>
> * The HD with Windows on it is definitely hde, since I can access the
> FAT partition on that disk at /dev/hde6.
> * The HD with Linux on it is definitely hdc, as I can see with mount or
> df.
> * The BIOS boots from the Win HD.
> * As grub numbers HDs in boot order, the Win HD is (hd0) and the Linux
> HD is (hd1).
> * Hence, (hd0) should be hde, and (hd1) should be hdc.
> * The original installation of grub, as performed by anaconda, the
> Fedora Core installer, gets it wrong. In the device.map file created by
> anaconda, (hd0) is mapped to hdc, and (hd1) is mapped to hde.
> * As per the grub documentation, as well as your post, I changed
> device.map:
> (fd0) /dev/fd0
> (hd0) /dev/hde
> (hd1) /dev/hdc
> * grub is installed on the /root partition, which is the first
> partition on hdc: hdc1, or (hd1,0) in grub notation.
I suppose you mean /boot instead of /root here.
But this might be where it goes wrong
> * I make sure that in grub.conf, I use the correct references. Also, I
> get rid of the LABEL:
> title Fedora Core
> root (hd1,0)
> kernel /vmlinuz-2.6.5-1.358 ro root=/dev/hdc2
> initrd /initrd-2.6.5-1.358.img
> title Windows XP
> rootnoverify (hd0,0)
> chainloader +1
> * I run "grub-install /dev/hdc1".
AFAICT from the grub-install documentation this should put the proper files
on your /boot partition. Could you check that the grub loaders are updated
properly ( probably /boot/grub/* )
> * I copy the boot record to a file: "dd if=/dev/hdc1 of=linuxboot.bin
> bs=512 count=1".
> * I boot to XP, put this linuxboot.bin on C: and add the line
> "C:\linuxboot.bin="Linux" to boot.ini.
>
> Now when I boot the machine, and choose "Linux", I get a black screen
> with the word "GRUB" in the upper left corner, followed by a blinking
> cursor. Nothing else happens...
Great. And this is exactly why I still prefer lilo.
It either complains during install or it just works :-)
Eric
Garmt de Vries
> > * grub is installed on the /root partition, which is the first
> > partition on hdc: hdc1, or (hd1,0) in grub notation.
>
> I suppose you mean /boot instead of /root here.
Of course. That was a typo, sorry.
> > * I run "grub-install /dev/hdc1".
>
> AFAICT from the grub-install documentation this should put the proper files
> on your /boot partition. Could you check that the grub loaders are updated
> properly ( probably /boot/grub/* )
All those stage1, stage2 etc. files in /boot/grub/ are
rewritten/updated when I run grub-install. At least, their
last-modified time changes.
> > Now when I boot the machine, and choose "Linux", I get a black screen
> > with the word "GRUB" in the upper left corner, followed by a blinking
> > cursor. Nothing else happens...
>
> Great. And this is exactly why I still prefer lilo.
> It either complains during install or it just works :-)
I guess I'll have a look at it. If it works, than I'll be glad to
switch to lilo.
--
Garmt de Vries.
Enrique Perez-Terron
> device.map:
> (fd0) /dev/fd0
> (hd0) /dev/hde
> (hd1) /dev/hdc
> * grub is installed on the /root partition, which is the first
> partition on hdc: hdc1, or (hd1,0) in grub notation.
> * I make sure that in grub.conf, I use the correct references. Also, I
> get rid of the LABEL:
> title Fedora Core
> root (hd1,0)
> kernel /vmlinuz-2.6.5-1.358 ro root=/dev/hdc2
> initrd /initrd-2.6.5-1.358.img
> title Windows XP
> rootnoverify (hd0,0)
> chainloader +1
> * I run "grub-install /dev/hdc1".
> * I copy the boot record to a file: "dd if=/dev/hdc1 of=linuxboot.bin
> bs=512 count=1".
> * I boot to XP, put this linuxboot.bin on C: and add the line
> "C:\linuxboot.bin="Linux" to boot.ini.
This all looks perfect to me.
> Now when I boot the machine, and choose "Linux", I get a black screen
> with the word "GRUB" in the upper left corner, followed by a blinking
> cursor. Nothing else happens...
Ouuuch. :(
Putting out the string "GRUB " is about the first thing that stage1 does.
Stage1 is the unpatched 512-byte file, that is patched and copied to
the boot record during setup.
This seems to show that NTLOADER is doing the right thing, it is
loading the file and running its contents. I would believe it loads
it the into the right place in memory too. What could it be that went
wrong??
The next thing stage1 does is to load a sector from a disk number and
address that has been patched into it. This should be the start of
stage1_5 (or stage2 if stage1_5 is not used). How to find out that,
short off...
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)." 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).
When running grub-install there is a --debug setting, which should
give fairly complete account of what it does. I have not used it
much myself, so I don't know exactly how usefull the information is.
I hope you find the time to try it, and post the final part of the
output, so we could all have a chance to learn. After all, you
don't reinstall grub in new configurations every day.
---
I saw the comment about Lilo "just works". I haven't used lilo for
many years, so others should tell, but I just don't know how lilo
achieves to load from a disk without knowing in advance which. Could
it be that it "just works" in the simple cases, where no "surprising"
disk enumerations occur? I positively know that lilo too needs to
patch the boot sector it installs with disk addresses of sectors to
load, and I suppose it needs to patch the drive to read from too.
Lilo too depends on Bios calls to do the reading, so it needs to know
if it should pass "0x80" in register dl, or 0xd81, etc. "0x80"
invariably is the drive that has been designated as boot drive in the
bios setup. The standard Microsoft MBR depends on that, so that is
nailed. Traditionally it used to be the primary master, as there
used to be no setting in the Bios setup for this. If there is no
primary master installed, the first disk found was used. The search
order used to deend on how the partial Bioses on additional disk
controllers are chained together and with the main Bios. The main
Bios searches the primary master, primary slave, secondary master,
secondary slave. Since we got boot drive designations in the bios
setup, the designated disk is taken out of this order and placed
first. Lilo and Grub cannot find out this, at least not in any way
I know about.
I believe having seen a Phoenix Bios specification saying that
the dl register should contain the boot drive when the boot code
is started, but the standard MS boot code discards that and loads
the "active flag" from the partition table into register dl. The
active flag is usually specified as 0x80.
In the present case, you _are_ booting from drive 0x80, but chaining
into something on 0x81. The NTLOADER does not know that, since it is
told to use a file, not a partition.
The more I think about it the more I suspect there is some kind of
operator error involved here, like using a different name when
saving the linuxboot.bin file the second time, and not adjusting
the boot.ini correspondingly. Oh, there have been some use
cases on my own computers that I have not been able to resolve,
so I am not 100% knowledgeable. (But I know more now than I did
then :)
-Enrique
-Enrique
Garmt de Vries
> This seems to show that NTLOADER is doing the right thing, it is
> loading the file and running its contents. I would believe it loads
> it the into the right place in memory too. What could it be that went
> wrong??
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
decided to do a completely fresh install.
At the beginning of the installation, I get (and previously got every
time) the following warning:
"Unable to align partitions probably. This probably means that another
partitioning tool generated an incorrect partition table, because it
dodn't have the correct BIOS geometry. It is safe to ignore, but
ignoring may cause (fixable) problems with some boot loaders."
I opted to remove all partitions and format the entire disk, so I
hardly believe this warning has anything to do with the problem, but I
thought I'd mention it, just in case it means something to you.
I repeated the steps I described earlier. As I did before, I had the
Fedora CD install the boot loader in /dev/hdc1. As before, I had to
change device.map and grub.conf, because grub had got hd0 and hd1 mixed
up.
I copied the file stage1, and the first 512 bytes of /dev/hdc1 for
future reference, 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)
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.
> 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 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".
> I hope you find the time to try it, and post the final part of the
> output, so we could all have a chance to learn. After all, you
> don't reinstall grub in new configurations every day.
See above. I hope it's of some use to you!
--
Garmt de Vries.
Peter T. Breuer
> Enrique Perez-Terron wrote:
>> This seems to show that NTLOADER is doing the right thing, it is
>> loading the file and running its contents. I would believe it loads
>> it the into the right place in memory too. What could it be that went
>> wrong??
> 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).
Put the boot stuff somewhere else.
Peter
Enrique Perez-Terron
> 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
Enrique Perez-Terron
> Running "embed /grub/e2fs_stage1_5 (hd1,0)"...failed (this is not fatal)
I have done some reading of the source, and it turns out that
grub does not implement an "embed" function for ext2/ext3 file
systems. It appears that only a few file systems have such
a function: Reiserfs, Jfs, and Ufs2. It may mean that only
file systems that presend certain particular difficulties
have this.
I have also seen in the code how it decides to leave the disk
number as 0xff. It says that if you are doing the setup on
the same disk where the grub files reside, leave it at 0xff.
The idea seems to be that if the earlier steps of the load
procedure have arrived at the point where the boot sector is
loaded into memory from disk X, then the code for disk X is
already in register dl, and there is no need to change it.
However, for what we are doing, this is wrong, because
we copy the boot sector to hde, and ntloader loads it from
there, and starts it. At that point, register dl probably
has the value 0x80, corresponding to (hd0).
We see in the output from install-grub that the setup command
executes the command
> Running "install --stage2=/boot/grub/stage2 /grub/stage1 (hd1,0) grub/stage2 p /grub/grub.conf "...succeeded
> Done.
> grub> quit
It is possible to run the "install" command directly, in stead of through
the setup command. Or so it seems from the code, but it may be only a
partial truth, because the program uses a lot of global variables and
it takes a lot of reading to make sure no preliminary commands are required
before issuing the "install" command.
To issue an install command that sets the disk number, a "d" has to be
inserted after "/grub/stage1", before "(hd1,0)".
I will read more code to see what else I can discover.
I have also some thoughts: It may be easier to install into the
MBR of hdc, instead of hdc1. In that case, there is an embed-function
that is independent of file system. With the stage1_5 installed there
the process may get one step further before errors happen. Hard to say
if stage1_5, once loaded, will perform better, since we don't know what
the problem really is. I mean, you tried to patch the disk number, and
it did not work, and we don't know why not.
Next: If the problem is diverging disk geometry settings in the Bios
and under Linux, it may work to do a "native" setup. That means
getting to run Grub natively. Is there a floppy drive in the computer?
If so, do
cd /boot/grub
cat stage1 stage2 > /dev/fd0
and boot from that floppy. If there is no floppy, I am not sure how
to achieve that easily. Perhaps it is not hard to create a "Grub CD";
I have never looked at the details of that.
If you manage to have a Grub prompt from a grub that runs "natively" or
"standalone" - not under a Linux kernel - then "find /grub/grub.conf"
should respond "(hd1,0)" - meaning it has been able to read the
directories and inodes, compute the sector numbers from the block
addresses and have the Bios load the right sectors in order to read the
/grub directory and locate the name "grub.conf". You could follow up
with "root (hd1,0)" and "cat /grub/grub.conf" to verify further. If
this works OK, then "setup (hd1,0)" should do it. Or "setup (hd1)"
if at this point you prefer the hdc's MBR.
If you do all this, it would be usefull to learn even more about what
Grub sees under these circumstances. Grub has a row of commands
that are poorly or not documented, but appear in the source.
"debug" toggles the setting of a "debug" global variable. There are
a couple of "printf" statements that depend on that variable.
"geometry (hd1)" should output the geometry setting that Grub is
aware of. It can be used both in the Linux version and the standalone
version of the program. When running under Linux, this command can
also be used to set Grub's notion of the geometry:
"geometry (hd1) X Y Z", where X=number of cylinders, Y=number of heads,
and Z=number of sectors per track. This may permit the setup to
work correctly even when running under Linux, if only you know the
correct values. (Assuming that the geometry is the problem.)
The correct values may possibly be found in the Bios setup.
-Enrique
Peter T. Breuer
> I have also seen in the code how it decides to leave the disk
> number as 0xff. It says that if you are doing the setup on
> the same disk where the grub files reside, leave it at 0xff.
> The idea seems to be that if the earlier steps of the load
> procedure have arrived at the point where the boot sector is
> loaded into memory from disk X, then the code for disk X is
> already in register dl, and there is no need to change it.
> However, for what we are doing, this is wrong, because
> we copy the boot sector to hde, and ntloader loads it from
> there, and starts it. At that point, register dl probably
> has the value 0x80, corresponding to (hd0).
Ahhhhhhhhhh. He wants to save the boot sector to another disk, then,
during the grub install, or force grub to embed the disk number.
grub doesn't seem to have thought that somebdy might want to copy its
BR somewhere else - it's not got completely absolute code in. Maybe
there's more!
Anyway, at this point I am convinced that he wants to use a lilo loader
for simplicity as a target for win.ini! (maybe chaining to a grub one,
but still).
Peter
Garmt de Vries
> 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
strace: command not found :(
> 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
Inode: 11814 Type: regular Mode: 0644 Flags: 0x0 Generation:
3614209032
User: 0 Group: 0 Size: 512
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 2
BLOCKS:
(0): 54785
TOTAL: 1
> stat /grub/e2fs_stage1_5
Inode: 11816 Generation: 3614209034
Size: 7616
Blockcount: 16
BLOCKS:
(0-7): 55809-55816
TOTAL: 8
> stat /grub/stage2
Inode: 11815 Generation: 3614209033
Size: 101800
Blockcount: 202
BLOCKS:
(0-11): 55297-55308, (IND): 55309, (12-99): 55310-55397
TOTAL: 101
So... no 110657 there.
> I would like to have the output of "fdisk -ul",
[...Info on /dev/hde...]
Disk /dev/hdc: 20.4 GB
16 heads, 63 sectors/head, 39566 cylinders, total 39882528 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hdc1 * 63 204623 102280+ 83 Linux
/dev/hdc2 204624 38047967 18921672 83 Linux
/dev/hdc3 38047968 39882527 917280 82 Linux swap
> and even the output of
>
> echo "x
> d
> q" | fdisk /dev/hdc
Here I get a warning that the number of cylinders for this disk is set
to 39566, which is OK, but could in certain setups cause problems with
software running at boot time (e.g. old versions of LILO) or
booting/partitioning software from other OSs. Followed by a bunch of
hexadecimals, showing the contents of the disk. I'll see if I can
somehow copy-paste this.
> 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.
Yes, I bought this computer only last month. Should be fine, I guess.
> Does the Bios setup have a function to display the disk geometry?
> Linux' fdisk -ul also outputs disk geometry data, are there
> differences?
Hmmm... I can't find anything about the geometry in the Bios setup.
Perhaps I should look harder. I'll let you know if anything pops up.
--
Garmt de Vries.
Garmt de Vries
> I have also some thoughts: It may be easier to install into the
> MBR of hdc, instead of hdc1. In that case, there is an embed-function
> that is independent of file system. With the stage1_5 installed there
> the process may get one step further before errors happen.
Good idea. I'll try.
> If you manage to have a Grub prompt from a grub that runs "natively" or
> "standalone" - not under a Linux kernel - then "find /grub/grub.conf"
> should respond "(hd1,0)" - meaning it has been able to read the
> directories and inodes, compute the sector numbers from the block
> addresses and have the Bios load the right sectors in order to read the
> /grub directory and locate the name "grub.conf". You could follow up
> with "root (hd1,0)" and "cat /grub/grub.conf" to verify further. If
> this works OK, then "setup (hd1,0)" should do it. Or "setup (hd1)"
> if at this point you prefer the hdc's MBR.
I'll try that as well.
> "geometry (hd1)" should output the geometry setting that Grub is
> aware of.
grub> geometry (hd1)
drive 0x81: C/H/S=158816/16/63
number of sectors=160086528, /dev/hde
Partition number: 0, Filesystem type unknown, partition type 0x7
Partition number: 4, Filesystem type unknown, partition type 0x7
Partition number: 5, Filesystem type is fat, partition type 0xb
grub> geometry (hd0)
drive 0x80: C/H/S=39566/16/63
number of sectors=39882528, /dev/hdc
Partition number: 0, Filesystem type is ext2fs, partition type 0x83
Partition number: 1, Filesystem type is ext2fs, partition type 0x83
Partition number: 2, Filesystem type unknown, partition type 0x82
Apparently, at this point grub thinks that (hd1) is hde and (hd0) is
hdc. So it doesn't use device.map in this case?
> "geometry (hd1) X Y Z", where X=number of cylinders, Y=number of heads,
> and Z=number of sectors per track. This may permit the setup to
> work correctly even when running under Linux, if only you know the
> correct values. (Assuming that the geometry is the problem.)
> The correct values may possibly be found in the Bios setup.
I'd be grateful for a tip on how to find it...
--
Garmt de Vries.
Garmt de Vries
> Anyway, at this point I am convinced that he wants to use a lilo loader
> for simplicity as a target for win.ini! (maybe chaining to a grub one,
> but still).
Although it feels like giving up, I may indeed switch to lilo if I
can't get grub to work. But my first (admittedly rather quick) try with
lilo didn't work either, so I'll keep both options open until one gives
me the desired result.
--
Garmt de Vries.
Eric Moors
I can't help you with grub, but if lilo is still an option I
might be able to help you.
Could you show the lilo.conf you used?
Eric
Garmt de Vries
> 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
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.
--
Garmt de Vries.
Enrique Perez-Terron
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.
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