New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shim/fallback 14 may fail to boot in some machines #128
Comments
lcp
added a commit
to lcp/shim
that referenced
this issue
May 24, 2018
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
lcp
added a commit
to lcp/shim
that referenced
this issue
May 24, 2018
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
that referenced
this issue
Jan 31, 2019
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. #128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 2, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 3, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 3, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 3, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 3, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 4, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 7, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 7, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 7, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 10, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 11, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 11, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 11, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 11, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 11, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 11, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 11, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 12, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 12, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 12, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 12, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Dec 12, 2020
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Feb 15, 2021
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com> This is a backport from devel of: commit da62845 Author: Gary Lin <glin@suse.com> Date: Wed May 23 18:13:05 2018 +0800 fallback: show a countdown menu before reset Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com> Signed-off-by: Peter Jones <pjones@redhat.com>
vathpela
pushed a commit
to vathpela/mallory
that referenced
this issue
Feb 15, 2021
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com> This is a backport from devel of: commit da62845 Author: Gary Lin <glin@suse.com> Date: Wed May 23 18:13:05 2018 +0800 fallback: show a countdown menu before reset Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. rhboot#128 Signed-off-by: Gary Lin <glin@suse.com> Signed-off-by: Peter Jones <pjones@redhat.com>
martinezjavier
pushed a commit
that referenced
this issue
Feb 16, 2021
Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. #128 Signed-off-by: Gary Lin <glin@suse.com> This is a backport from devel of: commit da62845 Author: Gary Lin <glin@suse.com> Date: Wed May 23 18:13:05 2018 +0800 fallback: show a countdown menu before reset Some machines with the faulty firmware may keep booting the default boot path instead of the boot option we create. To avoid the infinite reset loop, this commit introduce a countdown screen before fallback resets the system, so the user can interrupt the system reset and choose to boot the restored boot option. The "Always continue boot" option creates a BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot option afterward without asking. The user can revert the behavior by removing the variable. #128 Signed-off-by: Gary Lin <glin@suse.com> Signed-off-by: Peter Jones <pjones@redhat.com>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 14, 2021
Some Acer firmwares always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always behave as if a TPM is not present. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 14, 2021
Some Acer firmwares always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 17, 2021
Some Acer firmwares always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit implements a reboot counter and once a maximum amount of reboots (default 5, but change be changed via a build flag) is reached, it instead tries to chain-load the boot entry instead. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 17, 2021
Some Acer firmwares always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit implements a reboot counter and once a maximum amount of reboots (default 5, but change be changed via a build flag) is reached, it instead tries to chain-load the boot entry instead. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 17, 2021
Some Acer firmwares always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 20, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 20, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 20, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit implements a reboot counter and once a maximum amount of reboots (defaults to 5, but change be changed via a build flag) is reached, it tries to chain-load the boot entry instead. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 20, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 20, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 20, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit implements a reboot counter that is incremented every time the system boots throught fallback and reset when shim loads the second stage bootloader directly. Once a maximum amount of attempts to boot through fallback has been reached (default 5, configurable via build flag), fallback tries chain-loading the new boot entry instead of restarting the system. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit implements a reboot counter that is incremented every time the system boots throught fallback and reset when shim loads the second stage bootloader directly. Once a maximum amount of attempts to boot through fallback has been reached (default 5, configurable via build flag), fallback tries chain-loading the new boot entry instead of restarting the system. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always reset the boot entries and BootOrder variable to what was defined in the firmware setup program, completely overriding any changes made by fallback -- the machine will always boot BOOTX64.EFI. Before shim cared about TPMs this was not a problem, as fallback would always create and chain-load a boot entry for the OS. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, causing an infinite reboot loop. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chainload the newly created entry instead of restarting the system, to break out of the reboot loop. While this solution works, it is not user-friendly: it relies on the user taking the correct action after facing a technical / potentialy scary message. It is also sad that after a lot of work on several pieces of the graphics and boot stacks (shim, fallback, grub, Plymouth, kernel, login managers etc) to provide a clean and smooth boot experience, we are losing it when fallback is in the boot path to workaround broken firmware. This commit implements a reboot counter that is incremented every time the system boots throught fallback and reset when shim loads the second stage bootloader directly. Once a maximum amount of attempts to boot through fallback has been reached (default 3, configurable via build flag), fallback tries chain-loading the new boot entry instead of restarting the system. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit tries to automatically detect and break out of the reboot loop without requiring any user interaction. To achieve this, a boot counter is stored in an EFI variable and incremented every time fallback is about to reboot the system. If the counter ever reaches a maximum value configurable at build time (currently default to 3), another EFI variable is set to tell fallback to always chain-load the new entry (FB_NO_REBOOT, to make is backwards compatible with the previous solution). The counter is then reset when shim is started and knowns it is not going to load fallback. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit tries to automatically detect and break out of the reboot loop without requiring any user interaction. To achieve this, a boot counter is stored in an EFI variable and incremented every time fallback is about to reboot the system. If the counter ever reaches a maximum value configurable at build time (currently default to 3), another EFI variable is set to tell fallback to always chain-load the new entry (FB_NO_REBOOT, to make is backwards compatible with the previous solution). The counter is then reset when shim is started and knowns it is not going to load fallback. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit tries to automatically detect and break out of the reboot loop without requiring any user interaction. To achieve this, a boot counter is stored in an EFI variable and incremented every time fallback is about to reboot the system. If the counter ever reaches a maximum value configurable at build time (currently default to 3), another EFI variable is set to tell fallback to always chain-load the new entry (FB_NO_REBOOT, to make is backwards compatible with the previous solution). The counter is then reset when shim is started and knowns it is not going to load fallback. Fixes: rhboot#418 Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit tries to automatically detect and break out of the reboot loop without requiring any user interaction. To achieve this, a boot counter is stored in an EFI variable and incremented every time fallback is about to reboot the system. If the counter ever reaches a maximum value configurable at build time (currently default to 3), another EFI variable is set to tell fallback to always chain-load the new entry (FB_NO_REBOOT, to make is backwards compatible with the previous solution). The counter is then reset when shim is started and knowns it is not going to load fallback. Fixes: rhboot#418 Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit tries to automatically detect and break out of the reboot loop without requiring any user interaction. To achieve this, a boot counter is stored in an EFI variable and incremented every time fallback is about to reboot the system. If the counter ever reaches a maximum value configurable at build time (currently default to 3), another EFI variable is set to tell fallback to always chain-load the new entry (FB_NO_REBOOT, to make is backwards compatible with the previous solution). The counter is then reset when shim is started and knows it is not going to load fallback. Fixes: rhboot#418 Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry, in the same way it did before TPM support was added. Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Sep 21, 2021
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry, in the same way it did before TPM support was added. https://phabricator.endlessm.com/T32528 Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
Think this was supposed to have been fixed in #272 . |
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Feb 1, 2022
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry, in the same way it did before TPM support was added. https://phabricator.endlessm.com/T32528 Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
jprvita
added a commit
to endlessm/shim
that referenced
this issue
Feb 1, 2022
The firmware on some Acer machines (and maybe others) always resets the boot entries and BootOrder variable to what was defined in the firmware setup program, overriding any external changes (including the changes made by fallback). Before shim cared about TPMs this was not a problem in practice, as fallback would create and chain-load a boot entry for the OS on every boot. However, since commit 431b8a2 the system is restarted if a TPM is detected on the system, triggering an infinite reboot loop in systems with such firmware. This is a known problem which has been previously reported on rhboot#128 More recently, the problem has been addressed by commit a5db51a, which presents a screen with a countdown to the user, where they can interrupt boot and choose to have fallback always chain-load the new entry instead of restarting the system, to break out of the reboot loop. While this solution works, it has a few shortcomings: 1. It makes an otherwise glitch-free boot process not smooth anymore. 2. The message presented is not accessible / potentially scary for non-technical users: if they press a key to interrupt the boot process, the meaning of each option is not really clear for users not familiar with how shim and fallback work. 3. The whole experience is made a bit worse by the fact that after selecting "Continue boot" / "Always continue boot", the screen will remain frozen until something else draw on the framebuffer. If GRUB is configured to be quiet, for a glitch-free boot, this may last several seconds until the kernel has started and loaded the manufacturer logo from BGRT, which gives the impression that the whole boot process froze. 4. This Boot Option Restoration screen overwrites all the debug information printed before it is displayed, essentially neutering FALLBACK_VERBOSE or SHIM_VERBOSE and making it impossible to enable debug without rebuilding fallback. This commit adds a build-time flag that forces fallback to always try to chain-load the newly created boot entry, in the same way it did before TPM support was added. Fixes: rhboot#418 Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We recently got a bug report(*) that shim/fallback was stuck in an infinite reset loop. It's because that the firmware seems to ignore the restored boot option and also provides TPM protocol.
One possible solution is to add a count down menu before resetting the system so that the user has the chance to stop system reset and choose to load the boot option directly. We could also set a NV variable to notify fallback.efi not to reset afterward.
(*) https://bugzilla.opensuse.org/show_bug.cgi?id=1092000
The text was updated successfully, but these errors were encountered: