Secondary grub boot

English Install/Boot/Login
#1

I’m not sure if this should really be in the beta forum. But I’ll start here.

I have 11.4 running on my laptop.

I later installed the live gnome 3 CD, installing into a separate partition (sda10). The install overwrote the boot sector for the extended partition (sda4), but booted gnome 3 nicely. This was expected.

I restored the prior contents of sda4, so that I could get into my original 11.4 install. That worked too.

I next added grub entry so that I could do a secondary boot into gnome 3.


title gnome3
    root (hd0,9)
    configfile /boot/grub/menu.lst

That, too, worked as expected. If I selected “gnome 3” from the main grub menu, the secondary grub menu was shown and I could use that to boot into gnome 3.

That’s all background.

I later installed 12.1 M2 into the sda10 partition, overwriting the gnome 3 install. I told the installer to install grub in the root partition (instead the extended partition).

Now, when I boot, if I select gnome 3 from the main boot menu, it takes me into M2 (actually M3 now - I just updated).

That’s all fine. But here’s the problem:

Selecting gnome 3 does not display the secondary grub menu. It just boots me into the first item on the menu (even when the third item is listed as the boot default). So I don’t get a chance to select between default and desktop kernels, or standard or failsafe boots with the use of the secondary grub.

What went wrong? How do I fix it? Or is this a 12.1 bug?

#2

Hmmm … I don’t use the configfile command and I’m not sure how it works in this case. But if I understand correctly, you’re trying to load 12.1 stage2 (installed in sda10) from 11.4 menu (stage2 in some partition) previously loaded by 11.4 stage1 installed in sda4. Since you also installed 12.1 stage1 in sda10, couldn’t you chainload this Grub and tell us if it behaves differently? That would be:

title whatever
    root (hd0,9)
    chainloader +1

I assume that /boot/grub/menu.lst in sda10 is correct and doesn’t have a timeout of 0 (?).

