Installing the F44 RC 1.1 workstation image, on first boot printed twice: "error: ../../grub-core/commands/loadenv.h:read_envblk_file:51:invalid environment block." This keeps the grub menu from showing up, and acts like an ongoing grub breakage because timeouts, display and seemingly selection are all basically broken until the /boot/grub2/grubenv file is removed. AKA this is a real pain because it seems to default to no show, 0 timeout, meaning it takes some reset + keyboard mashing a few times to actually get into grub. Reproducible: Always Steps to Reproduce: 1. M1 + ashai, virt-manager, F44 RC 1.1 image 2. Install to a VM, use an encrypted disk, otherwise all defaults 3. reboot Actual Results: "error: ../../grub-core/commands/loadenv.h:read_envblk_file:51:invalid environment block." "error: ../../grub-core/commands/loadenv.h:read_envblk_file:51:invalid environment block." Expected Results: That message is missing, and grub acts properly (hiding or not, honors timeouts, etc) Additional Information: Largely I wouldn't consider this to serious but I know how to get into grub and it takes me a few tries on a reasonably fast machine to accomplish it when this happens, and combined with a console bug/etc requiring kernel parameter tweaks is likely impossible for someone not sure when to mash buttons to avoid ending up in uefi or just directly booting.
Jeremy, do you know the last working GRUB2 version on this area?
Not really, I don't remember seeing it during F43 testing. Or even earlier F44 betas. That said once the grubenv file is removed it gets regenerated and things start working again, so it seems something is broken during the install (ex its using an older grubenv formatted file/etc).
(In reply to Jeremy Linton from comment #2) > Not really, I don't remember seeing it during F43 testing. Or even earlier > F44 betas. That said once the grubenv file is removed it gets regenerated > and things start working again, so it seems something is broken during the > install (ex its using an older grubenv formatted file/etc). Right. If possible, can you try latest F43 and see if you can reproduce it?
Right, its not in the 43 1.6 release image.
Created attachment 2136620 [details] screenshot
Two paths to try: 1- latest version: Can you try booting a previous F44 that is not affected, then update to latest (latest is 2.12-56.fc44 https://koji.fedoraproject.org/koji/buildinfo?buildID=2975652) ? 2- enable debug: on your original setup, after reboot, go to the GRUB shell typing 'c' from GRUB menu (if reached) and type 'set debug=all,-scripting,-lexer' then try booting. Share log (pics, video, text, etc.)
Hi Jeremy, Could you please do an # ls -l /boot/grub2/ and also cat the bad grubenv file so we can see it? Also, do you see any warnings or errors in the installation logs related to this? Logs are in /tmp during installation AFAIR. thanks.
jlinton@fedora:/boot/grub2$ ls -Falh total 24K drwxr-xr-x. 3 root root 4.0K Apr 10 10:54 ./ dr-xr-xr-x. 7 root root 4.0K Apr 10 10:54 ../ drwx------. 2 root root 4.0K Apr 10 10:52 fonts/ -rw-------. 1 root root 7.5K Apr 10 10:54 grub.cfg -rw-r--r--. 1 root root 1.0K Apr 10 10:54 grubenv jlinton@fedora:/boot/grub2$ hexdump -C grubenv 00000000 23 20 47 52 55 42 20 45 6e 76 69 72 6f 6e 6d 65 |# GRUB Environme| 00000010 6e 74 20 42 6c 6f 63 6b 0a 23 20 57 41 52 4e 49 |nt Block.# WARNI| 00000020 4e 47 3a 20 44 6f 20 6e 6f 74 20 65 64 69 74 20 |NG: Do not edit | 00000030 74 68 69 73 20 66 69 6c 65 20 62 79 20 74 6f 6f |this file by too| 00000040 6c 73 20 6f 74 68 65 72 20 74 68 61 6e 20 67 72 |ls other than gr| 00000050 75 62 2d 65 64 69 74 65 6e 76 21 21 21 0a 65 6e |ub-editenv!!!.en| 00000060 76 5f 62 6c 6f 63 6b 3d 35 31 32 2b 31 0a 73 61 |v_block=512+1.sa| 00000070 76 65 64 5f 65 6e 74 72 79 3d 65 39 61 30 32 34 |ved_entry=e9a024| 00000080 34 33 33 36 38 31 34 64 31 31 39 65 62 62 32 62 |4336814d119ebb2b| 00000090 37 32 39 30 35 37 36 36 37 65 2d 36 2e 31 39 2e |729057667e-6.19.| 000000a0 31 30 2d 33 30 30 2e 66 63 34 34 2e 61 61 72 63 |10-300.fc44.aarc| 000000b0 68 36 34 0a 6d 65 6e 75 5f 61 75 74 6f 5f 68 69 |h64.menu_auto_hi| 000000c0 64 65 3d 31 0a 62 6f 6f 74 5f 73 75 63 63 65 73 |de=1.boot_succes| 000000d0 73 3d 31 0a 23 23 23 23 23 23 23 23 23 23 23 23 |s=1.############| 000000e0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 |################| * 00000400
The actual grubenv seems to be read ok with the grub debug enabled. The failure seems to be around "Opening '(hd0,gpt2)512+1' which opens ok, but fails to close with 4, and then the invalid environment block messages appears.
Right, so the older versions aren't using a env_block option, and given this is 512 inside the ESP, that's potential data corruption if it does somehow write to it, right?
(In reply to Jeremy Linton from comment #10) > Right, so the older versions aren't using a env_block option, and given this > is 512 inside the ESP, that's potential data corruption if it does somehow > write to it, right? That may be the case but I am not sure. Right, env_block was introduce starting at f44, older versions do not have this feature.
Proposed as a Blocker for 44-final by Fedora user pbrobinson using the blocker tracking app because: Shipped artifacts should boor without issue
I'm finally able to reproduce this. Here is the debug log up until the error: BdsDxe: loading Boot0004 "Fedora" from HD(1,GPT,445A6329-E014-4434-9228-5E557454C213,0x800,0x12C000)/\EFI\fedora\shimaa64.efi BdsDxe: starting Boot0004 "Fedora" from HD(1,GPT,445A6329-E014-4434-9228-5E557454C213,0x800,0x12C000)/\EFI\fedora\shimaa64.efi kern/file.c:grub_file_close:229:file: Closing `(hd0,gpt2)/grub2/grubenv' ... kern/disk.c:grub_disk_close:305:disk: Closing `hd0'. disk/efi/efidisk.c:grub_efidisk_close:551:efidisk: closing hd0 kern/disk.c:grub_disk_close:319:disk: Closing `hd0' succeeded. kern/file.c:grub_file_close:237:file: Closing `(hd0,gpt2)/grub2/grubenv' succeeded. kern/verifiers.c:grub_verify_string:212:verify: string: [ 512+1 ], type: 2 kern/verifiers.c:grub_verify_string:212:verify: string: [ hd0,gpt2 ], type: 2 kern/verifiers.c:grub_verify_string:212:verify: string: set env_block=(hd0,gpt2)512+1, type: 2 kern/verifiers.c:grub_verify_string:212:verify: string: export env_block, type: 2 commands/wildcard.c:wildcard_expand:549:expand: no expansion needed commands/wildcard.c:wildcard_expand:608:expand: paths[0] = `(hd0,gpt2)512+1' kern/verifiers.c:grub_verify_string:212:verify: string: load_env -f (hd0,gpt2)512+1, type: 2 kern/file.c:grub_file_open:78:file: Opening `(hd0,gpt2)512+1' ... kern/device.c:grub_device_open:37:device: opening device hd0,gpt2 kern/disk.c:grub_disk_open:200:disk: Opening `hd0,gpt2'... disk/efi/efidisk.c:grub_efidisk_open:495:efidisk: opening hd0 disk/efi/efidisk.c:grub_efidisk_open:524:efidisk: m = 0x13ea984c0, last block = 27fffff, block size = 200, io align = 0 disk/efi/efidisk.c:grub_efidisk_open:542:efidisk: opening hd0 succeeded partmap/gpt.c:grub_gpt_partition_map_iterate:93:gpt: Read a valid GPT header partmap/gpt.c:grub_gpt_partition_map_iterate:115:gpt: GPT entry 0: start=2048, length=1228800 partmap/gpt.c:grub_gpt_partition_map_iterate:115:gpt: GPT entry 1: start=1230848, length=4194304 kern/disk.c:grub_disk_open:292:disk: Opening `hd0,gpt2' succeeded. kern/file.c:grub_file_open:143:file: Running GRUB_FILE_FILTER_VERIFY file filter kern/verifiers.c:grub_verifiers_open:88:verify: file: (hd0,gpt2)512+1 type: 60 kern/file.c:grub_file_open:143:file: Running GRUB_FILE_FILTER_GZIO file filter disk/efi/efidisk.c:grub_efidisk_read:616:efidisk: reading 0x40 sectors at the sector 0x12ca00 from hd0 kern/file.c:grub_file_open:143:file: Running GRUB_FILE_FILTER_XZIO file filter kern/file.c:grub_file_open:143:file: Running GRUB_FILE_FILTER_LZOPIO file filter kern/file.c:grub_file_open:155:file: Opening `(hd0,gpt2)512+1' succeeded. kern/file.c:grub_file_close:229:file: Closing `(hd0,gpt2)512+1' ... kern/disk.c:grub_disk_close:305:disk: Closing `hd0'. disk/efi/efidisk.c:grub_efidisk_close:551:efidisk: closing hd0 kern/disk.c:grub_disk_close:319:disk: Closing `hd0' succeeded. kern/file.c:grub_file_close:239:file: Closing `(hd0,gpt2)512+1' failed with 4. error: ../../grub-core/commands/loadenv.h:read_envblk_file:51:invalid environment block. I can confirm that removing grubenv or `grub2-editenv - unset env_block` both result in the GRUB menu showing up again.
Additional data points: you don't need an encrypted disk to be affected. A vanilla installation on aarch64 VM is enough to trigger this. Error 4 is GRUB_ERR_BAD_FILE_TYPE
(In reply to Jeremy Linton from comment #9) > The actual grubenv seems to be read ok with the grub debug enabled. The > failure seems to be around "Opening '(hd0,gpt2)512+1' which opens ok, but > fails to close with 4, and then the invalid environment block messages > appears. Can you show the output of `lsblk -f`? All this logic is assumed for btrfs filesystems so perhaps this is the problem.
Jeremy/Marta A scratch build [1] with a possible fix, please try it. BTW, not fully tested on my end, but better to share it. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=144479874
There is something weird about this issue... because I can only reproduce it when installing from the Workstation Live Iso. Any other method of installation, using a URL with --location, or using a different (non Live) iso, like Fedora-Everything-netinst-aarch64-44_Beta-1.2.iso, and I don't have env_block in grubenv, and the GRUB menu shows up as it should. In all cases, I'm using defaults and actually the fs is btrfs. $ lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sr0 zram0 swap 1 zram0 d01bc66e-968a-4041-aed3-4f7c81698bd1 [SWAP] vda ├─vda1 │ vfat FAT32 706E-8364 561.7M 6% /boot/efi ├─vda2 │ ext4 1.0 f2174cb0-b91e-42ab-a31b-b6491ade2f5c 1.4G 21% /boot └─vda3 btrfs fedora 24024df0-1240-481b-8209-5978ff0142e6 13.3G 22% /home /
Well by itself a koji download-task, dnf update *.rpm;dnf reinstall *.rpm didn't fix it. The message is still present.
(In reply to Jeremy Linton from comment #18) > Well by itself a koji download-task, dnf update *.rpm;dnf reinstall *.rpm > didn't fix it. The message is still present. did you grub2-mkconfig -o /boot/grub2/grub.cfg after dnf commands? I believe this time we need to run it manually.
This isn't aarch64-specific, I see the environment errors on x86_64 installs as well. But I'm not sure it actually affects how easy/hard it is to get into the grub menu. Workstation intentionally makes that hard anyway, regardless whether this bug happens (by setting config options intended to hide grub and set its timeout as short as possible). It's similarly difficult on older releases unaffected by the bug.
> There is something weird about this issue... because I can only reproduce it when installing from the Workstation Live Iso. Any other method of installation, using a URL with --location, or using a different (non Live) iso, like Fedora-Everything-netinst-aarch64-44_Beta-1.2.iso, and I don't have env_block in grubenv, and the GRUB menu shows up as it should anaconda has diverging paths here: https://github.com/rhinstaller/anaconda/blob/c15935a4f73e02c72556d89f40a3567ff3acca7e/pyanaconda/modules/storage/bootloader/grub2.py#L344 i.e. it'll do a `grub2-editenv` *if* if conf.bootloader.menu_auto_hide is True. That's the *only* time it'll do a grub2-editenv . menu_auto_hide is set True on these profiles: data/profile.d/centos.conf:menu_auto_hide = True data/profile.d/fedora-designsuite.conf:menu_auto_hide = True data/profile.d/fedora-sericea.conf:menu_auto_hide = True data/profile.d/fedora-workstation.conf:menu_auto_hide = True data/profile.d/rhel.conf:menu_auto_hide = True data/profile.d/fedora-kde.conf:menu_auto_hide = True So Workstation, KDE and Design Suite - possibly also Sericea, but atomic installs use different bootloader paths, so possibly not. Also means this will affect RHEL and CentOS if we don't fix it before they get it.
Discussed at 2026-04-16 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-04-16/f44-final-go-no-go-meeting.2026-04-16-18.00.html . Rejected as a blocker as we don't believe this has any serious practical consequences - we believe it doesn't actually make it any harder to get into the grub menu that it was anyway. Proposing as a Final FE as there was some discussion of granting it, though I'd be reluctant to take what's apparently a cosmetic fix at this stage.
(In reply to Leo Sandoval from comment #16) > Jeremy/Marta > > A scratch build [1] with a possible fix, please try it. BTW, not fully > tested on my end, but better to share it. > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=144479874 Replying to myself: fix did NOT work. I tested with [1] with virt-manager, both BIOS and UEFI. So issue is not just related to aarch64 and btrfs, probably applies to all archs/fs where env_block is present on the grub's environment. [1] https://dl.fedoraproject.org/pub/fedora/linux/development/44/Workstation/x86_64/iso/Fedora-Workstation-Live-44-20260416.n.0.x86_64.iso
(In reply to Leo Sandoval from comment #23) > (In reply to Leo Sandoval from comment #16) > > Jeremy/Marta > > > > A scratch build [1] with a possible fix, please try it. BTW, not fully > > tested on my end, but better to share it. > > > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=144479874 > > Replying to myself: fix did NOT work. I tested with [1] with virt-manager, > both BIOS and UEFI. So issue is not just related to aarch64 and btrfs, > probably applies to all archs/fs where env_block is present on the grub's > environment. > > [1] > https://dl.fedoraproject.org/pub/fedora/linux/development/44/Workstation/ > x86_64/iso/Fedora-Workstation-Live-44-20260416.n.0.x86_64.iso I meant this one, sorry https://dl.fedoraproject.org/pub/alt/stage/44_RC-1.2/Workstation/x86_64/iso/Fedora-Workstation-Live-44-1.2.x86_64.iso
Er? That's the Final RC. It has no intended fix for this in it, certainly not any scratch build.
Hi, Given that "/boot" is on ext4, "grub2-editenv" should not have created `env_block=512+1` in the first place based on how it is written and contributed upstream. I verified that "grub-editenv" behaves as expected and does not create this variable on a Fedora 44 install using the iso file above. The details are provided below. This suggests that "env_block=512+1" was added by another component during installation, although it is still unclear which one. 1. The `env_block` exist right after installation: > root@localhost-live:~# hexdump -C /boot/grub2/grubenv > 00000000 23 20 47 52 55 42 20 45 6e 76 69 72 6f 6e 6d 65 |# GRUB Environme| > 00000010 6e 74 20 42 6c 6f 63 6b 0a 23 20 57 41 52 4e 49 |nt Block.# WARNI| > 00000020 4e 47 3a 20 44 6f 20 6e 6f 74 20 65 64 69 74 20 |NG: Do not edit | > 00000030 74 68 69 73 20 66 69 6c 65 20 62 79 20 74 6f 6f |this file by too| > 00000040 6c 73 20 6f 74 68 65 72 20 74 68 61 6e 20 67 72 |ls other than gr| > 00000050 75 62 2d 65 64 69 74 65 6e 76 21 21 21 0a 65 6e |ub-editenv!!!.en| > 00000060 76 5f 62 6c 6f 63 6b 3d 35 31 32 2b 31 0a 73 61 |v_block=512+1.sa| > 00000070 76 65 64 5f 65 6e 74 72 79 3d 35 66 34 31 66 30 |ved_entry=5f41f0| > 00000080 37 38 64 62 61 36 34 37 66 38 38 66 30 37 64 35 |78dba647f88f07d5| > 00000090 64 65 38 63 65 36 64 30 37 61 2d 36 2e 31 39 2e |de8ce6d07a-6.19.| > 000000a0 31 30 2d 33 30 30 2e 66 63 34 34 2e 78 38 36 5f |10-300.fc44.x86_| > 000000b0 36 34 0a 6d 65 6e 75 5f 61 75 74 6f 5f 68 69 64 |64.menu_auto_hid| > 000000c0 65 3d 31 0a 62 6f 6f 74 5f 73 75 63 63 65 73 73 |e=1.boot_success| > 000000d0 3d 31 0a 23 23 23 23 23 23 23 23 23 23 23 23 23 |=1.#############| > 000000e0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 |################| > * > 00000400 2. Remove this grubenv > root@localhost-live:~# rm /boot/grub2/grubenv > rm：是否刪除一般檔案 '/boot/grub2/grubenv'？y 3. Create a new grubenv and verify it's content doesn't have `env_block=512+1` > root@localhost-live:~# grub2-editenv - set menu_auto_hide=1 boot_success=1 > root@localhost-live:~# hexdump -C /boot/grub2/grubenv > 00000000 23 20 47 52 55 42 20 45 6e 76 69 72 6f 6e 6d 65 |# GRUB Environme| > 00000010 6e 74 20 42 6c 6f 63 6b 0a 23 20 57 41 52 4e 49 |nt Block.# WARNI| > 00000020 4e 47 3a 20 44 6f 20 6e 6f 74 20 65 64 69 74 20 |NG: Do not edit | > 00000030 74 68 69 73 20 66 69 6c 65 20 62 79 20 74 6f 6f |this file by too| > 00000040 6c 73 20 6f 74 68 65 72 20 74 68 61 6e 20 67 72 |ls other than gr| > 00000050 75 62 2d 65 64 69 74 65 6e 76 21 21 21 0a 6d 65 |ub-editenv!!!.me| > 00000060 6e 75 5f 61 75 74 6f 5f 68 69 64 65 3d 31 0a 62 |nu_auto_hide=1.b| > 00000070 6f 6f 74 5f 73 75 63 63 65 73 73 3d 31 0a 23 23 |oot_success=1.##| > 00000080 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 |################| > * > 00000400 > root@localhost-live:~# grub2-set-default 0 > root@localhost-live:~# hexdump -C /boot/grub2/grubenv > 00000000 23 20 47 52 55 42 20 45 6e 76 69 72 6f 6e 6d 65 |# GRUB Environme| > 00000010 6e 74 20 42 6c 6f 63 6b 0a 23 20 57 41 52 4e 49 |nt Block.# WARNI| > 00000020 4e 47 3a 20 44 6f 20 6e 6f 74 20 65 64 69 74 20 |NG: Do not edit | > 00000030 74 68 69 73 20 66 69 6c 65 20 62 79 20 74 6f 6f |this file by too| > 00000040 6c 73 20 6f 74 68 65 72 20 74 68 61 6e 20 67 72 |ls other than gr| > 00000050 75 62 2d 65 64 69 74 65 6e 76 21 21 21 0a 6d 65 |ub-editenv!!!.me| > 00000060 6e 75 5f 61 75 74 6f 5f 68 69 64 65 3d 31 0a 62 |nu_auto_hide=1.b| > 00000070 6f 6f 74 5f 73 75 63 63 65 73 73 3d 31 0a 73 61 |oot_success=1.sa| > 00000080 76 65 64 5f 65 6e 74 72 79 3d 30 0a 23 23 23 23 |ved_entry=0.####| > 00000090 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 |################| > * > 00000400 > root@localhost-live:~#
(In reply to Adam Williamson from comment #21) > > There is something weird about this issue... because I can only reproduce it when installing from the Workstation Live Iso. Any other method of installation, using a URL with --location, or using a different (non Live) iso, like Fedora-Everything-netinst-aarch64-44_Beta-1.2.iso, and I don't have env_block in grubenv, and the GRUB menu shows up as it should > > anaconda has diverging paths here: > > https://github.com/rhinstaller/anaconda/blob/ > c15935a4f73e02c72556d89f40a3567ff3acca7e/pyanaconda/modules/storage/ > bootloader/grub2.py#L344 > > i.e. it'll do a `grub2-editenv` *if* if conf.bootloader.menu_auto_hide is > True. That's the *only* time it'll do a grub2-editenv . After "env_block" variable, there's also "saved_entry" being set before "menu_auto_hide" and "boot_success", perhaps somewhere else sets the grubenv and didn't use grub2-editenv?
I find that /boot/grub2/grubenv in the booted live system installer image already contains env_block=512+1, can it be related ? > root@localhost-live:~# findmnt / > TARGET SOURCE FSTYPE OPTIONS > / LiveOS_rootfs overlay rw,relatime,seclabel,lowerdir=/run/rootfsbase,upperdir=/run/overlayfs,workdir=/run/ovlwork,uuid=on > root@localhost-live:~# hexdump -C /boot/grub2/grubenv > 00000000 23 20 47 52 55 42 20 45 6e 76 69 72 6f 6e 6d 65 |# GRUB Environme| > 00000010 6e 74 20 42 6c 6f 63 6b 0a 23 20 57 41 52 4e 49 |nt Block.# WARNI| > 00000020 4e 47 3a 20 44 6f 20 6e 6f 74 20 65 64 69 74 20 |NG: Do not edit | > 00000030 74 68 69 73 20 66 69 6c 65 20 62 79 20 74 6f 6f |this file by too| > 00000040 6c 73 20 6f 74 68 65 72 20 74 68 61 6e 20 67 72 |ls other than gr| > 00000050 75 62 2d 65 64 69 74 65 6e 76 21 21 21 0a 65 6e |ub-editenv!!!.en| > 00000060 76 5f 62 6c 6f 63 6b 3d 35 31 32 2b 31 0a 73 61 |v_block=512+1.sa| > 00000070 76 65 64 5f 65 6e 74 72 79 3d 38 31 31 65 63 32 |ved_entry=811ec2| > 00000080 64 30 65 62 35 34 34 35 65 33 62 30 36 61 66 34 |d0eb5445e3b06af4| > 00000090 39 63 37 37 66 32 35 36 32 38 2d 36 2e 31 39 2e |9c77f25628-6.19.| > 000000a0 31 30 2d 33 30 30 2e 66 63 34 34 2e 78 38 36 5f |10-300.fc44.x86_| > 000000b0 36 34 0a 23 23 23 23 23 23 23 23 23 23 23 23 23 |64.#############| > 000000c0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 |################| > * > 00000400 > root@localhost-live:~#
Hi Michael, thank you for looking at this issue. You're totally right that env_block is already set on the iso. I can still only reproduce this on aarch64 and with the Live ISO, which is being created using kiwi. @ngompa13 could you please take a look? Maybe you can help with this? thanks!
I have created a PR for f44 https://src.fedoraproject.org/rpms/grub2/pull-request/218 The idea is to limit loading/saving the env_block only for btrfs /boot fs.
Hi. I have opened a MR to remove the env_block in grubenv file if the filesystem do not support external environment block, in case the grubenv is copied from unknown source rather than a locally generated one. It should fix the issue here since the installer calls grub2-editenv to set variables and that triggers the cleanup. https://gitlab.freedesktop.org/gnu-grub/grub/-/merge_requests/106
(In reply to Michael Chang from comment #31) > Hi. > > I have opened a MR to remove the env_block in grubenv file if the filesystem > do not support external environment block, in case the grubenv is copied > from unknown source rather than a locally generated one. It should fix the > issue here since the installer calls grub2-editenv to set variables and that > triggers the cleanup. > > https://gitlab.freedesktop.org/gnu-grub/grub/-/merge_requests/106 Much cleaner, thanks Michael. I will just test it on f44 before merging.
AGREED RejectedFinalFreezeException Discussed at the 2026-04-20 (blocker / freeze exception) review meeting: This is rejected on the basis it's a bit late to be poking bootloader-related code to try and fix what ultimately appears to be a cosmetic issue. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-04-20/f44-blocker-review.2026-04-20-16.00.log.txt
(In reply to Michael Chang from comment #31) > Hi. > > I have opened a MR to remove the env_block in grubenv file if the filesystem > do not support external environment block, in case the grubenv is copied > from unknown source rather than a locally generated one. It should fix the > issue here since the installer calls grub2-editenv to set variables and that > triggers the cleanup. > > https://gitlab.freedesktop.org/gnu-grub/grub/-/merge_requests/106 With you MR included, error msgs are still seen "error: ../../grub-core/commands/loadenv.h:read_envblk_file:51:invalid environment block." "error: ../../grub-core/commands/loadenv.h:read_envblk_file:51:invalid environment block." Looks to me that we just have to lower the error to standard debug msg, but my worry is that we may hide possible unsupported grubenv, like in this case. This is just cosmetic at the end.
Thanks for your patch, Michael, but I still want Neal or other kiwi folks to take a look at this. I opened https://github.com/OSInside/kiwi/issues/2986 and hope to get some feedback.
(In reply to Leo Sandoval from comment #34) > (In reply to Michael Chang from comment #31) > > Hi. > > > > I have opened a MR to remove the env_block in grubenv file if the filesystem > > do not support external environment block, in case the grubenv is copied > > from unknown source rather than a locally generated one. It should fix the > > issue here since the installer calls grub2-editenv to set variables and that > > triggers the cleanup. > > > > https://gitlab.freedesktop.org/gnu-grub/grub/-/merge_requests/106 > > With you MR included, error msgs are still seen > > "error: ../../grub-core/commands/loadenv.h:read_envblk_file:51:invalid > environment block." > "error: ../../grub-core/commands/loadenv.h:read_envblk_file:51:invalid > environment block." > > Looks to me that we just have to lower the error to standard debug msg, but > my worry is that we may hide possible unsupported grubenv, like in this > case. This is just cosmetic at the end. I revisited the patch done by Michael and indeed it removes the env_block variable from the grubenv file. As mentioned by Marta/Michael, the problem is that the ISO already comes with a grubenv with env_block var and GRUB is doing what is supposed to do, detecting that the env block is invalid and printing the error. No need for a MR in GRUB for the moment, although Michael's patch would be nice to have it on rawhide to prevent future 'incorrect env_block' grubenv files.
*** Bug 2464264 has been marked as a duplicate of this bug. ***
(In reply to Marta Lewandowska from comment #35) > Thanks for your patch, Michael, but I still want Neal or other kiwi folks to > take a look at this. I opened https://github.com/OSInside/kiwi/issues/2986 > and hope to get some feedback. If I understand correctly, this is about kiwi calling grub2-editenv. In my testing, if the grubenv file is stored on a btrfs file system when grub2-editenv is called, then the env_block entry will be created. That could very well be the case when creating the Live image before transferring the files to an iso image. Anaconda does at install time create the menu_auto_hide=1 and boot_success=1 variables, so kiwi should not need to do so as well. See pyanaconda/modules/storage/bootloader/grub2.py at line 348.
(In reply to Villy Kruse from comment #38) > If I understand correctly, this is about kiwi calling grub2-editenv. > > In my testing, if the grubenv file is stored on a btrfs file system when > grub2-editenv is called, then the env_block entry will be created. That > could very > well be the case when creating the Live image before transferring > the files to an iso image. I saw that when this Bug has been made, it has been mentioned the Workstation Iso only. Till now, I can not confirm to read something similar with KDE or other spins. In the changelogs, I saw that the cloud image with F44 is being shipped with a btrfs boot partitions for the first time. I suspect that these entries may have been introduced into the workstation image through automation projects like Konflux (which are also cloud projects). Could this have an impact? I also had the idea to call Neal to ask him about this connection ... our toughs we made in the ask section, while I move it to the Discussion section to the workstation and kde wg/sig on which he Neal is part of. The link: https://discussion.fedoraproject.org/t/grub-error-with-new-fedora-44-install-grub-error/189848
two PR created, based on mchang work https://src.fedoraproject.org/rpms/grub2/pull-request/222 https://src.fedoraproject.org/rpms/grub2/pull-request/221 this may reduce future issues when the tool is used on unsupported filesystems and tries to include the env_block var.
(In reply to Leo Sandoval from comment #41) > two PR created, based on mchang work > > https://src.fedoraproject.org/rpms/grub2/pull-request/222 > https://src.fedoraproject.org/rpms/grub2/pull-request/221 > > this may reduce future issues when the tool is used on unsupported > filesystems and tries to include the env_block var. To me it would make more sense to exclude the grubenv file from the iso image and make it the responsibility of anaconda to create it with the right contents. Or anaconda could remove grubenv if it happens to be copied over from the iso image and then create it with the wanted contents. With the current version of grub, the grubenv should really be created only on the target system, as the file system type will affect how the file is created. Previous that was not the case, so back then it didn't matter.
(In reply to Villy Kruse from comment #42) > (In reply to Leo Sandoval from comment #41) > > two PR created, based on mchang work > > > > https://src.fedoraproject.org/rpms/grub2/pull-request/222 > > https://src.fedoraproject.org/rpms/grub2/pull-request/221 > > > > this may reduce future issues when the tool is used on unsupported > > filesystems and tries to include the env_block var. > > To me it would make more sense to exclude the grubenv file from the iso image > and make it the responsibility of anaconda to create it with the right > contents. Or anaconda could remove grubenv if it happens to be copied over > from the iso image and then create it with the wanted contents. > > With the current version of grub, the grubenv should really be created only > on the target system, as the file system type will affect how the file is > created. Previous that was not the case, so back then it didn't matter. Agree. The PR will not get rid of the issue but it would be at least more defensive when trying to add this fs-conditional variable.
I tested this change diff --git a/pyanaconda/modules/storage/bootloader/grub2.py b/pyanaconda/modules/storage/bootloader/grub2.py index e50d6be825..65d4f99394 100644 --- a/pyanaconda/modules/storage/bootloader/grub2.py +++ b/pyanaconda/modules/storage/bootloader/grub2.py @@ -341,6 +341,14 @@ class GRUB2(BootLoader): if rc: log.error("failed to set default menu entry to %s", get_product_name()) + # create the grubenv block. + rc = util.execWithRedirect( + "grub2-editenv", + ["-", "create"], + root=conf.target.system_root + ) + if rc: + log.error("failed to set menu_auto_hide=1") # set menu_auto_hide grubenv variable if we should enable menu_auto_hide # set boot_success so that the menu is hidden on the boot after install if conf.bootloader.menu_auto_hide: What I did is boot the Workstatin iso image and skipped going directly to the installer. Then I edited the file /usr/lib64/python3.14/site-packages/pyanaconda/modules/storage/bootloader/grub2.py and inserted the lines as shown above. Then I started the normal install procedure. The result is a grubenv file without the env_block line