Description of problem: There are use cases where is not wished to update the file /boot/grub2/grubenv with the boot successful information. Specifically, when the "boot_counter" and "menu_auto_hide" variable are not set there should be no reasons for updating /boot/grub2/grubenv. There could be situations where /boot resides on fragile storage, like SD cards, and the user might want to minimize writes. Version-Release number of selected component (if applicable): 2.06-2 How reproducible: Always Steps to Reproduce: 1. Remove the variables above mentioned 2. Logout / login 3. Check /boot/grub2/grubenv after few minutes Actual results: The file /boot/grub2/grubenv is changed Expected results: The grub2-set-bootflag associated timer should not be activated when the above mentioned variables are not defined. Additional info:
Javier, if you want I can make some time (in a couple of weeks) to write a fix for this.
*** Bug 1975888 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. 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 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Still pending, any fix on the horizon? Thanks. pg
Hi, just seen this bug report. As use case, it would be great to have the option to have an unchanging grubenv block and remove the boot variables when using a TPM token (to unlock root) & PCR slots. For now I've mostly been trying in a virtual machine and removed the executable permission of scripts 10_reset_boot_success 12_menu_auto_hide so that boot_success & boot_indeterminate would not change. I have grub showing a menu for 2s on default at every boot so don't need these variables. Without the default set-up, after an upgrade such as kernel, I have to reboot 3 times and wait for boot_success to be changed to 1 before being able to re-enroll a TPM token with PCRs 8, and 9. PCR 8 will change every time the grub variables change and PCR 9 will change each time the grubenv file changes. I posted on reddit about this, in a TPM discussion, with more details if helpful. Removing the above snippets from grub.cfg decreases the number of reboot to one before I'm able to enroll a new TPM token but I've just realised today that boot_indeterminate still changes from time to time. Hope that makes sense, Thomas
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. 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 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This seems to be still relevant. Thanks, bye, pg
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. 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 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Please consider re-opening this issue. It makes TPM unlocking unreliable on Fedora. It is not acceptable.
As a workaround, replace grub with systemd-boot. If you use secureboot however, you have to wait until there is a signed systemd-boot binary for Fedora. See this thread: https://pagure.io/releng/issue/10765