Can't upgrade system after last system upgrade

English Install/Boot/Login
1 
redshift -O 2000:2000 && su
Invalid MIT-MAGIC-COOKIE-1 keyUsing method `randr'.
Password:
# LANG=C zypper dup 
System management is locked by the application with pid 949 (/usr/bin/zypper).
Close this application before trying again.

Any solution please ?

journalctl -r
Apr 04 09:05:08 localhost.localdomain at-spi2-registr[2553]: Could not open X display
Apr 04 09:05:08 localhost.localdomain at-spi-bus-launcher[2553]: Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
Apr 04 09:05:08 localhost.localdomain at-spi-bus-launcher[2476]: dbus-daemon[2476]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=2286 comm="xfce4-terminal ")
Apr 04 09:05:08 localhost.localdomain at-spi2-registr[2551]: AT-SPI: Cannot open default display
Apr 04 09:05:08 localhost.localdomain at-spi-bus-launcher[2551]: Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
Apr 04 09:05:08 localhost.localdomain at-spi-bus-launcher[2551]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Apr 04 09:05:08 localhost.localdomain at-spi-bus-launcher[2476]: dbus-daemon[2476]: Successfully activated service 'org.a11y.atspi.Registry'
Apr 04 09:05:08 localhost.localdomain at-spi2-registr[2551]: Could not open X display
Apr 04 09:05:08 localhost.localdomain at-spi-bus-launcher[2551]: Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
Apr 04 09:05:08 localhost.localdomain at-spi-bus-launcher[2476]: dbus-daemon[2476]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=2286 comm="xfce4-terminal ")
2 
# LANG=C zypper dup
System management is locked by the application with pid 949 (/usr/bin/zypper).
Close this application before trying again.

This message is saying zypper is already running, either wait until it is done or follow the advice on the last line.

3

I didn’t started the first zypper, could it be started by system ?

4

It maybe a running zypper, a running YaST > Software Management, or even the update applet from your desktop.

Or one of those may have been killed unexpectedly (leaving the lock behind).

And when you mean with “could it have started by the system”, “could I have configured some automated running of it”, yes, you could have done that (but you should of course remember that).

And as suggested already above, inspect, and eventualy close/kill the process mentioned.

5

On the first boot after a new kernel install, it does “zypper -n purge-kernels”.

Because purge-kernels was broken for a while, you might have quite a few kernels to purge. So that could take a while.

6

I didn’t configure anything.

7

Thank you, it seems to be the most probably reason.