Ancient HDDs leading to an absolute mess of MBR chaos

Hi everyone,

I hope this is the right place to ask for generic (not OpenSUSE-specific) Linux support - the description made it seem like the best home for my issue.

I recently installed OpenSUSE on my second SSD and I’m loving it. Recently, Linux became my main OS and I feel very little reason to go back to Windows.

That said, I do have a Windows install in my machine, as well as a few HDDs that used to be the boot HDDs from my old machines that I liberated and use mostly for storage.

My setup looks something like this:
/dev/sda: Windows SSD (broken after a Windows update a couple of months ago - when I select it in the BIOS boot menu, I get an error about the operating system no longer being installed. All the files are still there though and I can browse them normally)
/dev/sdb: OpenSUSE SSD that I want to boot to first so I can select an OS through GRUB
/dev/sdc: Storage HDD (SATA)
/dev/sdd: Storage HDD (SATA)
/dev/sde: Storage HDD (SATA)
/dev/sdf: Storage HDD (External USB)

My goal here is to get my machine to automatically boot to the GRUB installed on /dev/sdb.

My motherboard is an MSI Z97 PC Mate. If I set UEFI booting, then my computer appears to boot to an old version of GRUB which then tells me I don’t have any operating systems. I get the same if I set UEFI/Legacy boot and just leave it to boot automatically. The only way I can get to Tumbleweed is by opening the boot menu (F11) and selecting the SSD corresponding to dev/sdb, which then takes me to the familiar OpenSUSE GRUB menu. From there, I can select Tumbleweed which works just fine, or I can pick the “Windows install” option, which takes me to a non-GRUB black screen that tells me that I don’t have an operating system installed.

