Empty menu.lst - can't boot

Hello and apologies if this is a common problem. I’ve searched around, but there are so many variations on the theme of dual-booting that it’s hard to be sure. Anyway, I just can’t even get as far as GRUB loading up …

I’ve installed OpenSuse KDE 4.2 from here: “KDE Four Live” CD](http://home.kde.org/~binner/kde-four-live/)

It is onto an extended partition, with XP and Windows 7 beta on two other partitions. I installed Grub to the root partition by ticking the “root” and “extended” options in the installer. Experience tells me that installing to the MBR is more likely to let my mess up XP booting, which leads to fights with my wife!

I can’t get the OpenSuse partition to boot, however. I am pointing boot.ini at my Linux partition, but can’t seem to get anywhere. Both the bootpart route (which looks for Linux partitions from within XP) and the dd if=/dev/sda of=boot.lnx route (Booting Linux from Windows NT/2000’s Boot Manager) aren’t working for me.

It seems that the system is failing to find a workable GRUB to load up. Using the OpenSuse liveCD to look at my installation, it seems that my menu.lst file is completely empty. Seems very odd and may be a big clue to my problem.

The other thing that I wonder about is whether using an extended partition isn’t helping. Not sure whether to point boot.ini at the “extended partition” (sda2 in my case) or the logical partition (sda5) to look for GRUB.

Can anyone help me out? All contributions gratefully received!

fdisk -l gives me this :-

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

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         261     2096451   82  Linux swap / Solaris
/dev/sda2             262        1536    10241437+   f  W95 Ext'd (LBA)
/dev/sda3            1537        9185    61440592+   7  HPFS/NTFS
/dev/sda4            9186       14593    43439760    7  HPFS/NTFS
/dev/sda5             262         898     5116671   83  Linux
/dev/sda6             899        1536     5124703+  83  Linux

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x8f898f89

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1        6374    51199123+   7  HPFS/NTFS
/dev/sdb2            6375       19122   102398310    7  HPFS/NTFS
/dev/sdb3           19123       30401    90598567+   7  HPFS/NTFS

Disk /dev/sdc: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x4a5e8b0b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1        2550    20482843+   7  HPFS/NTFS
/dev/sdc2            2551        9729    57665317+   7  HPFS/NTFS

Similar to what you have already researched, read my favorite aussie’s pages here… GRUB Boot Multiboot openSUSE Windows (2000, XP, Vista) using the Grub bootloader. and Boot Multiboot openSUSE Windows (2000, XP, Vista - any mix) with Windows bootloader. .

There was a bug in YaST Boot Loader that wipes out menu.lst - that is what I would suspect first. Are you able to boot the machine getting the grub prompt? If you can, I can give you the commands to boot openSUSE and once in you can install the patches and repair menu.lst. (If menu.lst is missing, the above links won’t help you.) If you can’t, I can help you fix it with the LiveCD.

Ah, mingus, it sounds like you might be on the right track.

Try what I might I just can’t get anything to stick in menu.lst (tried running Yast from liveCD, using install DVD to repair install, always get a blank menu.lst).

I can’t get into GRUB, but if you could help me write the correct line(s) in my menu.lst then I’m able to mount/edit it using the liveCD. Just don’t know what to put in there at the moment.

Would be much appreciated!

Won’t work running YaST from the LiveCD because it runs in RAM without a mounted root file system, and won’t work from the DVD because it contains the bug that was fixed. Even so, yes, we can rebuild it from the LiveCD. But how is that going to work if grub is not called at all when you start the machine? - we may need to fix that, too. You are now booting from either sdb or sdc. What happens if you set the bios to boot from sda? Regardless, I’ll need you to do the following before repairing menu.lst - boot the LiveCD, open a terminal, then do:

su -
mount -t ext3 /dev/sda5 /mnt
cat /mnt/boot/grub/device.map
cat /mnt/etc/grub.conf

Post the output back here.

Okay, thanks. I’ll run those commands when I’m back home.

In the meantime: if I use the “dd if=/dev/sda5 of=boot.lnx” route then it tries to pull up GRUB, it’s just that the screen is almost blank (just says “GRUB”) in the corner. Don’t know if that helps.

It is certainly (well, almost certainly) trying to boot from sda either via the “dd if=…” route or because I set it through XP using bootpart (which creates a boot.lnx file that points to any chosen partition, which is then called from boot.ini). At the moment it gives me a “no system disk” kind of an error. Again, I assumed that this was all related, with GRUB just not having anything in it.

What would help me get to the next stage, maybe, would be if I knew the answer to these two questions:

  1. Should I be pointing the boot manager at the extended partition (sda2) or the logical partition where my root folder, “/”, is located?

  2. Should I be ticking the “install boot loader in root partition” and the “extended partition” boxes in the OpenSuse boot manager installer?

Thank-you very much for your help with all of this. It is much appreciated.

if I use the “dd if=/dev/sda5 of=boot.lnx” . . .

I presume you know this syntax is incomplete; it needs to have “bs=512 count=1” at the end. Also, if you are using the ntldr method with boot.lnx in your Windows root directory, then all ntldr is doing is transferring control to the code in that copied sector, so its grub’s stage1 must have the correct embedded pointer to find its stage2. I haven’t tried using this method when the sector is from an extended or logical partition; I suspect that will work as long as it is on the same disk. But if you are booting from sdb or sdc and the boot sector was copied from sda, then I suspect this technique will not work; it may not be able to span disks.

In the meantime: if I use the “dd if=/dev/sda5 of=boot.lnx” route then it tries to pull up GRUB, it’s just that the screen is almost blank (just says “GRUB”) in the corner. Don’t know if that helps.

This usually means that grub stage1 is in the sda5 boot sector but that its embedded pointer to find stage2 is broken. Again, it may be because for it to work it must span the disks, and it may not be able to (ntldr has trouble with this). Note: If your intention is to eventually use W7, then it’s boot manager is much more flexible and powerful than XP’s; I would seriously consider using it to control all the booting on the machine.

At the moment it gives me a "no system disk" kind of an error.

A “no system disk” error is thrown by the bios when it cannot find bootstrap code in the boot disk’s MBR.

  1. Should I be pointing the boot manager at the extended partition (sda2) or the logical partition where my root folder, “/”, is located?

Depends on which partition’s boot sector holds stage1. Usually stage1 is put in the extended primary’s boot sector only when there is “generic” boot code in the MBR; that code will look for the “active” partition and transfer control to its boot sector. If stage1 is being “chainloaded” from another loader (as you are trying to do) then usually it is installed in the root partition boot sector.

  1. Should I be ticking the “install boot loader in root partition” and the “extended partition” boxes in the OpenSuse boot manager installer?

If you selected both, then grub stage1 has been installed in 2 different boot sectors (there can be reasons for doing this). In both sectors, the stage1 will point to the same location for stage2. And so either should work for a “chainload” boot - assuming there isn’t, again, an issue with spanning the disks.

Also, bear in mind with all this that grub at installation depends on the disk alignment in /boot/grub/device.map matching up with the bios boot disk configuration, and that if such is changed, that grub gets reinstalled and/or its menu.lst file reconfigured accordingly. Grub cannot know the configuration as the bios does not pass this data, so it depends on the user setting up device.map correctly. Menu.lst will use corresponding notation.

Okay, I’ve put in the code you asked for mingus. Output is …

linux@linux:~> su -
linux:~ # mount -t ext3 /dev/sda5 /mnt
linux:~ # cat /mnt/boot/grub/device.map
(hd2)   /dev/disk/by-id/ata-ST380013AS_3JV32XD1
(hd0)   /dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1LL946290
(hd1)   /dev/disk/by-id/ata-ST3120827AS_5MS06636
linux:~ # cat /mnt/etc/grub.conf
setup --stage2=/boot/grub/stage2 --force-lba (hd1,4) (hd1,4)
quit
linux:~ #

Does that help?

Again, thanks again for being so patient mingus. I can see you’re already answering this same sort of question for lots of people yet you take the time to answer in great detail for me. Many thanks. Makes for a much more pleasant experience than people just hurling random code around without explaining what’s going on.

A couple more things …

Doesn’t matter what order I put my drives in using the BIOS. If I choose sda (the 120Gb drive) it goes to the normal bootloader (presumably the 120Gb one is passed over as it has no MBR). If I choose sdc (the 80Gb) then it boots straight to Windows which must be because it’s still got the old MBR from when this was my primary XP disk.

I probably won’t use W7 in the end, but I have installed the beta. So for now I’m happy to use the W7 bootloader to tide me over until the beta expires in August, so if it makes it easier to put GRUB into action (e.g. avoids shrinking my XP partition and putting in a /boot partition) then that would suit me. I’m currently chainloading W7 bootloader, then XP bootloader (!).

I’d be happy to make sda my first disk in the BIOS and write a MBR (pointing to GRUB) on that one. If it all goes wrong, all I’d have to do is make my Windows disk (sdb) the first in the BIOS and I’d be back working again, right?

Glad to be of some assistance . . . just saw your latest post after I had about finished writing the following. To save time, I won’t edit all this, but loop back to your questions at the end.

From the guide that you used:

Before we proceed, let’s make a few assumptions: You’re using a single hard disk . . . Presumably, this should work on a system with two or more hard disks as well.

Unfortunately, the author presumed wrong. I posted earlier that the method you were using may not work because the sector is from another disk. To re-verify that (I also tested this quite a while ago), I set up a test case on my dev box. Two drives, both of which have multiple instances of Windows and multiple instances of Linux. Copied the boot sectors from an instance on an sda logical and another from an instance on an sdb logical to the Windows system partition and modified boot.ini accordingly. The boot succeeded using the sda8 sector but failed on the sdb5 sector; the failure displayed “GRUB” in the upper left-corner and hung, just as you experienced.

This method “chainloads” to the copied sector, which is how the MBR code works - it simply transfers control to the jump instruction at the front of the sector which in turn executes the stage1 code in the sector. In the sector is a BPB (bios parameter block) in which is embedded the disk address offset where stage2 is located. Stage1 has no way of knowing that the stage2 address is actually on another disk, nor can it interrogate the bios map for disk layout, etc. Nor does stage1 know that it itself is on a particular disk. It’s only function is to call stage2 at the designated disk sector address. If you wish, you can take a look at the sector you copied:

xxd boot.lnx

That’s a hex dump, but you will see the word “GRUB” - that is what you see from the executing stage1 code in the sector (up in the corner). But it locks because the BPB is for another disk.

Now to your last post’s points . . .

No, changing the boot sequence now to sda won’t work because the MBR is not set up to boot sda5. What you would need to do is (a) modify /boot/grub/device.map so that sda is grub’s (hd0), (b) modify /boot/grub/menu.lst to reflect this change in notation, (c) install grub to the sda MBR, (d) change the bios boot disk sequence to put SATA0 first (assuming the Seagate 120GB is on the first SATA port, sometimes the bios will read the ports in reverse, i.e., it could be SATA2). You can do all of the grub work from YaST Boot Loader.

Or you can boot using the W7 boot manager. From your posts, it didn’t appear that you installed W7 taking over boot control from XP, so I’m not sure exactly how you have it set up (independently on sdc1, using bios switch to boot?). W7 uses a program called bootmgr instead of ntldr, and bootmgr uses a registry hive located in the \boot directory of the system volume. Entries in the hive are similar to chainloading stanzas in grub’s menu.lst, there is both a disk and partition notation for the target sector. So bootmgr works well chainloading to any boot sector on any disk.

Finally, to your last question, yes, if for any reason sda got trashed, you could switch the boot back to the Samsung in the bios setup and the machine will boot Windows as it currently does.

Post back how you want to proceed and I can give you a bit more detail to step through it.

I’d prefer the GRUB-on-sda route (“What you would need to do is (a) modify /boot/grub/device.map …”). Improves my understanding of GRUB and gives me flexibility but doesn’t touch my fall-back MBR.

Could you walk me through it? Doesn’t sound too painful, but if I try to work it out myself I’ll likely spend days searching the internet and end up back here asking for help anyway …

Sure . . .

We need to work around the chicken-and-egg problem of SuSE not being bootable; how this is approached will depend on your bios. Please enter bios setup and reconfigure the boot device sequence to be (a) optical drive (b) Seagate 120GB SATA0 sda (c) Samsung 250GB SATA1 sdb; this must be done first. If the bios supports it, also configure sdc (where I assume W7 is installed) to follow sdb. Then boot the LiveCD, open a terminal, and do:

su -
grub
find /boot/grub/stage2

Grub should report back (hd0,4). If it does not, then do:

device (hd0) /dev/sda
device (hd1) /dev/sdb
find /boot/grub/stage2

Now it should definitely report back (hd0,4). If it does not, report back what happened. If it does, then proceed with:

root (hd0,4)
setup (hd0) (hd0,4)
quit

The setup command should return ~10 lines indicating stage1 was found, stage2 was found, and stage1 was installed to (hd0). Now reboot, removing the LiveCD. I expect that grub will load a text menu (you will see an error message on /boot/gfxmessage, the splash screen). But these menu selections will not work (yet) because menu.lst is still set up with sda being (hd1) not (hd0), which it now needs to be. So at the menu, press the ‘c’ key and you should be dropped into the grub shell. Then do:

root (hd0,4)
kernel /boot/vmlinuz root=/dev/sda5
initrd /boot/initrd
boot

This should boot you into openSUSE. Once there, go to YaST Online Updates and make sure the perl-bootloader and parted patches have been installed. Then go to YaST Boot Loader. Click on Other (bottom-right), click on Propose New Configuration (this will take a minute). Now click on Other, click on Edit Configuration Files. On the next screen, find device.map and make sure that (hd0) is aligned to sda, (hd1) is aligned to sdb, and (hd2) is aligned to sdc. If it is not this way, make it so in the text editing box below, then click OK, then again click Other, Edit Config Files, and verify the change was made. Then on the same screen look at menu.lst; the gfxmenu line should use (hd0) and in the SuSE boot stanzas below the root line should use (hd0); click OK. Then go to Section Management and look for section(s) added for booting Windows; they should show “chainloader=/dev/sdb1” and “chainloader=/dev/sdc1”. If there isn’t such a stanza, click on Add and it will walk you through adding it. Now click on the Boot Loader Installation tab and uncheck any boxes in the Location column. Now click Finish. You should now have working device.map and menu.lst files. (Note: I used this method to give you some familiarity with this YaST module, we could have just done this directly with a text editor.)

Now reboot. You should get a splash screen, the selections should all work. If the SuSE boot doesn’t work from this menu, boot using the shell as before, and post back here the contents of device.map and menu.lst by opening a terminal and doing:

su -
cat /boot/grub/menu.lst
cat /boot/grub/device.map

Go slow. :wink:

That’s odd. It was all going swimmingly and everything looked right first time. I didn’t have to change anything manually - it was all set up as expected. But after the final reboot, I got a “no active partition” then “install hal.dll” error.

I’ll try running through again. Something must have changed the MBR info on sda after the initial changes that made it boot GRUB happily. Must have done something wrong in YAST.

Deep breath …

Hurrah! Success at last.

Once I ran the “setup (hd0) …” commands again it booted to GRUB properly. Quickly edited my menu.lst and now it fires up Windows nicely too.

Many, many thanks Mingus. Finally I can play with my OpenSUSE.:slight_smile:

Terrific! :slight_smile:

fwiw, the “no active partition” error is thrown by “generic” (DOS) code in the MBR; my guess is that the “propose new configuration” decided to not install grub in the MBR but instead put generic code there. On the Boot Loader Installation screen, when you click Boot Loader Options that presents another screen where this setup is controlled - my bad, I didn’t think to have you check that.