Unresolvable conflict when updating repaired computer: "plasma-framework"

I have a 2015 Asus notebook that was running Manjaro-Plasma with no problems from about July 2022 to about March 2024, at which time it stopped booting and gave “insert bootable media into drive” error. The problem turned out to be a bad 3V MnO2 battery for the CMOS RAM that holds UEFI settings. The replacement battery I ordered with the wrong part, delaying repairs. The second replacement battery was correct, after which the “insert bootable media into drive” error went away, replace by a black screen. Turned out, Track 0 contents (Grub boot-loader) was messed-up, and the /boot/efi partition was corrupted, and /etc/fstab was also corrupted, further delaying repairs. So by the time I got all that fixed and the computer was up-and-running, it had over 1000 updates waiting for it.

But now it can’t be updated. I followed all of the advice in the thread on the big Plasma 5 → 6 update, to no avail. On booting to Ctrl-Alt-F3 as root and doing “pacman -Syu”, I get “removing plasma-framework breaks dependency ‘plasma-framework’ required by krunner5”. And krunner5 can’t be deleted because a bunch of stuff depends on it. And electing to not remove plasma-framework gives “Unresolvable package conflict: libplasma and plasma-framework are in conflict”.

So, how can I unravel this conundrum?

Very unusual that file contents should so easily become “messed up” by simply sitting there.

Whatever you did to create the situation or whatever you did to then rectify it might be important to know - but we will likely never …

sudo pacman-mirrors -f 5 to update mirrors
sudo pacman -Syyu to run the update (-yy because the mirrors most likely just changed with the prior command)

If you can’t interpret the messages - show them here.
Or post it to a pastebin service.

a bunch of stuff depends on it.

is just too vague.

All of them as you see them.
So we see what you see.

Use manjaro-chroot by booting from USB if you can’t comfortably work on a TTY but want a graphical environment instead.

1 Like

First, uninstall the:

…and then uninstall krunner5. Whatever you uninstall can be reinstalled later, if needed (after your system is successfully updated). Make sure to write them all down.

Using a chroot environment (via a Live Installer) may also be beneficial.

Cheers.

5 Likes

Yes, it was “unusual”, but that’s the situation I had to contend with: Grub was gone from Track 0 and the “/boot/efi/” partition had file-system-type “unknown” (should have been “FAT32”). I suspect that the computer’s UEFI, its settings garbled due to a bad battery, may have done that. But as you say, we’ll likely never know. And it’s now moot. (Been sorted: I successfully deleted the corrupt “/boot/efi/” partition and re-created it as FAT32, updated “/etc/fstab” with the new UUID, and installed Grub into Track 0 and “/boot/efi/”.)

Actually, “just sitting around for 4 months” may have caused problems, yes, because SSDs store data by holding electrons in memory cells which are basically highly-specialized capacitors. The leakage is very low, but not zero. So if storing data for years, spinning rust is a better option than SSDs. SSDs + “sitting around” = bad.

Good idea; I didn’t think to do that. I’ll add that to my list of approaches to try next.

I’ll try that again after updating mirrors first. But I’ll probably have to handle the “plasma-framework” dependency issue first.

That is going to be quite the chore, as they’re not listed anywhere, so I’d have to launch the GUI, run Pamac (instead of Pacman), mark all updates as “ignore”, and make repeated attempts at deleting krunner5 and its dependents (multiple levels deep). I tried that before, but got frustrated and gave up around 6 levels deep. Gonna take a while. And may prove fruitless if critical OS components that can’t be deleted are in the dependency tree. I’ll get back to you on that.

(Of course there is always the “nuke it from orbit” option: delete and re-create the main partition and install the latest Manjaro from a newly-created install stick. But I’m not quite ready to get that radical yet.)

I agree completely - I will keep using the spinning rust. :+1: Haven’t used a ssd yet.
I don’t care about the speed/access time.

I meant that you present all the dependency issues - one by one, as they come up
if you don’t know how to deal with them as they come up

it’s of the form:
… cant do this because this depends on that
and that depends on the next thing …

it’s usually the last thing in the error message line that is the culprit and needs to (temporarily) go

AUR packages can present a problem - just remove those
they are easily reinstalled afterwards

The only dependency issue is plasma-framework. I spent the time charting that dependency tree, and it would require manually deleting nearly the entire KDE Plasma Desktop Environment, 22 major packages in all:

plasma-framework
	krunner5
		milou
			plasma-workspace
				(see dependents below)
	kscreen
		plasma-workspace
			kdeplasma-addons
			khotkeys
			plasma-browswer-integration
			plasma-nm
			plasma-pa
			plasma-vault
			sddm-breath-theme
				manjaro-kde-settings
			systemsettings
				kgamma5
				kinfocenter
					plasma-disks
				plasma-desktop
				sddm-kcm
				systemd-kcm
	kwin
		plasma-workspace
			(see dependents above)
	print-manager
	sddm-breath-theme
		(see dependents above)
	xdg-desktop-portal-kde
		kde-manjaro-settings

