openSUSE-13.2 fresh install fails to boot grub2 after installing updates

As noted in thread title, an openSUSE-13.2 fresh install fails to boot grub2 after installing updates. The PC boots OK without the updates. I would like to learn how to avoid this problem after installing updates.

Details:

I installed a 64-bit openSUSE-13.2 (KDE) on my wife’s PC today from the 13.2 installation DVD, and it boots ok without any updates.

However if I select to install all the updates, the PC will not boot after restarting. Instead it hangs with the word ‘grub’ in the upper left corner of a black screen and simply sits there indefinitely. It does not response to key sequences such as ‘E’, <escape> , nor <enter>.

This is reproduceable, as I re-installed 13.2 after the 1st time it occurred, and it immediately happened again. My wife needs her PC functioning, so I re-installed a 3rd time, but this time left it without the updates. Currently without the updates the PC is working fine, and my wife happy. BUT I really should apply the updates.

Some details on this PC’s setup to help assess the problem:

[ul]
[li]the PC has two hard drives, sda and sdb.[/li][LIST]
[li]On sda is sda1 (NTFS) an old winXP which is rarely used, and sda2 an extended with sda3 being an NTFS my wife uses for storage. [/li][li]On sdb is sdb1 (NTFS) for win7, and sdb2 an extended with sdb5 a swap, and sdb6 (EXT4) for / (root) and sdb7 (EXT4) for /home. There is no sdb3 nor sdb4. [/li][/ul]

