Reactivation of a boot menu after installation of openSUSE 12.1

Today I could install openSUSE 12.1 on a new hard disk almost successfully. The freshly installed system was running fine after it was started by the installation system from a DVD.
Unfortunately, I stumbled on the next annoyance after a reboot of my computer. I expect that the software component “Grand Unified Boot Loader 0.97-177.1.2” should display a nice menu. But it does not appear from the selected boot partition.

Fortunately, I have still got a working GRUB menu on an other partition on a different hard disk where I could extend the configuration file “menu.lst” so that I can start openSUSE 12.1 with an entry from there at least. I wonder why the other boot configuration does not work as expected. Would you also like to find out where the nasty differences and errors are?

So, most often, this issue is caused by not making sure the hard disk boot order has the disk you installed openSUSE on to as being first. All new BIOS’ allow the selection of any drive to boot from, but if the target installation disk is not first in hardware order, even if selected as being first, openSUSE can place the grub bootloader on the wrong disk AND, the device.map file will not properly reflect the correct booting order. Apparently, there is no way to determine the boot drive selected by the BIOS. If you have not done too much with openSUSE, you can just reinstall, paying a closer attention to the booting section setup (hard disk Boot order & the location for Grub). If you have a working boot setup, it is possible to repair same. We would ask for the following information. Open up a terminal session and run:

sudo cat /boot/grub/device.map 
sudo cat /boot/grub/menu.lst 
sudo cat /etc/fstab 

Copy and then past the output of each command into a forum message using the Advanced message editor and placing the text withing a highlighted Code # field. It will look like the command above. With this info, we may be able to provide some help. There is also a great utility called findgrub by please_try_again that can be ran and gives very good booting information you can find here: http://www.unixversal.com/linux/open…grub-3.5.1.tgz, decompress the file, I would save it in the bin folder (/home/yourname/bin/findgrub). To use, open up a terminal session and run this command:

findgrub 

Thank You,

I specified that GRUB should start from the second partition on the hard disk while MBR adjustment should be excluded for my current system. I had to mark my new GRUB partition as bootable myself with the tool “fdisk” after the DVD installation application was “finished” with its configuration process.

Sonne:~ # cat /boot/grub/device.map
(hd0)   /dev/sda
(hd2)   /dev/sdc
(hd1)   /dev/sdb
Sonne:~ # cat /boot/grub/menu.lst
# Modified by YaST2. Last modification on Sa Nov 26 19:13:36 CET 2011                                                                                                                         
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader                                                                                                                                  
# For the new kernel it try to figure out old parameters. In case we are not able to recognize it (e.g. change of flavor or strange install order ) it it use as fallback installation parameters from /etc/sysconfig/bootloader

default 0
timeout 8
gfxmenu (hd2,1)/message

###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop -- openSUSE 12.1 - 3.1.0-1.2
    root (hd2,1)
    kernel /vmlinuz-3.1.0-1.2-desktop root=/dev/duda/root resume=/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1UA109248-part5 splash=silent quiet showopts vga=0x31b
    initrd /initrd-3.1.0-1.2-desktop

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 12.1 - 3.1.0-1.2
    root (hd2,1)
    kernel /vmlinuz-3.1.0-1.2-desktop root=/dev/duda/root showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x31b
    initrd /initrd-3.1.0-1.2-desktop

###Don't change this comment - YaST2 identifier: Original name:  Plop Boot Manager (/dev/sda2)###
title Plop Boot Manager
    rootnoverify (hd0,1)
    chainloader +1

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

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe - openSUSE 12.1
    root (hd2,1)
    kernel /vmlinuz-3.1.0-1.2-desktop root=/dev/duda/root showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x31b
    initrd /initrd-3.1.0-1.2-desktop

###Don't change this comment - YaST2 identifier: Original name: other###
title altes GRUB-Menü
    rootnoverify (hd0,1)
    chainloader +1
