How to reinstall bootloader without reinstalling the entire system

Hello - i don’t know what really went wrong with a system I run but after a recent batch of upgrades/security fixes I was told that I needed to reboot my system, which I tried doing, and my poor system didn’t come back up. It appears that something has gone wrong early on in the reboot/system startup phase and I kinda suspect the boot loader or early start of the system got corrupted somehow. So I am attempting to start at the beginning and want to reinstall the Grub2 bootloader to see if that will fix things. I do NOT want to do a re-installation of the entire system, since I am running a lot of services and it would take me days if not weeks to reconfigure everything from scratch.

I have tried to use the installation DVD to simply do a systems upgrade but that did not provide me with any joy. Google searches led me to a number of variations on the following theme which I have been attempting to follow, but again so far no joy in being able to follow these steps. First I downloaded and set up a Live DVD with an x64 bit system (Fyrelinux) and booted it up, brought up a console and did an su - to become the root user. Then tried the following -

**mkdir** /tmp/mydir
**mount** /dev/sdd2 /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/sdd

The root partition of the system I want to boot up (Leap 42.3 x64) is located at /dev/sdd2 and the BIOS is set up to boot the system in legacy mode, not in EFI mode. From all appearances, after I mount /dev/sdd2 the contents look like what I would expect. I have ran fsck on it also and no errors were reported. When I reach the chroot step things go sideways. Commands like grub2-install and even the ls (and similar /bin /sbin etc) commands are no longer available. Even the keyboard, like the backspace key gets weird and does not work as expected. So I am not sure what I am doing wrong, but I will say that I found a lot of Google hits all leading me to instructions that are very similar to what I have shown. This kinda makes me believe that something within the chroot command has either changed or is broken? Or something else is now needed, that wasn’t when all the advice I found with Google was written?

Thanks in advance for any advice and/or help offers, and please keep it simple with easy to following instructions. I won’t claim to be a Linux guru myself, I know just enough to be considered dangerous! :expressionless: Marc…

Show output of “btrfs su li /tmp/mydir” and “btrfs su get-default /tmp/mydir”.

Hi avidjarr - I am not using a btrfs filesystem (Ext4) so the output simply is reporting this as an error. (I tend to be a skittish slow adopter of new fangle things, and I experienced some difficulties with btrfs when I tried it so when back to Ext4. ) :\ Marc.

Can you still access /etc on your root? What is the content of /etc/fstab?

I can, bit tricky how to copy it across to my laptop (no network) but I figured out a way to “sneaker net” it using a USB stick… This is it, and yes there is a lot of history behind it, stuff from way back that I preserve. One thing I will mention is that while there is a /boot/efi partition I do not believe I am using efi. I believe I have disabled it in the BIOS and am using the legacy bootloader… I think that when I first installed Leap42.? that it was assumed that I would be using EFI but I had troubles with it so I disabled it and that is just a leftover ruminant that I have not bothered to get rid of. (I may try EFI again someday.)

UUID=25cb1647-baef-4e16-8472-d029cfad9fa6 swap                 swap       defaults              0 0
UUID=ebf32d3d-bbdd-4d70-99e5-c15735bcd81d /                    ext4       acl,user_xattr        1 1
UUID=F549-5098       /boot/efi            vfat       umask=0002,utf8=true  0 0
UUID=bb3a7d35-cdfb-464b-9c4f-2b562e13d7d7 /home                ext3       defaults              1 2
UUID=9241a80a-1670-4f08-b475-c0c7a769095d /SuSE12.3            ext4       defaults              1 2
UUID=277b7114-e703-4ac6-a621-c076305b151e /SuSE42.1            ext4       defaults              1 2
UUID=c8c10691-6447-4bfc-a3cf-2a91a2490129 /data1               ext4       defaults              1 2
UUID=8db6a5e9-592e-45a2-a5e5-55f30914cb69 /var                   ext4       defaults              1 2
UUID=9ea1620f-7c9b-4159-835b-133ce0f7cadd /srv                 xfs        defaults              1 2
UUID=585ba71e-3f31-4b07-9100-c3997311738e /data                xfs        defaults              1 2
UUID=d0947373-48e3-4ede-bc5f-8d210bb525d5 /mail                xfs        defaults              1 2

/ /slash none  bind
UUID=10dec5c6-981f-488e-87dc-27368b8f233b /tmp                 ext4       acl,user_xattr        1 2

# UUID=3ec87644-3595-4ab6-9379-546e311b5ae2 /websites            ext4       acl,user_xattr        1 2
UUID=3ec87644-3595-4ab6-9379-546e311b5ae2 /websites            ext4       loop,nodev,nosuid,acl,user_xattr        1 2
UUID=7f1befa9-b317-4849-a870-6e04c9268f3a /usr                   ext4       acl,user_xattr        1 2
UUID=c35dc661-eedb-454d-a895-401eca223be0 /sdb1                xfs        defaults              1 2
UUID=4819e0f7-7085-45ce-bb2b-15e3cf7b1d20 /sdb2                xfs        defaults              1 2

When you make most critical part of your root separate filesystem, you obviously need to mount this filesystem to get working root.

Have you considered

Thanks avidjaar! That makes sense now that you pointed it out to me! I just couldn’t see it so it is good to have more experienced eyes looking over my shoulders! So mounting /usr got me past the chroot hurdle and on to the next one… I am doing some Google research to see if I can figure this next problem out but will post it here in case you or someone else has a quick answer to speed me along the way…

