My system boots into GRUB initially

[rokejulianlockhart]

About 4 dups ago (perhaps 3 weeks ago) my relatively new installation started booting into GRUB for no discernable reason. Any idea of what to check for the cause, and how to remediate it?

[hendersj]

What do you mean when you say it “boots into GRUB”? Is the system rebooting spontaneously, or is it not proceeding from the GRUB menu?

It’s not clear what you’re experiencing, so hard to determine a plan for remediation.

[nrickert]

Is this the system with 32-bit EFI?

Can you boot into it using the installer iso, and selecting the option to boot linux system from the iso boot menu?

[devguy.ca]

Did you change one of your hard drives?

[rokejulianlockhart]

@nrickert

Is this the system with 32-bit EFI?

@nrickert, no, my main desktop. I built it about a month ago. kcmshell5 kcm_about-distro reports

Operating System: cpe:/o:opensuse:tumbleweed:20231011
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.11
Kernel Version: 6.5.6-1-default (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
Memory: 30.5 GiB of RAM
Graphics Processor: AMD Radeon RX 5700
Manufacturer: ASRock
Product Name: X670E Taichi

---

@hendersj

What do you mean when you say it “boots into GRUB”? Is the system rebooting spontaneously, or is it not proceeding from the GRUB menu?

@hendersj, neither – it initially boots into the GRUB CLI, but if I type exit, all proceeds as normal.

---

@devguy.ca

Did you change one of your hard drives?

@devguy.ca, I’ve not since it was initially constructed, so no.

[nrickert]

@rokejulianlockhart

it initially boots into the GRUB CLI, but if I type exit, all proceeds as normal.

I’m not sure, but I think that means you are using UEFI booting. Your BIOS goes with the first selection in boot order. But when you exit your BIOS has another try with the next in boot order.

[rokejulianlockhart]

I’ve always used UEFI, @nrickert, yet never experienced this until now. Are you suggesting that I need to modify the boot order (or configuration on the GRUB bootloader side)?

[nrickert]

You can use efibootmgr to list the boot order. The boot order can change during an update.

[rokejulianlockhart]

But should an option exist that boots into the GRUB CLI, @nrickert?

RokeJulianLockhart@s1e8h4:~> efibootmgr
Absolute path to 'efibootmgr' is '/usr/sbin/efibootmgr', so running it may require superuser privileges (eg. root).
RokeJulianLockhart@s1e8h4:~> sudo efibootmgr
[sudo] password for root: 
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0001,0000
Boot0000* opensuse-secureboot   HD(1,GPT,208ebaf9-361b-4c02-a1a5-8591738a07bc,0x800,0x100000)/File(\EFI\opensuse\shim.efi)
Boot0001* opensuse-secureboot   HD(1,GPT,1083f27e-827f-43dd-933e-80cc776111a6,0x800,0x100000)/File(\EFI\opensuse\shim.efi) File(.)
RokeJulianLockhart@s1e8h4:~>

Not certain what to make of that. Does that mean that an erroneous duplicate exists?

[mrmazda]

@rokejulianlockhart

Does that mean that an erroneous duplicate exists?

That’s exactly what it looks like to me. Did you install the OS more than once?

If you match up your ESP’s UUID with one of the two opensuse-secureboot efibootmgr entry’s UUID I would expect removal of the other with efibootmgr to be a cure.

[nrickert]

@rokejulianlockhart

But should an option exist that boots into the GRUB CLI,

No. That happens when of the boots options is broken.

From what you describe, it seems likely that Boot0001 has problems.

You apparently have two EFI partitions. You can use the PARTUUID of 1083f27e-827f-43dd-933e-80cc776111a6 to identify which is Boot0001. The command (as root): blkid will identify the PARTUUID of your various partitions.

[rokejulianlockhart]

@mrmazda

Did you install the OS more than once?

@mrmazda, no. I am solely able to surmise that this occurred during an update, since all internal (NVMe BTRFS SSD) drives had their partition tables wiped using KDE Partition Manager - KDE Applications previous to installation of the OS, and I haven’t used them for OS installation since.

[rokejulianlockhart]

@nrickert

You apparently have two EFI partitions. You can use the PARTUUID of 1083f27e-827f-43dd-933e-80cc776111a6 to identify which is Boot0001. The command (as root): blkid will identify the PARTUUID of your various partitions.

@nrickert, I don’t see any partition boot flag information in sudo blkid’s output.

RokeJulianLockhart@s1e8h4:~> sudo blkid
[sudo] password for root: 
/dev/nvme0n1p1: LABEL="s123j0" UUID="EFAD-7F6D" BLOCK_SIZE="512" TYPE="exfat" PARTUUID="6e5ecb90-d18a-4099-a234-5ddc4910451b"
/dev/nvme3n1p3: UUID="7ffbb2f4-3e39-410c-9fea-48964cf2ccd1" TYPE="swap" PARTUUID="6036280e-3600-4498-8b20-d19e23b8f0b1"
/dev/nvme3n1p1: UUID="9574-544B" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="1083f27e-827f-43dd-933e-80cc776111a6"
/dev/nvme3n1p2: LABEL="s1elx5" UUID="c88d3378-ecaf-4cd1-aff5-db631b8f50fb" UUID_SUB="5e7f2758-866b-4276-a21f-cab3616a0d44" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="7c231be7-6e0a-43e1-a994-b5054f30741c"
/dev/nvme2n1p1: LABEL="s11vzd" UUID="a8dc8530-f314-407a-896c-861783f62ecf" UUID_SUB="55f61632-4d9b-4bd5-b6d8-4a9a1afcfd5f" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="61ba37a3-83e4-446f-aca9-0a4f63908fed"
/dev/nvme1n1p2: LABEL="s1elrp" UUID="579fa64f-308b-4c25-a716-74ec679512e7" UUID_SUB="f0ecab10-8b90-4115-a208-a8c8dc8213ab" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="d9312f63-c3b5-49bf-899d-113f84cc6bd0"
/dev/nvme1n1p1: UUID="12AC-35DE" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="208ebaf9-361b-4c02-a1a5-8591738a07bc"

[mrmazda]

Boot0000* opensuse-secureboot HD(1,GPT,208e… is the ESP partition on nvme1n1p1

Boot0001* opensuse-secureboot HD(1,GPT,1083… is the ESP partition on nvme3n1p1

Efibootmgr reports the one on nvme3 has priority.

What you haven’t reported is where TW was installed, and what is on the nvmes that TW is not on, or what they are used for. How many fstabs are on those nvmes? What does TW’s fstab contain? Do you know why there are apparently two ESPs in blkid output? Output from lsblk -f could be useful here, to see what’s being mounted where.

[nrickert]

@rokejulianlockhart

I don’t see any partition boot flag information in sudo blkid’s output.

I guess “blkid” doesn’t give flags.

“/dev/nvme3n1p1” is a “vfat” partition, and seems to be the one causing problems. And “/dev/nvm41n1p1” is also “vfat” and appears to be the one that is working.

Which of those do you have mounted at “/boot/efi”?

[rokejulianlockhart]

Apologies for the wait, all. 1216245 – Can't access opensuse.org and certain subdomains. occurred and then I was burgled. Thank you for the assistance.

---

@nrickert

Which of those do you have mounted at “/boot/efi”?

@nrickert, I’ve not manually done so. How would I go about ascertaining that reliably? I’m familiar with KDE Partition Manager, but I can probably learn YsST’s too if need be.

@mrmazda

Boot0000* opensuse-secureboot HD(1,GPT,208e… is the ESP partition on nvme1n1p1

@mrmazda, per

is what I expect. However,

definitely shouldn’t be a boot drive. Would mere removal of the “Boot” flag using that GUI be safe, do you expect?

[mrmazda]

None of my UEFI installations have boot flags set on their GPT drives. You might try removing it to see if it has any effect. If it doesn’t, try adding it to the ESP that it should be booting from. I would simply use efibootmgr to remove 1083…

[nrickert]

@rokejulianlockhart

How would I go about ascertaining that reliably?

Try:

df /boot/efi

or, perhaps:

mount | grep efi

(neither of those requires root).

[rokejulianlockhart]

@nrickert,

@nrickert

df /boot/efi

RokeJulianLockhart@s1e8h4:~> df /boot/efi
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/nvme2n1p1    523248  5928    517320   2% /boot/efi
RokeJulianLockhart@s1e8h4:~>

so I’m going to remove the boot flag from nvme3n1p1

@rokejulianlockhart

---

@mrmazda

I would simply use efibootmgr to remove 1083…

How, though, @mrmazda? I’m not particularly proficient at commandline low-level actions like these. There’s a first time for everything, after all.

[rokejulianlockhart]

I wiped nvme3n1 by recreating its GPT partition and ran systemctl reboot. It fixed the GRUB issue, but now I can’t boot.

I’m getting the same as

Boot stops on "Reached target Remote File Systems"

Some days ago OpenSUSE installation began to stop on boot after cold restart. The last “OK” message on display is “Reached target Remote File Systems” and then the endless “A job is running for /dev/sda2” waiting is present (/dev/sda2 is a swap partition). However, Ctrl-Alt-Del key combitation can lead to successful boot, usually two or three arrempts are required. Warm reboot works: when I reboot the system from the KDE GUI “Restart” button, computer restarts normally. Is this a hardware probl…

Except that I’ve not had a successful boot yet, regardless of whether I use Ctrl+Alt+Delete or not.

Usually the system boots quickly enough that I can’t see the boot log if I were to want to. It did once progress just pass this to Virtual Console Setup, but it hung regardless.