[SOLVED] Grub advice needed after Fedora on Windows7 laptop

gcmartin · #1 4th January 2010, 01:06 AM

Lost Windows 7 Bootmanager after Fedora. Need to Boot Windows 7 but am at a loss of where to begin.

I simply want to use a Boot Manager (BM), any BM to boot either Win7 or Fedora at will. I can now only boot Fedora. I have read for 2 days and nothing is very straightforward or clear as to the problem and how to recover Win7. Everyone seems to be talking around the problem as if its a trade secret. I am not the enemy. Please help, anyone please, if you understand this. And, I will try to write a simple straight forward post to assist others who wind up in this dilemma.

Below is, both, a copy of my dirve's layout and my current Grub configuration.

Fedora 12 boots fine. Windows7 is NOT in the GRUB menu.
fdisk -lu shows:
# fdisk -lu

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x2afbc966

Device Boot Start End Blocks Id System
/dev/sda1 63 20466809 10233373+ 12 Compaq diagnostics
/dev/sda2 * 20466810 64002959 21768075 7 HPFS/NTFS
/dev/sda3 74220300 312576704 119178202+ f W95 Ext'd (LBA)
/dev/sda4 64002960 64412559 204800 83 Linux
/dev/sda5 104952645 210162329 52604842+ 7 HPFS/NTFS
/dev/sda6 210162393 230645204 10241406 83 Linux
/dev/sda7 230645760 261357567 15355904 7 HPFS/NTFS
/dev/sda8 261361548 304190774 21414613+ 7 HPFS/NTFS
/dev/sda9 304190838 312576704 4192933+ 82 Linux swap / Solaris
/dev/sda10 74220363 104936266 15357952 8e Linux LVM

Partition table entries are not in disk order

Disk /dev/dm-0: 9684 MB, 9684647936 bytes
255 heads, 63 sectors/track, 1177 cylinders, total 18915328 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/dm-1: 6039 MB, 6039797760 bytes
255 heads, 63 sectors/track, 734 cylinders, total 11796480 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

This laptop had a Windows7 Boot Manager and a Windows Vista boot in its menu as well. Now, I have Grub and I'm not sure after all the reading where to begin much less how to move in proper direction to resolution.

My GRUB is as follows
#
# 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,3)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_fedralv12b-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=15
splashimage=(hd0,3)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.31.5-127.fc12.x86_64)
root (hd0,3)
kernel /vmlinuz-2.6.31.5-127.fc12.x86_64 ro root=/dev/mapper/vg_fedralv12b-lv_root LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet
initrd /initramfs-2.6.31.5-127.fc12.x86_64.img
title Other
rootnoverify (hd0,0)
chainloader +1

I want to be able to boot fedora, Win7, and WinVista which is on this one drive system (laptop). thx in advance.
If this helps, here is my GRUB menu.lst
# 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,3)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_fedralv12b-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=15
splashimage=(hd0,3)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.31.5-127.fc12.x86_64)
root (hd0,3)
kernel /vmlinuz-2.6.31.5-127.fc12.x86_64 ro root=/dev/mapper/vg_fedralv12b-lv_root LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet
initrd /initramfs-2.6.31.5-127.fc12.x86_64.img
title Other
rootnoverify (hd0,0)
chainloader +1

stoat · #2 4th January 2010, 03:47 AM

Quote:

Originally Posted by gcmartin

I have read for 2 days and nothing is very straightforward or clear as to the problem and how to recover Win7. Everyone seems to be talking around the problem as if its a trade secret. I am not the enemy.

But it is straightforward. And it is clear. And it is not a trade secret. It happens all the time and gets discussed here very directly on a nearly constant basis.

Hello gcmartin,

According to your information, your grub.conf file is trying to boot (hd0,0) for Windows.

Quote:

Originally Posted by gcmartin

title Other
rootnoverify (hd0,0)
chainloader +1

That corresponds to /dev/sda1 in the fdisk report and is a utility partition.

Quote:

Originally Posted by gcmartin

Device Boot Start End Blocks Id System
/dev/sda1 63 20466809 10233373+ 12 Compaq diagnostics
/dev/sda2 * 20466810 64002959 21768075 7 HPFS/NTFS
/dev/sda3 74220300 312576704 119178202+ f W95 Ext'd (LBA)
/dev/sda4 64002960 64412559 204800 83 Linux
/dev/sda5 104952645 210162329 52604842+ 7 HPFS/NTFS
/dev/sda6 210162393 230645204 10241406 83 Linux
/dev/sda7 230645760 261357567 15355904 7 HPFS/NTFS
/dev/sda8 261361548 304190774 21414613+ 7 HPFS/NTFS
/dev/sda9 304190838 312576704 4192933+ 82 Linux swap / Solaris
/dev/sda10 74220363 104936266 15357952 8e Linux LVM

