Rock ➜ ROME upgrade failed: systemd duplicated (257.5 and 258.2 installed)

Support
, ,
1

Hello,

Requirements:

I have Searched the forum for my issue and found nothing related or helpful
I have checked the Resources category (Resources Index)
I have reviewed the Wiki for relevant information
I have read the the Release Notes and Errata

OpenMandriva Lx version:

OpenMandriva Lx release 25.11 (ROME) Rolling for znver1

Desktop environment (KDE, LXQT…):

System:
  Host: openmandriva-x8664 Kernel: 6.14.2-desktop-3omv2590 arch: x86_64
    bits: 64
  Desktop: KDE Plasma v: 6.5.2 Distro: OpenMandriva Lx 25.11 ROME

Description of the issue (screenshots if relevant):

TL;DR I attempted to migrate from Rock (Vanadium) to Rolling (ROME) following the official instructions. During the upgrade, the process was interrupted while updating systemd/udev, leaving my system with two different versions of systemd installed (257.5 and 258.2). Now:

  • dnf5 distro-sync cannot continue because removing systemd is blocked - all Rolling repos are enabled correctly
  • system boots and Plasma works after manually fixing X11 with the AMD GPU BusID
  • but the system cannot fully sync to ROME
  • dnf5 solver remains stuck between the two systemd versions

I am asking whether the system can be recovered safely, or if a clean reinstall of ROME is the only supported option.

(English is not my first language, so this report is written with the help of ChatGPT to ensure clarity and correct terminology.)

I want to provide a complete and accurate technical description of the issue, based entirely on the exact commands I used, in case any detail is relevant for diagnosing the problem.

  1. Initial system state

Original installation: OpenMandriva Lx 6.0 Rock (Vanadium)

Hardware:

  • AMD Ryzen 5 5600
  • NVIDIA GTX 960 (installed, but not used for display)
  • AMD Radeon RX 6800 XT (primary GPU used for display both in Rock and in ROME)

X11 was working correctly on Rock using the AMD GPU.

I decided to migrate from Rock → Rolling (ROME) to obtain newer Mesa and kernel versions for gaming. 2. Repository switch I followed the official OpenMandriva wiki instructions. Enabled repos:

openmandriva-rolling-znver1
openmandriva-rolling-znver1-extra
openmandriva-rolling-znver1-non-free
openmandriva-rolling-znver1-restricted

Disabled repos:

openmandriva-rock-znver1
openmandriva-rock-znver1-extra
openmandriva-rock-znver1-non-free
openmandriva-rock-znver1-restricted

Cooker was never enabled.

I then ran:

sudo dnf5 clean all
sudo dnf5 distro-sync

(and later also attempted with --allowerasing, --refresh, etc.)

  1. Upgrade interruption and black screen

During the major upgrade, while systemd, udev and core libraries were being updated, the system suddenly switched to a black screen.
I was away from the machine, so nothing was interrupted manually.

I switched to TTY (Ctrl+Alt+F2) and logged in as root.
Attempting to resume the upgrade always failed with:

Failed to resolve the transaction:
The operation would result in removing the following protected packages: systemd

dnf5 refused to continue.

  1. Result: systemd left in an inconsistent state

Because the upgrade was interrupted in the middle of systemd/udev updates, the system was left with two complete systemd families installed:

Old Rock versions (257.5):

systemd-257.5-1.znver1
lib64systemd-257.5-1.znver1
lib64udev-257.5-1.znver1
udev-257.5-1.znver1
systemd-resolved-257.5-1.znver1
systemd-analyze-257.5-1.znver1
systemd-locale-257.5-1.znver1
systemd-cryptsetup-257.5-1.znver1
systemd-console-257.5-1.znver1
systemd-boot-257.5-1.znver1
systemd-polkit-257.5-1.znver1
systemd-coredump-257.5-1.znver1
lib64nss_systemd-257.5-1.znver1
lib64nss_myhostname-257.5-1.znver1
lib64nss_resolve-257.5-1.znver1
lib64systemd-devel-257.5-1.znver1
lib64udev-devel-257.5-1.znver1