Sonne:~ # cat /etc/fstab
/dev/duda/root       /                    ext3       acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 1
/dev/sdc2            /boot                ext3       acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 2
/dev/duda/home       /home                ext4       acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 2
/dev/duda/opt        /opt                 ext4       acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 2
/dev/duda/swap       swap                 swap       pri=1                 0 0
/dev/duda/usr        /usr                 ext4       acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 2
/dev/duda/var        /var                 ext4       acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 2
/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1UA109248-part5 swap                 swap       pri=88                0 0
/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1UA109249-part5 swap                 swap       pri=99                0 0
/dev/system/swap     swap                 swap       defaults              0 0
/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1UA109248-part1 /windows/C           ntfs-3g    users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1UA109249-part1 /windows/D           ntfs-3g    users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B901367-part1 /windows/E           ntfs-3g    users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1UA109248-part6 /windows/F           ntfs-3g    users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
/dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1UA109249-part7 /windows/G           ntfs-3g    users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0

Thanks for your link to the tool for the issue “Looking for Grub and Windows bootloader in all partitions”.

Sonne:~/geladen # ./findgrub
Find Grub Version 3.5.1 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ...
 - searching partition /dev/sda1      (NTFS)          ... --> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - reading bootsector  /dev/sda2   *  (LINUX)         ... --> Legacy GRUB  found in /dev/sda2   => sda2   0x83 (openSUSE)
 - reading bootsector  /dev/sda3      (Extended)      ...
 - skipping partition  /dev/sda5      (swap)         
 - searching partition /dev/sda6      (NTFS)          ...

 - reading MBR on disk /dev/sdb                       ...
 - searching partition /dev/sdb1      (NTFS)          ...
 - reading bootsector  /dev/sdb2      (Extended)      ...
 - skipping partition  /dev/sdb5      (swap)         
 - searching partition /dev/sdb6      (LINUX LVM)     ...
 - searching partition /dev/sdb7      (NTFS)          ...

 - reading MBR on disk /dev/sdc                       ...
 - searching partition /dev/sdc1      (NTFS)          ...
 - reading bootsector  /dev/sdc2   *  (LINUX)         ... --> Legacy GRUB  found in /dev/sdc2   => sdc2   0x83 (openSUSE)
 - searching partition /dev/sdc3      (LINUX LVM)     ...

Which analysis steps should I consider next?

Should I try a GRUB re-installation for the second instance?

So elfring, you made lots of changes form normal. As I see it, to get openSUSE 12.1 to load, you would have to place the /dev/sdc hard drive as the boot drive. If the drive fails to boot, it may be because you did not think to copy generic booting code into the MBR and you loaded grub into partition sdc2. This single issue trips up many who load openSUSE into a hard drive that is not the normal boot drive. Other oddities I see are:

  1. You have modified the device.map file to use logical device names and not the normal device-by-id that is placed there (Not sure is LVM would do this)
  2. If you were to place /dev/sdc as the boot drive, the device.map file would be wrong as the boot drive must always be designated as HD0 there and in the menu.lst file.
  3. Using LVM is not the normal with openSUSE with fewer people around to provide assist on how to use it.
  4. I don’t know what device /dev/duda unless associated with LVM
  5. if /boot is located on /dev/sda2, sda is the designated boot drive, then you would think openSUSE could be loaded, but not sure what error message you are getting.
  6. As before, we normally use disk-by-id in the fstab file. When this is used, moving drives around and changing the BIOS boot drive still allows openSUSE to boot and run.

As a little more help, here is my disk partitioning blurb

