How does one reinstall grub2 in / ?

I have installed LEAP 42.1 (x86_64) from the distribution DVD on an HP 8570w laptop. I am using Terabyte BIBM as the boot manager (6 bootable partitions in an eMBR), so I installed grub2 in the / partition. Booting and execution then had no problems.

I next took the updates (138 updates including 50 security updates). The process did not appear to end normally. Even after closing all active windows, the System Monitor showed 15% CPU activity, with one of the CPUs showing pulses of 50% cpu activity. It would not settle down to normal idle behavior. When I rebooted, the system immediately aborted. It appeared to die in grub2. The screen never got to normal bootup logging.

The SuperGrub Disk 2.02s4 has no problem reading the grub2 configuration and booting the system. However, it provides no way to install the correct grub2 configuration, and RescaTux 0.40b7 is only capable of installing grub2 in the MBR. Running “grub2-install /dev/sda1” in the booted system gets:Warning: File system ‘ext2’ doesn’t support embedding.

error: Will not proceed with blocklists.

I have the un-updated installation backed up, so I can redo the update through YaST with selected updates excluded, but I would prefer to learn how to do the grub2 update directly, since I have had problems like this before. Also, if this problem has not been found before, I am willing to see if I can localize the bug in the updates, if I can get some suggestions on where to look.

Help, please. Thanks!

I would suggest that you revert to your backup, then run as root (from a terminal)

zypper up

instead of updating via YaST

Boot from any Linux live distro, chroot into real root, make sure /sys, /dev, /proc, /run and (of necessary) /boot are mounted in chroot, run “update-bootloader --reinit” or, if you prefer, directly “grub2-install /dev/sda1”, or whatever your root partition is.

What is the dufference between both?

No difference, of course. But there may have been a power outage during the update, so it is worth trying again (with either method, but zypper might give more info).

Correct and usefull hint. Maybe, next time, explaining this with your suggestion might inform the OP about why you suggest it.

First try. Boot from LEAP 42.1 media. Rescue. Mount /dev/sda1. chroot to it. “update-bootloader --reinit” Result:Cannot open directory ‘/mounts/mp_0001/boot/grubw/i3i6-pc’: no such file or directory.

Second try. Chroot as above. “grub-install /dev/sda1” Result:Cannot find a device for /boot/grub2 (is /dev mounted?)

Yes, it’s mounted. I am trying to update grub2 in the root partition.
Third try. Restore original install. Log in as root. “zypper up” Result:PackageKit is blocking zypper … Tell PackageKit to quit?

(a) PackageKit won’t quit. There is no way I can see to force it.
(b) In the message popup, the software installer has only one button: Install. There is no way to tell it to go away.
(c) “ps -ef | grep PackageKit” finds only the grep task. Ditto “Kit.” Typing “… grep kit” finds only two daemons, neither of which appear relevant.
(d) There are several hundred tasks running, so it is not practical to read them and try to guess which one to kill.
(e) YaST does not appear to have any way to disable the running updater.
(f) Typing “init 1” to get to single-user mode gives me a “login:” prompt followed immediately by “Welcome to Rescue Mode!..” and an unresponsive keyboard. I apparently can’t log in.

Suggestions?

It gets more interesting …
The inability to “init 1” may have been due to my use of an external wireless keyboard. I got into single-user mode after several tries. Then ‘zypper up’ installed 476 packages… and rendered the system unbootable.

I watched the installs scroll through the screen when zipper ran, and I am certain I saw a message that mentioned grub2 and contained the phrase “unable to install.” I will explain what I suspect below. However, I opened /var/log/zypper.log (7.4 MB) and searched for “unable.” There were zero hits on that string. I saw another message shortly before that reported “This may not be an error … swap.”

Please note: I have openSuSE 13.2 in another partition, and I have taken all updates via the KDE update app. This problem has not occurred there. Something in the change from 13.2 to 42.1 has broken the grub2 update mechanism. Furthermore, the error messages documenting the breakage do not make it into zypper.log.

Here is what is “odd” about my configuration. The install was done with 3 partitions: sda1=root, sda2=swap and sda3=data (NTFS). I have 6 bootable partitions. (Switching is handled by BIBM and an eMBR.) Each uses this layout. I have 2 nearly identical laptops. I can back up a linux partition from any one of 10, and restore it to any other. The 42.1 (and the 13.2) installs were made with the default, UUID=" in fstab. I then replaced the first parameter in each fstab definition with /dev/sda1 and 2 and 3. openSuSE 13.2 has no problem with that. LEAP 42.1 clearly does. The UUID of the root partition is unchanged, but that apparently is not enough for the grub2 update, perhaps because it is not referenced in fstab.