That should not be necessary; it should be handled automatically. And on my other computers, when I did the Plasma 5 → 6 Manjaro update, it all was handled automatically.

But on the computer that was offline for 4 months, it’s not working. No, not even after updating mirrors and databases. Pacman should just replace those 22 Plasma modules with the new versions, but it’s not. It even asks me “do you want to replace plasma-framework with extra/libplasma?” But though I say “Yes”, it won’t actually do that. Instead, it stops on the first unresolvable dependency conflict and says (read visually and typed manually, KVMing between computers):

looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing plasma-framework breaks dependency 'plasma-framework' required by krunner5
%_

So something is clearly broken. I’m loathe to attempt to manually uninstall the entire KDE Plasma Desktop Environment piece-by-piece, then run the rest of the update (if that would even work), then do “pacman -S plasma” or some such in order to re-install Plasma. Seems overly complicated. Isn’t there a better way? Some way to tell Pacman to just delete the old stuff and replace it with the new stuff instead of making me do it manually?

Similar problem on Arch forum? Of course, the apparent solution (involving pacman -Rdd) should be accompanied by the warning from the Arch wiki:

Warning: The following operation can break a system and should be avoided.

Arch Linux forum: Dependency problem upgrading system

1 Like

Alrighty! Yes, the dependencies have become circular due to the machine being off-line for 4 months and missing too many updates, and “dd” just skips those checks. I’m using that method, but I skipped most of the prelims and dived into the deep end with “pacman -Sudd”. That asked me about 30 “replace” questions, to which I answered “yes” in all cases, then immediately launched into downloading 1022 packages (instead of crashing with circular dependency errors as was before). I’ll get back to you on what the final result is. Likely there will be problems that will need to be cleaned up later with “pacman -Syyu”. But at least this way most of the package updates will be “already done” so the dependencies will be less tangled.

krunner5 is only one of several modules dependent on plasma-framework, and the entire KDE Plasma Desktop Environment (as currently installed, on that machine) depends on plasma-framework. The dependencies have become circular due to the machine being offline for 4 months and missing too many updates. So, no, the solution isn’t “uninstalling stuff”.

Instead, I took the advice of another responder here and simply turned off the dependency checking with “pacman -Sudd”. The result will almost certainly be a broken system, but that’s fine, much better than the circular-dependencies nightmare. Whatever problems come up, I think I can resolve by rebooting back to TTY3 as root and doing “pacman -Su” which should re-run sync with dependency-checking turned-back on. Well see. Currently updating item 110 of 1022. This is going to take a while.

Do you keep your /home on a separate partition or even better on its own disk?

If not, I recommend considering it.

You could have re-installed using the manual setup so you lose no data, just tell it where /home is located (don’t format) and been on your way doing whatever you need to do, instead of struggling for an entire day.

1 Like

There are no disks or SATA SSDs, or any room for any, on the afflicted machine, just a single PCIE slot directly on the motherboard for a m.2 device. I was in a hurry to get it back up and running, and “pacman -Sudd” failed spectacularly, and there was no data on that computer that wasn’t backed up in 3 other places, so I reinstalled the latest Manjaro from a USB install stick with “/” and “/home” in the same partition. It’s a tiny m.2 from 2015 (yes, apparently they had them back then), just 256GB, and I intend to replace it soon anyway.

I think what I’ll do in the longer term is, I’ll get a 2TB m.2 and partition it as you suggest. My main computer is already that way: has separate Boot, Root, Main, and Swap partitions. I’ll do the same on the new m.2 for the afflicted machine.

But for now I was able to get functionality back on my notebook by just doing a fresh install. I use it as a note-taker and web-surfer when traveling. A few things will need to be re-installed (settings, tweaks, Firefox & Thunderbird profiles, etc), but that’s fine. This machine was never far away from “stock Manjaro” anyway.

Ok, I gave up and used the “nuke it from orbit” approach. I was in a hurry to get it back up and running, and “pacman -Sudd” failed spectacularly (the system was left in a state so broken that I couldn’t log-on, and even in “rescue” mode, Pacman wouldn’t even run). And, there was no data on that computer that wasn’t backed up in 3 other places. So, I wiped-out the main partition and installed the latest Manjaro from a freshly-made USB install stick. (Balena Etcher worked fine for that.)

I think what I’ll do in the longer term is, I’ll get a 2TB m.2 and partition it with separate Boot, Root, Main, and Swap partitions.

But for now I was able to get functionality back on my afflicted notebook by doing a fresh install. I use it as a note-taker and web-surfer when traveling. A few things will need to be re-installed (settings, tweaks, Firefox & Thunderbird profiles, etc), but that’s fine. This machine was never far away from “stock Manjaro” anyway, which limits the amount of ricing I need to do to get it back up-to-speed.

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