I have just installed Fedora 44 Workstation from scratch.
I get this error as soon as the PC boots:
error:../../grub-core/commands/loadenv.h:read_envblk_files:51:invalid environment block.
error:../../grub-core/commands/loadenv.h:read_envblk_files:51:invalid environment block.
Then it stops for a little while and proceeds with the normal boot.
Edit: I tried to recreate Grub config but nothing changes.
The environment block is a separate file, usually at /boot/grub2/grubenv - I don’t think recreating the config would recreate the environment file.
Once your PC has booted, try running sudo grub2-editenv - list.
If that also says invalid environment block, then you need to recreate the block.
Check what filesystem /boot is on:
mount|grep boot
You should see something like:
/dev/nvme0n1p3 on /boot type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,....)
Ignore the /boot/efi line, and check the type of the /boot line. If it’s ext4, then you can recreate the environment block by running:
sudo mv /boot/grub2/grubenv /boot/grub2/grubenv.bak
sudo grub2-editenv - create
The next time you reboot you shouldn’t see the error, and sudo grub2-editenv - list should show a saved_entry line.
The manual mentions that the environment block is handled differently if /boot is on btrfs - I’m not sure if the same commands are safe in that instance or whether you need to call grub2-editenv differently to have it rewrite the reserved part of the filesystem.
sudo grub2-editenv - list
env_block=512+1
saved_entry=64fdae006ec44fbc967617580aa58ee3-6.19.14-300.fc44.x86_64
menu_auto_hide=1
boot_success=1
boot_indeterminate=1
mount|grep boot
/dev/sda2 on /boot type ext4 (rw,relatime,seclabel)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
Besides, I did a “clean install” of Fedora 44, no other OS present.
So IMHO there is something wrong in the installing/configuring procedure
Edit: I did the “-create” thing and now I don’t see the error BUT there is always the Grub menu with two seemingly identical options, rescue end uefi setting (which leads to the “bios”).
sudo grub2-editenv - list
boot_success=1
boot_indeterminate=0
OK. So the env_block=512+1 part in the first list means that Grub was going to look at that bit of the drive to store data, which I don’t think it’s supposed to do on ext4. That feels like a bug that should be reported.
You can reset the other variables:
sudo grub2-editenv - set menu_autohide=1 saved_entry=64fdae006ec44fbc967617580aa58ee3-6.19.14-300.fc44.x86_64
And then I think you should be fine from then on.
Looks like this has already been reported, and a fix is being worked on: 2457333 – Grub environment block is corrupted at first boot
I made the proposed changes:
sudo grub2-editenv - list
boot_success=0
boot_indeterminate=0
menu_autohide=1
saved_entry=64fdae006ec44fbc967617580aa58ee3-6.19.14-300.fc44.x86_64
Unfortunately nothing changes since before, I still get the Grub menu and I guess there is something else that is wrong because after it moves on there is a visible pause before the booting sequence recovers (blank screen).
Maybe Grub expects the above lines in some precise order (compare the first list to this one, the order is different).
I read the bug report and the following discussion, as a simple user I find it quite depressing because:
I guess I am back to Fedora 43. Or something else. 
Thanks for the assistance.
I don’t disagree as far as the nature of the bug is concerned, but that’s perhaps a discussion for another thread.
The order of the variables in that file isn’t important, but with boot_success set to 0 it will show the menu every time. That variable should be set to 1 two minutes after you login.
Check systemctl status --user grub-boot-success.service (no sudo for that one, it runs as your normal user account) more than two minutes after you’ve logged in and that variable should have changed. You can also run grub2-set-bootflag boot_success to mark it manually - if that doesn’t work then we have something else going on.
I do wonder if your grub.cfg has some odd values in it where you recreated it with the bad environment block in place?
If you’re willing to give it a try, I would regenerate the config file now that the env_block line is missing from grubenv and see if that helps.
Correct me if I am wrong.
If the only issue here is the line that points to some BTRFS reserved space that should not exist since the partition is EXT4, should be enough to remove that line.
I recreated the Grub config and no changes.
I don’t know about it since like I said it is a clean install with no other changes but the above.
Maybe when I am in a better mood I would try again since the beginning. Maybe.
Thanks again.
This discussion reminded me that for some time I have seen the message about an invalid line in grub when booting my VM with f44 (installed from the release iso).
I went back to my VM and looked at the content of grubenv and found the same as shown above. The first line showed env_block=512+1
To test my theory I simply used the command
sudo grub2-editenv - unset env_block followed by a reboot and the error message is gone.
I agree this appears to be a bug during installation of f44 and should be reported as such, but the command just above is a workaround that removes those error messages.
You are not wrong.
The content of the grubenv file went from this before I removed that line
env_block=512+1
saved_entry=65691051db24416796e541a46c278d5b-6.19.14-300.fc44.x86_64
menu_auto_hide=1
boot_success=1
To this after removing that line and rebooting
saved_entry=65691051db24416796e541a46c278d5b-6.19.14-300.fc44.x86_64
menu_auto_hide=1
boot_success=1
boot_indeterminate=0
I would like to add that I just did a new install of f44 workstation on a bare bones system, using the automatic partitioning, and found the same issue in the grubenv file.
The initial configuration creates that line env_block=512+1 as the first entry in the grubenv file and it triggers the noted 2 errors just as grub is beginning the boot.
Removing that line using grub2-editenv eliminates the errors that flash by on the boot screen.
This worked for me. Thanks @computersavvy.
To give feedback to @lendenu for me the error was cosmetics only. The boot process was not recognizable slower. Beside the error vanished to fast to see exactly what it says, I had to make a video that I could read, if it also shows the error as mentioned here, while pausing it.
I used an external USB SSD disk to do my installation on barebone (just on external disk, while the system recognizes the internal not touched harddrive too ).
For me same result.
Mine occurred when installing on a VM with a newly created vda device.
It also occurred when installing bare bones on a new system with a drive that contained only a blank gpt partition table. In both cases I was using uefi and allowed the system to perform the automatic partitioning during installation.
I would not expect this type error to occur EVER and have filed a bug report on it.
Feel free to add whatever additional information you choose.
Ok thanks for reporting it, hope we find it out what exactly is causing this issue.
I checked on a upgrade to F44 I made this week, there it looks normal and could not see any error.
It appears to be only with a new install and does not seem to appear when the system is upgraded.
I tested with an upgrade to an f43 vm and it does not put that strange variable into the grubenv file.
This appears to be copied over from the live system. To check run these commands
sudo mount -r Fedora-Workstation-Live-44-1.7.x86_64.iso /mnt
sudo mount -r /mnt/LiveOS/squashfs.img /mnt
sudo cat /mnt/boot/grub2/grubenv
sudo umount /mnt
sudo umount /mnt
I checked two iso’s i downloaded from the dev folder on dl.fp.o
Fedora-Workstation-Live-44-20260319.n.0.x86_64.iso #this contains the entry with `env_block=512+1`
Fedora-Workstation-Live-44-20260405.n.0.x86_64.iso #this has no
It seams to be there in the “March” version of the iso.
This means it’s recognized the error and somebody removed it already. If someone likes to check the newest one, we do have the possibility to give someone who complains, the possibility to have a error free experience, to install, with the link to dl.fp.o.
Respins are after releas here to find:
I made an observation in the change log for F44:
Switch Fedora Cloud to /boot as a Btrfs subvolume
Eliminate the separate /boot partition on Fedora Cloud images
- Owner: Neal Gompa, David Duncan
- Last updated: 2025-12-11
- Tracking bug: #2421525
- Status: 100% code completed
Maybe a test with the workstation image could have caused the addition of the BTRFS part?
This would explain then that for the cloud image in F44 this addition would be needed.
This is not a bug, but a feature. Just not for the Workstation Image yet. I hope you give this developers the credit of working hard and also take in consideration that the Gnome desktop is suffering from financial shortage.
While I understand that booting with /boot as btrfs or as ext4 may require a difference in grub configurations, the appropriate change probably should occur when doing the install and not be locked into every installation by copying a file within the image.
Possibly the installer could tell which file system is being used for /boot and select an appropriate grubenv file based on the file system in use. This could be critical since users already have the ability to select which file system is used for /boot if they use the storage editor to customize the installation.
If I am not mistaken, this is for cloud images only and not for the Live images.
Hi,
can confirm all of this.
sudo grub2-editenv - unset env_block
solved the problem for me.
Yet, as we can see from this thread, it’s quite a serious problem as it keeps especially new users from switching to Fedora: First thing they see is a cryptic error message, and they think it’s flawed.