Fixing vista multiboot with openSUSE

[swerdna]

Note: this is only for Vista, not for 2000/XP
There are of course other bootloader problems; this is simply one of the common ones.

Situation: Vista is installed first on OEM computers. You install openSUSE and Vista won't boot from the Grub bootloader.

Problem: Yast automatically configures Grub for us in a fashion that used to work with Win 98, 2000 and XP. It puts an entry like this in the Grub configuration file menu.lst located at /boot/grub/menu.lst:

title windows
rootnoverify (hd0,8)
chainloader (hd0,0)+1

The "root" is set to the root partition of the openSUSE installation, in this example partition sda9 [in Grub speak that's (hd0,8)]. That works for earlier versions of Windows but it doesn't work so good for Vista.

Solution: You have to edit the file menu.lst with this command in a console for KDE:

kdesu kwrite /boot/grub/menu.lst

or if you have Gnome use this:

gnomesu gedit /boot/grub/menu.lst

and change the windows entry from like this:

title windows
rootnoverify (hd0,8)
chainloader (hd0,0)+1

to like this:

title windows
rootnoverify (hd0,0)
chainloader (hd0,0)+1

Variation for some notebooks: Compaq and some other notebooks don't preinstall Vista on the first partition [which is designated (hd0,0)]. They have a utility partition as the first partition and Vista on the second. For those cases the correct entry in Grub looks like this, reflecting sda2/(hd0,1):

title windows
rootnoverify (hd0,1)
chainloader (hd0,1)+1

Further problems: This is just one of the quirks that you can get when multibooting Windows and Suse. There's a fuller rundown on fixing those problems here: GRUB Boot Multiboot openSUSE Windows (2000, XP, Vista) using the Grub bootloader.

Happy Vista-ing with openSUSE

[Cross_AM]

Thank you. Your inputs have always been great contributions.

[pturner7]

Originally Posted by swerdna

The "root" is set to the root partition of the openSUSE installation, in this example partition sda7 [in Grub speak that's (hd0,8)].

swerdna, are you sure this bit is right? Should it not be sda9? (Grub counts from 0 so always lags (or leads?) the sda/hda numbering).

[swerdna]

Originally Posted by pturner7

swerdna, are you sure this bit is right? Should it not be sda9? (Grub counts from 0 so always lags (or leads?) the sda/hda numbering).

OOOPppss, thanks Paul -- fixed

[MustardMan]

Here is my two cents...

I use two drives. This makes everything cleaner in my opinion. Well at least until I bought a crumby motherboard (K9A) that will not boot the second drive directly. Instead you change the drive order in the BIOS to switch witch drive you would like to boot.

So having already installed Vista on the first drive, and after installing openSUSE on the second drive and changing the drive order to boot the newly installed openSUSE11 [second drive mapped to first drive in BIOS]. It was no surprise I had some trouble multibooting with grub.

So here is the trick that worked for me.

Grub.lst

###Don't change this comment - YaST2 identifier: Original name: windows 1###
title windows
    rootnoverify (hd1,0)
    chainloader (hd1,0)+1

For whatever reason Yast would not let me write "rootnoverify (hd1,0)" and would repeatedly change it back to "rootnoverify (hd0,0)", [GRRR] so I had to do that by hand.

Now I could boot Vista, but had some troubles with setting Vista to "sleep" mode. My guess is that vista is unhappy booting from what the BIOS tells it is the second drive and that breaks RAM contents redundancy stored on disk. Luckily disabling "Hybrid Sleep" mode allowed sleep mode (S3) to work again.


Have Fun!

[torphoto]

Good info but I would like to know if there i a way to keep grub/suse from changing the windows entry every kernel update, rebuild etc? As it is now every time you update the kernel it resets the menu.lst windows entries for vista back to something incorrect. It just gets annoying.

[swerdna]

Originally Posted by torphoto

Good info but I would like to know if there i a way to keep grub/suse from changing the windows entry every kernel update, rebuild etc? As it is now every time you update the kernel it resets the menu.lst windows entries for vista back to something incorrect. It just gets annoying.

I hadn't heard of that and don't know of a way to make it fixed. Interesting. Thanks.

[snakedriver]

Originally Posted by swerdna

Note: this is only for Vista, not for 2000/XP
Happy Vista-ing with openSUSE

Swerdna -- something to add

Situation = new HP dv9700z with Vista on 1st partition; HP Recovery on 2nd partition (all on disk 1). In windows, they have it so that disk2 is seen as a storage disk only. BTW, there is essentially no bios controls. I didn't get a Vista install CD/DVD; only the recovery disks I made.

Fortunately, 11.0 sees & installs to drive 2.

Now, I want to multi-boot Vista, winxp, OpenSUSE 11.0 (and others eventually).

OK, I use Parted Magic to shrink the Vista partition & move the Recovery partition next to that; make a partition for winxp & install winxp on disk 1. Now thinking my OpenSUSE 11.0 installed on disk2 will detect vista & xp, I install 11.0. Grub will only see/boot xp because it overwrote the mbr.

As I don't have a Vista install disk, I searched & found "Windows Vista x64 Recovery Disc.iso" (a google search should find that for you). That is essentially the boot recovery part of the Vista disk. That fixed my Vista boot problem from Grub.

Then, I start to work on XP. Grub wants to boot it, but, I start getting errors like missing NTLDR, ntdetect.com, etc. Not to worry, I use 11.0 & copy all that from the XP CD to the winxp root. Then, I get \system32\ntoskrnl.exe corrupt; replace that & get the same error msg. I finally got tired of messing with it.

I finally came to the conclusion that the Windows Vista x64 Recovery Disc I used to get Vista to boot rewrote/deleted some of the XP files and took charge of the boot process.

Long story > short:
I found "EasyBCD @ Download EasyBCD 1.7.2 - NeoSmart Technologies which allows Vista to dual boot winxp.

Now I have an OpenSUSE 11.0 Grub that boots the Vista bootloader which allows me to select either Vista or winxp. Yeah, it's a two step process. but, it sure is easy

Note: how it does that & Grub's boot yields xp file corruption is beyond me.

[swerdna]

@snakedriver
This might explain what happened:

The active partition plays a big role for microsoft distros. You started with sda1 active, containing vista, and installed xp on sda3. During the xp install, xp sought out the active partition (sda1) and put its ntldr, ntdetect.com and boot.ini files there. And it wrote a bootstrap code into the MBR that is different from the bootstrap code vista put there earlier -- different in this regard:

• Bootstrap MBR code of vista instructs to seek the active partition and find the file bootmgr.
• Bootstrap MBR code of xp instructs to seek the active partition and find the file ntldr.

So: after you loaded xp, the bootstrap code sought the xp ntldr on sda1 and those files won't boot vista [because ntldr & boot.ini don't know about vista because they were born before it was invented].

So that's why you had to use the recovery CD of vista to get vista back. Now -- vista was born after xp so its parents taught the file bootmgr of vista always to look for the file boot.ini on the active partition just in case vista had relatives on the drive.

So once you fixed vista with recovery it should then have been able to multiboot xp.

Thus when you installed Suse, which is from a different tribe to microsoft and doesn't know about vista or xp, it said "heck i'll include both the ntfs partitions into Grub's menu.lst, it's all I can think to do". But we know now that there are no files like ntldr on sda3 because xp put them elsewhere deliberately during installation. So when grub points to sda3 you should get the response "like missing NTLDR, ntdetect.com, etc", because they are missing by design.

So to cut a long story short -- there is no file corruption and everything went according to plan.

Simple isn't it

[snakedriver]

Originally Posted by swerdna

Simple isn't it

Swerdna, you write a mighty good explanation!

Thanks