I installed opensuse 11 from a burned DVD. I have two hard drives: one 40GB drive with two ntfs partitions /dev/sda1 (with Vista install) and /dev/sda2, and another 8GB drive with the Suse installation and swap partition.
For some reason, when I choose to boot Vista from the GRUB menu, it just gets stuck at a black console screen with
rootnoverify(hd1,0)
chainloader(hd0,0)+1
How do I fix this?
Try: rootnoverify (hd0,0)
You’ll find this in the file menu.lst at /boot/grub/menu.lst under the title windows 1 probably, so edit the line there. To get the editor to work in KDE put this in a console:
kdesu kwrite /boot/grub/menu.lst
but if Gnome do
gnomesu gedit /grub/beoot/menu.lst
Thank you! It works perfectly. Although I have to wonder why openSUSE 11 automatically configures the Vista boot entry with hd1 for rootnoverify.
Well it’s a hangover from the days when vista didn’t exist. The line I gave works for 2000/xp/vista. The line Yast gives works for 2000/xp but not vista. Vista has a different bootloader entirely from xp and 2000 but Yast hasn’t quite cottoned onto that yet.
Ah thanks for the tip. I just feel that this should have been fixed before release, now that Vista is considered mainstream.
Maybe they don’t know why vista apparently creates problems for GRUB – why don’t you track down the long standing bug report and tell them that the installation of
rootnoverify (hd1,0)
points to your root partition and not the windows bootloader partition as it should, and that by tuning Yast to instead generate the line
rootnoverify (hd0,0)
as recommended in the Grub 2006 maual, vista would work too? You would be doing a great thing for openSUSE 
Hi,
As this is a common problem could this be put in the sticky list?
Thanks
Sure, I’ll attend to that over the next few days
I have the same problem with Windoze XP Pro, except that my feedback on trying to start XP from Grub was:
rootnoverify (hd0,5)
chainloader (hd0, 0)+1
I tried editing menu.lst to rootnoverify (hd0, 0) with no effect other than this appearing instead of (0, 5). I am a complete Linux newbie, who needs to use some Windoze legacy apps. Advice please.
Just so we get an accurate picture:
cat /boot/grub/menu.lst
fdisk -l
As swerdna already mentioned, windows xp boot loader is not so fussy with rootnoverify command. With my own system, I have
windows xp located on /dev/sda1
linux located on /dev/sda6
My windows xp grub entry:
rootnoverify (hd0,5)
chainloader (hd0,0)+1
Also check that grub hasn’t corrupted windows MBR.
The rootnoverify command can be there just to satisfy grub’s need for a “root” statement. It does not affect the operation performed here by grub, which is simply a hand-off call to the strap code in the partition boot sector (i.e., a "chain load).
IME xp doesn’t require it top be correct but vista does, have you noticed that sort of difference?
ya this is a sticky topic…i too have this problem d was fixed by Global moderator only …
Out of habit I’ve always used the rootnoverify to point to the partition being chain loaded to. If grub is given a root command, it will attempt to validate a filesystem exists there that it can read, unless the noverify is used where it then just validates that the partition exists. Having said that, I have removed the line entirely from a chain loading stanza without any problem, as long as the chainloader command specifies the partition (e.g., “chainloader (hd0,0)+1”). I just tested removing the root command line again, chain loading to the Vista BCD system volume (which is also the XP system volume, i.e., Windows dual-boot config); worked fine. Haven’t tried it with a solitary Vista setup; don’t know why it would be different, though.
Try these circumstances if you can, and let me know if it’s wider than just me:
Vista on drive 1 using “bootmgr”
Suse on drive 2 with Grub on (hd0)
chainloader like this:
rootnoverify (hd1,x)
chainloader (hd0,0)+1
For me, two different computers – misbehaves until I do this:
rootnoverify (hd0,0)
chainloader (hd0,0)+1
Now two computers is a small statistical sample – so if there’s another instance the same (or different), I’d be eager to know.
I can confirm the same. Windows XP will boot regardless of presence and configuration of rootnoverify command. However, I found Vista requires the rootnoverify command to point to the actual Vista partition.
Thanks for that. Saves me wondering if I was losing it.
Hmmm . . . I think there is more here than meets the eye 
. . . the following may be useful data re the rootnoverify question. However, while investigating this, I stumbled across some things about Vista which are of real concern. So this has ended up getting rather long; apologies but good to know re Vista anyway . . .
First, I conducted a series of SuSE-to-Vista chainloading tests on 3 different machines. On the 1st, the Windows “system volume” is the first partition with Vista BCD installed, dual-booting XP; formatted FAT32. The 2nd machine has the same setup, except using NTFS. On the 3rd machine I did a clean install of Vista, using Vista to wipe the disk, create/format its partition; followed by a new openSUSE installation. For comparison I also conducted these tests on a 4th machine with W2K (identical boot to XP) chainloaded by SuSE.
In all of the tests the menu.lst stanza had the command “chainloader (hd0,0)+1” preceded by a “rootnoverify (hd0,0)”. In the tests I changed the rootnoverify pointer to other partitions, used the same pointers but with the root command instead, and removed the line altogether. In every case, it had no effect on the boot (except when root was used to point to an NTFS partition, grub threw a “filesystem not found” soft error but still chainloaded successfully). The root command is definitely required, either separately or embedded in the chainloader command (as above). But the “noverify” option was not required.
Why then would rootnoverify sometimes make a difference? I can’t say for sure, but I can offer one educated guess. In addition to locating the boot sector, the root command also “attempts to mount [the partition] to get the partition size for passing the partition descriptor . . .” It is possible that if the grub calculation fails, or if grub encounters an unexpected condition in the table data that the pgm was not written to handle, conceivably that could cause the grub code to fail. This might explain why the “noverify” may resolve a grub problem, but doesn’t explain why grub doesn’t always need it.
Then I stumbled across this re Vista partitioning: It is using a different method to create partitions. From the best analysis I could find at Multibooters - Dual/Multi Booting With Vista:
“Vista is placing partitions on the hard drive using different starting and ending positions from the recognised conventions . . . if you partition or image or clone your drive or have a dual/multiboot configuration with OSes other than Vista, then there are various serious problems that can arise . . . Vista created partitions can ‘mis-align’ with other partitions, which is not a good situation on multiboot machines.”
There are Microsoft kb’s citing problems caused by this Vista change, such as Vista or XP partitions being destroyed by the other, disk read errors, errors loading the OS, unmounted boot volume, etc. The key points are that (a) Vista uses a different partition boundary and freespace calculation, (b) the calculation result is a variable, depending on registry settings, and (c) there can also be issues specific to “certain bios firmware” or bios disk settings.
I used the Symantec disk editor to look at the table on the Vista partitioned machine; it found what it thought were numerous geometry errors. I then tried to resize the partition with Parted (which SuSE, qtparted, gparted all use); it failed on read and write errors. Grub found the Vista boot sector, but it is using the kernel and not directly accessing the table. Still, after looking at the technical details discussed at the above site, it’s clear that there are a number of potential multi-boot problems with Vista.
So . . . as far as rootnoverify", I found at least one plausible reason that noverify could fix a grub Vista boot problem. But clearly the condition is not constant. That may be due to Vista’s new variable method of creating partitions, or related bios factors. It appears to be harmless to use rootnoverify, so it should probably be used by default. But there are other potential grub Vista boot issues that it will not resolve.
Further, from the above it certainly seems unwise to try to resize a Vista created partition with any tool not expressly for that purpose. In the SuSE install on my 3rd machine above, the installer offered to size down the Vista partition; that would have failed, as it did in my Parted test. But it could corrupt the table, making the entire system unbootable. In other cases it will not be a problem, again depending on how Vista has created the partition. (It should not fail if Vista has been installed on a partition first created with XP or a commercial tool.) Note that there are other differences in how Vista is using the partition table (involving the disk signature and the offset, discussed at the site above) that could result in Vista being unbootable, if the boot partition is written to the table by another tool. Seems like a lot of risk.
Finally, IMHO a strong argument can be made to not install grub in the MBR on a Vista disk, as long as openSUSE’s root is on a primary partition, thus avoiding any issues with grub reading the Vista created table. Interestingly, in the openSUSE install above, the installer actually recommended exactly that - install grub to the root partition boot sector and set that partition’s boot flag (making it the active primary), the Vista-supplied IPL then transparently chainloads the SuSE grub. (The “generic MBR code” that YaST can optionally install will do exactly the same thing.) This also provides the easiest method of getting back to booting Vista if something goes awry; all that is required is to re-set the Vista partition boot flag which can easily be done in rescue mode, with a live-CD, and other ways.
Hope some of this is useful.
Cheers.
How do I check that grub has not corrupted the Windows MBR?
“Vista is placing partitions on the hard drive using different starting and ending positions from the recognised conventions . . . if you partition or image or clone your drive or have a dual/multiboot configuration with OSes other than Vista, then there are various serious problems that can arise . . . Vista created partitions can ‘mis-align’ with other partitions, which is not a good situation on multiboot machines.”
The key points are that (a) Vista uses a different partition boundary and freespace calculation, (b) the calculation result is a variable, depending on registry settings, and (c) there can also be issues specific to “certain bios firmware” or bios disk settings.
This is a worry! You would think with all the various partitioning tools and boot managers in use, that one universal allocation system would be advantageous. Based on this info, I think it would be a good idea to consolidate useful multiboot information on a wiki outlining the best practices concerning resizing vista and other OS partitions, and grub configuration.
Finally, IMHO a strong argument can be made to not install grub in the MBR on a Vista disk, as long as openSUSE’s root is on a primary partition, thus avoiding any issues with grub reading the Vista created table. Interestingly, in the openSUSE install above, the installer actually recommended exactly that - install grub to the root partition boot sector and set that partition’s boot flag (making it the active primary), the Vista-supplied IPL then transparently chainloads the SuSE grub.
I’ve always preferred to install grub on the root suse partition anyway rather than mess with the windows MBR.