http://bugzilla.opensuse.org/show_bug.cgi?id=1137061 http://bugzilla.opensuse.org/show_bug.cgi?id=1137061#c1 Neil Rickert changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nwr10cst-oslnx@yahoo.com --- Comment #1 from Neil Rickert --- I am not able to reproduce this. I downloaded the 20190529 DVD installer, installed Tumbleweed with the defaults, including "btrfs" as the root file system. And the installed system booted up without any difficulty. This was in a KVM virtual machine. The generated "grub.cfg" in the EFI partition looks the same as previously, except for the changed UUID for the root partition. As far as I know, it is normal for "insmod" to fail if secure-boot is enabled. That's an intentional secure-boot restriction. But the grub modules likely to be needed are preloaded into "/boot/efi/EFI/opensuse/grub.efi" so the insmod should not normally be needed. At one time, I ran into the issue that you describe, except that I was not using "shim". I had installed "grub2" with grub2-install --boot-directory=/mnt/boot/grub2 and it did not build in support for "btrfs". I had to chroot into the mounted system and reinstall grub from there to get it right. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1137061 http://bugzilla.opensuse.org/show_bug.cgi?id=1137061#c3 --- Comment #3 from Javier de San Pedro --- Yeah, same thing in 20190529. I should elaborate: this does not result in unbootable system because linuxefi is builtin. However, no other Grub modules are loadable, so one cannot boot other OS, even if secure boot is disabled. To reproduce: 1. Install TW on UEFI system , using Grub2 2. Disable secureboot 3. On Grub2 prompt, type 'c' to go into Grub console 4. Enter "insmod linux" + <ENTER> 5. Enter "linux" + <TAB> Expected result: "Possible commands are: linux linuxefi" Actual result: "error: file `/boot/grub2/x86_64-efi/linux.mod' not found" Only linuxefi command is available Workaround: btrfs-mount-subvol ($root) /boot/grub2/x86_64-efi @/boot/grub2/x86_64-efi before running "insmod linux" Additionally, setting GRUB_USE_LINUXEFI="false" in /etc/default/grub WILL result in an unbootable system, because with this setting "linux" is used rather than "linuxefi" for the TW kernels, and "linux" module (as per the above) will fail to insmod. I am actually forced to use GRUB_USE_LINUXEFI=false on some workstations (due to multiple early UEFI firmware bugs *cough* AMI) . -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1137061 http://bugzilla.opensuse.org/show_bug.cgi?id=1137061#c5 --- Comment #5 from Javier de San Pedro --- I can confirm that. If I uncheck "Secure boot support" then it switches to grubx64.efi which does mount subvol /boot/grub2/x86_64-efi as part of its builtin load.cfg . It is intended then that the grub.efi run by the shim will not automount the /boot/grub2/x86_64-efi directory? It means that enabling the "secure boot support" checkbox has the side effect of making it slightly harder to load modules on btrfs system, even if secure boot is not actually enabled in the system. Modules can still be loaded by mounting the corresponding btrfs subvol (as long as secure boot is BIOS-disabled). If so feel free to close the bug. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1137061 http://bugzilla.opensuse.org/show_bug.cgi?id=1137061#c7 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #7 from Jiri Srain --- The main problem is: YaST enables SecureBoot by default on all machines; the idea is that it will do what is expected if there is proper support and has no harm in other cases. The second statement is obviously not true, as this report discovers. Therefore; While some wording could be changed in YaST, the main question is: How should YaST detect whether or not to enable secure boot during installation? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1137061 http://bugzilla.opensuse.org/show_bug.cgi?id=1137061#c9 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Bootloader |YaST2 Assignee|jsrain@suse.com |yast2-maintainers@suse.de Flags|needinfo? | --- Comment #9 from Jiri Srain --- Thanks, Neil, adding such hint at least to the help could indeed be useful. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1137061 http://bugzilla.opensuse.org/show_bug.cgi?id=1137061#c16 --- Comment #16 from Roger Whittaker --- A colleague and I came across this while debugging a dual boot issue recently. I understand the reasoning in some of the comments above, but it seems to me that the current status is unsatisfactory because it violates the principle of least surprise. We noted that from the grub command line we could not descend into subvolumes, then looked at /boot/grub2/x86_64-efi/load.cfg and assumed that therefore we should be able to do so, and suspected a bug, which is how we ended up here. Experimentation showed that the behaviour is only seen if "Enable Secure Boot Support" was checked when yast bootloader was run (as implied by the issue description here). "Enable Secure Boot Support" seems to be the default in yast bootloader, whether or not secure boot is actually enabled in the system firmware. I'm not sure what is feasible, but here are some suggestions for eliminating the element of surprise here. Is it possible for yast bootloader to actually check for whether secure boot is enabled in the firmware? And maybe, when the grub command line is invoked, would it be possible for it to emit a message saying something like: ============================================================ The bootloader was set up with secure boot support and btrfs subvolumes will be inaccessible unless you do: set btrfs_relative_path='y' and mount them using btrfs-mount-subvol ============================================================ Also maybe /boot/grub2/x86_64-efi/load.cfg could contain a comment stating that it will not be honoured if the bootloader is set up with secure boot support. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1137061 http://bugzilla.opensuse.org/show_bug.cgi?id=1137061#c17 Tripple Moon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |suse@trimoon.cloudns.eu --- Comment #17 from Tripple Moon --- There are ways to check for SecureBoot state: - mokutil --sb-state - /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c - /sys/firmware/efi/vars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/* Not sure if the GUID at end of that filename is fixed or not, but that is what i see on my current system while SecureBoot is disabled but present... I would expect that YAst should be able to use those pointers to check if SecureBoot is available and if so enabled or disabled... -- You are receiving this mail because: You are on the CC list for the bug.