I followed the STUPIDEST advice EVER and ran `sudo zypper rm libxcb1" and it went halfway through before I realized it was litterally uninstalling everything on my system
And, my snapshot are all also brokenā¦??? Dolphin, all browsers and pretty much one thing out of two is gone, I can no longer even browse my files nor the webā¦
But whatās the use of snapshots if later snapshots can break earlier snapshots???
Please if someone has any idea at all how to revert/fix thisā¦ Iām crying blood right now
I did. I pretty much copied the advertised partitioning. You are definitly understanding this message differently than me. Please explain what it means both basically and in my specific situation. You can ask (nicely please) for any clarification, Iām no expert I donāt know what info you need me to give you.
zypper presents you with what it will do BEFORE executing itā¦ which is why you have to answer yes no (etc).
When ācleaning upā using zypper, I always use āādry-runā to see what the results will be, without committing ā¦ a suggestion for future use
For example, did this recently, cleaning up excessive python versions:
zypper rm --dry-run python38
For fun, I ran your command as
zypper rm --dry-run libxcb1
HOLY SMOKE !!:
The following 805 packages are going to be REMOVED:
... blah blah ...
.
805 packages to remove.
After the operation, 3.6 GiB will be freed.
Continue? [y/n/v/...? shows all options] (y): n
What information do you have that indicates that your snapshots are broken?
With a default configuration, that shouldnāt happen. What is the output of snapper list on the broken system, and what snapshot in the list did you attempt to restore to?
Because, as I said, yes thatās exactly what I did. It turned out that every snapshot (no matter from how long ago) was corrupted. Thatās what I tried to explain.
Save your time, though, I managed to restore almost everything with a combination of zypper -t pattern minimal/kde/kde_plasma and history |grep zypper/snap/flatpak > reinstall_script.sh. It turned out it was mostly basic packages from the KDE patterns that had been deleted, most zypper commands from history returned ānothing to doā. I had to recreate a few systemctl services and the like though.
What Iām trying to understand is how you determined it was corrupted.
I actually did what you did in a virtual machine to test - Iād never actually done a recovery before, so the test seemed like something useful to try anyways.
Iām running GNOME in my VM rather than KDE (I have VMs installed for a number of distros) - it sounds like what you did was where I would have gone next - getting the patterns for the installation and reinstalling based on that after rolling back to the best possible snapshot.
From a snapshot recovery perspective, even if some things were missing (which they shouldnāt be - snapshots are insulated from each other, but not from tampering by the root user as I understand it); that sounds like a bug and something that should be reported through bugzilla for investigation.
One of the things that I ran into in my test is that the zypper rm process caused X to die, which halted the removal - I think I had 616 packages total to be removed, and it only got about 480 of them - so a reinstall of at least the patterns should recover most of what was deleted - excepting anything installed outside of the installation process - but it sounds like youāve managed to get most of the way recovered, which is great.
This warning is not saying that anything has been corrupted - just that if you changed the btrfs subvolume configuration for the root partition (which, if you went with defaults and didnāt change it, you should have been able to roll back the configuration).
What this means is that unless you made changes to the subvolume layout during installation, rollback isnāt supported (and it may not work as designed).
In the first place, why where you trying to remove that package? Where you trying to follow a procedure for development? Most of that stuff is outdated and you find people breaking their systems because of outdated documentation.
Tip: Clone your os to an external drive next time to babyproof your problems in case anything goes wrong
Really impressive! You may always specify --dry-run and rethink.
erlangen:~ # zypper --non-interactive remove --dry-run libxcb1
Reading installed packages...
Resolving package dependencies...
The following 1148 packages are going to be REMOVED:
GraphicsMagick ImageMagick Mesa
...
The following 6 patterns are going to be REMOVED:
games kde kde_plasma kde_yast x11 x11_enhanced
1148 packages to remove.
After the operation, 4.6 GiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
erlangen:~ #
Yes Iām becoming more and more aware of thatā¦ I was trying to solve errors I describe in this post (you guessed it, a display problem involving xcb).
But it seems to me that the āgood all platformsā ā the Stack-Everthing ā are less and less responsiveā¦ Thatās too bad it was usually quality advice
@karlmistelberger obviously. I had to make that mistake once though, for it to stick, I guess.
From Unix Stack Exchange, probably an old postā¦ No warning whatsoever on the potential danger of the command
Yes I do think Iāll think of that next time! I did manage to restore most things, but not thanks to a rollback, see my reply to @arvidjaar above for how I did