New Rolling versions (258.2):
All corresponding systemd/udev/libsystemd packages in version 258.2 are also installed.

Since Rolling no longer provides systemd 257.x, dnf5 cannot downgrade the older packages, and cannot remove them because systemd is protected.

  1. Restoring the graphical environment

After the interruption:

  • SDDM kept looping
  • Plasma could not start
  • task-plasma6 could not be installed due to missing dependencies

I reinstalled some Plasma components manually.

Because I have two GPUs, after the failed migration Xorg stopped choosing the AMD GPU automatically, even though the monitor is connected to it.

The fix was to explicitly set the PCI BusID of the AMD GPU in:

/etc/X11/xorg.conf.d/20-amdgpu.conf:

Section "Device"
    Identifier "AMD"
    Driver "amdgpu"
    BusID "PCI:9:0:0"
EndSection

(PCI:9:0:0 corresponds to the actual PCIe address of my RX 6800 XT.)

Once the correct BusID was set, X11 and Plasma worked again.

  1. Current state

The system is usable:

  • Plasma 6 works
  • X11 works on AMDGPU
  • Kernel 6.14.2-desktop-3omv2590 boots normally

But dnf5 remains unable to complete the migration.

These commands all fail:

dnf5 distro-sync
dnf5 distro-sync --allowerasing
dnf5 distro-sync --refresh
dnf5 swap systemd-257.5 systemd-258.2 --allowerasing

All fail with:

Failed to resolve the transaction:
The operation would result in removing the following protected packages: systemd

dnf5 --debugsolver distro-sync confirms the dependency solver is stuck between systemd 257.5 and 258.2.

  1. Questions

I would like to ask the OpenMandriva developers:

  • Is this mixed-systemd (257.5 + 258.2) state recoverable manually?
  • Is there a safe OpenMandriva-supported way to remove the obsolete 257.5 packages?
  • Or is a clean reinstall of ROME the correct solution?
  • Is such a partial-upgrade situation known or expected when a Rock → ROME migration is interrupted?
  • Should dnf5 block partial upgrades on protected packages like systemd/udev?

This report is written with the assistance of ChatGPT because English is not my first language and I wanted to ensure accuracy.

Thank you for your help.

Relevant informations (hardware involved, software version, logs or output…):

[kane@openmandriva-x8664 ~]$inxi -F
System:
  Host: openmandriva-x8664 Kernel: 6.14.2-desktop-3omv2590 arch: x86_64
    bits: 64
  Desktop: KDE Plasma v: 6.5.2 Distro: OpenMandriva Lx 25.11 ROME
Machine:
  Type: Desktop Mobo: Gigabyte model: B450 AORUS ELITE V2
    serial: <superuser required> UEFI: American Megatrends LLC. v: F67
    date: 03/22/2024
CPU:
  Info: 6-core model: AMD Ryzen 5 5600 bits: 64 type: MT MCP cache: L2: 3 MiB
  Speed (MHz): avg: 3561 min/max: 550/4470 cores: 1: 3561 2: 3561 3: 3561
    4: 3561 5: 3561 6: 3561 7: 3561 8: 3561 9: 3561 10: 3561 11: 3561 12: 3561
Graphics:
  Device-1: NVIDIA GM206 [GeForce GTX 960] driver: nvidia v: 575.51.02
  Device-2: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX 6800/6800
    XT / 6900 XT] driver: amdgpu v: kernel
  Display: x11 server: X.org with: Xwayland v: 24.1.9 driver: X:
    loaded: amdgpu dri: radeonsi gpu: amdgpu resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: kms_swrast,radeonsi,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 25.3.0-rc4
    renderer: AMD Radeon RX 6800 XT (radeonsi navi21 LLVM 21.1.5 DRM 3.61
    6.14.2-desktop-3omv2590)
  API: Vulkan v: 1.4.330 drivers: radv,llvmpipe surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console
    gpu: amdgpu_top, nvidia-settings, nvidia-smi wl: wayland-info
    x11: xdpyinfo, xprop, xrandr
