On 9/30/2020 8:17 AM, Chris Murphy wrote: I can confirm this bug does exist. Attempting to boot on my Surface Pro 4 requires secure boot to be momentarily shut-off. SB actually is reporting a secure boot violation for whatever reason. I have reason to believe that the UEFI files are missing correct signing, or that signing needs to be updated. I have also seen SB failures with my Dell laptop with SB enabled, but those are easier to work around than going nuclear on a Surface Pro and shutting-off secure boot. F31 and F32 are unaffected, this appears to have started with F33. -- Erich Eickmeyer Project Leader Ubuntu Studio Maintainer Fedora Jam

On Wed, Sep 30, 2020 at 12:45:40PM -0400, Stephen John Smoogen wrote: This would be my guess as well. If you install with secure boot disabled and then turn it back on after doing a full update does it boot correctly? Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

Am 30.09.20 um 18:45 schrieb Stephen John Smoogen: It you have removed windows, there is no update mechanism for a surface pro 4 ,, at least , not out of the box. I will ask in the surface kernel group, they tend to know such things. Best regards, Marius

On Wed, Sep 30, 2020 at 10:46 AM Stephen John Smoogen <smooge(a)gmail.com&gt; wrote: released to deal with the grub2 problems found during the summer. I believe some systems have needed firmware updates from the manufacturer to work with the new key because they worked by white listing the old set, and don't know how to handle when a new key signed and authorized is presented. I don't know how the Surface Pro does its firmware updates and if one is needed. Fedora 31, 32, and 33 have: shim-x64-15-8.x86_64 koji date 2018-10-02 The signing keys haven't yet been updated in Fedora, they'd need to happen here. And then these are current grub2-efi-x64-2.04-31.fc33.x86_64 grub2-efi-x64-2.04-23.fc32.x86_64 grub2-efi-x64-2.02-110.fc31.x86_64 I wonder if the affected hardware is adversely affected by all three of these versions of GRUB?

On Wed, Sep 30, 2020 at 3:42 PM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote: The race happens with the same probability regardless of GRUB Fedora release version? Sounds like a firmware bug. I wonder if it's strictly USB related or if it's at all triggered by the isohybrid nature of our ISOs - maybe it's more or less likely to happen if the USB stick were created using livecd-iso-to-disk with '--format --efi' options and allow it to blow away the entire USB stick. -- Chris Murphy

On Wed, Sep 30, 2020 at 4:22 PM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote: OK so some kind of regression in GRUB, but also a firmware bug because otherwise many other people would run into this. It's GRUB 2.02 in Fedora 31 and GRUB 2.04 in Fedora 32. So it could be an upstream bug. Where I'd start is making a livecd-iso-to-disk based USB stick, from the Fedora 32 ISO that you already know fails, and make sure it still fails when created this way. If it doesn't, then it's probably not GRUB it's something else about the image. But assuming it fails, you now have an easily modifiable USB stick, it's read-writable, so you can just copy each test grubx64.efi binary onto the stick. You could start with this, pretty sure it'll fail too. So just extract the grubx64.efi from grub2-efi-x64-2.04-1.fc32.x86_64.rpm and replace the one on the USB stick. https://koji.fedoraproject.org/koji/buildinfo?buildID=1356278 -- Chris Murphy

This attempt failed too:  #  grub2-install /dev/sda grub2-install: Fehler: /usr/lib/grub/x86_64-efi/modinfo.sh existiert nicht. Bitte geben Sie --target oder --directory an. and that file seems not to be part of any package. There is only one for "i386-pc". Marius

On Thu, Oct 01, 2020 at 11:07:28AM -0700, Samuel Sieb wrote: Of course you have. How else would you get GRUB EFI executable onto the boot partition and register it into boot environments? But the correct invocation for EFI systems is different. You just use "grub2-install" without the disk device name. The missing file is provided by grub2-efi-x64-modules package. -- Petr

Am 03.10.20 um 11:17 schrieb Marius Schwarz: A: because it's not found This is working and maybe the clue, why grub2-install fails: set root=(hd0,gpt3) configfile (hd0,gpt2)/grub2/grub.cfg Any ideas? Marius