Each hard drive can have up to four PRIMARY partitions, any of which could be marked active and bootable. No matter what you might hear, only one of the first four primary partitions can be booted from. That means you can boot from Primary partitions 1, 2, 3 or 4 and that is all. In order to boot openSUSE, you must load openSUSE and the grub boot loader into one of the first four partitions. Or, your second choice is to load the grub boot loader into the MBR (Master Boot Record) at the start of the disk. The MBR can be blank, like a new disk, it can contain a Windows partition booting code or generic booting code to boot the active partition 1, 2, 3, or 4. Or, as stated before, it can contain the grub boot loader. Why load grub into the MBR then? You do this so that you can “boot” openSUSE from a logical partition, numbered 5 or higher, which is not normally possible. In order to have more than four partitions, one of them (and only one can be assigned as extended) must be a extended partition. It is called an Extended Primary Partition, a container partition, it can be any one of the first four and it can contain one or more logical partitions within. Anytime you see partition numbers 5, 6 or higher for instance, they can only occur inside of the one and only Extended Primary partition you could have.

What does openSUSE want as far as partitions? It needs at minimum a SWAP partition and a “/” partition where all of your software is loaded. Further, it is recommended you create a separate /home partition, which makes it easier to upgrade or reload openSUSE without losing all of your settings. So, that is three more partitions you must add to what you have now. What must you do to load and boot openSUSE from an external hard drive? Number one, you must be able to select your external hard drive as the boot drive in your BIOS setup. Number two, you need to make sure that the external hard drive, perhaps /dev/sdb, is listed as the first hard drive in your grub device.map file and listed as drive hd0. I always suggest that you do not load grub into the MBR, but rather into the openSUSE “/” root primary partition which means a primary number of 1, 2, 3 or 4. If number one is used, then that will be out. You will mark the openSUSE partition as active for booting and finally you must load generic booting code into the MBR so that it will boot the openSUSE partition. I suggest a partition like this:

  1. /dev/sda, Load MBR with generic booting code
  2. /dev/sda1, Primary NTFS Partition for Windows
  3. /dev/sda2, Primary SWAP (4 GB)
  4. /dev/sda3, Primary EXT4 “/” openSUSE Partition Marked Active for booting (80-120 GB)
  5. /dev/sda4, Primary EXT4 “/home” Your main home directory (Rest of the disk)

<or>

  1. /dev/sdb, Load MBR with generic booting code
  2. /dev/sdb1, Primary SWAP (4 GB)
  3. /dev/sdb2, Primary EXT4 “/” openSUSE Partition Marked Active for booting (80-120 GB)
  4. /dev/sdb3, Primary EXT4 “/home” Your main home directory (Rest of the disk)

<or>

  1. /dev/sdc, Load MBR with generic booting code
  2. /dev/sdc1, Primary SWAP (4 GB)
  3. /dev/sdc2, Primary EXT4 “/” openSUSE Partition Marked Active for booting (80-120 GB)
  4. /dev/sdc3, Primary EXT4 “/home” Your main home directory (Rest of the disk)

The information from findgrub is very informative and all thanks for it goes to please_try_again.

Thank You,

Yes. - That is the way my configuration should look like. I chose such settings in the graphical user interface of the installation system from a DVD.

You have modified the device.map file to use logical device names and not the normal device-by-id that is placed there

No. - The installation process generated this file.

Using LVM is not the normal with openSUSE with fewer people around to provide assist on how to use it.

I have been using logical volume management for years (since openSUSE 10.2?) on my system. :wink:

I don’t know what device /dev/duda unless associated with LVM

That is just a LVM area on a new hard disk.

if /boot is located on /dev/sda2, sda is the designated boot drive, then you would think openSUSE could be loaded, but not sure what error message you are getting.

I can still use the GRUB menu there while it does not work from “/dev/sdc2” directly if I select the other disk (BIOS shortcut “F8”) for booting. Only a blank (black) screen is displayed so far for the other boot approach.

It seems that I need to look again if a command like the following will repair my recently added boot configuration.

Sonne:~ # mkdir /mnt/B && mount /dev/sdc2 /mnt/B && grub-install --recheck --root-directory=/mnt/B /dev/sdc2

I have added another entry to my working boot menu with the marching penguins of the winter theme.

title anderes GRUB-Menü                                                                                                                                                                                            
    rootnoverify (hd2,1)
    chainloader +1

This setting works actually. - A green openSUSE 12.1 menu is displayed from which I can also boot the provided kernel. :slight_smile:

Now I can jump between both boot menus by the feature “Chain-loading” successfully, too. :wink:

If I choose a boot try (BIOS shortcut “F8”) from my new hard disk and if the display on the screen remains black, does this mean that the first sector from this boot partition has got inappropriate settings anyhow? :\

If I choose a boot try (BIOS shortcut “F8”) from my new hard disk and if the display on the screen remains black, does this mean that the first sector from this boot partition has got inappropriate settings anyhow? :\

So it is hard to be 100% certain, but if you do not designate the MBR (Master Boot Record) be loaded with either 1) Grub or 2) Generic booting Code AND this was not the original boot drive AND it has not been used to boot any computer before, then the MBR is very likely blank. Since you say the screen just goes blank, that might mean that something is being loaded from the boot sector, but its corrupted for some reason and is a problem as explained above and means it was not over written. Some BIOS’, when they are instructed to boot from a boot drive with no boot sector, they then complain about the problem and not go blank. Some BIOS’ just go on to the next hard drive in sequence which may actually be the one with a corrupted boot sector, thus causing the blank screen. If this was me and I really wanted to boot from that hard drive, I just reinstall knowing what we have already talked about, but consider there is nothing wrong at all with doing a chain load as it works and adds little extra time to the startup. Also, I have a fastboot bash script program you can use to restart openSUSE for any reason that does not require you to actually reboot your setup to just restart openSUSE due to a kernel update or other change.

FastBoot for Grub Legacy Menu using Kexec - Version 1.32 - Blogs - openSUSE Forums

Thank You,

By the way: Do you find the information from an article like “Persistant Storage Device Names” interesting?

I reordered a few menu entries by the tool “YaST2 bootloader”. It displayed that the openSUSE boot loader was also re-installed.
But my situation did not change after a reboot.

I intended to leave it “untouched” on the new hard disk at the moment.

…], then the MBR is very likely blank.

Yes. - I expect this, too. :wink:

Some BIOS’, when they are instructed to boot from a boot drive with no boot sector, they then complain about the problem and not go blank.

I’m sorry that I do not know so far if the used AMI BIOS does not like an empty MBR. - Which software component should I convince to boot from the second partition on this disk directly?

…], but consider there is nothing wrong at all with doing a chain load as it works and adds little extra time to the startup.

I would like to avoid a bit of “GRUB menu hopping”? :wink:

FastBoot for Grub Legacy Menu using Kexec - Version 1.32 - Blogs - openSUSE Forums

Thanks for this link and your support.

Does this tool work also in a 64 bit environment currently?

You can use updategrub to add (kernel and chainload) entries to both Grub menus. You can install updategrub from my repo - the package also includes findgrub.
The updategrub howto is here: 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

  • It still refers to the 11.4 repo. You would install the 12.1 for version 12.1:
sudo zypper ar [noparse]http://download.opensuse.org/repositories/home:/please_try_again/openSUSE_12.1/[/noparse] PTA

The devel thread is here:
http://forums.opensuse.org/english/other-forums/development/programming-scripting/458234-updategrub-opensuse-legacy-grub-not-update-grub.html

updategrub and findgrub have some in common but don’t do everything the same way. updategrub uses (and installs) os-prober to find Linux kernels on other partitions - just like Ubuntu’s Grub2.

Hope it helps (I don’t know what you’re trying to do).

  • Notice that both findgrub and updategrub have an option to set the bootflag (activate) the Grub partition:

Thanks for the hint to your configuration tool.

Hope it helps

Not directly for the reported open issue on my system.

(I don’t know what you’re trying to do)

I could adjust a working GRUB menu to let me start another instance of openSUSE 12.1 here. I discovered that the other menu works also (“All Green”) after the addition of corresponding chain-loading entries.
I wonder still why the screen display remains blank for a boot try on my new hard disk from a selection by the BIOS shortcut “F8” while it contains only one partition (the second) that I activated for booting. :\

