PDA

View Full Version : Grub wont boot from bootsect.lnx



electroconvulsi
28th October 2006, 02:20 PM
Im having a problem with getting grub to boot on a second disk from (hdb1) from a windows bootloader on the first disk (hda1). Ive tried to load the bootsect file using both methods (1. using the dd command in linux & 2. Using bootpart.exe in Windows) I have previously acheived this on another pc without any worries except having to hit the any key an extra time to make it boot. On this machine when I hit the key the second time I get NON SYSTEM DISK error or using the dd command i just get a flashing cursor on the screen after choosing the linux boot from the windows bootloader. I have tried it several times now and am a little lost as to why my FC6 install wont boot using this method even though it will boot if I tell the system BIOS to boot from the disk with Fedora on it.

Anyone have any ideas? I always appreciate help given on this forum.

Cheers.

Firewing1
31st October 2006, 02:34 PM
If you can boot up a rescue disk, use
grub-install /dev/hda
To install grub to the MBR, and from there you should be able to chainload to XP's bootsector :)
Firewing1

electroconvulsi
1st November 2006, 07:28 AM
Thanks for responding, Firewing, but I would rather use the Windows bootloader to boot FC6. I have done this before on another PC with XP and FC5 using bootpart and waqs so proud of my acheivment that I recommended it to other users. I was looking into whether there was some hardware setting I missed or something has to be done with GRUB so it will load from the bootsect.lnx file instead of me having to go into the BIOS and changing the boot order. Loading Windows from GRUB is not an option as it can turn out to be a bit of a nightmare and in the end I will have to repair my XP installation and Reinstall GRUB to HDB.

Firewing1
1st November 2006, 11:14 PM
Then do

grub-install /dev/hdx#
where hdx# is your Linux partition.
Firewing1

electroconvulsi
26th November 2006, 04:26 PM
Maybe someone who wrote this OS can explain this to me. For some reason even after a fresh install grub does not sit on the first 512 bytes of the drive like it has in every other linux distro. Why is this? and how do I get my OS to boot from the windows bootloader. No other option is acceptable so please dont bother responding unless you are going to help with the solution I want. Also dont bother responding unless you have taken the time to read my original post on this thread in full.

Firewing1
26th November 2006, 05:16 PM
It does, just depends which 'first 512 bytes'. If you install to the MBR, then it's the first 512 of the entire disk. If you install to a partition's boot sector, then it's the first 512 of that partition.
Firewing1

kldixon
27th November 2006, 10:45 AM
Have you checked the sector you dd'd from hdb to confirm that it does contain the stage1 loader? When I installed FC6 I could not find an option in anaconda to choose the disk on which to write the stage1 loader, if loading it on the MBR. I ended up overwriting the MBR of hda, which contained a FC5 installation. If you wrote the stage1 loader to the first sector of the /boot partition (assuming you created a separate /boot partition), which is the safer option, the boot sector may be in the first block of the /boot file system which may be offset one track in from the start of the partition containing it. You can use df and sfdisk to find it.

electroconvulsi
29th November 2006, 04:03 PM
Ok I run both of those commands and here are the results. Take note i used the -n switch with the sfdisk command as not to actually write anything to the disk. I hope this info can help you work it out. Firstly I had /dev/hda disconnected when I installed FC6 on /dev/hdb so the boot partition would write to /hdb. If the bootloader is offset what command do i enter to make a sucessful bootsect.lnx file

# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
35740376 17668596 16226944 53% /
/dev/hdb1 101086 15774 80093 17% /boot
tmpfs 517452 0 517452 0% /dev/shm
/dev/hda5 102398276 50724364 51673912 50% /mnt/storage

]# sfdisk /dev/hdb -n

Disk /dev/hdb: 77545 cylinders, 16 heads, 63 sectors/track
Old situation:
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 77545/16/63).
For this listing I'll assume that geometry.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/hdb1 * 0+ 12 13- 104391 83 Linux
/dev/hdb2 13 4864 4852 38973690 8e Linux LVM
/dev/hdb3 0 - 0 0 0 Empty
/dev/hdb4 0 - 0 0 0 Empty
Input in the following format; absent fields get a default value.
<start> <size> <type [E,S,L,X,hex]> <bootable [-,*]> <c,h,s> <c,h,s>
Usually you only need to specify <start> and <size> (and perhaps <type>).

I didnt carry this command any further as I didnt know what it would actually do so Im hoping you can help me on that one as well.

kldixon
29th November 2006, 07:09 PM
I am afraid I never use this LogVol thing but it shouldn't matter. BTW if you use "code, /code " (put the tags in [] brackets) tags around terminal output it makes it easier to read. You can also use the # in the message tool menu to insert code tags. Hit Edit in the top right hand corner of your post to edit it.

OK, you have a /boot filesystem on partition hdb1. You can view the full linked list of partition tables on a disk with the following command:-

/sbin/sfdisk -l -uS -x /dev/hdb

That should show us where the /boot filesystem actually starts.

kldixon
29th November 2006, 07:41 PM
Did your procedure of disconnecting the other drive work when you had success with FC5? I am just thinking that anaconda, or the gub installer, may have interpreted the fact that there was only one disk at the time to create a stage1 loader that points to the first disk, which is now your XP disk...

I have just looked at your first post again and see that FC6 does boot if you tell the BIOS to boot from the second drive. That implies that there is a valid stage1 loader in the MBR. You say you used the same technique on another machine with FC5. I presume there were two disks in that case too? I can see there being a problem if some context information about the current disk is passed to the loader. If the BIOS passes that information then everything works but if the XP chain loader passes the information the context will be the XP disk.

What is in your /boot/grub/grub.conf? Is it refering to root (hd0,0) or root (hd1,0). Since the first disk was not present at installation time I would guess you have root (hd0,0) when you actually need root (hd1,0), but then I am not sure how the BIOS route works.

Could you post /boot/grub/grub.conf and /boot/grub/device.map. (inside code tags)

Could you also post the contents of mbrb.hex after doing:-

od -A x -t x1 bootsect.lnx > mbrb.hex
assuming that bootsect.lnx contains the MBR you dd'd from the disk

electroconvulsi
30th November 2006, 01:06 PM
Ok thanks for the advice on the code tags I will use them in future.
The output of the command /sbin/sfdisk -l -uS -x /dev/hdb is:
Device Boot Start End #sectors Id System
/dev/hdb1 * 63 208844 208782 83 Linux
/dev/hdb2 208845 78156224 77947380 8e Linux LVM
/dev/hdb3 0 - 0 0 Empty
/dev/hdb4 0 - 0 0 Empty
The output of od -A x -t x1 bootsect.lnx > mbrb.hex is:
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
000200
And here is the output of /boot/grub/grub.conf
#boot=/dev/hdb
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.18-1.2849.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2849.fc6 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
Is there something wrong with the dd command? Should there be any different syntax there? By the looks of the hex file there is nothing sitting on those first few bytes.
Here is the syntax for the dd command I used: dd if=/dev/hdb1 of=bootsect.lnx bs=512 count=1 It is the command I got from a few different threads outside of Fedora Forums
Anyway I hope this info helps.

kldixon
30th November 2006, 02:36 PM
Well... the asterisk means the file is 512 zeros, which is pretty whacky because there should also be the primary partition table in there. The reason is, you used /dev/hdb1. That is the /boot partition. For the MBR you need:-


dd if=/dev/hdb of=bootsect.lnx bs=512 count=1

Just for interest, the output from sfdisk indicates tha the /boot filesystem starts at sector 63. That is where the stage1 loader would have been written if you had chosen the non-MBR option at installation. That is generally the safer option when dual booting windows and linux and essential if the OS's are on the same disk, (well you could save the MBR before installing linux and reinstate the original after capturing the linux MBR, but that is more work).
What about /boot/grub/device.map?

P.S.

code tags?????

electroconvulsi
30th November 2006, 04:07 PM
Thanks Ill try it. About the code tags I didnt think the code blocks were big enough to actually use them but I get the picture about using them for all code and will from now on. Cheers

So I tried it and now I get just get the word grub on my screen with a flashing cursor. Thanks for your help and it is good that things are progressing. Anymore thoughts on this will be graetly appreciated.

kldixon
30th November 2006, 04:29 PM
You are up late/early...

kldixon
30th November 2006, 04:32 PM
A hex dump of the new file would be useful too.

electroconvulsi
30th November 2006, 04:38 PM
Here is the hex dump of the new file:


