http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 Andrés Barrantes Silman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andresbs2000@protonmail.com Found By|--- |Community User -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c3 --- Comment #3 from Andrés Barrantes Silman --- Ugh I forgot to mention in my last comment: despite the bootctl output poiting to the correct partition, when I boot, according to the UEFI entry (opensuse-secureboot), it loads from Windows EFI, not booting at all. The entry I createad manually is OpenSUSE, and it boots successfully. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c5 Andrés Barrantes Silman changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(andresbs2000@prot | |onmail.com) | --- Comment #5 from Andrés Barrantes Silman --- Created attachment 839974 --> http://bugzilla.opensuse.org/attachment.cgi?id=839974&action=edit UEFI entries Attached picture showing EFI entires. Not much to say about them, they just point to different drives. You can see Pci-Root is the correct one (since the SSD operates on PCI). Theres nothing but a generic boot error "boot failed" showing retry, setup and diagnostic hotkeys. I also checked the Windows EFI in case, somehow, my grub files were there, and I only saw Microsoft's EFI files. The left entry is the one I created; the right one, after changing any bootloader settings at Yast or booting from bootx64. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fabian@ritter-vogt.de | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c8 --- Comment #8 from Fabian Vogt --- (In reply to Andrés Barrantes Silman from comment #7)

Created attachment 839979 [details] Shim log and efibootmgr output

efibootmgr appears to speak the truth, the partition uuid is wrong.

Looking at shim's log... four lines caught my attention:

+ rootdir= + efidir= + install_device= + efibootdir=

They're empty.

Attached requested logs as logs.zip.

That's actually just the initialization of variables at the beginning. shim-install fails because neither /boot/efi nor /boot/EFI exist as directory, which is weird. Can you confirm that? What's /etc/fstab, the output of findmnt and systemctl status /boot/efi (as root)? When YaST ran shim-install, /boot/efi was mounted and it finished successfully. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c10 --- Comment #10 from Andrés Barrantes Silman --- When installing I used guided setup for my partitions, and setup full disk encryption (except boot for obvious reasons, I assume the installer handled that). My home partition is using XFS while the others use BTRFS. I never changed anything in regards to EFI mountpounts, by the way. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c12 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(andresbs2000@prot | |onmail.com) --- Comment #12 from Fabian Vogt --- (In reply to Andrés Barrantes Silman from comment #9)

You're right! Aparantely there is /boot/efi/EFI...

That's normal - /boot/efi is the mountpoint of the ESP, which has everything below /EFI. So if /boot/efi/EFI exists, why does test -d /boot/efi in shim-install fail? Maybe this helps: findmnt test -d /boot/efi && echo "exists" grub2-probe --target=disk --device-map= /boot/efi grub2-probe --target=drive --device-map= /boot/efi bash -x shim-install --efi-directory /boot/efi AFAICT this is an unrelated issue though. Either /boot/efi is mounted as the wrong partition (which AFAICT is unlikely), grub2-probe is returning the wrong device or libefiboot translates the path wrong. Does this result in a working boot entry? efibootmgr -c -d /dev/nvme0n1 -p 1 -w -L efibootmgr-manual -l '\EFI\opensuse\shim.efi' -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c14 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |glin@suse.com --- Comment #14 from Fabian Vogt --- (In reply to Andrés Barrantes Silman from comment #13)

After running the other commands, the new boot entry "efibootmgr-manual" does not work either. It also points to the hard disk.

Ok, so it's efibootmgr or efivar doing something weird, reassigning. For completeness, what does blkid say? blkid /dev/sda /dev/sda1 /dev/nvme0n1 /dev/nvme0n1p1 blkid -p /dev/sda /dev/sda1 /dev/nvme0n1 /dev/nvme0n1p1

=drive shows:

(hostdisk//dev/nvme0n1,gpt1)

=disk shows:

/dev/nvme0n1

That confirms grub2-probe is working correctly.

Considering I had to do so many workarounds to get the Leap installer going... neither Balenaetcher, dd, or Rufus worked on Windows. Imagewriter on Leap did work and the installer now loads.

How did I start the installer? Somehow, the live iso did boot, so I added the DVD iso as a repository and the installer worked, business as usual from there.

Probably that confused something in the install process.

Possibly, but that would still be a bug and it's also reproduable manually apparently - AFAICT the system is configured correctly and there's nothing weird going on like duplicate UUIDs.

Anyways, now that I can load the installer, I might reinstall, just for the sake of it. I still want to see what went wrong in case there is actually a bug lying behind or it happens again.

FWICT, it does actually look like a bug. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c16 --- Comment #16 from Gary Ching-Pang Lin --- It's weird that "efibootmgr-manual" also points to /dev/sda1 since the dev path was already given explicitly... While I'm investigating the root cause, would you mind to try efivar 37? There is an planned update for efivar to upgrade from 35 to 37, and I would like to know if the upgrade fixes this issue. https://download.opensuse.org/repositories/home:/gary_lin:/bsc1174412/openSU... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c18 --- Comment #18 from Andrés Barrantes Silman --- Installed efivar 37 and updated libefivar1 to version 37, and it did not get fixed (didn't break anything either). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c20 --- Comment #20 from Gary Ching-Pang Lin --- The current efibootmgr didn't set the debug message for libefivar properly, so I modified it a bit. Please install the following efibootmgr along with libefivar1(*) that you already installed. https://download.opensuse.org/repositories/home:/gary_lin:/bsc1174412/openSU... After the installation, please try to create the boot entry with the following command: efibootmgr -v -v -c -d /dev/nvme0n1 -p 1 -w -L efibootmgr-manual -l '\EFI\opensuse\shim.efi' 2&>1 | tee efibootmgr.log It should provide the information of how efivar parses the path, so that we can find more clues of why it always falls back /dev/sda1. (*) https://download.opensuse.org/repositories/home:/gary_lin:/bsc1174412/openSU... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c22 --- Comment #22 from Gary Ching-Pang Lin --- (In reply to Andrés Barrantes Silman from comment #21)

Created attachment 840054 [details] 1

Attached log.

efibootmgr.log was empty.

I did not think too much about the command, just ran it as su and ignored warnings about signatures for the rpms.

¯\_(ツ)_/¯

Urghh, my silly typo. "2&>1" should be "2>&1". The correct version: sudo efibootmgr -v -v -c -d /dev/nvme0n1 -p 1 -w -L efibootmgr-manual -l '\EFI\opensuse\shim.efi' 2>&1 | tee efibootmgr.log -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c24 --- Comment #24 from Gary Ching-Pang Lin --- Per your log, nvme was recognized correctly linux.c:459 device_get(): trying nvme linux-nvme.c:65 parse_nvme(): entry linux-nvme.c:67 parse_nvme(): searching for nvme/nvme0/nvme0n1 or nvme/nvme0/nvme0n1/nvme0n1p1 linux-nvme.c:71 parse_nvme(): current:"nvme/nvme0/nvme0n1" rc:3 pos0:18 pos1:0 linux-nvme.c:72 parse_nvme(): ^ Actually, all those efibootmgr-manual boot entries point to the correct disk UUID: Boot0002* OpenSUSE PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-46-D1-0C-40)/HD(1,GPT,ac673ad3-75db-4ff0-85fc-1ee42b852d7c,0x800,0xfa000)/File(\EFI\opensuse\shim.efi) Boot0003* efibootmgr-manual HD(1,GPT,ac673ad3-75db-4ff0-85fc-1ee42b852d7c,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)2 Boot0004* efibootmgr-manual HD(1,GPT,ac673ad3-75db-4ff0-85fc-1ee42b852d7c,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)2 Boot0005* efibootmgr-manual HD(1,GPT,ac673ad3-75db-4ff0-85fc-1ee42b852d7c,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)2 Boot0006* efibootmgr-manual HD(1,GPT,ac673ad3-75db-4ff0-85fc-1ee42b852d7c,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)2 Boot0007* efibootmgr-manual HD(1,GPT,ac673ad3-75db-4ff0-85fc-1ee42b852d7c,0x800,0xfa000)/File(\EFI\opensuse\shim.efi)2 But I wonder why the device path ends in "2". Anyway, it's quite different from the boot entry showed in comment#5. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c26 --- Comment #26 from Andrés Barrantes Silman --- Alright I just noticed the 2 is not there anymore in my previous comment. Forgive that. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c28 --- Comment #28 from Andrés Barrantes Silman --- Created attachment 840098 --> http://bugzilla.opensuse.org/attachment.cgi?id=840098&action=edit tree output at both efi partitions The UEFI only shows one efibootmgr-manual entry, either at the boot selection screen or system setup. It does not boot. Nothing from OpenSUSE was installed at the hard drive, and actually, as I said above, disabling the HDD and creating the boot entry by just running Yast bootloader does create a boot entry pointing to the right disk. Until I enable it again. Attached session: a text file containing the output of tree for /dev/sda1 and /dev/nvme0n1p1 Those files seems to be where they are supposed to. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c30 --- Comment #30 from Gary Ching-Pang Lin --- I've tried qemu with NVME+HDD but had no luck. I installed openSUSE 15.2 in nvme.qcow2 and fedora 32 in hdd.qcow2. My qemu command: $ qemu-system-x86_64 -enable-kvm -s \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/ovmf-x86_64-ms-4m-code.bin \ -drive if=pflash,format=raw,file=current-vars.bin \ -smp 2 \ -machine type=q35 \ -m 4096 \ -hda hdd.qcow2 \ -drive file=nvme.qcow2,if=none,id=NVME1 -device nvme,drive=NVME1,serial=nvme-1 \ -chardev socket,id=chrtpm,path=/home/gary/VM/nvme/tpm/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ -device tpm-tis,tpmdev=tpm0 \ -virtfs local,id=fsdev,path=share,security_model=mapped-file,mount_tag=v_share \ -monitor stdio \ -debugcon file:debug.log -global isa-debugcon.iobase=0x402 \ -netdev user,id=hostnet0 -device virtio-net-pci,romfile=,netdev=hostnet0 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c32 --- Comment #32 from Gary Ching-Pang Lin --- Would you mind to paste the current "efibootmgr -v"? There are two mysterious parts till now. 1. The boot entry to the wrong partition We could not reproduce it manually, so I don't have a clear clue yet. 2. The failure of "efibootmgr-manual" The boot entry looks fine to me since it points to the correct partition. However, the firmware seems needing a full device path instead of a short one. I'll look into efibootmgr and see if it's possible to generate a full device path. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c34 --- Comment #34 from Andrés Barrantes Silman --- One thing I'd like to add that might be useful (or not!). When I was using Tumbleweed (between March and July 2020) on my SSHD, everything worked fine and the boot entry was created properly whenever I changed any settings or updated. The SSHD had Manjaro, Ubuntu, Windows and TW, all in single separate partitions. If it was my EFI, it would have failed there as well, I guess. What other software is invovled in the process of making the boot entry, apart from efibootmgr and libefivar1? Could it be something already fixed? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c36 --- Comment #36 from Gary Ching-Pang Lin --- (In reply to Andrés Barrantes Silman from comment #34)

One thing I'd like to add that might be useful (or not!). When I was using Tumbleweed (between March and July 2020) on my SSHD, everything worked fine and the boot entry was created properly whenever I changed any settings or updated. The SSHD had Manjaro, Ubuntu, Windows and TW, all in single separate partitions. If it was my EFI, it would have failed there as well, I guess. What other software is invovled in the process of making the boot entry, apart from efibootmgr and libefivar1? Could it be something already fixed?

So did the boot entry created by TW work for you? TW and 15.2 use the same efibootmgr version while TW uses efivar 37 already, it would be interesting if the TW boot entry actually works. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c38 Andrés Barrantes Silman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #38 from Andrés Barrantes Silman --- Well well... there was a firmware upadate, but it didn't solve it (just security). I didn't get any notifications so something is wrong with Dell. So the idea that if I install Leap on my hard drive the issue should happen there as well is not off... If it is the UEFI, I am wondering why did it start happening until now? The only different thing is that the UEFI has a master password now and USB boot locked. I think the same as the forum guys, I can't tell if it's the UEFI or Linux, but it seems like they're not talking to each other properly. Yup, -e 3 did it. Thanks! Boot0003* opensuse-manual PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-1B-44-8B-46-D1-0C-40)/HD(1,GPT,4aaad53c-5ec2-4c59-a48d-981c60d11db4,0x800,0xfa000)/File(\EFI\opensuse\shim.efi) Should I edit the title so it refelcts the actual problem or I leave it like that? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1174412 http://bugzilla.opensuse.org/show_bug.cgi?id=1174412#c40 --- Comment #40 from Andrés Barrantes Silman --- One thing I forgot to add is the fact that this time I ran the installer with my SSHD disabled in the UEFI, so that might have affected the outcome as well. I'll report again if the issue happens when I install TW (probably in the next five months?). Note that comment #5 also had an incomplete drive entry, so that was only half of the problem. Many things were not working as intended because of the weird way I had to install Leap. For example, Yast was not saving some settings properly after rebooting, my UID did not start where it was supposed to and locale settings were broken as well (man actually complained about it). No wonder why some discourage the use of the live iso, but that was the only option I had. -- You are receiving this mail because: You are on the CC list for the bug.