If you wonder which stage1 is looking for which stage2 and where, you might want to try findgrub](http://forums.opensuse.org/english/other-forums/development/programming-scripting/447138-looking-grub-windows-bootloader-all-partitions-12.html#post2366377).

fingrub -k can also list all Linux kernels found on all partitions (but it doesn’t use os-prober for scanning - unlike updategrub](http://forums.opensuse.org/english/get-technical-help-here/how-faq-forums/advanced-how-faq-read-only/458238-updategrub-opensuse-legacy-grub-not-update-grub.html#post2329167))

  • Speaking of that, I just noticed a minor bug in the display (which doesn’t affect the info) that I’m going to fix right now - I have been trying to shorten the code while adding new features. As jdmcdaniel3 would say, we don’t get points for writing shorter code - but if the code is less than 15.000 characters (actually less than that), we can post it in the forum. Otherwise we have to past it somewhere and it is less elegant (but I’m aware that I’m a snob).

I’m also interested in learning if findgrub actually identifies 12.1 Grub as “openSUSE”. If it does not, I’ll be busy looking for its signature in bootsector sooner or later.

#3

Excellent suggestion. I have now tried that. And it behaves the same way.

The “menu.lst” looks correct to me. The timeout is 8. Apart from the actual boot lines, the menu.lst looks much the same as in the 11.4 menu.lst

Here’s the output from running “findgrub” on the 12.1 system:


# findgrub
Find Grub Version 3.4 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ...
 - searching partition /dev/sda1      ()              ...
 - searching partition /dev/sda2      (NTFS)          ... --> Windows7/Vista Loader found in /dev/sda2

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda2
    rootnoverify (hd0,1)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - searching partition /dev/sda3   *  (NTFS)          ... --> Windows7/Vista Loader found in /dev/sda3

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda3
    rootnoverify (hd0,2)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - reading bootsector  /dev/sda4      (Extended)      ... --> Grub  found in /dev/sda4   => sda5   0x83 (openSUSE)
 - reading bootsector  /dev/sda5      (LINUX)         ...
 - searching partition /dev/sda6      (FAT32)         ...
 - reading bootsector  /dev/sda7      (LINUX)         ...
 - reading bootsector  /dev/sda8      (LINUX)         ...
 - skipping partition  /dev/sda9      (swap)         
 - reading bootsector  /dev/sda10     (LINUX)         ... --> Grub  found in /dev/sda10  => sda10  0x83 (openSUSE)


Press <enter> to Exit findgrub...
#4

An update.

I tried booting again, still using the chainload method. This time I did get the full boot menu. Perhaps there was a careless keystroke on my first try.

At least that is some progress.

The reason I need the full menu, is that thus far 12.1 M3 is booting fine with the default kernel, but just giving me a blank screen with the desktop kernel.

I guess the next step to try will be to copy the desktop kernel and initrd files to my 11.4 “/boot” (which is a separate partition), and try booting 12.1M3 directly with the 11.4 grub. Is there anything else I need to copy (such as the symtable)? I would not think so, but I’m not a grub expert.

#5

Since you don’t have Grub in MBR (according to findgrub output) and your sda3 partition is active, you must boot Grub from the Windows Boot Manager. Is that right? It adds one level of complexity. Did you update the bs file you’re loading from Windows? I would set the bootflag on sda4 (easy done with findgrub -a). You can reactivate the Windows partition at any time (with fdisk). We know that Grub installed on sda4 will load its menu from sda5. Now in this menu, you can chainload Grub installed on sda10 (using the entry I posted previously) and it should display the menu in sda10. If this menu doesn’t let you select the 12.1 kernel you want to boot and assuming the syntax is correct, I don’t have an explanation either (might be a bug indeed). Why don’t you also try to add 12.1 kernel entries in 11.4 menu.lst in sda5? You can do that easily by just running updategrub under 11.4 or updategrub -i to see a menu where you can enable/disable boot entries, or just by copying/pasting the entries manually. But better use updategrub, so we will learn how os-prober deals with openSUSE 12.1 (you have to run updategrub on 11.4. It ignores the host system and looks for others). The thread might indeed belong in the beta forum - but you were right to post it here somehow, because I wouldn’t have looked in the beta forum. :frowning:

  • Sorry, I didn’t see your post (was busy looking for typos in my answer).
#6

Yes, I do currently have Windows as the primary boot. That’s because Windows will boot stand-alone, while linux requires an encryption key (I am encrypting “/home” and swap). If I turn it on, and forget to hang around, then it will at least boot Windows.

Since I am using 11.4 as primary grub, the install of 12.1 did not require updating the Windows booter. Using the secondary boot entry in the primary grub should take care of that.

Here’s what I am currently thinking. Maybe the BIOS cannot read all of sda10, and was only seeing the beginning of menu.lst . And maybe the reason the desktop kernel isn’t working, is that the BIOS cannot read it. That’s why I plan to copy the desktop kernel to “/boot” from my 11.4 install.

I still think that I had the same incorrect behavior on my first attempt to chain boot 12.1. Before the second attempt, I copied over an alternate version of menu.lst (with the desktop line first). That copy could have resulted in menu.lst being located earlier on the disk. When I attempt to boot the Desktop kernel, it prints the boot line and immediately hangs. There is no indication that it is actually trying to load the kernel. Oh, the sda10 partition does straddle the 128G mark on the disk, and supposedly that’s a problem for some BIOS versions.

#7

If I correctly remember you mentioned this method already. What can I say? The BIOS doesn’t know nor care about logical partitions at boot time. You were able to chainload sda10 successfully, so its bootsector is not out of range. Copying kernels from one release/distro to a common /boot partition is not something I would do, even if the start sector of the partition was too far away. Whenever I encountered similar problems - back to the time of the 1023 cylinder limit, about 15 years ago - I simply created as many /boot partitions as I needed. As for the 128G LBA limit, I saw the problem once on a mainboard which defaulted to Legacy IDE mode. Switching to AHCI allowed me to boot from anywhere.

No. That’s not how it works. And by the way the menu is user-friendly but not necessary to boot (you could also type commands in the Grub shell). Only the offset and BIOS drive (if you have more than one) of stage2 matters to stage1. That’s what findgrub reads in bootsectors to determine in which partition stage2 is located. An that’s why you have to reinstall stage1 if you move stage2.

That the desktop kernel of a Milestone version might hang on some machines is not really surprising, I guess.

#8

The original configfile entry in the 11.4 grub is now displaying the full menu. The only change from when it didn’t work properly, is that I copied the “menu.lst” that didn’t work to elsewhere on the disk before editing to restore the default kernel boot to first position. Then I copied it back. Both times, I used “cp -p” to copy. The difference cannot be the content of “menu.lst”. The only change would be in the disk sectors occupied by “menu.lst”.

It seems to still hang after the change in how I am booting.

One last check will be to copy the default kernel and initrd instead, and make sure that my 11.4 boot line works for that.
Okay, tried that and it boots fine to the default kernel. So the desktop kernel does indeed hang.

I’ll report this on the M3 thread. Thanks for your suggestions here.

#9

I’m guessing the OP has Nvidia card which will mean he’s hit the “nomodeset” issue - openSUSE:Most annoying bugs 12.1 dev - openSUSE
Bugs https://bugzilla.novell.com/show_bug.cgi?id=706305 https://bugzilla.novell.com/show_bug.cgi?id=707110 https://bugzilla.novell.com/show_bug.cgi?id=707148

Fix info - https://bugzilla.novell.com/show_bug.cgi?id=707110#c6
Please confirm oldcpu’s work if you can, he’s feeling lonely! :wink:

#10

No, bad guess. I have an Intel card. I am not making it as far as the nouveau issue indicates. It is looking to me as if the attempt to load the desktop kernel is failing. That is, it hangs during kernel load rather than after the kernel has loaded.

Perhaps I need to reinstall that desktop kernel.

I failed to mention in earlier posts in this thread, that M3 is installed as 32 bit, though the hardware is capable of 64 bit. The default kernel would be fine, but it limits me to 4G of memory (there is actually 6G).

#11

No. I mean, stop believing that the sector of menu.lst is relevant!.. unless it is damaged and in that case, just replace the hard disk! Grub is able to read the filesystem at this point, so it will find the menu or not and act accordingly.

If you remove or rename menu.lst and chainload Grub on sda10, what do you see? The Grub shell prompt:

grub>

In this shell, type:

root (hd0,9)
kernel /boot/vmlinuz-xxx........ root=/dev/sda10 .... ( + kernel options if needed) 
initrd /boot/initrd-xxx.....
boot

You can even use tab to see the filenames (it doesn’t complete them though). Now, can you reach the kernels on this partition? Yes. Where is menu.lst? Gone! What is its sector number? Nothing. To whom does it still matter? :wink:

If the kernel still hangs, that’s not Grub’s fault. Grub would have complained earlier if it had not found it.

#12

I still have the observed fact that grub did not display the menu. Then I copied menu.lst to elsewhere, and later copied it back. And, since then, the menu has been displayed. It should not be a damaged sector, since the copies worked just fine. Well, I suppose error recovery might be better when the sector is read by a kernel rather than by the bios.

In any case, I agree that the kernel hanging is a kernel problem, not a grub problem.

#13

I was kidding. I simply don’t know how else I should explain you that the physical sector of menu.lst doesn’t matter, and that’s why I’ve been trying to say that the file itself didn’t matter. You could also use a symlink for menu.lst (Fedora actually does) and it would work too, because at this point stage2 has been already loaded and looks for the menu in the filsesystem, not in sectors. The sector of stage2 however does matter to stage1.

Here’s an example of a machine where openSUSE’s Grub stage1 and stage2 are on /dev/sda11 (as shown in findgrub output below)


# findgrub
find Grub Version 3.4.1 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ... --> Grub2 found in sda MBR     => sda6   0x83 (Ubuntu)
 - searching partition /dev/sda1   *  (FAT16)         ... --> Windows NT/2K/XP Loader found in /dev/sda1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
    rootnoverify (hd0,0)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - skipping partition  /dev/sda2      (FreeBSD)      
 - skipping partition  /dev/sda3      (FreeBSD)      
 - reading bootsector  /dev/sda4      (Extended)      ... --> Grub  found in /dev/sda4   => sdb6   0x83 (Mandriva)
 - skipping partition  /dev/sda5      (swap)         
 - reading bootsector  /dev/sda6      (LINUX)         ... --> Grub2 found in /dev/sda6   => sda6   0x83 (Ubuntu)
 - reading bootsector  /dev/sda7      (LINUX)         ...
 - reading bootsector  /dev/sda8      (LINUX)         ...
 - reading bootsector  /dev/sda9      (LINUX)         ...
 - reading bootsector  /dev/sda10     (LINUX)         ...
 - reading bootsector  /dev/sda11     (LINUX)         ... --> Grub  found in /dev/sda11  => sda11  0x83 (openSUSE)
 - reading bootsector  /dev/sda12     (LINUX)         ...
 - reading bootsector  /dev/sda13     (LINUX)         ...
 - reading bootsector  /dev/sda14     (LINUX)         ...
 - reading bootsector  /dev/sda15     (LINUX)         ... --> Grub  found in /dev/sda15  => sda15  0x83 (Mandriva)
 - reading bootsector  /dev/sda16     (LINUX)         ...
 - reading bootsector  /dev/sda17     (LINUX)         ...
 - reading bootsector  /dev/sda18     (LINUX)         ...
 - reading bootsector  /dev/sda19     (LINUX)         ... --> Grub  found in /dev/sda19  => sda19  0x83 (Mandriva)
 - reading bootsector  /dev/sda20     (LINUX)         ...

 - reading MBR on disk /dev/sdb                       ... --> Grub  found in sdb MBR     => sda11  0x83 (openSUSE)
 - searching partition /dev/sdb1      (FAT16)         ... --> Windows NT/2K/XP Loader found in /dev/sdb1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sdb1
    rootnoverify (hd1,0)
    map (hd1) (hd0)
    map (hd0) (hd1)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - skipping partition  /dev/sdb2      (FreeBSD)      
 - skipping partition  /dev/sdb3      (FreeBSD)      
 - reading bootsector  /dev/sdb4   *  (Extended)      ... --> Grub  found in /dev/sdb4   => sda11  0x83 (openSUSE)
 - skipping partition  /dev/sdb5      (swap)         
 - reading bootsector  /dev/sdb6      (LINUX)         ... --> Grub  found in /dev/sdb6   => sdb6   0x83 (Mandriva)
 - reading bootsector  /dev/sdb7      (LINUX)         ...
 - reading bootsector  /dev/sdb8      (LINUX)         ...
 - reading bootsector  /dev/sdb9      (LINUX)         ...
 - reading bootsector  /dev/sdb10     (LINUX)         ...
 - reading bootsector  /dev/sdb11     (LINUX)         ...
 - reading bootsector  /dev/sdb12     (LINUX)         ...
 - reading bootsector  /dev/sdb13     (LINUX)         ...

 - reading MBR on disk /dev/sdc                       ...

And Here’s a quick and dirty script which checks stage2 inode and sector. You can call it with /dev/sda10 as argument. It’s quick and dirty and will work only if stage1 and stage2 are on the same partition (which is the case here).

#! /bin/bash
# findstage2

dev=$1

stage2_offset=$(hexdump -v -s 68 -n 4 -e '"%u"' $dev)

printf "grub on %s looks for stage2 at sector %s
" $dev $stage2_offset

stage2_inode=$(find /boot/grub -name stage2 -ls | awk '{ print $1 }')

printf "stage2 first inode is %s
" $stage2_inode

blocksize=$(/sbin/dumpe2fs -h $dev 2>/dev/null | sed -n '/Block size:/s/.*: *//p')

printf "blocksize of filesystem in %s is %s
" $dev $blocksize

sectorsize=$(/sbin/fdisk -lu ${dev:0:8} | awk '/Sector size/{ print $(NF-1)}')

printf "sectorsize of harddisk %s is %s
" ${dev:0:8} $sectorsize

startsector=$(/sbin/fdisk -lu ${dev:0:8} | grep "$dev " | awk '{print $2}')

printf "startsector of partition %s is %s
" $dev $startsector

fsblock=$(((($stage2_offset - $startsector)*$sectorsize)/$blocksize))

printf "filesystem block of stage2 in %s is %s
" $dev $fsblock

**debugfs $dev -R "icheck $fsblock" 2>/dev/null**

Here’s the output on this script on my computer (with openSUSE root in /dev/sda11)

# findstage2 /dev/sda11
grub on /dev/sda11 looks for stage2 at sector 628086648
stage2 first inode is 87657
blocksize of filesystem in /dev/sda11 is 4096
sectorsize of harddisk /dev/sda is 512
startsector of partition /dev/sda11 is 625137408
filesystem block of stage2 in /dev/sda11 is 368655
Block   Inode number
**368655  87657**
  • We determine the start sector of stage2 by hexdumping stage1 (command and result in blue)
  • Using find, we get the inode of /boot/grub/stage2 (command and result in green)
  • We determine the blocksize by reading the partition’s superblock - although it’s almost always 4096 (command and result in purple)
  • Using the info provided by fdisk, we determine the block number (command and result in red)
  • finally we determine the inode of this sector block by debuging the filesystem (last command and result in bold)

I hope it helps make it clearer.

#14

No.

Fact: Nothing changed in “/boot” (on sda10 or on sda5) other than menu.lst (/boot/grub/menu.lst on sda10).

And the contents of that “menu.lst” did not change. All that happened is that menu.lst was copied elsewhere. Then the original was edited (to change the order of entries), and the edited version was copied elsewhere. Then the copy of the original version that was elsewhere was now copied back.

Nothing else changed. However, the behavior of grub changed. It now started acting as it should, and displaying a menu during boot, instead of booting into the first entry.

You can present elaborate explanations as to how the disk sector does not matter. I agree that it should not matter. But the explanation does not match the observed facts. When the explanation does not fit the facts, something is missing in the explanation.

#15

If booting without menu.lst (did you try that?) does not prove that the location and the existence of this file is irrelevant (to boot one kernel or the other), I guess I should rather let you believe what makes you feel better. You’ll not be the first person to believe his own observations more than any logical explanation.

Do you seriously believe that or were you just trying to be nice? lol!

#16

Obviously, the existence and readability of that file is a requirement for it to be able to display the menu that is in the file.

That I could boot without the file does nothing to explain why the menu was not displayed and the first menu item booted, when the menu should have been displayed. That is what was unexplained when I started this thread, and is what remains unexplained.

#17

And it will remain unexplained until you aknowledge your mistake and lack of understanding ( + the fact that you’re dealing with a Milestone version).
Over and out.

#18

Sorry, but I don’t know what mistake I am supposed to acknowledge.

You keep explaining to me that grub reads the file system. I have never challenged that. I don’t know what you think is gained by repeatedly explaining what has not been questioned.

As best I can tell, based on web documentation, grub does not contain its own disk device drivers. It apparently relies on the drivers provided by the BIOS. And therefore, any limitations of the BIOS would affect it. That it reads the file system doesn’t magically eliminate BIOS restrictions if it uses the BIOS to read the file system.

I hypothesized that there might be such a problem here. I don’t know it to be true. It is only a tentative hypothesis. I would certainly be interested in a better hypothesis. Thus far, no alternative has been offered.

It is my impression that when I used the “configfile” entry in the 11.4 grub, the menu should be displayed by that 11.4 grub, which is not a Milestone version.

Sure, the hang during the attempt to load the desktop kernel is probably because it is a Milestone version. I have already acknowledged that. All along, I thought that the most likely explanation for that problem, though it was worth experimenting with other possibilities.

#19

Would have been a big time waster if that was the cause. Hmmmmm Is it a jornalled filesystem that GRUB has to read? It can’t do a replay on unclean filesystem, so I’ve seen quite Bugzilla’s about quite subtle problems to do with suspend to disk, or unexpected shutdown; ReiserFS & XFS were most affected. They had me glad, that I’d stuck to ext2 for /boot. There was kernel crashes with 12.1 M3 update, but I can’t remember if / was remount rw at that stage or not. If it was an issue like that, you might see strange effects, as a result of GRUB only having 16 bit code and very limited memory. Also if your BIOS was limitted in LBA number then copying the file so it’s allocated new sectors could indeed “make it work”, the openSUSE installer warns in fact just of such a possibility.

#20

Yes, it is ext3. I have wondered whether that could be a problem. Still, it should not have been dealing with an unclean filesystem. When the attempt to load the desktop kernel failed, I had to power off. I rebooted to 11.4, and ran “fsck” on “/dev/sda10”. It showed as clean. The kernel load had not gotten far enough to contaminate the root partition.

When I was running M2, I had occasion freezes (video related, happens in 11.4 unless I use “nomodeset”). And those did leave the partition unclean.

I always keep “/boot” as ext2 when that’s on its own partition. There never seemed to be a point in journaling for that. But my install for M3 does not have a separate “/boot” partition.