With grub 2.06.r456.g65bc45963-2 I reverted a change to also support installs with in-proper grub updates. Here the background:
A normal user will install grub only once. This happens when our installer Calamares does it for you. If you update the grub package via pamac or pacman you won’t update grub itself in your master boot record (MBR) or UEFI. This means you may still run an outdated grub on your system to boot your OS. Some grub updates however have security fixes which need to call grub-install. However, that most of you have different installs and there is now standard way like Asahi-LInux may do on their end calling grub-install is more riskier to break your bootability than not installing grub in your MBR.
Wait a minute, if I update grub I actually don’t? Yep, that is the case here. But why is it now a potential issue if the grub package gets updated? Well with a certain commit late 2022 the application fwsetup got a flag added to test for a function your UEFI firmware may or may not have. Those who have the support were fine, others not. Also the initial support called that application on legacy BIOS systems. That was fixed by upstream.
For me it is better to not call fwsetup at all and have a potential grub menu entry to enter the UEFI firmware from the grub menu, which potentially may fail in rare cases, than causing infinite bootloops into the UEFI firmware and not being able to boot Linux or any OS at all …
@philm After reading the bug reports and discussions, I have tried installing it on my EFI machine, and it doesn’t have this problem where choosing UEFI settings via the grub selector causes a bootloop. Thank you for applying the fix, and I completely agree about not calling fwsetup.
If one follows the protocol of not changing any settings other than in /etc/default/grub, even calling grub-install and grub-mkconfig via pamac should be fine, should you one day decide to push it, but in rare cases where people use custom.cfg for grub menus and specific fw paths for multiboot, it might create conflicts with os_prober (it didn’t in my case).
So if I am understanding this right, security has been sacrificed for the sake of stability? If someone has been using Manjaro for years without knowing this, they could be open to tons of CVEs that they believe had been patched on their system.
not really :
version Grub r322 was a grub-dev , with a change on script grub result ,
if you apply Grub-install , you have to update-grub in one time , and be prepared to restore grub with live USB iso manjaro in this case.
FYI, there is a minor issue with systemd 253.2-1 that will need to be dealt with manually for now if it affects you until Arch decides to change the default hooks in mkinitcpio:
Perhaps Calamares could store the exact grub-install command used during installation into a config file on the installed system. That command could be run as a post-install hook any time the “grub” package receives an update.
if you had libva issues with chromium derived browsers with video acceleration on old intel iGPUs (AFAIK pre-haswell) on X11 you might need some intervention.
@philm could it be possible that for grub updates we get a thread similar to those eos does? Just an idea for gathering in the same place the most common solutions for any grub-related problem, if they ever happen again, as they happen.
i agree, usually i think everyone(who has experience installing bootloader) has their own set of parameters they supply to their respective setups and a generic command would not work. however as someone suggested, probing how calamares does it (most of the time) successfully is worth a shot. till then this should remain forwarding people to the wiki with all the options for the respective setups.
Upgrading libvirt from 9.1.0 to 9.2.0breaks the compatibility of virt-manager, whichloses the ability to create a new internal snapshots of KVM.
See the error message of virt-manager when creating a new internal snapshot of KVM:
Error creating snapshot: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/details/snapshots.py", line 237, in _do_create_snapshot
self.vm.create_snapshot(xml)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1197, in create_snapshot
self._backend.snapshotCreateXML(xml, flags)
File "/usr/lib/python3.10/site-packages/libvirt.py", line 3119, in snapshotCreateXML
raise libvirtError('virDomainSnapshotCreateXML() failed')
libvirt.libvirtError: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported
Solution:
Downgrade to libvirt9.1.0 and then reboot to fix the issue.
Edit:
Creating internal snapshot hat the limit with UEFI, but it has no issue with legacy BIOS.
