I’m on Fedora atomic KDE, to give a bit of context: I layered virt-manager native packages for a certain use-case and now having failed to achieve its purpose I intend on returning to a clean state pre-layering so to speak. I did try to rollback into an older commit yet it still appears to have the layer packages. And as I am tech illiterate par excellence I consulted LLM to guide me since people are otherwise not readily available for immediate guidance, it suggested that I rpm-ostree reset which happened to not only remove the layered packages but also the local packages (my VPN that is not available on flathub). The commit that got reduced to a sorry matter is index 0, thankful to God himself that index 1 was not affected. However, my problem is that the system does not automatically boot into index 1, and as it is a rollback version, I cannot update it, hence I cannot rely on using it long-term.
Incidentally, I might need to help with the rollback function automatically creating a duplicate deployment of index 0’s version right after a rollback/reset (as I just experienced this with the rpm-ostree reset command, sans copying the reset state itself). Currently my system does not automatically boot from index 1, and I need to make it do that. Rollbacking from index 0 might not work, because recently I had an unlayered commit that I could rollback to, but since I wanted to make it the default, Perplexity’s call was that I boot from the layered package (index 0) and rpm-ostree rollback , which to my astonishment made index 1 another layered version. Oddly though it seems I cannot uninstall the layered packages either. I suspect somehow that there’s a mismatch between the info shown from rpm-ostree status and the state of things as they are.
In short, if my intuition is on the mark, it appears that index 1 does not have virt-manager layered packages, since I cannot uninstall them, nor do I even see libvirt when I run groups, which I’ve had to add as part of my virt-manager setup. Only issue I thus have is that my default deployment that I got gaslit to reset by the AI removed my Mullvad VPN (and potentially also my own hardening configurations but I might be wrong). So I wish to (1) make index 1 my default, to possibly make the system create rollbacks based off of it; (2) to be able to update it normally; and (3) if possible to remove the default altogether or overwrite it with the next rollback that is created based on the index 1 image.
If most of this or none of it is possible then I’d like to be guided on what to do in this situation, because I don’t wish to manually select the deployment to boot from on the GRUB menu everytime I turn my computer on.
Let me know if you require more details or clarifications!
It looks like your current deployment at index 1 is pinned, so it shouldn’t be affected by upgrades and you should be able to rollback to it at any time.
rpm-ostree only keeps one rollback version available by default, so the deployment currently indexed as 0 will eventually be cleaned up during upgrades. There is also an option to manually clean up deployments that you don’t want to keep for some reason.
So, if I understand you correctly, you want to keep the deployment you are currently booted into and uninstall only the layered packages related to virtualization.
It looks like your current deployment at index 1 is pinned, so it shouldn’t be affected by upgrades and you should be able to rollback to it at any time.
Point is, I only want this deployment to be upgraded. So far I couldn’t upgrade it at all.
rpm-ostree only keeps one rollback version available by default, so the deployment currently indexed as 0 will eventually be cleaned up during upgrades. There is also an option to manually clean up deployments that you don’t want to keep for some reason.
I’m currently only using index 1, as I ran rpm-ostree reset on my default deployment and it removed my VPN. I don’t get what you mean when you say that the deployment currently indexed as 0 will eventually be “cleaned up” during upgrades. Cleaned up as in overwritten by another? By upgrade I understand that you mean when my deployment indexed as 1 receive an upgrade it will clean up the deployment indexed as 0? I’d like for you to delineate what you mean.
So, if I understand you correctly, you want to keep the deployment you are currently booted into and uninstall only the layered packages related to virtualization.
That is correct. But as I mentioned, I want to it to also be my default deployment.
If you reboot the machine and do not manually select the deployment with layered virtualization packages (should be the second one) in the GRUB boot menu, it should boot into the reseted deployment (the one without layered virtualization packages).
I’m not entirely sure I understand this completely, but if you then run rpm-ostree rollback and reboot, the order of deployments in the GRUB boot menu should effectively be reversed.
If you reboot the machine and do not manually select the deployment with layered virtualization packages (should be the second one) in the GRUB boot menu, it should boot into the reseted deployment (the one without layered virtualization packages).
What to do on the default deployment afterwards?
I’m not entirely sure I understand this completely, but if you then run rpm-ostree rollback and reboot, the order of deployments in the GRUB boot menu should effectively be reversed.
I do not either. It basically copied the default to the second deployment at least according to the status; before the rollback, rpm-ostree status showed the deployment to have no layered packages, and now it shows that it is layered. Even if everything else indicates the opposite, namely running groups showing only user & wheel, no libvirt, and uninstalling any of the layered packages outputs error: Package/capability '<insert package>' is not currently requested. I want to try rolling back from the default but I fear that it will overwrite index 1 with the default deployment.
Ok so, I was able to rollback, now it boots from it by default. My only remaining concern is that I want to ascertain whether the layered packages are still there or not. rpm-ostree status shows that they are. Curious to know why.
Assuming from your previous posts that you want to check if virtualization related packages are indeed installed, you can try the command rpm --query --all | grep virt. It will search for the string “virt” in all installed packages and will probably show more than those from the output of the rpm-ostree status command, but it should display them in case they are actually installed.
Uninstalling/removing layered packages is done with rpm-ostree uninstall <package-a> <package-b> <...package-x>, where etc are the package names as shown in the LayeredPackages section of the rpm-ostree status command.
The command should create a new deployment, keeping only the layered packages that weren’t explicitly uninstalled, as well as the installed layered/local VPN package (as long as it wasn’t specifically uninstalled by the command mentioned above).
Thanks. One last thing I’m having trouble with my Mullvad VPN being layered as well. It used to be a localpackage but I reinstalled it again from the CLI and it got defined as a layered package (not that it was different before as a localpackage, but just to give you a bit of context for the changes I made). The inconvience with having to uninstall and reinstall to update the app is bothersome, and as a flatpak user, I want to be able to install it as flatpak and get it updated like with every other app I use.
Did you set up mullvad repository on your system? In that case it might be a layered package indeed (as opposed to a local package). I am not familiar if there are any quirks with this package in particular (given there is also a systext option as provided by @hricky), but generally, if a package is layered from a maintained repository on top of the base image, it would make it automatically update with every new OSTree upgrade, so you should be fine with no manual reinstall needed.
If you’d like to be sure, please share the output of rpm-ostree status -v and ls -l /etc/yum.repos.d/.
In that case it might be a layered package indeed (as opposed to a local package).
Makes sense.
if a package is layered from a maintained repository on top of the base image, it would make it automatically update with every new OSTree upgrade
I see. Curious though, is having it on top of the base image affect one’s privacy in any way under a high threat model…?
This is the output for the second command. Incidentally, I noticed a google chrome repo? What is that? Never installed anything google or google-related, which is strange.
-rw-r--r--. 1 root root 376 Jun 27 16:12 _copr:copr.fedorainfracloud.org:phracek:PyCharm.repo
-rw-r--r--. 1 root root 1102 Jun 27 16:12 fedora-cisco-openh264.repo
-rw-r--r--. 1 root root 1239 Jun 27 16:12 fedora.repo
-rw-r--r--. 1 root root 986 Jun 27 16:12 fedora-updates-archive.repo
-rw-r--r--. 1 root root 1286 Jun 27 16:12 fedora-updates.repo
-rw-r--r--. 1 root root 1344 Jun 27 16:12 fedora-updates-testing.repo
-rw-r--r--. 1 root root 199 Jun 27 16:12 google-chrome.repo
-rw-r--r--. 1 root root 186 Jun 27 15:57 mullvad.repo
-rw-r--r--. 1 root root 1487 Jun 27 16:12 rpmfusion-nonfree-nvidia-driver.repo
-rw-r--r--. 1 root root 1391 Jun 27 16:12 rpmfusion-nonfree-steam.repo```
I’d say there is no difference between a layered package and a package in the base image, from a privacy point of view. So it boils down to the level of trust you’re having in the package, the maintainer and the repository.
It’s fine. The Google Chrome repo gets enabled at initial setup, along with the two RPM-Fusion repos from your list, if the user chooses to enable third party repositories.
!