On Fri, Oct 10, 2025 at 9:17 PM Chris Murphy <[email protected]> wrote: > > > > On Fri, Oct 10, 2025, at 9:07 PM, Chris Adams wrote: > > Once upon a time, Chris Murphy <[email protected]> said: > >> On Fri, Oct 10, 2025, at 2:02 PM, Chris Adams wrote: > >> > Yep, I got bit by this once when I did updates and then something (don't > >> > know what) happened that caused the grub2.cfg update (pre BLS) to still > >> > be in the XFS log. The system would just boot to a grub prompt... I was > >> > on a trip and sitting in a hotel room (so no access to another system, a > >> > rescue USB drive, etc.), and basically hadn't had to mess much with boot > >> > loaders in a long time, so didn't really remember any GRUB2 commands. I > >> > eventually puzzled out enough to get the system booted, but it was a bit > >> > of a pain. > >> > >> Unintuitively, booting with rd.break=pre-mount and then merely mounting > >> the xfs boot volume and then rebooting would have fixed it. Log replay > >> would have happened on mount, making the grub.cfg appear in the metadata > >> that GRUB can read. > > > > That requires remembering how to boot from the GRUB2 command-line, what > > the necessary kernel arguments were, etc. Once I got past that, I could > > boot normally, I didn't need to do anything extra. > > Oh right, the menu was empty, grub> prompt. So you'd have to manually type in > linux command with grub device notation path to kernel, and initrd, and then > boot it. Most of this is done with ls command, to see what's on all the > partitions if you don't know which one is boot. But anyway, USB stick to the > rescue. > > My periodic problem is Lenovo firmware likes to occasionally remove efi boot > entries. And the firmware boot manager doesn't won't read the internal drive > system partition to create a boot list. It only shows Fedora as a boot entry > if it's in NVRAM. And it ignores the fallback bootloaders in EFI/BOOT. So no > matter what I need to keep a USB stick on hand. > > I've been told this is spec as intended and thus not a bug. But if that's > true, then it's a UEFI spec design flaw. Only removable drives have the ESP > read and bootable options enumerated? What?
This is likely a firmware bug with certain older Lenovo PCs. I ran into it - or something similar - at my workplace with a set of Lenovo ThinkCentre M820z All-In-One machines. I spent several workdays fruitlessly attempting to upgrade the hardware and image it using a corporate Windows 11 USB. Eventually the customer complained about downtime, so we gave up and suggested replacing the PCs. The firmware wouldn't boot an OS install on the main drive after the first boot, same with Fedora or Windows. On the second power cycle you'd just get a message that no OS was present, or fall back to network boot if that was enabled. Updating the firmware didn't fix it, and the last release was years ago. There were two ways that I could get it to fix itself somewhat: (please excuse my spotty memory on this) - Booting the Fedora Workstation Live image, where efibootmgr would show that the right boot entry existed but was disabled for some reason. You could manually set it as BootNext and reboot once into it, but that only works for a single boot by design. Enabling the disabled entry didn't work; it would become disabled again on reboot, and it wouldn't show up in the firmware's boot selection menu. I don't remember what would happen if you deleted the entry. - Powering off and opening up the system (progressively destroying those little plastic clips) and then either pulling the drive or the CMOS battery and then rebooting would convince the firmware to delete boot entries for the removed drive and evaluate the ESP files on the 'new' drive. I hope I haven't gone too off-topic for `devel` here; I'd be happy to discuss this more in a different thread more germane to hardware/firmware issues. > > > -- > Chris Murphy > -- > _______________________________________________ > devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