[li]sdb is set in BIOS as the default boot drive, where sdb2 is the active partition. Hence by default the PC boots to sdb2. As an aside sdb has a win7 MBR which is ignored as the PC boots to sdb2. I do NOT want to copy the generic openSUSE mbr code into the drive sdb mbr. [/li][li]I have grub2 first stage in both the extended and the / (root) (which may be the problem, as its possible the update only updates the / (root) and not the extended. [/li][/LIST]

Some pix below where this first pix illustrates what I think may be the problem (that confuses an update). Note in this YaST image dump two “boot loader locations” are specified :

wrt the above, my guess is since the /sdb2 is the active partition, I should remove (deselect) the boot from ‘Root partition’ flag, and leave the ‘Boot from Extended Partition’ flag. Comments on this guess/speculation of mine ?

Here is another boot loader (yast) image, which I think irrelevant to the problem.

And another image. Win7 is flagged as default (as my wife is an exclusive win7 user, and this is her PC). Again, I do not think this selection relevant to the problem.

So aside from asking for concurrence of my assessment (that having both extended and / selected as boot loader locations) , if I were to update and encounter this problem again, what is a quick way to recover without being forced to conduct a re-install.

It takes 60-minutes to re-install (including tuning the printer, scanner, skype, virtual box, and some packman apps) and I would prefer to avoid having to ‘waste’ 60-minutes if my wife or myself encounters this again ?

Typo Correction to the above (in red) below:

= = = =

[ul]
[li]the PC has two hard drives, sda and sdb.
[/li][LIST]
[li]On sda is sda1 (NTFS) an old winXP which is rarely used, and sda2 an extended with sda3 being an NTFS my wife uses for storage.
[/li][li]On sdb is sdb1 (NTFS) for win7, and sdb2 an extended with sdb5 a swap, and sdb6 (EXT4) for / (root) and sdb7 (EXT4) for /home. There is no sdb3 nor sdb4.
[/li][/ul]

[li]sdb is set in BIOS as the default boot drive, where sdb2 is the active partition. Hence by default the PC boots to sdb2. As an aside sdb has a win7 MBR which is ignored as the PC boots to sdb2. I do NOT want to copy the generic openSUSE mbr code into the drive sdb mbr.
[/li][li]I have grub2 first stage in both the extended and the / (root) (which may be the problem, as its possible the update only updates the / (root) and not the extended.
[/li][/LIST]

I don’t have an answer.

I have heard that choosing two “boot from” options causes problems with grub2 that did not happen with legacy grub. So I suggest not doing that. If you need more than one, you can use “dd” to copy the boot sector later (say 440 bytes to the extended partition).

What puzzles me, is that I don’t recall grub2 ever being reinstalled in opensuse 13.2. Updating it should usually only require updating “grub.cfg”. On two of my systems, I boot via Windows boot manager. For that, I have to put a copy of the boot sector into a file used by Windows. My typical experience is that reinstalling grub requires that I update that boot sector file for Windows, or booting will fail. And I have never had to do that since installing 13.2.

Possibly, having two “boot from” boxes checked causes that. Perhaps it is installed then re-installed in quick succession. But that still happens to work until the free space is recovered in later updates.

I don’t know what package (in the update) broke the boot. Clearly it impacted grub, as after installing the update, the Grub menu never appears (only the GRUB in the upper left hand corner). The update from a basic openSUSE-13.2 install to the latest patches is large, in excess of 2GB (with hundreds of rpms to update) and being that large in size, I am not particularly keen to try to narrow it down by trial and error. Fortunately I have an unlimited (and very fast) Internet connection, such that the time ‘spent’ in the two ‘failed’ installs had no impact other than a couple of hours of lost time.

Next weekend I’ll likely remove the 'boot from / ’ selection, and leave only the ‘boot from /extended partition’ selection.

I am curious thou, how one can recover in such a case without a re-install. I assume it is done by boot from the liveCD and/or something along those lines. I note booting from the installation DVD and selecting ‘recovery’ lands one at a command prompt asking for a login, where root as user, with no password, works to login. But one then needs to know what commands to send to repair the boot.

You then need to mount everything; then chroot into the mounted system. Then run “grub2-install”.

You have multiple partitions in “Boot Loader Location” and that is Bad Thing ™ which can result in exactly this problem. As you can have only single active partition anyway - leave just one and retry.

Hi oldcpu,

I’ve been struggling with this for for about a week now. My last install, dual-booting w7, just broke after updates too. If you want to see what I tried and didn’t work, see here: https://forums.opensuse.org/showthread.php/507245-Fast-non-stop-beeping-after-GRUB-text-on-boot-screen?p=2708792#post2708792

I got slightly different broken grub symptoms: like yours, like yours + continuous beeping, grub cmd line.

Note my setup is MBR/Legacy BIOS, no UEFI, GPT or Secure BIOS.

See my latest posts on the thread above for recent results I got and what I’m doing next to fix this.

Thanks - that gives me confidence that I simply need to remove the grub2 boot loader 1st stage from / (root) and keep the one in the extended partition. I believe YaST will do that all for me simply by my deselecting the appropriate box in YaST’s GUI for the boot loader. I plan to do this next weekend, after I prepare for a recovery in case things do get messed up.

I saw your thread … but I confess I struggled a bit with understanding your sdx setup and your Windows needs.

I’m pretty confident that by specifying in YaST only one location in which to install the grub2 1st stage (instead of the two locations that I have specified now) it will solve the problem. I do want thou, to bush up how to configure grub2 from the recovery command line, in case I’m wrong wrt my confidence.
.

I was, too…

Caf’s instructions worked for me - actually a modification by a poster on page 3 of the comments, IINM, mounting sys and proc with the --bind option before chroot. I’ve linked to it in my thread.

The first time it fixed oS boot, but not windows. I also made a mistake in the heat of things by resetting to BIOS defaults, which changed SATA from AHCI to IDE, so windows repair kept prompting me to load device drivers and I didn’t pay the attention it deserved (oS does this automagically on boot).

The second time, after trying to fix w7 boot, it didn’t work. Too messed up, I suppose.

I skimmed through that guide and saw that reference, but its not clear to me if that was unique to LVM. The main guide page was not updated, and I would have thought that if it necessary to mount sys and proc with the --bind option before chroot that caf4926 would have updated the 1st page in the article. I figure if necessary and if the grub2-mkonfig fails, one can simply reboot and restart all over with the appropriate sequence as nothing has yet been written to the drive.

Hence with my wife’s setup, I suspect if I need to do this, noting that in the setup on my wife’s pc root is sdb6 and the location where I believe 1st-stage grub should be located is sdb2, means if necessary the commands should be:


fdisk -l
mount /dev/sdb6 /mnt
mount --bind /mnt/dev
chroot /mnt
mount /proc
mount /sys
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sdb2

The ‘fdisk -l’ would help me confirm the sda2 and sda6 are correct.

I’m hoping the above won’t be needed. Again - I plan to wait until the upcoming weekend before attempting with this.

The entries for “/proc” and “/sys” are not in “/etc/fstab” for opensuse 13.2. So those mounts will fail. You can either workout the full mount command, or use a “–bind” mount. The latter is easier.

ok thanks. That likely means also we should ask caf4926 to update his guide for openSUSE-13.2 users.
.

Given the above, and given the fstab observation, my understanding then is for the possibility (hopefully remote) that deselecting ‘boot from / (root) partition’ and retaining ‘boot from extended partition’ causes my wife’s PC not to boot, I can try:


fdisk -l
mount /dev/sdb6 /mnt
mount --bind /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sdb2

Again - I’m fairly hopeful it won’t come to having to do the above after a boot failure and after I start the PC from the installation DVD rescue selection. wrt sdb2 and sdb6 in the above, the idea of mine is to put stage-1 of grub2 on sdb2 and the PC’s current root partition is sdb6. I don’t want to put stage-1 of grub2 on sdb nor on sdb6. sdb2 is the active partion (and it also happens to be an extended partition) and the bios is setup to boot to sdb drive (and not to sda). Hence as the active partition on sdb the partition sdb2 should start up first, and when it starts up on sdb2 openSUSE should execute stage-1 of grub2, which will then send it to stage-2 which I think is on sdb6 (root).

One warning. That last command will fail – been there, done that.

You will instead need:

grub2-install --force /dev/sdb2

The grub2 developers want you to install in the MBR, and you need the “–force” to tell them that you don’t agree.

Good to know! Many thanks.

I’ll post again this weekend and let everyone monitoring the thread how this all turned out.

Please, no town legends.

GRUB consists of three parts - primary boot block, secondary core.img, all other drivers. Primary boot block loads core.img; it does it using absolute disk location(s). core.img contains enough drivers to find and access filesystem (/boot/grub) where all other GRUB is located. core.img then loads main grub code and executes it.

grub-install installs both primary boot block and core.img. To install boot block grub simply needs to make sure there is unused sector at the beginning of device. That is, it is either MBR or partition with filesystem that is known to reserve at least one sector. To skip this check (on your own risk of course) --no-fs-probe is used.

To install core.img GRUB attempts to embed it outside of any filesystem. Remember that it is located by absolute disk address and filesystems may change location of file blocks. If it cannot find space to do it, it fails, unless you use --force, in which case core.img is left in /boot/grub and primary boot block points directly at it. Which is called “blocklists install”. In practice only btrfs and zfs reserve enough space to embed bootloader, for all other filesystems the only chance is to use blocklists.

So no, GRUB developers do not want you to install in MBR. But they want core.img to be as safe as possible, and using MBR installation is the best way to ensure it.

Oh, and the above is only correct for PC BIOS. Other platforms may not even have primary boot block.

As noted by yourself and others, this indeed was the problem. Lucky me, in that I have a long weekend this weekend (but need to stay in the area due to work related ‘on call’ reasons), so this morning once I confirmed that my wife did not need her desktop computer for a few hours (she is using her laptop and tablet as I type this) I jumped on her computer and gave this a try.

I removed the selection of boot from / root partition (as seen in the image below). Saved that in YaST and restarted the PC.

http://thumbnails107.imagebam.com/40951/0991d7409506761.jpg](ImageBam)

The PC restarted fine.

I then installed the massive amount of updates to a fresh openSUSE-13.2 install ( 611 packages currently, with > 2 GB of downloads), and restarted afterward (as that update includes a kernel update).

This time the reboot worked fine ! :slight_smile:

I did not need the contingency plan as it turns out, where for the record that contingency plan was if grub2 did not boot (but if if left me at the black screen with GRUB in upper left corner) I was going to boot the to recovery mode in the installation DVD, login as user root, and send the commands below. These commands are configured to use the root install on /dev/sdb6 (which is inside the extended) and put the 1st stage of GRUB2 on /dev/sdb2 which is the extended partition.


 fdisk -l
 mount /dev/sdb6 /mnt
 mount --bind /mnt/dev
 mount --bind /proc /mnt/proc
 mount --bind /sys /mnt/sys
 chroot /mnt
 grub2-mkconfig -o /boot/grub2/grub.cfg
 grub2-install --force /dev/sdb2



But as noted, they were not needed.

Many thanks to all for your help and participation in this thread.