New Shim Update Causing Boot Error

[denverjim]

Running LM 20 on a early 2015 MBP. Been using LM 20 since released with no issues. I only have LM 20 on my MBP. On Sep 26, Update Manager install two packages: shim & shim-signed. When booting my MBP, I now get the following message:

Failed to set MokListRT: Invalid Parameter
Could not create MokListRT: Invalid Parameter
Importing MOK states has failed: import_mok_state() failed
: Invalid Parameter
Continuing boot since secure mode is disabled_

MBP does boot and all seems normal. Did some research on Internet and found the following: https://askubuntu.com/questions/1277828 ... him-update

Looking for answers on what I should do about this error. Would using Timeshift to restore backup that was done before two shim packages were installed remove the boot error? Many thanks.

[denverjim]

No response from anyone? Seems like this is a valid LM 20 bug as it is effecting many people that have repurposed older Apple PCs with linux. Not sure how to report to development team, but will figure that out.

[SMG]

I have a legacy boot install (not EFI) so I did not receive these packages. However, it is my understanding reverting to an earlier Timeshift snapshot should remove the packages you installed. If you were able to boot at that time then I would think you would be able to boot after reverting your system to that. However, I also do not have an Apple computer and do not know if there might be something special about their boot sequences which might be a factor.

In the link you referenced How do I fix broken boot after shim update?, are you not able to do the "most promising reference" Comment 3 for bug 1867092?
"Just remove shim/shim-signed/mokutil, and make sure you also deleted /boot/efi/EFI/*/shimx64.efi, then this problem goes away. It's not related to linux kernel."

Here is the original bug thread Failed to set MokListRT: Invalid Parameter which indicates the original bug was in early 2020. Maybe something in the discussion will give you ideas. Comment 14 does give an alternate approach to getting into the system since "the most promising reference" didn't work for that person. Comment 18 lists what I think is a different workaround.

I did a search on the first term (Failed to set MokListRT) and found this CentOS 7: Failed to set MokListRT: Invalid Parameter which seems to indicate a similar approach to addressing the issue as "the most promising reference" even though it is with a different OS. (And seems similar to what was in Comment 18 of the bug thread.)

[fabien85]

Hi,
the error is inconsequential.
These macs do not have secure boot. shim-signed is a package made to comply with secure boot.
The "MokList" is the list of Machine Owner Keys (MOKs), a mechanism put in place by shim in order to allow the user to sign/certify their bootloaders to comply with secure boot.
So shim fails to import this list, then it realises that there is no secure boot, so it just continues to boot (i.e. launch grub) normally :
"Continuing boot since secure mode is disabled"

Admittedly this is a conception bug in shim, it should look whether secure boot is present before trying to import the MokList.
But in the end, it does not matter, you just boot normally and there is no consequence whatsoever to the system after it has been booted.

I suggest to just ignore the error and wait for an update that will remove it. If there are bug reports, this will happen one day.

The alternative is to purge the bootloader packages and reinstall the unsigned (=no secure boot) versions. But if you do it wrong you get the risk of making your system not boot anymore.

[pbear]

The alternative is to purge the bootloader packages and reinstall the unsigned (=no secure boot) versions. But if you do it wrong you get the risk of making your system not boot anymore.

I'm puzzled. Why can't the OP simply delete the shim packages and the shim boot loader?

denverjim, don't be misled by the post counts. fabien85 knows more about boot loaders than I do.

[fabien85]

I'm puzzled. Why can't the OP simply delete the shim packages and the shim boot loader?

I may be wrong, this is to be tested, but if you delete shim then grub will still be there and can serve as direct bootloader but it will not have been registered in the NVRAM as a boot entry.
In other words, all necessary files will be there, but the firmware will not know what to do with them.
The symptom is that the computer will not boot. Depending on the manufacturer and model, it should either stop at a black screen with a blinking white underscore, or a message like "No valid boot entry", or it will go to the firmware interface (/BIOS).

I might be wrong. I will test your suggestion later and come back.

[pbear]

... if you delete shim then grub will still be there and can serve as direct bootloader but it will not have been registered in the NVRAM as a boot entry.
In other words, all necessary files will be there, but the firmware will not know what to do with them.

Good point. I was thinking of the backup boot loader, but same problem. Fixable, of course, but no longer simple.

[pbear]

Out of curiosity, I decided to run a couple of tests in VirtualBox. Installed Cinnamon 20 in EFI mode. Updated (curiously, no shim or shim-signed update). Took a snapshot, so would have a baseline.

First tried my secure boot lobotomy strategy. Purged shim and shim-signed, then deleted the ubuntu subfolder in the EFI partition. As fabien85 predicted, the firmware was unable to figure out what to do and went into a loop. Presumably this could be fixed with efibootmgr run from a live session, but that would be complicated to explain and I didn't bother to test.

