Unfortunately, Boot Repair doesn't handle NVMe disks properly, so a bunch of important information is missing from your BootInfo report; however, it does show a single ubuntu
entry in the NVRAM boot manager list, so it's unlikely that the system is booting through some other path -- EXCEPT that you have a fallback boot loader (EFI/BOOT/bootx64.efi
) that, from the other file in that directory (fbx64.efi
), is probably a tool to recover the boot setup in case of a firmware failure. This tool, and how to configure and use it, is described in my rEFInd documentation (although it's not part of rEFInd; that page just has the most complete and concise description of fbx64.efi
that I know about):
http://www.rodsbooks.com/refind/bootcoup.html#fallback
It's possible that your computer is losing its boot order variable, booting through Shim (as EFI/BOOT/bootx64.efi
) and fbx64.efi
, which then kicks the boot process over to the regular ubuntu
entry (which launches a second Shim and then GRUB), which then hangs; but when the ubuntu
entry launches directly, it works fine. This could happen because of bugs involving two copies of Shim being launched, because fbx64.efi
itself is causing problems, or for some other reason. This hypothesis is very speculative; it's based on very little evidence and quite a few assumptions. It also assumes bugs in your firmware, and likely in Shim, fbx64.efi
, and/or GRUB. It is consistent with the symptoms you're seeing, though, and it's the only explanation that springs to mind. If it's what's happening, you could try, as diagnostic procedures or to fix the problem:
- Rename the
EFI/BOOT
directory on the ESP -- If you rename this directory and the problem persists exactly as it has, then my hypothesis is wrong. (This is because renaming EFI/BOOT
will prevent the computer from attempting to launch the Shim and fbx64.efi
stored in that directory; so if it keeps booting, it must be that the boot order and boot variables are being retained and honored, contrary to my hypothesis.) If, however, the computer begins booting correctly, or booting straight to Windows, then that's evidence that it had been booting in this way, and my hypothesis becomes much more likely. You should be able to rename the directory back to EFI/BOOT
to restore the (failing) boot operation, which will be necessary for the next three repairs....
- Disable Secure Boot -- Disabling Secure Boot will alter the way Shim works, and if my hypothesis is correct, this might get things working -- or it might have no effect. Even if my hypothesis is correct, this change will work only if the failure is caused by Secure Boot, which might not be the case.
- Copy
EFI/ubuntu/grub*
to EFI/BOOT
-- If you copy GRUB (grubx64.efi
) and its configuration file (grub.cfg
) from EFI/ubuntu
to EFI/BOOT
, then Shim in EFI/BOOT
(that is, EFI/BOOT/bootx64.efi
) should launch GRUB directly from EFI/BOOT
, rather than going through fbx64.efi
. This should bypass the problem, if my hypothesis is correct.
- Use rEFInd -- My rEFInd boot manager boots in an entirely different way from GRUB, so chances it won't be affected by the problem. With Secure Boot active, though, you'll need to enroll a key or two in your MOK list, as described in the rEFInd Secure Boot documentation. Also, you may need to delete or rename the
EFI/ubuntu/BOOTX64.CSV
file on your ESP. (Rename it to something with a filename that does not end in .CSV
, or any case-altered variant of that, like .csv
.) The reason is that fbx64.efi
looks for .CSV
files to regenerate the NVRAM-based boot entry, so if that file is present, there's a 50/50 chance it will take precedence over the BOOT.CSV
file that rEFInd creates for itself, thus causing the system to boot to GRUB and continue failing in the way you describe.
- Update your firmware -- If your manufacturer offers a newer firmware (probably called a "BIOS") than what you're using now, you can upgrade it. This is a shot in the dark, though; your problem sounds exotic enough that it's unlikely to have been addressed in a firmware update.
I recommend you try the first of these options as a diagnostic. If the boot behavior changes as I've described, you can then restore EFI/BOOT
to the way it had been and try any of the next three options -- or more than one, if your first attempt fails. If, OTOH, renaming EFI/BOOT
has no effect, then the next two options are unlikely to work (although disabling Secure Boot might help). Installing rEFInd becomes the option that's most likely to work in this case, but that's really a shot in the dark. Updating the firmware might work even if the first diagnostic option doesn't change the behavior, but as I said, that's a desperate option that's unlikely to work no matter what the cause is. Still, it's worth trying if you have no other options (or maybe even if you do -- firmware updates can fix all sorts of problems, add features, and improve performance).
Good luck fixing your problem!
Best Answer
You might try upgrading the firmware in the Logitech unifying dongles. See
https://community.logitech.com/s/question/0D531000055gw8YCAQ/logitech-response-to-unifying-receiver-research-findingsfor instructions and the firmware.You might also check the USB settings in your BIOS. They may need to be set to USB 2.0, or legacy.
Lastly, you might have to plug the dongle directly into your computer's USB port, instead of a hub (if you're using one).
Update #1:
new link is https://community.logitech.com/s/question/0D531000058b3B7CAI/logitech-response-to-research-findings