http://bugzilla.suse.com/show_bug.cgi?id=978593 http://bugzilla.suse.com/show_bug.cgi?id=978593#c10 Alexander Graf <agraf@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |agraf@suse.com, | |glin@suse.com, | |ihno@suse.com, | |jeffm@suse.com, | |ohering@suse.com, | |snwint@suse.com --- Comment #10 from Alexander Graf <agraf@suse.com> --- We've stumbled over an issue that looks very similar to this one, so let's hijack this bug in the hope that it really is the same problem. I see 2 issues overlapping themselves here. 1) Btrfs naming --------------- I had a quick chat with Olaf who ran into a similar issue with Xen's pvgrub. The basic problem boils down to difference between upstream grub2 btrfs handling and SUSE grub2 btrfs handling. While upstream uses full path names including the subvolume id: /@/boot/grub2 we omit the subvolume id and directly use a relative path into some default subvolume: /boot/grub2 This leads to a number of problems. In this case, it means that grub2-install puts the upstream style path into the prefix template in grubaa64.efi while our btrfs driver code expects the downstream style path. In the pvgrub case, it means that grub2 compiled from upstream sources can't read our grub.cfg properly, since the paths don't match. I guess this warrants a new bug id though and we should leave this bug to the yast2-bootloader issue that secure boot should be disabled on AArch64. 2) removable media binary To support systems that don't have working NVRAM to store EFI boot entries, I added code that determines we're running on such a system and in that case writes grub2 in the default EFI\BOOT\BOOTAA64.efi path: https://github.com/openSUSE/perl-bootloader/commit/bfd36e38188ccfbb737ffe57d... That code however gets invoked during installation without /sys mounted, so the heuristics fail and we always create a removable fallback binary. The net result of this is that you get a removable media bootaa64.efi (or bootx64.efi) which has a default btrfs path embedded that doesn't work because our btrfs paths look different. -- You are receiving this mail because: You are on the CC list for the bug.