On Tue, Mar 19, 2024 at 2:26 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On Mon, Mar 18, 2024 at 6:13 PM Darryl Gregorash <...> wrote: On 2024-03-18 07:12, Carlos E. R. wrote: > On 2024-03-18 13:49, Roger Oberholtzer wrote: >> >> after that. If I wasn't booted into it perhaps? Like boot from a USB >> stick and then try the rollback on this filesystem? I suspect I'm just >> demonstrating my ignorance about that it the reason for the
On 2024-03-19 10:13, Roger Oberholtzer wrote: problem.
> > You are just demonstrating one of my reasons for not using btrfs
:-)
> Btrfs has nothing to do with this, except perhaps that Roger would
not
have got into this mess if he didn't have snapshots available.
Of course, he could also have avoided it by first learning how to properly do a rollback.
I did the rollback correctly. Or at least it did not complain. I have done this before when a zypper dup went astray. But when I rebooted, I still had odd stuff from the failed zypper dup. That I do not understand. I have never seen that before.
Ah, the kde6 zypper dup.
I heard that the desktop could crash during the procedure, halting the zypper process in its tracks and leaving a botched upgrade.
Exactly what happened. And that is how I interpreted what had happened. But it seems that what really happened was that the desktop service was restarted. And the KDE6 stuff was not complete. So one sat with a sddm that had complaints and would not let one log in. So I figured, do a rollback as it was an unsuccessful update. If I had instead popped to a virtual terminal and restarted the zypper dup, it would have finished and I would instead be asking about odd KDE6 quirks. The recommendation, a really old one that people has forgotten, is to
run "zypper dup" in one of the virtual text consoles, not in graphic mode.
Exactly. -- Roger Oberholtzer