Audio:
  Device-1: NVIDIA GM206 High Definition Audio driver: snd_hda_intel
  Device-2: Advanced Micro Devices [AMD/ATI] Navi 21/23 HDMI/DP Audio
    driver: snd_hda_intel
  Device-3: Advanced Micro Devices [AMD] Starship/Matisse HD Audio
    driver: snd_hda_intel
  API: ALSA v: k6.14.2-desktop-3omv2590 status: kernel-api
  Server-1: PipeWire v: 1.4.9 status: active
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    driver: r8169
  IF: eno1 state: up speed: 1000 Mbps duplex: full mac: 18:c0:4d:09:28:8d
  IF-ID-1: virbr0 state: down mac: 52:54:00:de:05:a2
Bluetooth:
  Device-1: Realtek Bluetooth Radio driver: btusb type: USB
  Report: hciconfig ID: hci0 state: up address: 00:A6:44:02:1F:59 bt-v: 5.1
Drives:
  Local Storage: total: 1.93 TiB used: 604.24 GiB (30.6%)
  ID-1: /dev/nvme0n1 vendor: MSI model: M371 1TB size: 931.51 GiB
  ID-2: /dev/sda vendor: Seagate model: ST1000DM003-1SB10C size: 931.51 GiB
  ID-3: /dev/sdb vendor: Kingston model: SA400S37120G size: 111.79 GiB
Partition:
  ID-1: / size: 109.19 GiB used: 94.68 GiB (86.7%) fs: ext4 dev: /dev/sdb2
  ID-2: /boot/efi size: 299.4 MiB used: 2 MiB (0.7%) fs: vfat dev: /dev/sdb1
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 392 KiB (0.0%) dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 50.9 C mobo: N/A gpu: amdgpu temp: 41.0 C
  Fan Speeds (rpm): N/A gpu: amdgpu fan: 0
Info:
  Memory: total: 32 GiB available: 31.28 GiB used: 5.09 GiB (16.3%)
  Processes: 359 Uptime: 14m Shell: Bash inxi: 3.3.39
ROME upgrade failed and cannot boot anymore
2

Welcome @Kane to OpenMandriva forum and OM Linux.

A fresh install is always preferred over this type of upgrade.

To fix maybe:

List the old systemd packages:

rpm -qa | grep 257.5-1

Remove them manually with:

sudo rpm -e --nodeps <package_name>

Then:

sudo dnf clean all
sudo dnf dsync --allowerasing

My guess is that if you had used sudo dnf5 distro-sync --allowerasing instead of without --allowerasing the transaction would have worked. Edit: So possibly what happend was the new systemd stack was installed without the old systemd stack being erased. If so the only intervention would be manual removal of the old packages.

Note: dsync is an alias for distro-sync

1 Like
3

Also, and this might not be super helpful, but it could explain why things didn’t work out well, the latest upgrade wasn’t one that was eligible for a ROCK > ROME upgrade. That update happened back in the spring with the release of ROCK 6.0. ROME is now further along than ROCK, so it wouldn’t be an easy transition.

I’ve only been using OM since January, but from what I understand, upgrading from ROCK to ROME can only happen when ROCK is being synced with ROME. This update was ROME syncing with COOKER. ROCK should be staying on the 6.14.2 kernel, and all of the packages associated with it.

At least, that’s my understanding…but I could also be totally wrong here.

1 Like
4

Im having the same problem but I was on rome when I updated the system. All the systemd packages are duplicated as well as about 1700 other packages and now system update is broken with the same error.

1 Like
5

TL;DR (Short Summary)

  • I upgraded from Rock → ROME, but the upgrade stopped halfway and left two systemd versions installed (257.5 + 258.2).

  • This broke dnf5 distro-sync and blocked all updates with “removing protected package: systemd”.

  • I manually removed all old systemd 257.5 packages using rpm -e --nodeps.

  • After that, dnf5 distro-sync --allowerasing worked, but the graphical session was killed mid-upgrade.

  • After finishing the upgrade from TTY, the system would not boot: new kernel entries were missing initrd.

  • I used the old kernel’s recovery mode to run dracut and rebuild initramfs for 6.17.7.

  • The actual problem: my Aorus motherboard was booting the wrong EFI loader (the fallback BOOTX64.EFI), which had an old grub.cfg without initrd lines.

  • I fixed booting by copying the correct OpenMandriva GRUB into the fallback location and creating a new EFI entry with efibootmgr.

  • SDDM needed to be manually re-enabled after boot.

  • System now boots fine into ROME, fully synced.

  • Reinstallation would have been faster, but recovery was successful.

