I just updated to RL 9.6 with DNF on my VPS, but now, when I do as root
dnf update --refresh
I get the following output
Error:
Problem: The operation would result in removing the following protected packages: grub2-efi-x64, grub2-pc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
The reason for that is probably contained somewhere in the output before those lines that you didn’t include here.
Hi, this is the complete output and command,
$ sudo dnf update --refresh
Docker CE Stable - x86_64 118 kB/s | 3.5 kB 00:00
Extra Packages for Enterprise Linux 9 - x86_64 497 kB/s | 41 kB 00:00
Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 14 kB/s | 993 B 00:00
gitlab_gitlab-ce 793 B/s | 862 B 00:01
MariaDB 24 kB/s | 3.4 kB 00:00
Remi's Modular repository for Enterprise Linux 9 - x86_64 26 kB/s | 3.5 kB 00:00
Safe Remi's RPM repository for Enterprise Linux 9 - x86_64 23 kB/s | 3.0 kB 00:00
Rocky Linux 9 - BaseOS 16 kB/s | 4.1 kB 00:00
Rocky Linux 9 - AppStream 15 kB/s | 4.5 kB 00:00
Rocky Linux 9 - CRB 20 kB/s | 4.5 kB 00:00
Rocky Linux 9 - Extras 11 kB/s | 2.9 kB 00:00
runner_gitlab-runner 779 B/s | 862 B 00:01
Error:
Problem: The operation would result in removing the following protected packages: grub2-efi-x64, grub2-pc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Disable the “non-standard” repos you have there and see if the problem goes away.
If so, then re-enable them one at a time and see when the problem comes back.
With all non-standard repos disabled, I get
$ sudo dnf update --refresh
Rocky Linux 9 - BaseOS 16 kB/s | 4.1 kB 00:00
Rocky Linux 9 - AppStream 17 kB/s | 4.5 kB 00:00
Rocky Linux 9 - CRB 18 kB/s | 4.5 kB 00:00
Rocky Linux 9 - Extras 11 kB/s | 2.9 kB 00:00
Error:
Problem: The operation would result in removing the following protected packages: grub2-efi-x64, grub2-pc
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Examine /var/log/dnf.log and see what happened.
This seem to be relevant:
2025-06-07T21:29:11+0200 DDEBUG Command: dnf update --refresh
2025-06-07T21:29:11+0200 DDEBUG Installroot: /
2025-06-07T21:29:11+0200 DDEBUG Releasever: 9
2025-06-07T21:29:11+0200 DEBUG cachedir: /var/cache/dnf
2025-06-07T21:29:11+0200 DDEBUG Base command: update
2025-06-07T21:29:11+0200 DDEBUG Extra commands: ['update', '--refresh']
2025-06-07T21:29:11+0200 DEBUG User-Agent: constructed: 'libdnf (Rocky Linux 9.6; generic; Linux.x86_64)'
2025-06-07T21:29:11+0200 DEBUG repo: downloading from remote: baseos
2025-06-07T21:29:11+0200 DEBUG countme: no event for baseos: window already counted
2025-06-07T21:29:12+0200 DEBUG baseos: using metadata from Mon 02 Jun 2025 07:21:55 AM CEST.
2025-06-07T21:29:12+0200 DEBUG repo: downloading from remote: appstream
2025-06-07T21:29:12+0200 DEBUG countme: no event for appstream: window already counted
2025-06-07T21:29:14+0200 DEBUG appstream: using metadata from Mon 02 Jun 2025 09:27:13 AM CEST.
2025-06-07T21:29:14+0200 DEBUG repo: downloading from remote: crb
2025-06-07T21:29:14+0200 DEBUG countme: no event for crb: window already counted
2025-06-07T21:29:15+0200 DEBUG crb: using metadata from Mon 02 Jun 2025 04:18:19 PM CEST.
2025-06-07T21:29:15+0200 DEBUG repo: downloading from remote: extras
2025-06-07T21:29:15+0200 DEBUG countme: no event for extras: window already counted
2025-06-07T21:29:15+0200 DEBUG extras: using metadata from Wed 28 May 2025 11:43:02 PM CEST.
2025-06-07T21:29:16+0200 DDEBUG timer: sack setup: 4542 ms
2025-06-07T21:29:16+0200 DEBUG Completion plugin: Generating completion cache...
2025-06-07T21:29:16+0200 DEBUG --> Starting dependency resolution
2025-06-07T21:29:16+0200 DEBUG --> Finished dependency resolution
2025-06-07T21:29:16+0200 DDEBUG timer: depsolve: 19 ms
2025-06-07T21:29:16+0200 SUBDEBUG
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 130, in cli_run
ret = resolving(cli, base)
File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 166, in resolving
base.resolve(cli.demands.allow_erasing)
File "/usr/lib/python3.9/site-packages/dnf/base.py", line 931, in resolve
raise exc
dnf.exceptions.DepsolveError:
Problem: The operation would result in removing the following protected packages: grub2-efi-x64, grub2-pc
2025-06-07T21:29:16+0200 CRITICAL Error:
Problem: The operation would result in removing the following protected packages: grub2-efi-x64, grub2-pc
2025-06-07T21:29:16+0200 INFO (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
2025-06-07T21:29:16+0200 DDEBUG Cleaning up.
2025-06-07T21:29:16+0200 DDEBUG Plugins were unloaded.
add -v to your commandline
No new information in output or log.
What versions of grub2-pc and grub2-efi-x64 are currently installed?
I wonder if the issue is whatever mirror you’re using doesn’t have the latest versions of those available.
I get
$ sudo dnf info grub2-efi-x64 grub2-pc
Last metadata expiration check: 0:00:21 ago on Sat 07 Jun 2025 11:39:44 PM CEST.
Installed Packages
Name : grub2-efi-x64
Epoch : 1
Version : 2.06
Release : 94.el9_5
Architecture : x86_64
Size : 4.7 M
Source : grub2-2.06-94.el9_5.src.rpm
Repository : @System
From repo : baseos
Summary : GRUB for EFI systems.
URL : http://www.gnu.org/software/grub/
License : GPLv3+
Description :
: The GRand Unified Bootloader (GRUB) is a highly configurable and
: customizable bootloader with modular architecture. It supports a rich
: variety of kernel formats, file systems, computer architectures and
: hardware devices.
:
: This subpackage provides support for efi-x64 systems.
Name : grub2-pc
Epoch : 1
Version : 2.06
Release : 94.el9_5
Architecture : x86_64
Size : 31
Source : grub2-2.06-94.el9_5.src.rpm
Repository : @System
From repo : baseos
Summary : Bootloader with support for Linux, Multiboot, and more
URL : http://www.gnu.org/software/grub/
License : GPLv3+
Description :
: The GRand Unified Bootloader (GRUB) is a highly configurable and
: customizable bootloader with modular architecture. It supports a rich
: variety of kernel formats, file systems, computer architectures and
: hardware devices.
:
: This subpackage provides support for pc systems.
Name : grub2-efi-x64
Epoch : 1
Version : 2.06
Release : 104.el9_6
Architecture : x86_64
Size : 4.7 M
Source : grub2-2.06-104.el9_6.src.rpm
Repository : @System
From repo : baseos
Summary : GRUB for EFI systems.
URL : http://www.gnu.org/software/grub/
License : GPLv3+
Description :
: The GRand Unified Bootloader (GRUB) is a highly configurable and
: customizable bootloader with modular architecture. It supports a rich
: variety of kernel formats, file systems, computer architectures and
: hardware devices.
:
: This subpackage provides support for efi-x64 systems.
Name : grub2-pc
Epoch : 1
Version : 2.06
Release : 104.el9_6
Architecture : x86_64
Size : 31
Source : grub2-2.06-104.el9_6.src.rpm
Repository : @System
From repo : baseos
Summary : Bootloader with support for Linux, Multiboot, and more
URL : http://www.gnu.org/software/grub/
License : GPLv3+
Description :
: The GRand Unified Bootloader (GRUB) is a highly configurable and
: customizable bootloader with modular architecture. It supports a rich
: variety of kernel formats, file systems, computer architectures and
: hardware devices.
:
: This subpackage provides support for pc systems.
So what that tells us is that you have somehow installed two versions of grub2-pc and grub2-efi-x64, or at least your computer thinks you have.
The next thing to look at is to use the rpm verify command on all four of those package names and see what it tells you.
Also check whether the system is using EFI partitions or not, you can check that using the mount command and also checking the contents of /etc/fstab or by using fdisk -l. Once verified whether you are using EFI or BIOSBOOT, you can then remove the package that isn’t needed.
If EFI partitions exist, delete the grub2-pc package. If the other way around, remove the grub2-efi one.
hmm.. it seems it’s.. both?
$ sudo fdisk -l
Disk /dev/vda: 240 GiB, 257698037760 bytes, 503316480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E811E2B5-98BE-4773-8387-812FAE82D5C6
Device Start End Sectors Size Type
/dev/vda1 2048 6143 4096 2M BIOS boot
/dev/vda2 6144 210943 204800 100M EFI System
/dev/vda3 210944 2258943 2048000 1000M Linux extended boot
/dev/vda4 2258944 503316446 501057503 238.9G Linux root (x86-64)
What do you have in your /etc/fstab? Does it show it mounting an EFI partition? Also output of mount command.
Also take a look here:
root@kvm:~# ls /sys/firmware/
acpi dmi memmap qemu_fw_cfg
it should show an efi directory here if booted in EFI. For example, another of my Rocky systems:
root@rocky9:~# ls /sys/firmware/
acpi dmi efi memmap qemu_fw_cfg
the first one is using BIOSBOOT due to lack of EFI in that /sys/firmware directory, as well as lack of entries in fstab and partitions.
Hi, I get the following
# rpm -qa | grep grub
grub2-common-2.06-94.el9_5.noarch
grub2-tools-minimal-2.06-94.el9_5.x86_64
grub2-pc-modules-2.06-94.el9_5.noarch
grub2-tools-2.06-94.el9_5.x86_64
grubby-8.40-64.el9.x86_64
grub2-pc-2.06-94.el9_5.x86_64
grub2-efi-x64-2.06-94.el9_5.x86_64
grub2-tools-extra-2.06-94.el9_5.x86_64
grub2-tools-efi-2.06-94.el9_5.x86_64
grub2-common-2.06-104.el9_6.noarch
grub2-tools-minimal-2.06-104.el9_6.x86_64
grub2-pc-modules-2.06-104.el9_6.noarch
grub2-tools-2.06-104.el9_6.x86_64
grub2-pc-2.06-104.el9_6.x86_64
grub2-efi-x64-2.06-104.el9_6.x86_64
grub2-efi-x64-modules-2.06-104.el9_6.noarch
# rpm -V grub2-pc-2.06-94.el9_5
# rpm -V grub2-efi-x64-2.06-94.el9_5
S.5...... /boot/efi/EFI/rocky/grubx64.efi
# rpm -V grub2-pc-modules-2.06-104.el9_6
# rpm -V grub2-efi-x64-2.06-104.el9_6
The fstab:
# cat /etc/fstab
UUID=8b81c9e7-5c4e-465e-994a-0c461380b4b6 / xfs defaults 0 1
UUID=82dc8497-5e61-4d31-9ee2-54ddb325d068 /boot xfs defaults 0 0
UUID=F1A4-E751 /boot/efi vfat defaults,umask=0077,shortname=winnt 0 0
/swapfile none swap sw 0 0
and the output of
# mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=969095,mode=755,inode64)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,size=1567164k,nr_inodes=819200,mode=755,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime,seclabel)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
/dev/vda4 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,nosuid,noexec,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19736)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,seclabel)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime,seclabel)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
none on /run/credentials/systemd-sysctl.service type ramfs (ro,nosuid,nodev,noexec,relatime,seclabel,mode=700)
none on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs (ro,nosuid,nodev,noexec,relatime,seclabel,mode=700)
systemd-1 on /efi type autofs (rw,relatime,fd=54,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=18225)
/dev/vda3 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/vda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
none on /run/credentials/systemd-tmpfiles-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,seclabel,mode=700)
/dev/vda2 on /efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=783580k,nr_inodes=195895,mode=700,uid=1000,gid=1000,inode64)
and
# ls /sys/firmware/
acpi dmi memmap qemu_fw_cfg
Based on the content of /sys/firmware it would suggest you aren’t using efi. But then your filesystem layout and fstab contents also contradicts that. Seems strange that you have an installation like that.
My BIOS install doesn’t have any EFI partitions created, nor mounted in fstab. Nor does it appear under /sys/firmware. And on the UEFI system, it does have EFI partitions, no BIOSBOOT partition, and EFI in fstab and /sys/firmware. It could well be you had something else installed prior to Rocky and didn’t clean up the partition layout perhaps? Or EFI partitions were created when not necessary?
I would remove the grub2-efi packages and reboot. Worst case, you’d have to reboot in rescue mode later to reinstall them again if the system doesn’t boot. But based on the content of /sys/firmware it’s doesn’t look like it’s using EFI.
As this is a remote VPS, I am not quite sure I can go into rescue mode…
Actually it’s interesting, as I figured after you said about rescue mode, I’d check my VPS at Hetzner. I do have a console for that, so can do rescue mode without problems. But what else is interesting is that it has a similar situation to yours in that both grub EFI and pc packages are installed. It also on the disk has EFI and BIOSBOOT partitions, and /sys/firmware isn’t using EFI.
I’m guessing they have an image to work on either system. Although in this instance I am actually running RHEL10 on it and as such haven’t had any issues with this conflict during update.
Device Start End Sectors Size Type
/dev/sda1 135168 80003038 79867871 38.1G Linux filesystem
/dev/sda14 2048 133119 131072 64M EFI System
/dev/sda15 133120 135167 2048 1M BIOS boot
root@web:~# ls /sys/firmware/
acpi dmi memmap qemu_fw_cfg
root@web:~# rpm -qa | grep -i grub | sort
grub2-common-2.12-14.el10_0.noarch
grub2-efi-x64-2.12-14.el10_0.x86_64
grub2-efi-x64-modules-2.12-14.el10_0.noarch
grub2-pc-2.12-14.el10_0.x86_64
grub2-pc-modules-2.12-14.el10_0.noarch
grub2-tools-2.12-14.el10_0.x86_64
grub2-tools-efi-2.12-14.el10_0.x86_64
grub2-tools-extra-2.12-14.el10_0.x86_64
grub2-tools-minimal-2.12-14.el10_0.x86_64
grubby-8.40-77.el10.x86_64
and fstab and mount:
UUID=095eabe3-6170-4016-9c8c-0ef66354819b / ext4 noatime 1 1
UUID=7512-4BBD /boot/efi vfat defaults,uid=0,gid=0,umask=077,shortname=winnt 0 2
/swapfile swap swap defaults 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,noexec,seclabel,inode64 0 0
root@web:~# mount | grep efi
/dev/sda14 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
Perhaps try and update the grub packages first before doing a full update. Eg:
dnf update grub2-pc
dnf update grub2-efi-x64