000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00
000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75
000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 03 02
000040 80 00 00 80 41 58 00 00 00 08 fa 90 90 f6 c2 80
000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc
000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 be 7f 7d
000070 e8 34 01 f6 c2 80 74 54 b4 41 bb aa 55 cd 13 5a
000080 52 72 49 81 fb 55 aa 75 43 a0 41 7c 84 c0 75 05
000090 83 e1 01 74 37 66 8b 4c 10 be 05 7c c6 44 ff 01
0000a0 66 8b 1e 44 7c c7 04 10 00 c7 44 02 01 00 66 89
0000b0 5c 08 c7 44 06 00 70 66 31 c0 89 44 04 66 89 44
0000c0 0c b4 42 cd 13 72 05 bb 00 70 eb 7d b4 08 cd 13
0000d0 73 0a f6 c2 80 0f 84 ea 00 e9 8d 00 be 05 7c c6
0000e0 44 ff 00 66 31 c0 88 f0 40 66 89 44 04 31 d2 88
0000f0 ca c1 e2 02 88 e8 88 f4 40 89 44 08 31 c0 88 d0
000100 c0 e8 02 66 89 04 66 a1 44 7c 66 31 d2 66 f7 34
000110 88 54 0a 66 31 d2 66 f7 74 04 88 54 0b 89 44 0c
000120 3b 44 08 7d 3c 8a 54 0d c0 e2 06 8a 4c 0a fe c1
000130 08 d1 8a 6c 0c 5a 8a 74 0b bb 00 70 8e c3 31 db
000140 b8 01 02 cd 13 72 2a 8c c3 8e 06 48 7c 60 1e b9
000150 00 01 8e db 31 f6 31 ff fc f3 a5 1f 61 ff 26 42
000160 7c be 85 7d e8 40 00 eb 0e be 8a 7d e8 38 00 eb
000170 06 be 94 7d e8 30 00 be 99 7d e8 2a 00 eb fe 47
000180 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 44
000190 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 00
0001a0 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 00 00 00
0001b0 00 00 00 00 00 00 00 00 37 98 00 00 00 00 80 01
0001c0 01 00 83 fe 3f 0c 3f 00 00 00 8e 2f 03 00 00 00
0001d0 01 0d 8e fe ff ff cd 2f 03 00 f4 61 a5 04 00 00
0001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
000200

I hop it helps

kldixon
30th November 2006, 04:46 PM
Yes, byte 0x40 is 0x80, that means that it is looking for the linux installation in the first disk, which is your windows installation...

electroconvulsi
30th November 2006, 04:50 PM
So does that mean I should diconnect my Windows drive and run the dd command again?

kldixon
30th November 2006, 05:02 PM
What you need to do is generate a new stage1 loader. That byte needs to be 0x81. There are tools to do this but I have not done it before so things are going to get interesting. I will have to read the docs and get back to you. If you want to experiment, you could try swapping the discs around physically so that linux is the first disk and windows the second and change the BIOS settings to boot from the second disk.

electroconvulsi
1st December 2006, 03:54 AM
What you need to do is generate a new stage1 loader. That byte needs to be 0x81. There are tools to do this but I have not done it before so things are going to get interesting. I will have to read the docs and get back to you. If you want to experiment, you could try swapping the discs around physically so that linux is the first disk and windows the second and change the BIOS settings to boot from the second disk.

Wont that change the drive mappings between /dev/hda and /dev/hdb?

kldixon
1st December 2006, 04:55 PM
OK I have found out how to get a stage1 loader pointing to a specific disk, but first of all, can I ask you to change a couple of things so that I have a better idea of what you will be seeing on the screen.

First, edit /boot/grub/grub.conf, you will have to be root, so open a terminal and do:-


su
gedit&
exit

that will get you an editor with root priviledges.

There will be lines near the start like:-


splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu

change them to:-


#splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu

Now edit the file /etc/sysconfig/init and change the line:-


GRAPHICAL=yes

to:-


GRAPHICAL=no

Post the results for grub.conf so I can check it.
Can you also post /boot/grub/device.map?

The changes will mean that you can see what linux is doing as it boots. If you prefer it the way it was, you can easily reverse the edits.

electroconvulsi
2nd December 2006, 06:37 AM
Ok I have modified both /boot/grub/grub.conf and /etc/sysconfig/init as you asked. Just a note though I usually use nano to mess around with config files unless nano is denied access or the file is massive and I have to find code on it. I usually log into the root user as soon as I open the terminal using the command

su - This makes me root in the terminal. If there is another reason you want me to do things differently please tell me.

This is the output of /boot/grub/device.map

# this device map was generated by anaconda
(hd0) /dev/hdb

This is the output of grub.conf

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/hdb
default=0
timeout=5
#splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title Fedora Core (2.6.18-1.2849.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2849.fc6 ro root=/dev/VolGroup00/LogVol00 rhgb qui$
initrd /initrd-2.6.18-1.2849.fc6.img
title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00 rhgb qui$
initrd /initrd-2.6.18-1.2798.fc6.img
Again thanks for your help I thought this issue was going to remain unresolved but there is always someone out there willing to help. If you are ever in Sydney Australia Ill buy you a beer.