Both the KDE update app and zypper are trying to install an update that fails, and the failure does not appear in the zypper log. YaST might show me the name in a list, so I can stop it, but I do not know what it is.

Here is what I would particularly like to know:

  1. How to shut off the KDE updater, at boot or when it’s running.
  2. What the offending grub2 update is called, what it does, and whether it is essential.
  3. How to tell update-bootloader to use /boot/grub2/i386-pc/. The man page doesn’t show how.
  4. How to install or update grub2 independent of the RPM update process.
    The process suggested above via chroot looked promising, since it reported:(sda1) mounted filesystem with ordered data mode. Opts: (null)

That might get around grub2’s problem with writing to the (ext4) partition, but I don’t see how the root partition can be unmounted to allow the write, while still having access to it to run the grub2-install or update-bootloader tool.

This worked for me, for a different problem. Boot from the install disc in rescue mode, login as root. Issue:

**mkdir** /tmp/mydir
**mount** /dev/sda1 /tmp/mydir
**mount** --bind /dev /tmp/mydir/dev
**mount** --bind /proc /tmp/mydir/proc
**mount** --bind /sys /tmp/mydir/sys
**chroot** /tmp/mydir
**grub2-install** /dev/sda
exit


NOTE the grub2-install /dev/sda, NOT /dev/sda1

Indeed, I “NOTE the grub2-install /dev/sda, NOT /dev/sda1”
Doesn’t that write outside the /dev/sda1 partition? grub is presently in the sda1/boot, and I want to keep it there.

But you said in first message:

"grub2-install /dev/sda1" in the booted system gets:Warning: File system 'ext2' doesn't support embedding

and

grub is presently in the sda1/boot, and I want to keep it there.

I’m getting confused. Surely you need to boot the entire disc (/dev/sda), not just one partition (/dev/sda1)? As I said, it works for me; I have /dev/sda1 as swap and /dev/sda2 as /.

As I already said

make sure /sys, /dev, /proc, /run and (of necessary) /boot are mounted in chroot
and @bbuolder provided example how to do it.

Then do it. Oh, and if /dev/sda1 is ext* you need to call grub2-install with --force option; update-bootloader does it.

Thank you all very much for your time and effort. To bbuolder:
I am using Terabyte BIBM as my partition and boot manager. It transfers control to the boot code in the root partition. The SuSE installer provides for this. One can choose installing in “/” on the configuration screen, but must click on the Boot options header to prevent it from also putting “generic” code in the sda boot sector.

To Omniscient Penguin:
I probably didn’t understand what you meant when you saidmake sure /sys, /dev, /proc, /run and (of necessary) /boot are mounted in chroot

I now infer that you mean the use of “–bind” as bbuolder has indicated. I had assumed that the presence of the directories in the chroot to which I moved was sufficient. I clearly have some reading to do to understand more of this.

Thanks very much for the advice.

Here are two more conceivably useful insights for lurkers:

  1. I learned how to kill the KDE update app. Simply answer “no” to the prompt to ask PackageKit to quit, and you learn the PID of the offending task. Then use su to kill it. At that point, the YaST package manager will run, and it gives a complete list of the updates. In the system described above, there is one “grub2” update. I miarked it “Taboo” and took the updates. After the updates, it still won’t boot, but the word GRUB appears at the top of the screen and the keyboard is again locked.

  2. I went back to the 42.1 distro DVD and did a fresh install, this time specifying “Fstab options” to identify the devices by “Device Name.” That tells the installer what I actually intend to do. The install went uneventfully and the system booted properly, but KDE couldn’t remember what windows were present at shutdown for the next bootup. I then took the updates. This time, there were four updates to grub2 that I Taboo’ed. After the updates, the system booted, but KDE still can’t remember what was open when I last shut down. That is a feature I particularly miss.

Thanks again for the help. At this point, I’m going back to 13.2 which does everything I need, and put the update to 42.1 on the back burner.

Postscript: Thanks again Omniscient Penguin! The command “grub2-install /dev/sda1 --force” solved the boot problem. Now, if I can figure out how to do it, I’ll mark the tltle “solved.”