Upgrade from 42.3 to 15.0 is stalled because of KDE screenlock problem

It seems to never fail. Never can I get a clean upgrade without running into some type of problem. During the installation process of upgrading from 42.3 to 15.0 I got a screen telling me about a broken screen locker and giving instructions for unlocking. However when I go to a virtual terminal to put in the given command (loginctl unlock-sessions) the virtual terminal will not accept the password. Can someone tell me what might be happening and where to go from here?

I am somewhere half way between the upgrade and hoping the system is not broken.

I see in some forum entries where similar problems have risen but under slightly different circumstances and they don’t seem to address the problem i am having with the upgrade.

Thanks for any help.

I am not quite understanding what your situation is. You say you are upgrading from 42.3 to 15.0, but as there are several ways to do this and you do not mention which one, you let us guess (and that often is a source of misunderstanding and thus of possibly the wrong advice given).

Also explaining about where you are during the installation process (better then “somewhere halfway”) might be helpful. We realy can not look over your shoulder to see what you have done and where you are.

Also as far as I see it, there is no DE running during system installation/upgrade, thus why is KDE doing things?

If you’re not going to sit on your upgrade every second,
Disable your screenlocker before you upgrade.

If you think your upgrade failed in the middle of an upgrade, then after you disable your screenlocker run the upgrade again.

TsU

I started the upgrade using zypper. (I used the command zypper dup --download-in-advance) During the installation process I get a message telling me about the screen lock problem and supposedly how to unlock it using a virtual terminal. The virtual terminal is not working. I have no control over the process now because I cannot get a working terminal. When it boots it boots into 42.3 but the screen that appears, and, where it is stuck is a KDE screen from 15.0

Does this information help?

Can you tell me how to get control of my machine as I cannot reach a terminal.

Sorry, but I am still trying to see before my mental eye what you did. Just starting zypper dup (from the console or treminal in a GUI?) in your 42.3 does not do much useful (when your 42.3 is up-to-date).

When you intention is to use the upgrade method of changing the repos to those of the new version, then you first have to change the URLs of the repos to those of the new version and also disable all non-standard repos (at least for the time being) before you do a zypper dup (at best from run level 1). All these actions are missing from your description above.

I first ran the command " sed-i’s/42.3/15.0/'/etc/zypp/repos.d/* " and then “zypper refresh”

Ok, we are now getting somewhere.
It took me some time to remove the gaudy colors and to add some spaces (what you post is realy not how you can use that command).

You did (I assume)

sed -i 's/42.3/15.0/' /etc/zypp/repos.d/* 
zypper refresh
zypper dup

But I get the idea that you did that from a terminal emulator in a GUI. That is dangerous, because you are replacing all software, thus it is best to have the minimum of software in use. And that is certainly not while using a GUI.

You should do this at the minimum from the console (e.g. Ctrl-Alt-F1 with all GUI users loged out, but better in run level 1.

And my idea is that to repair, it is the best to boot into run level 1 and then do the

zypper dup

again.

Yes,
Since you are rebooting into your system,
If you switch into runlevel 1 first then your graphics environment should be disabled so you can continue your upgrade without any concern for graphics issues like a screenlocker.

If on the other hand you run your upgrade within a windowed console,
Then you should first disable your screenlocker in your KDE configuration.
And, there are other glitches that can happen when upgrading in a windowed console, so although it’s usually successful is not recommended.

The following is a nice, easy to read article how to change runlevels using systemd commands

https://www.tecmint.com/change-runlevels-targets-in-systemd/

The command to change to runlevel 1 is

systemctl isolate rescue.target 

TSU