PS I havent tried swapping the drives around Ive been to busy with customers jobs.

kldixon
2nd December 2006, 12:10 PM
I am an xemacs man myself. It is just that gedit is the default gnome editor which most people know. I usually keep my user path when root as that can save you from some mistakes. Root's path gives you access to lots of dangerous things.

Don't bother swapping the drives around now. We want them just as they have been for the following.

Can you add a line to /boot/grub/device.map so it looks like


# this device map was generated by anaconda
(hd0) /dev/hdb
(hd1) /dev/hda

Then add a few lines to grub.conf so it looks like:-


# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/hdb
default=0
timeout=5
#splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title Fedora Core (2.6.18-1.2849.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2849.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2849.fc6.img

title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2798.fc6.img

title Windows
rootnoverify (hd1)
chainloader +1

You do not have to remove the rhgb quiet from the end of the kernel lines but that is just another way to stop the graphical boot screen.
The additional lines, together with the additional line in /boot/grub/device.map, should allow you to boot windows from grub.
To stop the 5 second timeout, hit the down arrow key immediately you see the Grub menu screen, with the above items on it, during boot and select the last entry using the arrow keys, hit return and windows 'should' boot. If it does not, I have just been reading a few posts which imply that the XP loader is likely to be in the first partition rather than the MBR so you could try changing the last menu item in grub.conf to:-


title Windows
rootnoverify (hd1,0)
chainloader +1

If it still doesn't work, could you post the parttition table using:-

/sbin/sfdisk -l -uS -x /dev/hda

If all goes well, then we can get on with booting linux from windows.

kldixon
2nd December 2006, 04:29 PM
You use the grub installation itself to generate a boot loader.

First, though, if you are sufficiently paranoid then backup your windows drive.
There is a small possibility that you will overwrite a sector on the wrong drive. Do not disconect the drive or the linux drive will become the first drive again. That is what caused the problem in the first place. You could replace it though, if you have another drive with stuff on it you are not interested in.

Reboot (into linux).

Hit the down arrow key when you see the grub page to stop the timeout.

type 'c' to get a grub command-line.

Find the root devices where the boot loader images are:-


grub> find /grub/stage1
(hd0,0)

If you do not get (hd0,0) then stop and post what you do get. To get back to the grub menu, hit the Esc key then select one of the items and hit return to boot linux or windows.
BTW, the root device in this context has nothing to do with the Linux root device. This is the Grub root device which is, generally, the /boot partition.
If all is as expected then set the root device where the images can be found:-


grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83

Again, if you get anything different, stop and post.
Now, the next step is the dangerous one. Install the stage1 loader in the boot sector of the /boot partition. The 'd' is the magic parameter which should make the 0x40 byte into 0x81. The question in my mind is whether the fact that the disk ordering is reversed will confuse grub. hd0 is the second disk, from the BIOS's point of view, and hd1 is the first. Type:-


grub> install /grub/stage1 d (hd0,0) /grub/stage2

Hit the Esc key, select the first menu item and hit return to boot linux.

Get a copy of the stage1 loader, it should be at sector 63 of hdb:-


$ su
# dd if=/dev/hdb of=bootsect.lnx bs=512 skip=63 count=1
# exit
$

You can do a hex dump and check that the 0x40 byte is 0x81 then you can try using the file. This image will not have a partition table at the end nor the BIOS parameter block near the begining. I do not know if this matters but I don't think it does. I have tried this on my machine, which has two disks, with no ill effects but my grub device mapping is the right way around and I have FC5 on the first disk and FC6 on the second.
If it does not work, try repeating the grub session above but using the following as the last 'dangerous' command:-


grub> install /grub/stage1 d (hd0,0) /grub/e2fs_stage1_5

If it still does not work, I have a few more ideas, so come back and post.

electroconvulsi
4th December 2006, 05:47 PM
Thanks dude I will get around to trying it soon but ive been busy fixing other peoples windows problems for money and I feel like such a w#0%e and I will get back to it as soon as possible.

electroconvulsi
5th December 2006, 04:12 PM
I tried the chainloader with both edits to /etc/grub.conf and it didn't work either way.


The edit that used
title Windows
rootnoverify (hd1, 0)
chainloader +1returned an error message saying there was an unrecognised device string.

But anyway here is the output of the partition table.

Disk /dev/hda: 19457 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/hda1 * 63 107780084 107780022 7 HPFS/NTFS
/dev/hda2 107780085 312576704 204796620 f W95 Ext'd (LBA)
start: (c,h,s) expected (1023,254,63) found (1023,0,1)
/dev/hda3 0 - 0 0 Empty
/dev/hda4 0 - 0 0 Empty

/dev/hda5 107780148 312576704 204796557 7 HPFS/NTFS
start: (c,h,s) expected (1023,254,63) found (1023,1,1)
- 107780085 107780084 0 0 Empty
- 107780085 107780084 0 0 Empty
- 107780085 107780084 0 0 EmptyAnd yeah ive got plenty of spare hard drives hanging around for when I get to the next stage of this.

Cheers

kldixon
5th December 2006, 05:38 PM
I think grub does not like the space in (hd1, 0). Try changing it to (hd1,0). Sorry, that was my mistake. I am going to edit the earlier post in case it confuses anyone else.

electroconvulsi
6th December 2006, 03:13 AM
I tried using the corrected syntax and the bootloader stopped at

booting 'Windows'
rootnoverify (hd1,0)
chainloader +1

joewp
6th December 2006, 06:38 AM
I tried using the corrected syntax and the bootloader stopped at

booting 'Windows'
rootnoverify (hd1,0)
chainloader +1

I don't know if this will help, but I just worked through a booting problem myself, and found something strange about grub. To illustrate, here's my device.map:


# this device map was generated by anaconda
(hd0) /dev/hda
(hd1) /dev/hdb


Looks fine, right? All normal. Windows in on hda and FC6 is on hdb, along with grub.

Now, if I point my bios to boot disk 0 (hda), I get Windows/XP booting. I've looked and there's definately a MS MBR on that disk. And if I point my bios to boot hdb, where grub and linux are, I boot to the FC6 pretty splash screen, and can choose two FC6 kernel or Windows/XP, and everything works fine.

Now for the strange part.... Here's my grub.conf:


# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd2,0)
# kernel /boot/vmlinuz-version ro root=/dev/hdb1
# initrd /boot/initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.18-1.2849.fc6)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-1.2849.fc6 ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.18-1.2849.fc6.img
title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-1.2798.fc6 ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.18-1.2798.fc6.img
title Windoze
rootnoverify (hd1,0)
chainloader +1


Please notice that in spite of what the device.map says, the only way, after many tries using Super Grub Disk, this was the only way I could get grub to work. Please note a few things here. The /dev/hda in the comments is a lie. FC6 rests on hdb, partion one to be exact. Somehow the FC6 installer thought it was on hda. Why I don't know. But look at the rest of the file. The grub device notations are reversed from the physical arrangement of my disks. Also, note that "root (hd2,0)" in the anaconda generated comments? That's where the linux root parameters were originally pointing from the installation! That was with the bios pointing to hda for booting.

I guess because I'm pointing my bios to hdb for booting, grub thinks it's hd0 and windows is on hd1 even though in reality they're just the opposite. Once I've booted up to FC6 though, fdisk -l shows:



Disk /dev/hda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 14592 117210208+ 7 HPFS/NTFS

Disk /dev/hdb: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 * 1 7636 61336138+ 83 Linux
/dev/hdb2 7650 24792 137701147+ 7 HPFS/NTFS
/dev/hdb3 7637 7649 104422+ 82 Linux swap / Solaris

Partition table entries are not in disk order

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 14593 117218241 42 SFS


One other thing: For some strange reason I can't make the hda1 partition active in Windows disk manager. It's just greyed out, even though it has ntloader ntdetect.com and boot.ini on it. But yet when I point my bios to boot from it, it boots quite happily!

Strange, isn't it? I thought this interesting thing might help when I saw electroconvulsi talk about his linux on hdb.

kldixon
6th December 2006, 08:59 AM
joewp has a good point. I think it is an issue of which way round the BIOS thinks the disks are and which way round GRUB thinks the disks are. They are both faking it and getting thoroughly confused. It is time to deploy the map swapping trick try:-


title Windows
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd1,0)
chainloader +1

I am going to have my breakfast now so, back in a couple of hours.