It didn't work to boot Windows, so the only other possible partition that can contain boot loader files for a Windows system is /dev/sda2 (/dev/sda3 is an extended partition, /dev/sda4 is the Fedora boot partition, and the others are all logical partitions).

This happens all the time. Anaconda (the Fedora installer) is a sucker to fall for (hd0,0) as the partition with the Windows boot loader files. However, it is often a utility or recovery partition. You should try editing your grub.conf to chainloader boot the correct partition. For example...

Code:

title Other
rootnoverify (hd0,1)
chainloader +1

You can also change "Other" to whatever you want to appear in the boot menu.

P.S.: When you install multiple Windows systems such as Vista and Windows 7 in your case, the last one of those installed (usually the newest version) takes over the boot loader chores and boots both of the Windows systems from its boot menu. So when you get this GRUB thing fixed, you will have a single choice in the GRUB menu for Windows. Selecting that makes the Windows boot menu will appear and offer Vista and Windows 7. It's possible to have both Vista and Windows 7 as separate choices in the GRUB boot menu, but that is a very advanced boot loader topic. I recommend that you not try that now.

gcmartin · #3 4th January 2010, 07:33 PM

@Stoat - Thanks you very much for this explanation.

I did several things and the following is the results.

I used your example and added 4 instances of this to grub; an instance for each partition on the drive; e.g. (hd0,6), etc.
The ONLY one that worked was your recommendation of (hd0.1).

I have 2 remaining questions.

How did you know to use hd0,1 (I understand the linux notation, but was it your experiences or something else you saw which was your reason for recommending hd0,1)?
What does the "*" mean in the fdisk -lu list that I provided?

My final grub looks like this:

Thanks in advance. You were clear and accurate in your response.

stoat · #4 4th January 2010, 11:32 PM

Quote:

Originally Posted by gcmartin

1. How did you know to use hd0,1 (I understand the linux notation, but was it your experiences or something else you saw which was your reason for recommending hd0,1)?
2. What does the "*" mean in the fdisk -lu list that I provided?

The last question first...That asterisk in the fdisk report indicates the partition that is marked as the active partition. It really only matters to Windows systems because Windows boot loaders rely on it. When a Windows system boots, the BIOS program loads and executes the boot code in the first hard drive's master boot record (the very first sector of all partitioned hard drives). That program examines the partition table (also in the master boot record) to determine the active partition and then loads and executes the boot code in the first sector of that active partition. When that program runs, it finds and executes the boot loader files in the filesystem of the partition. Eventually, the kernel is loaded and executed. It looks kinda like this on paper for XP, for example...

Code:

                                                boot.ini               /--> kernel
                                                    |                 /  
BIOS --> Partition Loader --> Boot Sector Code --> ntldr --> XP Menu -----> kernel
           (Master Boot      (Active Partition       |                \
              Record)           Boot Sector)     ntdetect.com          \--> kernel

In that example, the "Partition Loader" is what MS calls the little binary program in the master boot record that looks at the partition table to find out which partition is active and then loads the boot code in its first sector (aka volume boot record, aka boot sector). ntldr, boot.ini, and ntdetect.com are the XP boot loader files in the filesystem of the partition. In Vista and Windows 7, different files are involved, but the overall concept is the same.

GRUB does not rely at all on the active state (or not) of partitions for booting. GRUB boots in stages that each already know (or can find) where the next stage is located. The default GRUB arrangement installs stage1 in the master boot record (erasing the MS code that probably was there). GRUB stage1.5 is installed in the so-called DOS Compatibility Area immediately following the master boot record. The DOS Compat Area is the normally unused 62 sectors between the master boot record and the start of the first partition (on a legacy hard drive; not a GPT hard drive). And finally, stage2 is a file in the filesystem and located in the /boot/grub directory. Stage2 displays the splashscreen, creates the menu in front of the splashscreen, and finally launches the kernel that you choose in the menu. It all kinda looks like this on paper...

Code:

                                            grub.conf                  /--> kernel
                                                |                     /
BIOS --> GRUB stage1 --> GRUB stage1.5 --> GRUB stage2 --> GRUB Menu -----> kernel
         (Master Boot     (DOS Compat      (/boot/grub)               \
            Record)          Area)                                     \--> kernel