Am 03.10.20 um 11:43 schrieb Tomasz Torcz: That seems to be commented incorrectly: L1045:       /*         The EFI System Partition may have been given directly using         --root-directory.       */ there is no such option according to man and --help .        grub-install [--modules=MODULES] [--install-modules=MODULES]                      [--themes=THEMES] [--fonts=FONTS] [--locales=LOCALES]                      [--compress[=no,xz,gz,lzo]] [-d | --directory=DIR]                      [--grub-mkimage=FILE] [--boot-directory=DIR]                      [--target=TARGET] [--grub-setup=FILE]                      [--grub-mkrelpath=FILE] [--grub-probe=FILE]                      [--allow-floppy] [--recheck] [--force] [--force-file-id]                      [--disk-module=MODULE] [--no-nvram] [--removable]                      [--bootloader-id=ID] [*--efi-directory=DIR*] INSTALL_DEVICE could --efi-directory be meant? ### UPDATE ### .... after investigating the problem with not finding grub.cfg in the proprosed bootpath /boot/ .. the solution was simple. The system died not use secure boot, as secure-boot was disabled for the kernel-surface kernelseries. They are not signed, so no secure boot possible. Means: bios is loading "/boot/grub2/grub.cfg" but it can't find it, because those are symlinks to "/boot/efi/fedora/grub.cfg" but that is not accessible, because the partition it's linked to, is not mounted there when grub starts. those symlinks where necessary to fix some  other bugs with grubby, which has a slight different imagination where to do updates to grub.cfg, as grub itself has. In other words, one loads from efi path, one not . So symlinks were there to keep them in Sync. ( documented in a grub/grubby br @ bz ) Because it worked before the grub2-install with those symlinks (grub.cfg & grubenv) , there needs to be a different grub-install cmd needed : which could that be? (for now my system starts again) best regards, Marius

Am 03.10.20 um 22:23 schrieb Chris Murphy: I believe this due to the way the system got installed in the first place, which was via a secure booted livedisc. Later, as the usual kernel build for Fedora did not support touch on the pro4,  Jake Day's 5.1 kernel was build on the system, but i needed to be started without secure boot. now, the efi stuff is installed, i accept a few "oh, theres efi, i do efi" mistakes from time to time. But i don't have a clue, how the system could boot with those symlinks before that grub-install destroyed it. And still,we do not know why the f33 livedisc does not boot at all when inserted early AND why grub-install /dev/USBDRIVE  (correct devicename ofcourse ) is overwriting the ssd boot setup, instead of the usbdrive bootconfig. best regards, Marius

On Sun, Oct 4, 2020 at 3:01 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote: This is why, for elementary OS image testing or live image testing, it's often safer and faster to do it inside of a virtual system, whether you use KVM, Virtualbox, VMWare, Xen, or whatever. Manipulating your test system's grub settings is somewhat risky.

On 10/5/20 11:21 AM, Marius Schwarz wrote: I don't understand why you think that would be a problem. You left out the following line. When Fedora is installed on a UEFI system, the "grub2-efi" package is installed which puts grub on the EFI partition where it should be. If you want to fix the grub install, then you need to reinstall that package with the right EFI partition mounted at /boot/efi.

Am 06.10.20 um 01:50 schrieb Chris Murphy: I already tried to replace it with a f31 one, it did not help at all. The difference must be something else: a block signature, blockloader, mbr whatever is used on an efi bios with secure boot disabled before that file is loaded. I did not try to boot it with secure boot enabled, maybe i should test that. Best regards, Marius

On Fri, Oct 2, 2020 at 3:12 AM Petr Pisar <ppisar(a)redhat.com&gt; wrote: It's in an arch specific RPM. e.g. grub2-efi-x64-2.04-31.fc34.x86_64.rpm contains grubx64.efi created and signed within the Fedora build system. The grub2-install created executable is not signed, will not work with UEFI Secure Boot enabled unless manually signed by the user, and it has different behavior from the Fedora created one: where it expects to find modules and the grub.cfg. No the correct invocation is "dnf reinstall grub2-efi-x64 shim-x64" Suggesting UEFI users install GRUB with grub2-install is asking for a support nightmare, it's untenable. -- Chris Murphy

On Sun, Oct 4, 2020 at 10:50 AM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote: No because grub comes in arch and firmware specific flavors, which are compile time options. You get one or the other. As amazing as GRUB is in terms of all the use cases it can support, it's mind numbingly complicated because of all the use cases it can support. And that's a reference to upstream. Fedora keeps over 200 patches on top of that, which have to be updated and tested every time we rebase. -- Chris Murphy

Am 01.10.20 um 00:19 schrieb Elliott Sales de Andrade: The working procedure is: Power on entering Bios switching to boot manager page inserting the stick waiting until it gets powered on swiping the usb storage boot entry to left acknowledging the usb boot. None working procedure: Power on Inserting stick switching to bios switching to boot manager page swiping the usb storage boot entry to left acknowledging the usb boot. ... none secure boot message from bios reset. Marius

On 9/30/20 10:28 PM, Elliott Sales de Andrade wrote: He was saying that if he puts the stick in earlier, it's less likely to be able to boot. It's not about the firmware seeing it.