nick.stumpos
6th December 2006, 09:09 AM
Ok thanks for the advice on the code tags I will use them in future.
The output of the command /sbin/sfdisk -l -uS -x /dev/hdb is:
Device Boot Start End #sectors Id System
/dev/hdb1 * 63 208844 208782 83 Linux
/dev/hdb2 208845 78156224 77947380 8e Linux LVM
/dev/hdb3 0 - 0 0 Empty
/dev/hdb4 0 - 0 0 Empty
The output of od -A x -t x1 bootsect.lnx > mbrb.hex is:
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
000200
And here is the output of /boot/grub/grub.conf
#boot=/dev/hdb
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.18-1.2849.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2849.fc6 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
Is there something wrong with the dd command? Should there be any different syntax there? By the looks of the hex file there is nothing sitting on those first few bytes.
Here is the syntax for the dd command I used: dd if=/dev/hdb1 of=bootsect.lnx bs=512 count=1 It is the command I got from a few different threads outside of Fedora Forums
Anyway I hope this info helps.
if linux is indeed on hdb, you may want to try root(hd1,0)

nick.stumpos
6th December 2006, 09:10 AM
wow nevermind i didnt see the 2nd page just ignore me

electroconvulsi
6th December 2006, 02:50 PM
joewp has a good point. I think it is an issue of which way round the BIOS thinks the disks are and which way round GRUB thinks the disks are. They are both faking it and getting thoroughly confused. It is time to deploy the map swapping trick try:-


title Windows
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd1,0)
chainloader +1

I am going to have my breakfast now so, back in a couple of hours.

The map swapping trick worked. Thanks a lot. I'll get on to the next stage in the next day or two. Gotta get up in the morning.

Question: Would it not be just as effective to use

rootnoverify (hd0,0)
chainloader +1?

Re: Post 24'
Does this reverse drive mapping also effect the process of creating the new bootloader?

kldixon
7th December 2006, 01:34 PM
Yes you very likely could do that. Try it. However, I have taken this path so that each issue is clear in the config files. The files act as documentation for the user as well as instructions to the machine. In six months time, when you want to change something, you will look at the file and ask "why did I do that?" or "can that be correct?". To clean things up properly, you should go back to the device.map file and put the devices in the correct order then edit the whole grub.conf file so that all the device references are correct. Windows is on the first disk which, from the Linux perspective, is /dev/hda. The current device.map file maps that to the Grub device (hd1) so that is what the rootnoverify command should refer to, for reasons of clarity. If and when you do clean it up, remember that, if you make a mistake, you could end up with an unbootable system. There are many ways to recover from such a situation, using the rescue CDROM or the first installation CDROM, but it is better not to get into that situation in the first place or at least know all the recovery techniques before you do so.

As for your second question The reverse drive mapping does not matter in itself. However, I am not expecting Post 24 to work now, in the light of what we have learned so far. It would seem that the BIOS is calling whatever disk it boots from "disk 0" and the other "disk 1" and so byte 0x40 is likely to remain 0x80. But it is still worth doing it just to be certain. I have a method for beating this but its simplest incarnation requires a floppy disk drive.

Can you confirm that there is a floppy drive on this machine?

electroconvulsi
7th December 2006, 02:03 PM
Yes I do. Is this because we are going to try to run bootsect.lnx from the floppy?

kldixon
7th December 2006, 02:25 PM
This is the modified procedure using the floppy drive

Remember to replace the windows disk with a disk with nothing important on it.

1) Boot into Linux.
2) Insert a floppy in the drive, this will be overwritten by the procedure below.
3) Create a Grub Boot floppy:-


$ su root
# cd /usr/share/grub/i386-redhat
# dd if=stage1 of=/dev/fd0 bs=512 count=1
# dd if=stage2 of=/dev/fd0 bs=512 seek=1
# exit
$

4) Reboot and enter the BIOS setup
5) Set the boot sequence to boot from floppy first and reset the hard disk to boot from to the first one, the Windows disk.
6) Exit Setup, saving changes. The machine should boot from the floppy into GRUB. You will see the grub prompt appear.
7) Do the following commands but stop if the responses are not as shown:-


grub> find /grub/stage1
(hd1,0)

grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0x83

grub> install /grub/stage1 d (hd1,0) /grub/stage2

grub>

8) Remove the floppy and hit CTRL+ALT+DEL to reboot.
9) Enter Setup and set the hard disk to boot from to the Linux disk.
10) Exit Setup, saving changes.

When you have booted back into Linux, you can follow Post 24 to get a copy of the stage1 loader and check byte 0x40.

The reason this should work this time is that the BIOS would have booted into Windows if there had not been a floppy in the drive. With the BIOS in that state, we used Grub to install the stage1 loader in (hd1) which, in turn, we confimed was the Linux drive with the find command.

electroconvulsi
9th December 2006, 09:09 AM
OK I tried the process you described by creating the grub floppy, turning off my PC using another disk in place of the windows drive. I run the commands
grub> find /grub/stage1
(hd1,0)

grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0x83

grub> install /grub/stage1 d (hd1,0) /grub/stage2

grub>I generated a newbootsect.lnx file using
dd if=/dev/hdb of=bootsect.lnx bs=512 skip=63 count=1 I made a mbrb.hex file and here are the results

000000 eb 48 90 00 00 00 00 00 00 00 00 00 00 00 00 00
000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 02
000040 81 00 00 80 41 58 00 00 00 08 fa 90 90 f6 c2 80
000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc
000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 be 7f 7d
000070 e8 34 01 f6 c2 80 74 54 b4 41 bb aa 55 cd 13 5a
000080 52 72 49 81 fb 55 aa 75 43 a0 41 7c 84 c0 75 05
000090 83 e1 01 74 37 66 8b 4c 10 be 05 7c c6 44 ff 01
0000a0 66 8b 1e 44 7c c7 04 10 00 c7 44 02 01 00 66 89
0000b0 5c 08 c7 44 06 00 70 66 31 c0 89 44 04 66 89 44
0000c0 0c b4 42 cd 13 72 05 bb 00 70 eb 7d b4 08 cd 13
0000d0 73 0a f6 c2 80 0f 84 ea 00 e9 8d 00 be 05 7c c6
0000e0 44 ff 00 66 31 c0 88 f0 40 66 89 44 04 31 d2 88
0000f0 ca c1 e2 02 88 e8 88 f4 40 89 44 08 31 c0 88 d0
000100 c0 e8 02 66 89 04 66 a1 44 7c 66 31 d2 66 f7 34
000110 88 54 0a 66 31 d2 66 f7 74 04 88 54 0b 89 44 0c
000120 3b 44 08 7d 3c 8a 54 0d c0 e2 06 8a 4c 0a fe c1
000130 08 d1 8a 6c 0c 5a 8a 74 0b bb 00 70 8e c3 31 db
000140 b8 01 02 cd 13 72 2a 8c c3 8e 06 48 7c 60 1e b9
000150 00 01 8e db 31 f6 31 ff fc f3 a5 1f 61 ff 26 42
000160 7c be 85 7d e8 40 00 eb 0e be 8a 7d e8 38 00 eb
000170 06 be 94 7d e8 30 00 be 99 7d e8 2a 00 eb fe 47
000180 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 44
000190 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 00
0001a0 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 00 00 00
0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
But when I try to boot to linux using the bootsect.lnx file it gives me a grub command line the same as the grub boot floppy. Well I guess things are progressing here as the PC can now boot the grub file from boot.ini. but its not booting the OS itself yet.

kldixon
9th December 2006, 02:11 PM
When you get the grub prompt, could you try:-


grub> configfile /grub/grub.conf

That should display the menu and start the timeout so that Linux boots.

Of course, it should have done that automatically. The problem is that the stage2 loader is looking for the configuration file on "disk 0", the Windows disk. The following should do the trick. Could you repeat the process in Post 36 (you can use the same Grub floppy, you do not have to recreate it, and you do not need to get a copy of the stage1 loader as it should be identical) but replace the install command with:-


grub> install /grub/stage1 d (hd1,0) /grub/stage2 p /grub/grub.conf

grub>

The 'p' parameter causes grub to look for the configuration file on the same partition as it found the stage2 loader when the install command was run, which is now on "disk 1". It does this by modifying the stage2 loader file itself. Unfortunately, this will mean that the BIOS method, of changing the boot disk, will now not find the config file as it will look on "disk 1" which, in that case, would be your Windows disk. However, the same solution, using the configfile command, should work.

I just realised that there is, of course, a much easier method. When you boot Grub, using NTLDR, and get the grub prompt, you are in the same state as booting by the Grub floppy, so you can just use the commands:-


grub> find /grub/stage1
(hd1,0)

grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0x83

grub> install /grub/stage1 d (hd1,0) /grub/stage2 p /grub/grub.conf

grub>

immediately, to set the stage2 loader.

Also, now, when you get the Grub menu, you should be able to boot into Windows. But, to do so, you will probably have to remove the map swapping commands from before the rootnoverify command. Indeed, you could put two menu entries in grub.conf, one with the map commands and one without. Then you could also boot Windows if you had booted into Grub from the BIOS.

electroconvulsi
9th December 2006, 05:37 PM
So anyway I tried
grub> find /grub/stage1
(hd1,0)

grub> root (hd1,0)
Filesystem type is ext2fs, partition type 0x83