Now on to the issue of how GRUB chainloader boots Windows. It does that by getting things going from a later point in the Windows boot loader chain of events. It loads and executes the boot code in the first sector of the Windows partition. It does that just like the MS boot code in the master boot record would have done. It looks kinda like this on paper...

Code:

                                            grub.conf                  /--> kernel
                                                |                     /
BIOS --> GRUB stage1 --> GRUB stage1.5 --> GRUB stage2 --> GRUB Menu -----> kernel
         (Master Boot     (DOS Compat      (/boot/grub)               \
            Record)          Area)                                     \--> chainloader +1
                                                                                /
                                         /<------------------------------------/
                                        /
                                       /        boot.ini               /--> kernel
                                      /             |                 /  
                              Boot Sector Code --> ntldr --> XP Menu -----> kernel
                                                     |                \
                                                 ntdetect.com          \--> kernel

Stare at all of that stuff for a while and you'll see how that is a sort of combination of the first two diagrams. Except now it doesn't matter whether the Windows partition is active or not since MS master boot record code is not involved.

That probably was an overkill answer for the question. But I just felt like saying it for the record, and it kinda relates to the answer for the other question. Anyway, now back to the first question...I just kinda knew. Or at least it was a safe guess. It's happened so many times. In fact, I was surprised at your comments about this subject being hard to find and obscure here. But one clue was that /dev/sda2 was a primary NTFS partition marked as the active partition (made that way by the Windows installer because it is essential for Windows boot loaders when they boot directly from BIOS). Besides that, all of the other partitions easily could be eliminated from consideration. You already tried /dev/sda1 and it didn't work. The extended partition (/dev/sda3) was out of the question. The Linux partition is /dev/sda4 (forget that as having Windows boot loader files). And those logical partitions were off the table because no Windows installer would ever agree to putting its boot loader files in a logical partition because they cannot be made active. The Windows system itself can be in a logical partition, but never its boot loader files. BTW, fdisk will agree to mark any partition including a logical partition as "boot", but a logical partition marked active by fdisk will not work in the MS boot loader scheme that I described earlier because logical partitions are not recorded in the master boot record partition table. The partition table for logical partitions is a daisy-chained affair in the first sectors of the logical partitions.

So that left /dev/sda2 as the only viable possibility through a process of elimination of the others.

duende · #5 5th January 2010, 10:04 PM

Stoat, thanks for a very interesting description! Much appreciated. Pity it was getting buried far away....

There are several things I was wondering about, related to the boot process.
You say that stage 1.5 is located in the 62 sectors immediately following MBR, so I understand that if during the installation I chose the option to install GRUB in MBR of /dev/sda, then I can make a backup of GRUB by:

Code:

dd if=/dev/sda of=boot_stage1_backup bs=446 count=1

and

Code:

dd if=/dev/sda of=boot_stage1.5_backup skip=1 bs=512 count=62

Later I can recover these two stages by the corresponding dd commands. (I know that grub has its proper tools for recovery. But this seems to be easier to restore a previously functioning system if mbr and dos compatibility area get accidentally overwritten by a different install.)

Where is stage1.5 located, if I choose the option of installing grub onto the first sector of the boot partition? Are these sectors 2-63 of, say, /dev/sda5, if this is the boot partition?

Is DOS compatibility area also used by other bootloaders? Or, is it safe to assume that it is just used by GRUB?
- I don't think that Win XP uses it (Once I unintentionally allowed Fedora to install grub in mbr instead of the first sector of the boot partition, and, having problems with executing windows fixmbr command I simply copied using dd the first 446 bytes from mbr of one computer with win XP onto the machine in question, and XP booted without problems).
How about Vista and Win 7? I think that LILO did not use this area either. (By the way, does anyone still use LILO?)

I am also curious, how does stage1 of grub determine where stage 1.5 is located?
On one of my laptops fedora did not want to resume from suspend (as usual with me, win xp bootloader in mbr and grub installed on the first sector of the boot partition). In a desperate attempt to fix it, having tried many other things, I decided to see what happens if grub is in mbr. But before I started reading and learning how to reinstall grub I decided to try "dd if=/dev/sda5 of=/dev/sda bs=446 count=1", since it was only a few seconds. Just this one command was enough to get grub booting properly as the first bootloader! So, it obviously was able to find stage 1.5. (And, miraculously also the resume problem was fixed! Strange that only that one laptop had this problem.) Later on, out of pure curiosity I tried copying the same into the mbr of a usb stick (/dev/sdc), but this did not work, fedora would not boot. Does it have to be the same disk for this procedure to work?

stoat · #6 5th January 2010, 11:40 PM

Quote: