On Tue, Mar 19, 2024 at 2:26 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2024-03-19 10:13, Roger Oberholtzer 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 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