Firstly, hello. I am new here but a long time lurker in the forum. I’ve recently been fed up with Windows enough to move to Linux full time. Mostly it’s been fine, a few issues here and there but part of the goal of this transisiton was to learn as well as be more on control.
I recently ran my usual apt update; apt upgrade during login and I was hit with something I’ve not seen before and I am a tad concerned since it’s claiming that the system might not boot correctly. I captured some of the output of the command just in case and I can tell you the following basics (and I will provide any information you all need) but any nudges or points in the right direction would be helpful. I am not afraid of doing work or reading but I am a tad lost on where to go at first.
I am running:
Linux Mint 20, Kernel 5.4.0-54-generic
And I have secure boot disabled on my motherboard.
Below is a snippet of the information I captured.
–
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/50_linuxmint.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-54-generic
Found initrd image: /boot/initrd.img-5.4.0-54-generic
Found linux image: /boot/vmlinuz-5.4.0-53-generic
Found initrd image: /boot/initrd.img-5.4.0-53-generic
Found linux image: /boot/vmlinuz-5.0.0-32-generic
Found initrd image: /boot/initrd.img-5.0.0-32-generic
Adding boot menu entry for UEFI Firmware Settings
done
Setting up grub-efi-amd64-signed (1.142.9+2.04-1ubuntu26.7) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
grub-install: warning: Internal error.
grub-install: error: failed to register the EFI boot entry: Operation not permitted.
Processing triggers for shim-signed (1.40.4+15+1552672080.a4a1fbe-0ubuntu2) ...
Secure Boot not enabled on this system.```
–
Any and all information would be welcome on how to resolve this issue and indeed if it even **is** an issue in the first place. I have timeshift backups, a live disk ready to go if the worst should happen as well as Crashplan backups but was hoping to not spend this week off rebuilding my core workstation.
Thanks!
for future reference you can paste entire logs and just use three backticks before and after. This will make the post cleaner but also give us a scroll inside your post. That allows us to view the entire log without making your post 2 miles long in the browser window.
If you look at these lines, its at least going to be able to boot 5.4.0-54-generic. I’m guessing there was a kernel update in there somewhere otherwise it wouldnt be trying to update grub entries, but theres not enough of the log to know what that is.
It might be an issue, I cant tell. Theres not enough log here. I dont think its going to stop you from booting though. You still have 3 kernels in your grub entries to choose from at boot.
So would you suggest not using autoremove on apt in order to remove the older Kernels as I upgrade? I am still learning this as I go mind you, so any advise is welcome.
autoremove only removes packages not in use anymore. Its mainly for getting rid of dependencies of applications you no longer have installed or if a dependency changes.
Theres really no harm in keeping older kernels as they dont take up that much disk space. Generally you dont need to worry about removing old kernels as mint is getting them from Ubuntu LTS repos. Thats a pretty slow and steady repo and theres not usually any harm in ditching the old kernel. You could test the new kernel before removing the old of course.
I am away from my PC at the moment but that issue happens on some motherboards and requires clearing out the efi logs on your motherboard…
Basically the issue is that you motherboard has the debug symbols on and it is writing all the debug info to the board and eventually runs out of space. You will be able to use your system but the errors are annoying and once you actually add another boot drive or change boot orders, then things will fail and you will need to fall back to an older kernel or manually booting to the desired disk and kernel (read Grub will not work as intended.)
I would not have thought of that. Is there a method of clearing the EFI logs from the BIOS? Or can I do this via command line? I am running an ASRock x570 Taichi motherboard for what it’s worth.
I am on an ASUS Sabertooth v2.0 990FX on AMD AM3+. You can do it from the command line. I don’t remember the steps right off hand but I basically have to do this once a year. Wen I get home, I will look at my notes and update the thread.
Well update, you all were correct and it rebooted just fine. I wanted to let this thread know because I hate forum threads where the OP vanishes after posting a problem; presumingly getting it fixed; and not telling everyone how.
Mastic_Warrior, did you happen to find that command to clear out the EFI logs?
I could not find the exact resources that I used in the past but my notes sat this,
Check for existence of /sys/firmware/efi/efivars/dump-* files. If they exist delete them (ie. pstore dumps stored in efivars) and reboot.
If you see nothing there or the directory does not exist try mount -t efivarfs efivarfs /sys/firmware/efi/efivars
If the above does not work, you may need to remount your ESP/vfat boot partition as read/write (rw) if you fstab mounts it as read only (ro).
Once you mount it, try to use EFI var to see if it will list your boot entries, efivars -l. If it does not, then your Boot partition is note being linked to the EFI variables in the ESP partition. Look at the Archwiki for more explanation on that, https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_variables
Once you remove those dump files (which really serve you no purpose), after the reboot, you should be able to do a dpkg-reconfigure grub-efi-amd64 to ensure that grub adds an entry for the new kernel(s)
Like I said, I have to go through this once a year but I run Debian Unstable and ArchLinux on the same box so I go through many more EFI variable updates than you do. also, the above needs to be done as root or with sudo escalation. If you are stumped let me know. Depending on the errors, there may be something else going on.
**Edit
Forgot to mentioned that just like CentOS, Linux Mint has a lot of old packages with some known issues/bugs so it is possible that you may also need to manually update some packages if you cannot use the above tools (like if you don’t have efivars or efibootmgr installed, then you will need to pull them from Debian if they do not exist in your stock repos.)
Path but there is no dump files of any kind inside this path. Further more, after the reboot I was able to finish up the update to grub with no issues. I can only suspect whatever it was causing that EFI boot entry issue it’s resolved. I wish I could understand what it might have been but I am thankfully it didn’t cause any issues beyond the initial scary warnings.
Thank you very much for your help regardless. I am going to study that arch wiki and learn a little more about these variables.
I rely on the ArchWiki and the GentooWiki. They are the most up to date, and Gentoo goes into more detail, which is handy when it seems that you may have a one off issue.
Was there anything in that efivars folder for you? If you see nothing in there, then that means that it may have not been mounted. You should see stuff there. But if things are working for you that is great. My recommendation would be that if you run into this issue again, make sure to retain the previous kernel for safe booting, or make a rescue image.
There was stuff there indeed, just no dump files at all.
I do keep full crashplan backups of the system for remote backups as well as timeshift on an external drive for live booting if need be. I think that should cover it right?