To help diagnose what’s going on, I ran arvidjaar’s bootinfoscript (https://github.com/arvidjaar/bootinfoscript), and I’ve put the results on pastebin at https://pastebin.com/2sddYMiT.

As you can see, it looks like I have 6 MBRs (!?), and a possible reason why Windows isn’t booting is because of some GPT corruption on /dev/sda. This is clearly a complete mess, and I’d like to find a way to clear all this up and “start again”, but WITHOUT losing any data on the storage HDDs (or losing access to them). I’ve read about some dd commands online to manually delete the first few sectors that correspond to the MBR, but I’m nervous about messing that up and bricking my storage drives.

Summary of my aims:

  1. Boot to the Linux install (/dev/sdb) automatically after power on
  2. Restore access to the Windows install on /dev/sda
  3. Remove the old, defunct, and useless GRUB install on /dev/sdd
  4. Remove the old, defunct, and useless MBRs on /dev/sdc, /dev/sde, and /dev/sdf as these HDDs no longer have an operating system on them

Any advice you folks can give about the best way of going about all this would be greatly appreciated. Boot problems are usually the kind of thing I ignore, but it’s getting tedious having to manually select the right drive to boot to every time I turn my computer on.

Thanks a lot!

Blasky

I don’t blame anyone for not wanting to take this challenge on, but just wanted to let you know that any advice or suggestions are still greatly appreciated!

Many thanks!

Matty

It is a mess. I was hoping that somebody more familiar with bootinfo would take this on.

From what I can see:

Windows is installed for UEFI booting. Whether that still works, I cannot tell. But you would need to use UEFI booting to test that.

You have, at some time, had Ubuntu installed for UEFI booting.

Your Tumbleweed is installed only for legacy booting, not for UEFI booting.

If this were my computer, the first thing I would want to do is somehow boot it with UEFI. To do that, I would probably use the Tumbleweed live Rescue CD, written to a USB device – or maybe the live KDE CD if you prefer that.

If I were able to get that booted, then I would look for the output of:

efibootmgr -v

which would tell me something about the status of the UEFI setup.

I would wait until I had seen what happened with those steps before deciding how to further proceed.

In legacy BIOS or EFI mode?

Restore access to the Windows install on /dev/sda

What exactly “restore access” means?

Remove the old, defunct, and useless GRUB install on /dev/sdd
Remove the old, defunct, and useless MBRs on /dev/sdc, /dev/sde, and /dev/sdf as these HDDs no longer have an operating system on them

What for? They do not harm anyone. If you insist you can simply overwrite first 440 bytes with zeroes but I do not see what is it supposed to achieve.

Hi guys,

Thanks for your responses! Sorry for my late reply, I’ve been out of town for a few days, but I appreciate you chiming in and trying to help out.

In response to arvidjaar’s reply:

Honestly either. UEFI would be preferred, I guess, but currently my only boot option when I have UEFI enabled is to an old version of GRUB 2.3 linked to a no-longer existing Ubuntu installation. It takes me straight to the GRUB shell with no other booting options. To get to OpenSUSE, I need to have Legacy+EFI enabled in the BIOS, and then select dev/sdb - there is no other way to boot.

Since a Windows update 2 or so months ago, selecting dev/sda from the boot menu takes me to a black screen that says I do not have any operating systems installed (I recognise the screen from previous, unrelated Windows boot issues). I can mount the drive in Tumbleweed, but it just reads it as a “Basic Data Partition”, which makes me think that the MBR or the GPT has gotten corrupted somehow.

I was under the impression that this is the root of my problems - multiple MBRs that the motherboard keeps trying to boot from, which is why I have to manually select everything to get where I want to to be (which is clearly `wrong’). If this isn’t the issue, then fine. I’m not interested in saving 440 bytes of storage space or anything, I just figured it was connected to my issues.

@nrickert:

I have hinted at this in my response to arvidjaar, but with UEFI booting I have no option to pick my Windows drive, and it automatically boots to the old Ubuntu GRUB (no idea which drive that’s actually stored on), which takes me straight to a GRUB shell that I cannot seem to do anything useful from. In order for my OpenSUSE drive to even be an option, I have to have Legacy+UEFI enabled on my mobo.

This is also correct. I’ve had various instantiations of Ubuntu installed over the years. Most recently I had Xubuntu installed right before I switched over to OpenSUSE, but that was on the same drive, and I got the drive wiped completely when I installed Tumbleweed. I therefore suspect that the “Ubuntu” GRUB that UEFI booting keeps taking me to is located on one of the storage hard drives, but not sure how to confirm this.

That would make sense, and explain why there is only one UEFI boot option when I disable legacy on my mobo. Is there some way to change this without reinstalling the OS, or do I have to wipe it and start again?

I’m at work right now, but I’ll dig out my live environment and run

efibootmgr -v

tonight, see what the output is and post it here.

Thanks a lot for your suggestions and help guys!

Yes, you can change to UEFI booting without having to reinstall. But to do that, you have to be booted in UEFI mode.

If you can boot the Tumbleweed install media in UEFI mode, or a Tumbleweed live image in UEFI mode, then you can use that to reinstall booting.

If you can experiment and make sure that you are able to boot either the installer (or installer rescue system) or live Tumbleweed in UEFI mode, then ask here for details on how to use that to fix the booting for your already installed system.

Which boot menu? BIOS boot menu? I doubt it calls it “/dev/sda”, you really need to be very exact about what you see or do. I suspect you attempt to boot EFI Windows installation in legacy BIOS mode, which probably is not going to work, at least right away.

I can mount the drive in Tumbleweed, but it just reads

What is “it” here? What “just reads” means? Really, it is impossible to suggest anything constructive without having at least some understanding what’s going on and your description provides zero information. Just copying command and its output would be much more useful.

with UEFI booting … it automatically boots to the old Ubuntu GRUB (no idea which drive that’s actually stored on)

The boot menu item is stored in BIOS setup (you may be able to actually see it there, but it really depends on vendor) and it likely points to file on /dev/sda2 as this is the only ESP on your disks. There should be directory \EFI\ubuntu there, exact content of this directory may vary.

Is there some way to change this without reinstalling the OS

You may be able to do it in BIOS setup, you may be able to do it using efibootmgr. Of course it will only change firmware boot selection. Whether your Windows is still bootable I cannot say.

I’ll dig out my live environment and run

efibootmgr -v

Yes, that would be good start.

Thank you for your response.

I am having some problems booting from my Tumbleweed install media flash drive. I have set my mobo to “UEFI” boot mode only (no legacy), and selected my USB flash drive from the boot menu. This has taken me to the familiar OpenSUSE boot menu. The “Boot from Hard Disk” option results in a black command line opening in the middle saying:
“error: no such device: /efi/boot/fallback.efi.
Press any key to continue…”.

The other options in the menu are “Upgrade”, “Install” and “More…”. Under “More…”, both “Rescue System” and “Boot Linux System” take me to the same place. A black command line opens in the middle saying:
“Loading kernel …
Loading initial ramdisk …”

After a couple of seconds, two additional lines appear at the bottom of the screen (no longer in the middle command line) saying:
“exit_boot() failed!
efi_main() failed!”.

The computer then sits there until I reboot it.

In my messing around here, the boot behaviour of my computer has changed a little. I am not sure why. Below I give a full description of what happens with the various options in my boot menu.

–==UEFI Boot Mode Only: ==–

  • ubuntu (P0: Samsung SSD 840 Evo 120G)
  • UEFI: Built-in EFI Shell
  • Enter Setup

Option: ubuntu (P0: Samsung SSD 840 Evo 120G)
Result: There are a few messages that pop up at the bottom that look like errors but they disappear too quickly to read. Then I am met with:
"GNU GRUB version 2.02~beta2-36ubuntu3.17

Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.

grub> _"

I believe this is the old UEFI Ubuntu install that nrickert noticed.

–==LEGACY+UEFI: ==–

  • ubuntu (P0: Samsung SSD 840 EVO 120GB)
  • Hitachi HCS5C1010CLA382
  • SATA1:Samsung SSD 840 EVO 120G
  • SATA2:Samsung SSD 850 EVO 250G
  • SATA3:SAMSUNG HD501LJ
  • SATA5:ST3500641AS
  • SATA6:Hitachi HDP725050GLA360
  • SATA4:TSSTcorp CDDVDW SH-224DB
  • UEFI: Built-in EFI Shell

Enter Setup

Choices:

  1. ubuntu (P0: Samsung SSD 840 EVO 120GB)
    GRUB 2.02 as before
  2. Hitachi HCS5C1010CLA382
    Takes me to my normal openSUSE Tumbleweed GRUB menu. I can boot my Tumbleweed OS here as normal by selecting “openSUSE Tumbleweed”. I also have an option in GRUB for “Windows 10 (on /dev/sdc1)”. Selecting that takes me to a Windows blue screen entitled “Recovery”, with the text “Your PC/Device needs to be repaired // A required device isn’t connected or can’t be accessed // Error code: 0xc000000e”.
  3. SATA1:Samsung SSD 840 EVO 120G
    As 2) described above
  4. SATA2:Samsung SSD 850 EVO 250G
    As 2) described above
  5. SATA3:SAMSUNG HD501LJ
    Same Windows blue screen as observed when picking “Windows 10 (on /dev/sdc1)” as described in 2) above
  6. SATA5:ST3500641AS
    “GRUB Loading” briefly flashes up before going to a black screen and then the computer resets.
  7. SATA6:Hitachi HDP725050GLA360
    A black screen appears with the text: “BOOTMGR is missing // Press Ctrl+Alt+Del to restart”. However, pressing Ctrl-Alt-Del doesn’t do anything and I have to hit the reset button on the front of my machine to proceed.
  8. SATA4:TSSTcorp CDDVDW SH-224DB
    As 2) described above

I’m not sure what happened to change this behaviour from what I mentioned earlier - all I have done is toggle UEFI and LEGACY+UEFI a couple of times and try to boot from my Tumbleweed USB in UEFI mode.

Thank you for your response. I respectfully ask for your patience.

My complete transcript of boot options above should elucidate the issues with my previous description. Additionally, I apologise for my ambiguity concerning “it just reads” before. To be explicit - when I boot into Tumbleweed and open Dolphin, on the left under “Devices”, I see the labels of all the drives in my computer listed. I recognise “Files (G)”, “Samsung (F)” and “Seagate (D)” as sde, sdc, and sdd respectively. Continuing with the “Devices” section: “185.1 GiB Hard Drive” is my home partition on the drive that Tumbleweed is installed on (sdb), and “40.0 GiB Hard Drive” is the root partition on the same drive. You will notice that all drives are accounted for except sda, which is listed as “Basic data partition” under “Devices” in “Dolphin”.

It sounds like the next step is working out why I can’t UEFI boot from my Tumbleweed USB. Do you guys have any suggestions why that might be?

Many thanks.

“Boot from Hard Disk” won’t work in this situation. It’s a hack that assumes you already have UEFI booting installed for openSUSE.

The other options in the menu are “Upgrade”, “Install” and “More…”. Under “More…”, both “Rescue System” and “Boot Linux System” take me to the same place. A black command line opens in the middle saying:
“Loading kernel …
Loading initial ramdisk …”

The should not take you to the same place. And “Rescue System” is what you should use.

It should take you to a command line prompt for language, and then to a login prompt. At the login prompt, you should be able to login as root.

“Boot Linux System” – I have not tried that recently. I think it is supposed to use “kexec” to load the kernel of your installed system.

Try again to get into the rescue system. And if you can do that, I can tell you how to continue to setup UEFI booting for openSUSE.

Thanks for clarifying.

When selecting both “Boot Linux System” and “Rescue System”, I get the same messages about loading the kernel and initial ramdisk before the additional two lines pop up “exit_boot() failed!” and “efi_main() failed!” and then the system hangs. If instead of making these selections I hit “C”, I get to a GRUB command line, but I suspect that is not what you are talking about?

I’ve never had that happen with Rescue System. I’m not surprised that something goes wrong with the Boot Linux System choice.

I can try and remake the flash drive tomorrow, but this is the same one that I installed OpenSUSE with in the first place (just a month or so ago), so I’m not sure that’d help…

No, remakiing the flash drive probably won’t help.

At the moment, I don’t have a good suggestion.

Hmm, if you can boot into the installer, maybe you can work from there. In the installer, on the license approval screen, you should be able to use CTRL-ALT-F2 and that will give you a command line.

If you are able to get to that point, then try:

efibootmgr -v

mostly to check that you are in UEFI mode.

If that all works, then I think it is possible to install UEFI booting from there.

Nice idea! That worked, and I get a response from

efibootmgr -v

.

I’m not sure what information is most useful here and I don’t have a good way of sending it to you, but the bits that I can see are:

BootCurrent: 000B
Timeout: 1 seconds
BootOrder: 0002,000B,0009,0001,0008,000A,0003,0000,0007

The rest of the screen seems to describe each device, although the names have LOTS of periods in them (one example would be my DVD drive where it gives the name as BBS(CDROM,0x0)…G0…N0…o.T.S.S.T.c.o.r.p. .C.D.D.V.D.W. .S.H.-.2.2.4.D.B… and then it carries on like this with various other characters after it. It’s almost as if it’s trying to format the output in columns or something, but nothing is aligned so it is quite difficult to read. If you let me know what I’m looking for though I might be able to parse it better.

Ignoring the period spam, the remaining lines after “BootOrder” look pretty familiar with the names of each of my drives, and looks something like this:

Boot0000 Windows Boot Manager
Boot0001* Hard Drive (I can make out “Samsung SSD 850 EVO 250GB” in the spam that comes afterwards)
Boot0002* ubuntu
Boot0003* UEFI: Built-in EFI Shell
Boot0007 ubuntu
Boot0008* CD/DVD Drive
Boot0009* Unknown Device (I can see Hitachi in there)
Boot000A* Unknown Device (This one says SanDisk Cruzer, which is the flash drive I’m booted from)
Boot000B* UEFI: (FAT) SanDisk Cruzer 8.02

How does this look? What else can I give you from the spam that might help?

Do you imply that “Rescue System” menu fails but “Installation” works? I find it very hard to believe - both load exactly the same kernel and initrd and differ only in one option for linuxrc and error message you provided indicates kernel failed very early, before any user space could be loaded, so this option should make no difference. Can you consistently reproduce failure of “Rescue System” when you try it as the very first thing after boot from installation medium?

How does this look?

Nothing spectacular. Somewhat interesting is the fact that Windows boot option is disabled (which is probably why it is not offered as firmware boot menu entry). I am not sure what could cause it. As you “helpfully” edited out most of the output it is not even possible to cross-reference this option with previous BIS information. You may try to enable this option (efibootmgr -a 0000) and see if it appears after reboot and what happens when you select it. If it works and actually loads Windows next step would be to switch your openSUSE installation to EFI boot.

What else can I give you from the spam

When you are asked to provide output of command that is exactly that - output of command. Where have you seen someone asking you to edit this output and remove everything you consider spam?

Symptoms reported point to Compatibility Support Module being enabled. Disabled CSM on my machine and got a nice menu:

erlangen:~ # efibootmgr  -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* opensuse      HD(1,GPT,ad12e59d-b80f-4641-83ad-ab306e5d30ea,0x800,0x32000)/File(\EFI\opensuse\grubx64.efi)
Boot0001* opensuse.repair       HD(1,GPT,7b789b0c-9cf6-470d-907a-05df8a001cd7,0x800,0x32000)/File(\EFI\opensuse\grubx64.efi)
erlangen:~ # 

You may disable CSM on your machine and try one of the remaining boots first.

Great.

Now lets see if you can continue from there.

As before, CTRL-ALT-F2 on the license screen.

And then:

Mount the root partition of your installed system at “/mnt”. It looks as if that should be

mount /dev/sdb2 /mnt

Hmm, it is “btrfs” so you have to also mount a bunch of subvolumes. I’m not sure on how to best do that.

Let’s delay that for a moment.
It looks like “/home” is “/dev/sdb3”.

mount /dev/sdb3 /mnt/home

and lets add swap for good measure

swapon /dev/sdb4

Then you also need:


mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

Back to those subvolumes:


chroot /mnt
mount -a

That puts you in a “chroot” environment, and attempts to mount everything. I’m not sure if that works, since some parts are already mounted. If it doesn’t, then you have to go through “/etc/fstab” and mount subvolumes one at a time.

If that worked, while still in a chroot subshell


mount /dev/sda2 /boot/efi

That should mount the EFI partition.

And then:


grub2-install --target=x86_64-efi
cd /boot/grub2
grub2-mkconfig -o grub.cfg

If that all worked, then you should be set for UEFI booting of opensuse.


exit   ### leave the chroot environment
umount -R /mnt

Then CTRL-ALT-F7 to get back to the installer GUI. There you should abort and reboot. And maybe you can reboot into openSUSE using UEFI.

Hi again, nrickert.

I was able to get the rescue kernel working (see below for explanation), and log in as root.

I then proceeded to punch in all of the commands above that you listed, up until the

mount /dev/sda2 /boot/efi

one. At this point I get the following error:
“mount: /boot/efi: mount point does not exist”.

Does this mean that I’m not actually booted to the USB in UEFI mode? I noticed that if I set my BIOS to “UEFI” only, then I get the error I posted above (“exit_boot() failed!” and “efi_main() failed!”) on all of the “Installation”, “Rescue System”, and “Boot Linux System” options on the USB. The only way I can get “Rescue System” (and “Installation”) to work is if I change the BIOS to “LEGACY+UEFI”, and then select “UEFI: (FAT) SanDisk Cruzer 8.02” from my BIOS boot menu. This seems really odd to me, because the option in the BIOS boot menu is the same whether my BIOS is set to “UEFI” or “LEGACY+UEFI”, but it won’t let me load the Rescue kernel when the BIOS is set to “UEFI”.

Thanks for chiming in, karlmistelberger. I had a dig around my BIOS for a Compatibility Support Module, but couldn’t find anything. Some Googling (MSI Global English Forum) suggested that CSM might be an Asus specific motherboard feature and I should look for WHQL instead (my motherboard is an MSI Z97 PC Mate). Unfortunately, I wasn’t able to find that in any of my BIOS settings either. There are some Windows 8/8.1/10 Configuration options:

Windows 8/8.1/10 Feature: Disabled (Desc: Enables the supports for Windows 8/8.1/10 or disables for other operating systems.)
MSI Fast Boot: Disabled (Desc: MSI Fast Boot is the fastest way to boot the system. It will disable more devices to accelerate the system boot time which is faster than the boot time of “Fast Boot”.)
Fast Boot: Disabled (Desc: Enables or disables the Windows 8/8.1/10 fast boot feature. This item will only be available when “MSI Fast Boot” is disabled).

Are any of these similar to what you are referring to?

Many thanks.

I read the fine manual and found:

Boot Mode Select:

[UEFI]
[LEGACY-UEFI]

Make sure to install first Grub2 for UEFI as detailed by nrickert. Then you may refer to Frühjahrsputz | Karl Mistelberger

Oops! My mistake. It should have been:


mkdir /boot/efi   ## ignore an error that says it already exists
mount /dev/sda2 /boot/efi

Does this mean that I’m not actually booted to the USB in UEFI mode?

No, it only means that the directory “/boot/efi” (or, really, “/mnt/boot/efi”) does not yet exist.

You can test if you are in UEFI mode with:

efibootmgr -v

If you are in UEFI mode, that should give a bunch of output about booting. Otherwise it will give an error message about “efivars”.