Boot issues GRUB2 vs Win10

English Install/Boot/Login
1

I realize this may be a Windows 10 issue, but here goes.

I installed OpenSUSE LEAP 15.2 on my Dell Inspiron 7591 1TB SSD after using GParted to make space for it. GRUB2 did a good job booting the system (which has Secure Boot disabled in BIOS), so all seemed good.

Suddenly, possibly after a Windows update, GRUB2 would not load. I can boot off the install media and select More > Boot System, etc, and OpenSUSE isn’t damaged. I’ve tried reinstalling GRUB2 like a dozen times. I’ve tried changing parameters by turning secure boot and trusted boot support on and off, telling update-bootloader to --reinit and write over files, looked around under /etc and various subfolders for any clue as to why it’s doing this, but nothing seems to work.

The system uses /dev/nvme0n1 as the hard drive device name, with (weird) my MicroSD slot as sda. I made it a point to remove the MicroSD any time I try to reinstall Grub2 for fear it might think to use sda. Granted, I didn’t own this MicroSD when I installed OpenSUSE LEAP 15.2, so I don’t think it’s getting “confused” by this device existing…

I have told Windows to boot into UEFI menu (which results in nothing happening on reboot). I have gone into the system BIOS and, sure enough, SecureBoot isn’t even enabled.

I’ve tried installing GRUB2 with secure and trusted boot off, etc. I’ve basically “Christmas-treed” all the options on and off trying to reinstall GRUB2, to no avail.

I’m glad it boots Windows 10, because I need that for graduate school, but as we all know, OpenSUSE is better :wink:

Does anyone know if there are advanced options in Windows or special flags in GRUB2 that I can use to force GRUB2 to not get “taken over” by Windows 10?

Also, GRUB2 has worked before, but I recall the warning message in the OpenSUSE installer about the EFI partition not being 256MB or whatever it says. Does that matter? Do I really need to boot back into GParted and move partitions around to resize EFI to be 256MB or higher? It’s currently 150MB, but since GRUB2 has worked before, I would tend to believe that’s not an issue, but am I wrong?

2

No, that is not needed, unless the partition is full. OpenSUSE uses around 25M of space on that file system.

The chances are that this is a BIOS problem.

Can you post the output from:

efibootmgr -v

and use CODE tags to post that.

3 
BootCurrent: 0005
Timeout: 2 seconds
BootOrder: 0004,0002,0001,0005
Boot0000  Windows Boot Manager	HD(1,GPT,21e5a8ca-5f9b-4ebf-b599-f10785209159,0x800,0x4b000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...O................
Boot0001* UEFI: Seagate BarraCuda 510 SSD ZP1000CM30001, Partition 1	HD(1,GPT,21e5a8ca-5f9b-4ebf-b599-f10785209159,0x800,0x4b000)/File(\EFI\Boot\BootX64.efi)..BO
Boot0002* opensuse	HD(1,GPT,3bbe57da-ec8a-bb40-be31-435e2035c68d,0x800,0x4b000)/File(\EFI\opensuse\grubx64.efi)
Boot0004* opensuse-secureboot	HD(1,GPT,3bbe57da-ec8a-bb40-be31-435e2035c68d,0x800,0x4b000)/File(\EFI\opensuse\shim.efi)
Boot0005* UEFI: TSSTcorpCDDVDW SN-S083F SB01	PciRoot(0x0)/Pci(0x14,0x0)/USB(0,0)/CDROM(1,0x2bd,0x207c)..BO
4

What does it mean? You get some error message? According to efibootmgr output default boot choice is openSUSE shim which should then load grub.

5

It looks as if you have two EFI partitions.

One of them is used by Windows, and has PARTUUID=21e5a8ca-5f9b-4ebf-b599-f10785209159

The other is used by openSUSE, and has PARTUUID=3bbe57da-ec8a-bb40-be31-435e2035c68d

Do those two partitions both exist? You can check by looking in “/dev/disk/by-partuuid”. Or, as root, you can use the “blkid” command.

6 
/dev/nvme0n1: PTUUID="5ffe92da-fd75-40f5-bbc4-12033d293db6" PTTYPE="gpt"
**/dev/nvme0n1p1: LABEL="ESP" UUID="18F3-A46F" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="21e5a8ca-5f9b-4ebf-b599-f10785209159"**
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="b7a644d1-94cc-484f-8cfb-d565ab4a2fae"
/dev/nvme0n1p3: LABEL="OS" UUID="30EEC500EEC4BEFA" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="fab70f79-54ad-4b7f-a5a3-79cc8fd1faf4"
/dev/nvme0n1p4: LABEL="WINRETOOLS" UUID="5430C67930C6619A" TYPE="ntfs" PARTUUID="e18bfd1b-9439-4bee-bc65-4bb6616a1584"
/dev/nvme0n1p5: LABEL="Image" UUID="B8A2C355A2C316B2" TYPE="ntfs" PARTUUID="733eb9c8-16ab-4d25-9d2f-b2a0099a3dfc"
/dev/nvme0n1p6: LABEL="DELLSUPPORT" UUID="98603E5D603E4274" TYPE="ntfs" PARTUUID="945c6960-24a7-46af-9937-ec20c3a6836f"
/dev/nvme0n1p7: UUID="d9ac2967-2ef3-420e-ad87-86c3ba3b5160" TYPE="ext4" PARTUUID="2373c141-1dac-4c46-9abf-cd940cadfa44"
/dev/nvme0n1p8: UUID="6ebf9b9f-007e-4522-8e40-719bd5b4d29d" TYPE="crypto_LUKS" PARTUUID="320c3835-9442-433d-acfc-e09658af4e73"
/dev/sr0: UUID="2020-06-26-06-47-10-29" LABEL="openSUSE-Leap-15.2-DVD-x86_64695" TYPE="iso9660" PTUUID="6fd2dfbf" PTTYPE="dos"
**/dev/sda1: LABEL="SCRATCHPAD" UUID="20745EC1745E98FC" TYPE="ntfs" PARTUUID="3bbe57da-ec8a-bb40-be31-435e2035c68d"**
/dev/mapper/cr_nvme-Seagate_BarraCuda_510_SSD_ZP1000CM30001_7QL009PN-part8: UUID="mN1jko-elb2-r5mp-M0cz-kzBe-u8Lj-fJgNlr" TYPE="LVM2_member"
/dev/mapper/system-swap: UUID="3019b66f-bcc7-420f-8047-ce312110e167" TYPE="swap"
/dev/mapper/system-home: UUID="13d66495-9beb-48f3-95c4-cd57c530da47" TYPE="ext4"

So it appears something, possibly GRUB2, turned my MicroSD into an EFI. I’ll fix that by moving the data off the MicroSD and zeroizing it.

Then I’ll run update-bootloader --reinit with it not even in the computer and see if that fixes the problem.

Thanks, I had no clue how to go about troubleshooting it. Here’s hoping it will begin behaving.

Does anyone know where in the configuration of systemd and/or OpenSUSE I can find what keeps telling GRUB2 to try to write the EFI code to /dev/sda1 ? I know that would make logical sense on the majority of systems, but in my case it’s detrimental…

7

Now it looks like this (deleted any entry that wasn’t the hard drive)

BootCurrent: 0005
Timeout: 2 seconds
BootOrder: 0002,0001
Boot0000  Windows Boot Manager	HD(1,GPT,21e5a8ca-5f9b-4ebf-b599-f10785209159,0x800,0x4b000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...O................
Boot0001* UEFI: Seagate BarraCuda 510 SSD ZP1000CM30001, Partition 1	HD(1,GPT,21e5a8ca-5f9b-4ebf-b599-f10785209159,0x800,0x4b000)/File(\EFI\Boot\BootX64.efi)..BO
Boot0002* opensuse	HD(1,GPT,21e5a8ca-5f9b-4ebf-b599-f10785209159,0x800,0x4b000)/File(\EFI\opensuse\grubx64.efi)

I re-ran update-bootloader --reinit

Let’s see what happens.

8

That last output looks better. It now shows openSUSE using the same EFI partition as used by Windows.

9

Thanks for all your help, it rebooted into GRUB2 again.

Is there already an open bug for this? I say that having looked in

man update-bootloader

and

grep -R sda /etc/*

for this, looking for maybe a config file somewhere that was defaulting to the /dev/sdXX hard drive types. Given the proliferation of SSDs in laptops, it might be helpful to the community to report this bug (I can do that) so that others benefit from this finding.

Granted, my MicroSD reader should probably not be /dev/sda (might reflect on Dell or Intel’s decisions regarding how to populate their hardware), but…

10

What do you have mounted at “/boot/efi”.

Maybe:

grep efi /etc/fstab
11

Sure, I know how to figure out what’s in fstab and what’s mounted :wink:

root@desktop-01721d1:~> mount | grep efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

root@desktop-01721d1:~> grep efi /etc/fstab
UUID=18F3-A46F                             /boot/efi  vfat  defaults      0  2
12

Output looks good.

I don’t know of any open bugs on the same problem. But I might not notice, so there could be one.

13

For what? You still did not explain what the problem is.

14

If you boot the installer in EFI mode it sets up EFI stuff. If you boot in legacy/MBR mode it sets up MBR stuff.