If you’re using BIOS shortcuts to swich boot devices, you’re just confusing any boot manager, including Grub.

I have tried this configuration once more. Now I would like to add to my previous information an interesting detail that I overlooked before accidentally.
:\ The display is not completely blank if I chose to start from my new hard disk from the BIOS menu. I see also a blinking white underline character in the top left corner. Which software component does show a kind of feedback in this way?

Why does GRUB not get confused if I switch between the other two hard disks from the AMI BIOS menu instead of my new one?

Does GRUB also show a flashing white underscore in the top left corner eventually?
Or do I see a blinking character on the screen from a Microsoft boot loader variant? :\

Well, the definition of being confused is that sometimes you get confused and sometimes not (I don’t mean “you” personally). There are many reasons why Grub might not be able to find the correct disk, depending on the mb architecture, the BIOS, the SATA or IDE controller used, the combination of SATA, IDE, USB, external and internal hard disks and the SATA ports (which sometimes are not even correctly labelled). The only thing I can tell you for sure is that boot managers don’t like when BIOS device numbers change. Switching BIOS order to select the OS to boot does not embrace the definition of dual or multi-booting. You don’t even need a boot manager to do that.

My suggestion is to put the BIOS drives in the correct order for each OS to boot and not touch them afterwards. It doesn’t mean that pressing F8 doesn’t work. It only means that it’s a bad idea. Sometimes bad ideas work … and sometimes they don’t. Anyway, you will use what works for you. I’m just explaining that boot managers and BIOS shortcuts are not good friends.

It does also not help in my situation to change the boot priority for the new hard disk in the AMI BIOS configuration instead of the selection in the “F8” menu.

Is it possible to determine if the blinking white underscore is displayed on my screen by a software component from GRUB?

If you switch boot order to a disk with a blank MBR and no active partition, what else do you expect besides a blank underscore?

This hdd is not going to boot anything on its own, if that’s the one you mean. You should either install a boot manager in its MBR or set the bootflag on a primary partition with a valid bootsector.

You are right that the disk “/dev/sdb” does not provide a bootable partition.

The name “sdc” belongs to the device “/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B901367” which I call as “my new hard disk”. :wink:
(I activated the second partition for booting manually because the openSUSE installation system did not apply this setting for me because of unknown reasons.)

When you add a new disk, you should add it to /boot/grub/device.map. openSUSE originally writes a device.map with the disks it finds during setup. But it doesn’t get updated when you add or remove hard disks, and utilities which query the device.map - such as updategrub but not only - won’t know the BIOS order. It’s impossible to guess the BIOS order of disks without a device.map (I tried here: http://forums.opensuse.org/english/other-forums/development/programming-scripting/447138-looking-grub-windows-bootloader-all-partitions-12.html#post2365480). Option -M of findgrub might provide some infos though.

findgrub -M

The device.map tells the Grub installer the order (or mapping) of hard disks. It is needed to install or reinstall Grub. Otherwise it is not needed - except by utilities which read it - such as updategrub (but not only). If device.map contains an invalid entry (for a disk that doesn’t exist anymore) updategrub won’t change the Grub menu - for obvious reasons. But it is not just about the menu - which is easy to change with updategrub or manually. The location of stage2 (start sector of the partition and BIOS number of the disk) is written in stage1 - the part of Grub installed in the MBR or in a partition bootsector, if you choose to install it there. If you move a partition, the offset will be wrong and Grub won’t find stage2. If you play with F8, it won’t find the disk where stage2 is located (if stage1 and stage2 are on different hard disks, which is not very happy anyway). If you switch BIOS order before booting, Grub is not going to find what it expects … and I won’t be able to help either. However it does work in “simple” situations where you have two OSes and each knows that it is installed on the first disk. But this is not multi-booting. We could call that “hard disk switching” maybe. When you have 3 hard disks, it becomes too complicated and it’s different from one mainboard to another - not because of the AMI or other BIOS or not only, but because of the mainboard design (and bugs), models and number of SATA or IDE controllers, etc.