I recently upgraded my gaming rig (Fedora 36 w/ an AMD 3700X) to an AMD RX 6700 (non-XT, non-50.) More of a sidegrade really, since my old card was 2070 Super, but I was sick of the butt pucker every time I got a kernel update.
Anyway, I somehow got rid of most of the nvidia driver, but some of the nouveau blacklisting is still in place. Following various tutorials I tried ‘dnf erase nvidia\*’ and the more complicated ‘sudo dnf erase nvidia* akmod-nvidia xorg-x11-drv-nvidia*’. However both of these commands resulted in the following ‘preview’:
sudo dnf erase nvidia\*
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
nvidia-gpu-firmware noarch 20230117-146.fc36 @updates 1.2 M
Removing dependent packages:
linux-firmware noarch 20230117-146.fc36 @updates 125 M
Removing unused dependencies:
amd-gpu-firmware noarch 20230117-146.fc36 @updates 23 M
intel-gpu-firmware noarch 20230117-146.fc36 @updates 8.0 M
Transaction Summary
================================================================================
Remove 4 Packages
Freed space: 158 M
Is this ok [y/N]:
Deleting the AMD firmware seems rather stupid considering I have an AMD GPU in my system. Any idea why AMD firmware is an ‘dependency’ unused dependency of the NVidia firmware?
Thanks for the reminder to cleanup after a drop in replacement. I should also do this.
Edit: Ok so it did not remove much (just about 1.5 MB worth of binaries. I recalled prior to this that I disabled the non-free nvidia repo. I guess that took care of that?
It is a Recommends of the linux-firmware package. DNF installs recommended packages by default (but are by default ignored if not satisfied as opposed to Requires).
I wouldn’t really worry about it TBH. If the amdgpu driver or mesa needed it, they would ask for it.
Do you have any space in the volume group? Try vgs to check that you have something free there, don’t allocate all of it to partitions. Also, the partitions might get activated automatically by systemd, so you may want to:
Then edit /etc/lvm/lvm.conf and change use_lvmetad=0. On some newer systems, in lvm.conf, it might be named event_activation=0 and you might not find the systemd service and socket. Just set that value to 0 and reboot your system, then try a new snapshot and then reboot.
Note that when you disable lvmetad, you cannot run vgextend, lvextend and other commands like that. You have to re-enable these, reboot your system, then change then, reboot, disable, reboot, continue taking snapshots.
Also, don’t leave the snapshots there for too long, they might become corrupted when the volume group fills up its space.
It’s just linux-firmware, which has all 3 firmwares. I wouldn’t worry too much about it. I used to have these installed on my arm system, until I excluded them in the package manager (along with some other ARM firmware), so they never got installed again. A bit silly, but they should not be interfering with your system and new GPU. As long you have mesa-dri, you’re fine.
Dude, you killed my wifi. Or more specifically, sudo dnf erase nvidia\*
clobbered my wireless. Fortunately it was easily reversed with sudo dnf history undo <transaction-id>
So it seems my wireless card’s firmware was in linux-firmware. Very uncool of dnf to disable my networking, but it also provided the means to quickly reverse it. SMH.
Huh, that’s weird… honestly I’d file that as a bug on the RedHat tracker.
It shouldn’t remove linux-firmware if it’s a dependency of anything else so evidently some package is missing a dependency on it.
As an aside: I don’t understand why linux-firmware is listed as a “dependent package” in your erase (which btw is just a deprecated alias of remove/rm) in the first place. nvidia-gpu-firmware only has a Requires on linux-firmware-whence, which itself has no dependency on anything.
On a hunch, I upgraded to F37, which was overdue anyway. And as I suspected, when I tried to erase/remove/delete/uninstall nvidia-gpu-firmware, dnf behaved nicely and only removed that package. So apparently the screwed up dependency(ies) that were in place have been cleaned up.
Mh well if you look at the file it has a conditional on the Fedora version. On 36 and below it’s a Requires, on 37 and above it’s a Recommends.
But that shouldn’t change the behaviour really. If you try to uninstall the nvidia package then by that logic yes it should select the linux package for removal. However that should fail because some other package should depend on it too…
Weird thing, IDK.
I also ran into a dependency mystery recently with my OBS package and I can’t explain how it happened. But maybe I’ll type that when I’m awake again
Ah. That makes sense. I am not used to Windows. The file was created with Windows since I can’t get handbrake to use Intel QSV for my Arc A380 on Linux. I am transferring the file from a BTRFS filesystem partially because there is a way to make it work in Windows. I tried using WSL, but I couldn’t get kt to mount and I don’t care enough to fix it. I would rather get Handbrake to use hardware encoding on Linux. sigh
Having done more experimenting with suspension, the closest I can get to figuring this out is that suspending mostly works if I trigger it from KDE’s lock screen, it works the second time if I trigger it from another computer via ssh, and it always instantly wakes if I trigger it from an unlocked KDE session. Such a headache. I think I’ll just accept the constant 150W load instead, maybe one day some boffin will solve this for me.
Error while installing package: trying to overwrite '/usr/lib/x86_64-linux-gnu/dri/i915_dri.so', which is also in package libgl1-amber-dri
I`ve tried to sudo apt upgrade and sudo apt --fix-broken install and this was the result:
Blockquote
sudo apt upgrade
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
You might want to run ‘apt --fix-broken install’ to correct these.
The following packages have unmet dependencies:
libgl1-mesa-dri : Depends: libglapi-mesa (= 22.2.0-1pop0~1664294850~22.04~4e1b64f) but 22.3.4-1pop1~1675300365~22.04~6b66c01 is installed
Breaks: libgl1-mesa-dri:i386 (!= 22.2.0-1pop0~1664294850~22.04~4e1b64f) but 22.3.4-1pop1~1675300365~22.04~6b66c01 is installed
libgl1-mesa-dri:i386 : Breaks: libgl1-mesa-dri (!= 22.3.4-1pop1~1675300365~22.04~6b66c01) but 22.2.0-1pop0~1664294850~22.04~4e1b64f is installed
E: Unmet dependencies. Try ‘apt --fix-broken install’ with no packages (or specify a solution).
Blockquote
sudo apt --fix-broken install
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Correcting dependencies… Done
The following packages were automatically installed and are no longer required:
appmenu-gtk-module-common appmenu-gtk2-module appmenu-gtk3-module
gir1.2-gweather-4.0 libappmenu-gtk2-parser0 libappmenu-gtk3-parser0
libgl1-amber-dri libllvm13 libllvm13:i386 libvulkan1:i386
libwayland-client0:i386 libxcb-randr0:i386 linux-headers-5.19.0-76051900
linux-headers-5.19.0-76051900-generic linux-image-5.19.0-76051900-generic
linux-modules-5.19.0-76051900-generic mesa-vulkan-drivers:i386
Use ‘sudo apt autoremove’ to remove them.
The following additional packages will be installed:
libgl1-mesa-dri
The following packages will be upgraded:
libgl1-mesa-dri
1 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.
2 not fully installed or removed.
Need to get 0 B/7.499 kB of archives.
After this operation, 700 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database … 311271 files and directories currently installed.)
Preparing to unpack …/libgl1-mesa-dri_22.3.4-1pop1~1675300365~22.04~6b66c01_am
d64.deb …
Unpacking libgl1-mesa-dri:amd64 (22.3.4-1pop1~1675300365~22.04~6b66c01) over (22
.2.0-1pop0~1664294850~22.04~4e1b64f) …
dpkg: error processing archive /var/cache/apt/archives/libgl1-mesa-dri_22.3.4-1p
op1~1675300365~22.04~6b66c01_amd64.deb (–unpack):
trying to overwrite ‘/usr/lib/x86_64-linux-gnu/dri/i915_dri.so’, which is also
in package libgl1-amber-dri:amd64 21.3.7-0ubuntu1
Errors were encountered while processing:
/var/cache/apt/archives/libgl1-mesa-dri_22.3.4-1pop1~1675300365~22.04~6b66c01_a
md64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Blockquote
sudo apt autoremove
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
You might want to run ‘apt --fix-broken install’ to correct these.
The following packages have unmet dependencies:
libgl1-mesa-dri : Depends: libglapi-mesa (= 22.2.0-1pop0~1664294850~22.04~4e1b64f) but 22.3.4-1pop1~1675300365~22.04~6b66c01 is installed
Breaks: libgl1-mesa-dri:i386 (!= 22.2.0-1pop0~1664294850~22.04~4e1b64f) but 22.3.4-1pop1~1675300365~22.04~6b66c01 is installed
libgl1-mesa-dri:i386 : Breaks: libgl1-mesa-dri (!= 22.3.4-1pop1~1675300365~22.04~6b66c01) but 22.2.0-1pop0~1664294850~22.04~4e1b64f is installed
E: Unmet dependencies. Try ‘apt --fix-broken install’ with no packages (or specify a solution).
Any idea how to solve this issue?
And did I format the terminal text right?
No, but they release a large number of different product lines… too many to have thoroughly debugged Linux support on all of them. The reverse of something like an Optiplex, where millions of people have the same system.
That’s the blunt force trauma approach. You could also try uninstalling what appears to be the conflicting package by trying:
sudo apt remove libgl1-amber-dri
That could also cause breakage too, so it would be best to read carefully before hitting 'Y’es.
There are a couple of tools that might be safer to use, and have some more ‘intelligence’ than apt, Hopefully one or both are either already installed or apt-get will let you install them from the repo. The one with highest likelihood of already being present is aptitude. Try ‘aptitude’ from the command line with the same options you fed apt and see if it can work around the problem. The other program, wajig, is less likely to be pre-installed. If it is, or apt will let you install it, odds are good it can figure out what the issue is. Again, you would feed it the same options that you put after the apt command.
Let me follow with the usual disclaimer: I would strongly suggest doing a full system backup first, unless you’re feeling really brave.
I seem to recall a similar issue. IIRC I was trying to upgrade to a newer version, and I think it failed on some nvidia dependency. Since going AMD and upgrading to F37 there doesn’t appear to be a problem with dependencies. However…AMD’s hardware encoder has been a sore spot for a while, so I don’t know how well OBS will do.
Maybe someone has a clue what was going on there. Look at this:
As you can see they couldn’t install my package because .8 was already in the repos while the package was still built with .7 in mind (why RPM Fusion’s package nails the Qt version is beyond me, I just took it as is). So far so good that makes sense right.
However, at the time of reporting I already had .8 installed on my machine. Strictly speaking the dependency for my package wasn’t satisfied anymore. Which also means DNF shouldn’t even have updated my Qt version in the first place because it would break my package’s dependency, no?
Anyone have an idea what was going on there, i.e. why DNF updated Qt at all?
On a related note: Anyone know how I can keep up to date when a new Qt version is hitting the repos? I know I can check Koji, but that only tells me when new packages are being built, not when they are actually being deployed to the repos. Unless I’m missing something there.
I tried adding use_lvmetad=0 in /etc/lvm/lvm.conf and that still doesn’t allow me to boot after creating a snapshot of my /root LV using this command:
lvcreate -s -n preup -l 100%FREE /dev/voidvg/root
I don’t see event_activation=0 in my lvm.conf, nor in the lvm.conf manpage.
Thanks for the suggestions, this problem is really hurting me since I’m on a rolling release distro and I want to be able to safely do full updates without always needing to take a full backup.
I’m on Void too, but I use ZFS (which is not hard to set up and you can even use the chroot installation method, but with a backup of your current rootfs instead, just to switch the underlying fs - I run full disk encryption and encrypted luks swap, but I never tried doing a root snapshot, but I’d think zfs will just work, I’ll have to give it a shot). Check Chain’s Computar projects thread on the forum and my reply about luks swap.
The bug with lvmetad only affects systemd, because systemd activates whatever file systems it can find. I’d think it’s not a problem on non-systemd oses.
What does your fstab says? Also, did you regenerate the initramfs after the snapshot and update? Curious if it has any impact, but I kinda doubt it. It’s possible that the boot fails because the bootloader doesn’t know which fs to load up, the rotiginal voidvg/root or the snapshot preup, because they both might be sharing the same underlying UUID. Can you take a picture of how your pc behaves when you take a snapshot and reboot?
Every once in a while my whole system starts to lag (mouse movement is choppy, audio loops) for about 1-2s. Happens multiple times a day. I am not sure where to even start troubleshooting something like this.
Checking journalctl doesn’t report anything significant. If anybody could point me to any resources i would be grateful.
I’m running arch, everything is up to date.