Detailed Explanation of the Recovery Steps After Manually Removing Old systemd Packages

Below is a precise, technical description of everything that happened starting from the moment I manually removed the old systemd 257.5 packages with rpm -e --nodeps, followed by all the problems I encountered and how I eventually recovered the system.
This is written in English with the help of ChatGPT because English is not my first language.

  1. Identifying duplicate systemd packages

After attempting to migrate from Rock to ROME, I discovered that the upgrade had partially completed and left my system in an inconsistent state:

  • systemd 257.5 (old, Rock)
  • systemd 258.2 (new, ROME)

were installed at the same time.

This prevented all dnf5 distro-sync transactions with the error:

The operation would result in removing the following protected packages: systemd

So I listed the old packages:

rpm -qa | grep 257.5

and prepared to remove them manually.

  1. Force-removing old systemd packages with rpm --nodeps

To allow dnf5 to proceed, I removed the old 257.5 systemd stack one by one, using:

sudo rpm -e --nodeps <package>

This included:

  • systemd-257.5
  • lib64systemd-257.5
  • lib64udev-257.5
  • systemd-polkit-257.5
  • systemd-console-257.5
  • systemd-resolved-257.5
  • systemd-bash-completion-257.5
  • systemd-hwdb-257.5
  • …and all other 257.5 packages.

All removals completed successfully.
There were warnings about deprecated posix.fork(), but no fatal errors.

At this point, the system had only the 258.2 systemd stack installed, which allowed the packaging system to become consistent again.

  1. Running the full system synchronization

Once the old systemd components were gone, I ran:

sudo dnf5 clean all
sudo dnf5 distro-sync --allowerasing

This time the transaction succeeded and removed several GB of leftover outdated packages.

However, during the process, my graphical session terminated automatically, and I was forced back to a TTY. I continued the upgrade in TTY2 as root until dnf5 reported:

Complete!

  1. System does not boot anymore: stuck at “Loading Linux …”

After rebooting, the system failed to start.
It got stuck indefinitely on:

Loading Linux 6.17.7-desktop-1omv2590...

I pressed E in GRUB to inspect the entry and discovered the issue:

The new kernel entries had no initrd line.
Example:

linux /boot/vmlinuz-6.17.7-desktop-1omv2590 ...
# missing:
initrd /boot/initrd-6.17.7-desktop-1omv2590.img

This made the kernel unbootable.

The only entry that still worked was the old kernel 6.14.2 (recovery mode), which still had a valid initrd.

  1. Using the old kernel’s recovery mode to rebuild initramfs

I booted into:

OpenMandriva Lx, with Linux 6.14.2 (recovery mode)

Then manually created a new initramfs for the new kernel:

sudo dracut --force /boot/initrd-6.17.7-desktop-1omv2590.img 6.17.7-desktop-1omv2590

The initramfs was generated correctly.

But after rebooting, GRUB still did not show the initrd lines, meaning the correct initramfs existed but was not being referenced.

  1. Discovering the real issue: the wrong GRUB was being used

After investigating /boot/efi/EFI, I found three GRUB locations:

/boot/efi/EFI/BOOT
/boot/efi/EFI/openmandriva
/boot/efi/EFI/OpenMandriva_Lx_[GRUB]

My motherboard (Gigabyte Aorus) was loading the fallback:

EFI/BOOT/BOOTX64.EFI

instead of the proper OpenMandriva bootloader.

The fallback GRUB configuration was old and incorrect, still referencing kernel 6.17 without initrd.

The correct grub.cfg inside EFI/openmandriva/ did contain initrd entries.

So the system was simply booting the wrong GRUB.

  1. Fixing the EFI loader (and backing up the motherboard’s vendor bootloader)

