Description of problem: I'm getting install errors with grub2-mkconfig in bare metal UEFI systems. Version-Release number of selected component (if applicable): grub2-2.02-0.42.fc26 How reproducible: Always reproducible Steps to Reproduce: 2. create UEFI system 3. install FAH ISO Actual results: 00:24:00,920 DEBUG program: Return code: 0 00:24:00,921 INFO program: Running... grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg 00:24:01,690 INFO program: /usr/bin/grub2-editenv: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory. 00:24:01,691 INFO program: /sbin/grub2-mkconfig: line 247: /boot/efi/EFI/fedora/grub.cfg.new: No such file or directory 00:24:01,691 DEBUG program: Return code: 1 00:24:08,539 INFO program: Running... ostree admin instutil set-kargs rd.lvm.lv=fedora-atomic/root rd.lvm.lv=fedora-atomic/swap root=/dev/mapper/fedora--atomic-root 00:24:09,466 INFO program: Bootloader updated; bootconfig swap: yes deployment count change: 0 00:24:09,466 DEBUG program: Return code: 0 Expected results: No errors Additional info: This bug shares causes with the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=1479960 but with the caveat that it happens on F26 UEFI installations as well, but the fix hasn't been made available for F26 FAH images yet.
AFAICT, this is the exact same bug as https://bugzilla.redhat.com/show_bug.cgi?id=1479960, except it's targeted at f26. @pjones, can we get a new f26 grub2 build with the same patch?
(In reply to Jonathan Lebon from comment #1) > AFAICT, this is the exact same bug as > https://bugzilla.redhat.com/show_bug.cgi?id=1479960, except it's targeted at > f26. @pjones, can we get a new f26 grub2 build with the same patch? i've been told in f26 this only affects non virtual machines (or maybe it does affect virtual machines if the disk had been previously used from a previous installation). This would explain why our qcows still build just fine. jonathan can you try to get more details from drakonis (in IRC) and reproduce?
I saw some discussion to the effect that this may only happen when there's another OS installed? So something somehow related to os-prober?
> grub2-2.02-0.42.fc26 Which ISO is this from? From the IRC discussion, it seems like you used the latest stable one (timestamped 20170807), though the embedded tree there has grub2-2.02-0.40, which doesn't have the regression. Even the latest Bodhi ISO (timestamped 20170821) still only has -0.40. I don't see any pending Bodhi updates for F26 grub2 either. Regardless, I do expect 0.42 to indeed cause similar issues, so I'll build my own ISO with that update to confirm.
The ISO i used was: https://download.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-26-20170807.0/Atomic/x86_64/iso/Fedora-Atomic-ostree-x86_64-26-20170807.0.iso As for the issue with it happening when another OS is installed, its related to OSTree failing at deployment during the install phase, see bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1483818
@dusty: note the cloud images are all BIOS, not EFI, so wouldn't trigger this regardless. The only automated coverage AFAIK is https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=26&build=Fedora-Atomic-26-20170822.0&groupid=1
@Victor: I am testing this in virt-manager UEFI <https://fedoraproject.org/wiki/Using_UEFI_with_QEMU> and things seem OK. You said this is on metal; are you preserving any existing partitions? Is there any more detail you can provide about how to reproduce?
To confirm, I haven't been able to reproduce this on VMs. I tried overwriting existing installs and side-by-side installs (though that runs into https://bugzilla.redhat.com/show_bug.cgi?id=1483818). Neither with 20170807 nor with a custom ISO with grub2 0.42. With the latter, I *do* see this: 0:24:00,921 INFO program: Running... grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg 00:24:01,690 INFO program: /usr/bin/grub2-editenv: error: cannot rename the file /boot/grub2/grubenv.new to /boot/grub2/grubenv: No such file or directory. which has the same root cause as https://bugzilla.redhat.com/show_bug.cgi?id=1479960. But in grub2-mkconfig, that's not fatal. The real issue is: 00:24:01,691 INFO program: /sbin/grub2-mkconfig: line 247: /boot/efi/EFI/fedora/grub.cfg.new: No such file or directory 00:24:01,691 DEBUG program: Return code: 1 Which I think is from: exec > "${grub_cfg}.new" Where $grub_cfg is "/boot/efi/EFI/fedora/grub.cfg". I.e. something along this path does not exist/isn't mounted. Are you using custom partitioning? Are you doing anything special for /boot?
(In reply to Colin Walters from comment #6) > @dusty: note the cloud images are all BIOS, not EFI, so wouldn't trigger > this regardless. The original bug reported against rawhide caused the qcow images to fail to build: https://bugzilla.redhat.com/show_bug.cgi?id=1479960. But it only made rawhide builds fail. This reported bug says he can get the same error, but with F26 and only on "dirty environments", which would explain why our qcows successfully build in F26. At least that was my logic.
Just to reword what I said in comment #8; this bug and the rawhide one are separate issues. The output *looks* the same (hence my knee-jerk reaction in comment 1), but they are not. The rawhide bug is due to grub2-install failing to rename the grubenv file. This bug is due to failing to output to grub.cfg.new. As mentioned in comment #8, the part of the output that is the same as the other bug is non-fatal and comes from grub2-mkconfig calling grub2-editenv. @Victor, if you can easily reproduce this, can you add inst.nokill to the linuxefi cmdline, and after the failure, exit the installer and run `findmnt`?
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.