grub> install /grub/stage1 d (hd1,0) /grub/stage2 p /grub/grub.conf

grub> from the grub prompt that I got when I booted from the Windows bootloader and it came up with the grub selector screen and then when I tried to boot to Fedora core from there it said
error 17 cannot mount the selected partition Another thing to mkention is that the top line above the error message said
root (hd0,0). For some reason as soon as grub is passed from the Windows bootloader it suddenly thinks it is (hd0,0) again.

kldixon
9th December 2006, 06:42 PM
Sorry, forgot, of course, the existing menu items are refering to (hd0,0), you need to change them to (hd1,0). If you reboot using NTLDR into grub then you should now get the Grub menu. You must get the grub prompt by stopping the timeout and typing 'c'. Then you can boot into linux by:-


grub> root (hd1,0)

grub> kernel /vmlinuz-2.6.18-1.2849.fc6 ro root=/dev/VolGroup00/LogVol00

grub> initrd /initrd-2.6.18-1.2849.fc6.img

grub> boot

and then edit grub.conf to look like:-


# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/hdb
default=0
timeout=5
#splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title Fedora Core (2.6.18-1.2849.fc6)
root (hd1,0)
kernel /vmlinuz-2.6.18-1.2849.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2849.fc6.img

title Fedora Core (2.6.18-1.2798.fc6)
root (hd1,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2798.fc6.img

title Windows
rootnoverify (hd0,0)
chainloader +1

title Fedora Core (2.6.18-1.2849.fc6) by BIOS
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2849.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2849.fc6.img

title Fedora Core (2.6.18-1.2798.fc6) by BIOS
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/VolGroup00/LogVol00
initrd /initrd-2.6.18-1.2798.fc6.img

title Windows by BIOS
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd1,0)
chainloader +1


and the device.map file


# this device map was generated by anaconda
(hd0) /dev/hda
(hd1) /dev/hdb


Just a word of warning. When you do a kernel update, do it when Linux has been booted via NTLDR. The update will insert an entry for the new kernel into grub.conf and remove the previous but one entry, if it exists, so that it keeps the new entry and the previous entry. I am not sure just how clever the algorithm is for determining which is the current entry and which is the previous one. It will not modify the entries ending with "by BIOS". You will have to do that by hand.

electroconvulsi
10th December 2006, 03:48 PM
Seriously I think for what its worth Id like to thank you for all your help but to tell the truth this has been much too much messing around and for the moment Im haapy to use the grub chainloader to boot Window$. The entire point of this exercise from the outset has been that I dont have to put grub on my Windows drive and I dont have to use BIOS to dual boot. This has been a major effort on your part to resolve this but.
Just a word of warning. When you do a kernel update, do it when Linux has been booted via NTLDR. The update will insert an entry for the new kernel into grub.conf and remove the previous but one entry, if it exists, so that it keeps the new entry and the previous entry. I am not sure just how clever the algorithm is for determining which is the current entry and which is the previous one. It will not modify the entries ending with "by BIOS". You will have to do that by hand. made me think I want to keep things simple as possible and possibly having to do any reconfiguration every time the kernel updates would be a pain and I dont really want to look at it again afterwards. So again I thank you for all the effort you have put in on this thread and it will probably help anyone else who has the same issue so it hasnt been a big waste of time. Maybe its this PCs BIOS as you have mentioned. I rememner that on my other PC and FC5 it worked like a charm the first time and I guess now is a good time to leave it out. Let me apologise if you feel inconvenienced by me pulling out but I have a good dual boot working and Im happy with that.

Cheers

kldixon
10th December 2006, 04:30 PM
Sorry to here that. My last post should have got you to where you wanted to be. You do not have to include the "by BIOS" entries in grub.conf I just suggested that so that you could boot into linux via NTLDR or by the BIOS. I do not think that there is anything particularly peculiar about your BIOS. The BIOS is that way because NTLDR has trouble booting Windows from anywhere but the first disk. At some time in the future, you are going to have to know how Grub works, if you continue to use Fedora, and especially if you want to build multi-boot systems. If you read the grub manual at:-
System->Help->GNU Info Pages->Kernel->GRUB
or
http://www.gnu.org/software/grub/manual/html_node/index.html
and go through this thread again, it should become clear what was happening and then it will all seem obvious and you will wonder why it seemed so difficult.

I think you probably just got lucky with FC5. There was nothing essentially different in this area to what FC6 did. Think, what are you going to do at the next release.

Anyway, thanks for persisting this far. I was only doing it because I was learning too!