I have a running Leap 16 beta running the MATE desktop in a VirtualBox virtual machine.
I have attempted to update today with no GUI.
I have put back the same virtual machine and did the following steps.
zypper ref
zypper up -y
reboot
I have a log of all the updates but no clue as to why no gui.
network pings
I even tried uninstalling VirtualBox guest additions - no change.
and I get a login prompt
I login as root and do init 5 but no gui
As Leap 16.0 is still not released, as far as I know there will be no updates, but new test versions will made available. And those are to be installed by upgrading: zypper dup.
In the Factory mail list it was asked - they said to use zypper up for Leap 16 updates not zypper dup.
I will try it with a dup but I doubt that will make any difference.
OK, that is not intuitive for me, but when âtheyâ say it themselves âŚ
I just updated (in a VM).
I still have a GUI. KDE, Gnome and Icewm all work as expected. I do not have MATE installed, so I cannot test that.
Before the update, I was using GDM as display manager. Now I find that I am using SDDM, and Gnome complains about that.
That is correct. It can be confusing âwhatâ to do during a pre release.
While in Alpha or Beta stages, do zypper up.
If youâre on Alpha, and Beta is released, then do a zypper dup, because youâre doing a dist upgrade, as if youâre moving up from 15.5 to 15.6.
Keep a watch on ânewsâ updates.
Hmmmm! Concerned.
I thought I would check my current Leap 16 Beta install , with a âzypper upâ:
2,066 packages to upgrade. (is there a move up from Beta?).
@larryr ⌠for your zypper up, how many packages did it upgrade?
It update 1852 packages. I do not have XFCE, gnome, or KDE installed only MATE.
I believe the problem is that MATE requires X11 and apparently X11 is not valid in the latest Beta update. I think only wayland is available now.
I do have the alt-f1 console to get to Linux with but no gui.
FYI, the zypper dup did the same thing.
For those that do not know - MATE is basically a gnome 2 fork. It looks and feels just like gnome 2.
This is from the zypper dup log file.
The following 10 packages are going to be REMOVED:
libamd2 libcamd2 libccolamd2 libcholmod3 libcolamd2 libmpdec3
libsuitesparseconfig5 libtag1 libumfpack5 xorg-x11-fonts-converted
The following package requires a system reboot:
kernel-default-6.12.0-160000.18.2
1852 packages to upgrade, 33 new, 10 to remove, 1 to change arch.
This is news to me. IME, zypper dup is the only reliable way to up-anything any Leap pre-release, and Iâve been doing pre-releases since long before Leap 42.1, and since before openSUSE 11.4, probably back to around when zypper was first unleashed, 10.2 perhaps, many many moons ago.
I just did one of my 6 16.0pres, one which has none of XFCE, Gnome, KDE or Mate: 667 transactions via zypper dup. X did not start automatically, but cause and solution were quickly determined:
# alias | grep luf
alias scluf='systemctl list-unit-files | sort | grep -E '
# scluf dm
dm-event.service static -
dm-event.socket enabled enabled
initrd-udevadm-cleanup-db.service static -
mdadm-grow-continue@.service static -
mdadm-last-resort@.service static -
mdadm-last-resort@.timer static -
mdmon@.service static -
mdmonitor-oneshot.service static -
mdmonitor-oneshot.timer disabled enabled
mdmonitor.service static -
nfs-idmapd.service static -
xdm.service bad disabled
# scluf lega
display-manager-legacy.service disabled disabled
# systemctl enable display-manager-legacy.service
Created symlink '/etc/systemd/system/display-manager.service' â '/usr/lib/systemd/system/display-manager-legacy.service'.
# systemctl start display-manager-legacy.service
# inxi -GSxxz --vs --za --hostname
inxi 3.3.38-00 (2025-04-06)
System:
Host: ga88x Kernel: 6.12.0-160000.18-default arch: x86_64 bits: 64
compiler: gcc v: 13.4.0
Desktop: TDE (Trinity) v: R14.1.4 tk: Qt v: 3.5.0 wm: Twin dm: 1: TDM
2: XDM Distro: openSUSE Leap 16.0 Beta
Graphics:
Device-1: Advanced Micro Devices [AMD/ATI] Kaveri [Radeon R7 Graphics]
vendor: Gigabyte driver: amdgpu v: kernel arch: GCN-2 ports:
active: DVI-D-1,HDMI-A-1 empty: VGA-1 bus-ID: 00:01.0 chip-ID: 1002:130f
Display: x11 server: X.Org v: 21.1.15 compositor: Twin v: 3.0 driver: X:
loaded: modesetting dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x2250 s-dpi: 120
Monitor-1: DVI-D-1 pos: top model: Dell P2213 res: 1680x1050 hz: 60
dpi: 90 diag: 558mm (22")
Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: primary,bottom model: NEC EA243WM
res: 1920x1200 hz: 60 dpi: 94 diag: 612mm (24.1")
API: EGL v: 1.5 platforms: device: 0 drv: radeonsi device: 1 drv: swrast
gbm: drv: radeonsi surfaceless: drv: radeonsi x11: drv: radeonsi
inactive: wayland
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.3.3 glx-v: 1.4
direct-render: yes renderer: AMD Radeon R7 Graphics (radeonsi kaveri LLVM
19.1.7 DRM 3.61 6.12.0-160000.18-default) device-ID: 1002:130f
API: Vulkan v: 1.4.309 surfaces: xcb,xlib device: 0 type: integrated-gpu
driver: mesa radv device-ID: 1002:130f device: 1 type: cpu
driver: mesa llvmpipe device-ID: 10005:0000
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo x11: xdriinfo,
xdpyinfo, xprop, xrandr
#
X11 is running. 
Yes, that fixed it.
Thank you mrmazda.
systemctl enable display-manager-legacy.service
systemctl start display-manager-legacy.service
What a very odd occurrence for this big update today.
Yes, "zypper up"showed 2066 updates ⌠when I answered Yes, it immediately crashed with an error ⌠Iâll get the error tomorrow, as Iâve shut down that VM.
Anyway, so I thought Iâll try Myrlyn to do the Update (I clicked Update, NOT Dup) ⌠what can I lose - zypper failed, so the worse that will happen is Myrlyn will fail too.
It did NOT !! It updated the 2066 packages with ZERO errors.
After the update, I rebooted the VM and it started up with no issues ⌠KDE Plasma /X11 works as expected. 
Iâm shocked Myrlyn performed the update, but zypper failed.
@aggie did you use -vvv in the dup command? If so only use -v itâs a preload bugâŚ
yes, I actually use â-vvvvâ (yea, four), as Iâve always used 
Odd itâs a bug, considering how long Iâve used it
But I will check the error text in the morning.(I saved in a text file).
@aggie it will be a boost error 
Hit this or a similar problem in Leap 16 zypper dup with 19xx packages to upgrade . . . which went through OK. I rebooted to TW to update-bootloader and shut down. On cold boot it went to a TTY . . . logged into it and tried to run another zypper and the repo errored out on the GPG key?? âWe expected xxxxx but we found âbb69â . . . if you think bb69 is OK, enter the first 4 numbers.â
I did that for two lines (two repos enabed) and that brought red font errors!!! I tried to just run zypper dup and I got a âthis could damage your systemâ . . . .
I rebooted out of it. But I have had this issue before of âno GUIâ . . . but here it seemed like the repos were erroring out on the âkeyâ . . . . But likely it is a display manager problem. Have to check that in a bit.
Yes. That also worked for me to get back into the GUI.
I tried to --config display-manager . . . it was showing âlightdmâ I âpickedâ that and rebooted, to no change. Then I tried to zypper in sddm . . . but because of the repo error it said, âpackage not found.â So I changed to the only other option, âxdmâ . . . again on reboot, nada.
Ran mrmazdaâs systemctl commands and the GUI log in loaded, looks like it might be âxdmâ . . . simple. But, typing this in Leap 16 GUI.
It seems like there is or still will be some repo error, possibly relating to the GPG key . . . there was some serious âerrorâ being reported . . . again, after this large upgrade had gone through, w/o error reported.
Yes, it was a âboost::bad_any_castâ error.
But something interesting happened today, after that big 2,066 package update yesterday.
Today I did my instinctive âzypper up -vvvvâ and guess what?
There was four packages to Update and I tapped âYâ(es) and zypper updated, with no âboostâ error.
So I assume the boost fix was included in the 2,066 Update. Or I lucked out
And again, no KDE gui display issues here - all running fine.
@aggie I believe the fix has made itâŚ
The old way of controlling which DM is now deprecated:
update-alternatives --config default-displaymanager
What actually happened using the old method is xdm.service was used either to launch itself directly, or to launch the DM configured via update-alternatives. TW made a switch some time back to using systemd directly, but only for those DMs which have direct systemd configuration enabled, which AFAIK so far have only been GDM, SDDM and XDM itself.
Now, 16.0pre is being/has been switched to doing the same. For the DMs that arenât yet supported by loading directly via systemd, display-manager-legacy.service was created for systemd to service the rest. I suppose for XFCE users with LightDM, the transition is yet to be perfected (if even begun). So regards this thread, display-manager-legacy.service didnât get enabled when the old xdm.service was disabled on the instant installations, thus leaving no DM being enabled or started until having run the commands to enable and to start DMs other than GDM, SDDM & XDM.
Typed all above >2 hours ago, but before sending, phone rang, then I forgot about it. 