Next restored snapshot and tried purge-and-reinstall of Grub. Easy enough. First ran apt purge grub-common, confirming removal of Grub files. Then ran apt install grub-efi-amd64 os-prober. Wheels go around. Reboot. Uses grub64.efi (not shim64.efi) and that's what's listed when I run efibootmgr -v. shim64.efi still in the EFI partition, just not used.

Not sure what to recommend, denverjim. As fabien85 says, the error you're seeing is merely a squawk, not preventing boot. OTOH, if it bugs you, purge-and-reinstall should work. Are you prepared to reinstall if it doesn't? In any event, don't try the other strategy.

[fabien85]

Thanks pbear.
So the commands to fix the problem would be

Code: Select all

apt purge shim*
apt install --reinstall grub-efi-amd64

were the second command would correctly re-create a boot entry in the NVRAM.

We did not get any news from the OP though, I'm not sure whether they still follow the thread.

[Moonstone Man]

We did not get any news from the OP though...

That would probably be because the OP's post hasn't been quoted so he or she hasn't received an alert. Alerts seem to only be issued when they are quoted or when they are subscribed.

[pbear]

So the commands to fix the problem would be

Code: Select all

apt purge shim*
apt install --reinstall grub-efi-amd64

were the second command would correctly re-create a boot entry in the NVRAM.

Well, no, that's not how I did it. OTOH, testing, I see your way also works. Except they've done something weird with apt (or maybe it's apt-get). Have run into this before and not yet tracked down why. Ubuntu 20.04 and Mint 20 no longer accept the asterisk. So, has to be apt purge shim, which will take out shim-signed, but only because it's a dependency.

Alerts seem to only be issued when they are quoted or when they are subscribed.

Perhaps more to the point, the OP only sees an alert if he visits the forum (email notification is not default). But, hey, notifications are cheap.

Looking for answers on what I should do about this error.

Paging denverjim.

[denverjim]

Hi All. Sorry but away on hunting/fishing trip and away from my MBP. First time I've been online since past weekend Will try suggestions once I'm back home. Thanks so much for all the wonderful replies and advice. You guys are tremendous!!

[fabien85]

Except they've done something weird with apt (or maybe it's apt-get). Have run into this before and not yet tracked down why. Ubuntu 20.04 and Mint 20 no longer accept the asterisk. So, has to be apt purge shim, which will take out shim-signed, but only because it's a dependency.

Oh, I had not noticed that yet. Another change to break everybody's habit, damn.
That ref : https://askubuntu.com/questions/1233459 ... s-not-work tells it's a change in apt not accepting regexp anymore. So in our case, alternatives are :

Code: Select all

sudo apt-get purge 'shim*'

(regexp still works with apt-get if put between quotes) and

Code: Select all

apt purge '^shim*'

(found on the net, ^ apparently means : everything that begins with ...)

[pbear]

FYI, denverjim, a good GUI tool for this is Synaptic Package Manager. Open from Menu. Do a search for shim (Edit > Search). Scroll down to the shim and shim-signed packages. Right-click and select Complete Removal (= purge). In this case, selecting either with automatically select the other, because they're co-dependent, but in other cases you simply keep selecting and marking till you've gotten 'em all. Click Apply.

[feffer]

Considering starting a new thread, but I have exactly the same issue as the OP. MacBook is a multi-boot grub-efi install of Mint, LMDE & Ubuntu. Ran fine for months and as suggested, I ignored the brief MokListRT notice during boot, but after a recent update, it booted to a black screen. Evidently grub was running but hidden as I could arrow down, hit enter and get a distro to boot. Tried the fix from AskUbuntu: You have to replace shimx64.efi with grubx64.efi as follows:

Code: Select all

sudo su -
cd /boot/efi/EFI/ubuntu
cp grubx64.efi shimx64.efi
reboot

This broke grub and I had to re-install it from a live USB. The machine works fine now, but If the problem recurs, should I try to use the solution from this thread instead?

[feffer]

Thanks pbear.
So the commands to fix the problem would be

Code: Select all

apt purge shim*
apt install --reinstall grub-efi-amd64

were the second command would correctly re-create a boot entry in the NVRAM.

We did not get any news from the OP though, I'm not sure whether they still follow the thread.

I also have an old eMac with linux installed. It has been off for a while. Before updating, I tried fabien85's commands with one exception: my version of grub was "grub-efi-amd64-signed" Seems to have worked fine and rebooted w/o problem. Thx!

[fabien85]

Evidently grub was running but hidden as I could arrow down, hit enter and get a distro to boot.

This seems to me a different problem. Looks more like grub loses its video configuration.
Reinstalling never hurts and seems to have fixed it, but if the problem comes back I suggest making a new thread.