When I tried the command to install grub2 -

**grub2-install** /dev/sdd

this is what happened -

localhost:/ # grub2-install /dev/sdd
Installing for i386-pc platform.
grub2-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub2-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub2-install: error: will not proceed with blocklists.

Do you know what this means? Thanks again, Marc…

I goofed up a bit when I earlier posted my fstab file. I had picked up the wrong one from an earlier installation of openSuSE Leap 42.2. instead of the one I am using for Leap 42.3. :frowning:
I can repost the correct version if that will be useful but at least I am past the earlier hurdle where I could not do anything after the chroot command was given. :slight_smile:

Anywise, my Google research about why the grub2-install command is failing shows that a lot of helpers assisting others with this same problem often ask for the output from doing a gdisk -l be shown. So I will go ahead and post it here in the hope that it will be useful…

localhost:/ # gdisk -l /dev/sdd
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdd: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): CE411C8A-1FF7-4104-AE2B-081DFB7D7DAB
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 104859629 sectors (50.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          321535   156.0 MiB   EF00  primary
   2          321536        21301247   10.0 GiB    0700  primary
   3       251979776       293941247   20.0 GiB    0700  primary
   4       126158848       231014399   50.0 GiB    0700  primary
   5       231014400       251979775   10.0 GiB    0700  primary
   6       293941248       557342719   125.6 GiB   0700  primary
   7       557342720       976773119   200.0 GiB   0700  primary

Thanks as always for your patience and assistance! Marc…

Thanks John for the pointer, I will take a look see! :slight_smile:

Your system is apparently installed for EFI boot but you booted in legacy BIOS mode. You may try “grub2-install --target x86_64-efi --no-nvram” (as writing NVRAM entries will fail anyway) after mounting ESP as /boot/efi in chroot.

Thanks arvidjarr! I think that did it! And yeah I am not surprise that I still have stuff around for doing an EFI boot. When I first installed one of the Leap systems it defaulted to wanting to use EFI and not knowing any better I let it do so. But I ran into troubles with it for some reason (don’t remember why now) so I tried to go back to using the legacy approach. And to date it has not caused me any significant troubles… Perhaps it is time to try using EFI again…

Anywise, at least your last suggestion got me far enough along that I was able to get the system back up and running… But not without some further hiccups… The Grub menu did come back but when I tried to boot up Leap42.3 it only got about a dozen lines of the instrumented messages printed out before once again crashing. So I took a guess and figured something was wrong with the loading of the kernel code also. I decided to use my installation disk to reinstall the latest version of the kernel, along with some misc additional updates. That lead to another failure telling me that the file system was corrupted. So again I booted up a Live CD and ran fsck on the partition. This time it resulted in LOTS of error messages and not knowing any better I simply chose to let fsck do whatever it defaulted to, for each problem it found. Then I again reinstalled the kernel software and this time I got an incompatibility error message saying that the installation media did not agree with what was being replaced. I ignored it and told the installation to continue on… It took quite awhile but eventually it worked things out and reported that everything was also installed. I also had it install both the 32 bit and 64 bit runtime support packages as it confused me as to why it was wanting to install just the 32 bit stuff on a 64 bit architecture. Anywise, after all that the system now boots up once again, but it leaves it’s owner with a bit of a shaky feeling about just how robust everything is. Guess time will tell…:\

Again thanks so much for your help and time, couldn’t have done this without your assistance!!! Marc…:wink:

You can’t mix boot modes ALL OS must use the same mode to be able the chain. I suspect you have one OS installed using MBR boot and the other using EFI.

When installing the installer default to the mode that it’s media is booted to. It is not entirely obvious what mode is used when looking a the boot menu. Biggest difference is that MBR mode shows option at the bottom of the screen and EFI mode does not. There is no big sign saying I booted in EFI or MBR :frowning:

Hi gogalthorp - Actually I really only have one OS installed on the system I was having troubles with. I run this system to support a number of services - web, mail, ftp, and a bunch more. What I have been doing is to keep the operational OS updated to the latest “stable” version of OpenSuSE which is at the moment Leap 42.3. But there are remnants of stuff from previous OS’s. I usually try to keep a previous version for awhile, after I do an upgrade, in case I have to fall back to it. But as soon as I feel my newest system is stable, I drop supporting the older versions and let them go. and eventually I reuse those partitions for something new…

At some point, I think it was when I upgraded to Leap42.1, the installation software decided to switch me from MBR to EFI. (I don’t remember why, perhaps I was following advice at the time and thought I would try it out.) Anywise, it didn’t go well, so I tried to switch back to MBR mode. I may not have done that very cleanly, again I don’t recall and this is now relegated to the dim foggy past… That has been working OK, until now. The BIOS is configured to boot up using legacy MBR as well, so I am not really clear why my Leap42.3 system is even using EFI, but apparently it still is using some aspect of it…

I have been too darn lazy to do a clean install also, way too much of a PITA to reset up, configure, and debug all the servers and web applications that I run! And while I keep everything well backed up, I much prefer doing migrations slowly over time when things change, rather than all at once!

Well if you have 42.3 and 42.1 installed on different partitions and expect to see 42.1 in grub you do have two OS/s installed If one was installed MBR and the other EFI grub will not chain. But you stillshould be able to pick the boot OS from the UEFI boot menu