Before modifying anything, I created a backup of the original vendor BOOTX64.EFI, which is important in case the firmware expects that specific binary:

sudo cp /boot/efi/EFI/BOOT/BOOTX64.EFI \
        /boot/efi/EFI/BOOT/BOOTX64.EFI.vendor-backup

Then I replaced the fallback loader with the correct OpenMandriva one:

sudo cp /boot/efi/EFI/openmandriva/grub.efi \
        /boot/efi/EFI/BOOT/BOOTX64.EFI

sudo cp /boot/efi/EFI/openmandriva/grub.cfg \
        /boot/efi/EFI/BOOT/grub.cfg

After that, I created a clean new EFI boot entry:

sudo efibootmgr --create \
 --disk /dev/sdb --part 1 \
 --label "OpenMandriva ROME" \
 --loader '\EFI\openmandriva\grub.efi'

This produced Boot0000, which I selected from the motherboard’s boot menu.

Immediately:

  • GRUB started instantly
  • Fonts were rendered correctly (no scaling glitches)
  • All kernel entries included initrd
  • Kernel 6.17.7 booted successfully

  1. Restoring SDDM

After booting successfully, graphical login still did not start automatically.
systemctl status sddm showed the service was disabled.

I fixed it with:

sudo systemctl enable sddm --force
sudo systemctl start sddm

SDDM started normally and the desktop loaded without issues.

Final State

After all these steps:

  • System boots normally on kernel 6.17.7
  • GRUB is correctly linked to the OpenMandriva loader
  • No duplicate systemd packages remain
  • dnf5 check, dnf5 distro-sync, and dnf5 refresh run cleanly
  • The system is fully synchronized with ROME
  • Only a separate missing library issue remains (libgpgme.so.11) which I will fix later

Closing Notes

Thank you to everyone who took the time to read this and provide guidance — and a special thank-you to @ben79, whose suggestion to manually remove the old systemd packages finally put me on the right track.

I want to be transparent: I’ve spent many hours wrangling ChatGPT, debugging step by step, and piecing together the recovery process. Some of the decisions were trial-and-error, and the situation became far more complex than I expected when I first attempted the Rock → ROME transition.

In hindsight, backing up and performing a fresh install would have been much faster, and I would strongly recommend that approach to anyone facing similar upgrade issues. Still, I hope that documenting this experience in detail will help future users who run into the same combination of:

  • partial upgrade
  • mixed systemd versions
  • missing initrd in GRUB
  • firmware booting the wrong EFI loader
  • and manual recovery steps requiring TTY, dracut, and efibootmgr.

Thanks again, especially to @ben79 , for the patience and guidance.

3 Likes
6

Good work. That looks like a pretty good how to for what it takes to upgrade Rock to ROME at this time.

FWIW the OM Contributor group has been focused on the very recent ROME(rolling) upgrade which was a heck of a lot of work.

Looks like the next Rock release may be a bigger project as well.

New install build 4292 ->: tty1 blinky cursor; instal icon; 3 efi_grub entries
7

Holy molly @Kane. That is both impressive and intimating. Impressive because of its depth, clarity, and thoroughness. Intimidating because I’m pretty sure I have multiple boot loaders being referenced and think I’m going to have to learn how to edit them myself now also.

Might be worth noting here,

I think at least some of this is not specific to Rock –> ROME upgrades. Both @LinNoob and myself have had similar issues with failed upgrades from earlier versions of ROME to the newest one (build 4292) with the

error, and the duplicate systemd packages and all. I am wondering if it is an issue with the new version/build, perhaps with particular hardware or something.

Also worth noting I think. Even a new install of 4292, using the erase disk option, is booting to tty1, with no log-in prompt (just blinky cursor) and I have to switch to tty2 manually to get to the gui (I didn’t even know about virtual terminals 2 days ago lol)

I can’t get any more detail atm because ANOTHER @#^#$ Storm (every time I sit down to troubleshoot this ffs)

Edit:
Also, is dnf5 now the package manager command?
I had not seen this mentioned elsewhere (I probably just missed it)

8

dnf will work just fine.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.