Used “zypper dup” (as always) but it crashed during process. Everything seemed otherwise normal
After I logged out I couldn’t log in.
Updated system from ISO which seemed to go well but still no login
Checked sddm config files - identical to those of another working system.
used passwd - no effect
could only photograph output of journalctl -b -u display.manager (command form memory)
Do you have snapshots? If yes, use the Boot from read-only snapshot, find a working snapshot, and run sudo snapper rollback.
1 Like
Unfortunately not. This system has been running for about 15 yrs and is still on ext4.
Can you boot to init 3, login and do the zypper dup again?
Or init 3 login and open yast alternatives and change SDDM to lightdm and see if you can login in GUI.
If you don’t have lighdm install it via yast.
I used a DVD ISO to upgrade the system which seemed to work except that I got to the same place.
After ctl alt F1, the wired network was up so I tried zypper dup. which made some changes.
However after a reboot, the network wasn’t up.
How did you run the update?
Which packages were suggested for updateing?
Sorry to ask that: but have you ever done a offline upgrade via DVD? Seems not the case…
It’s not obvious to me that this was an offline upgrade. Isn’t it possible to run a “zypper dup” in a chrooted system in openSUSE?
Edit: And to answer your question: I used Arch in the recent years and there it’s not so common to do offline upgrades. One would mainly use arch-chroot and do it online if there is something to repair.
So, yes, I have done offline upgrades, but not in the last let’s say 5 years.
You don’t get a comprehensive overview which packages get updated in the process via DVD. It is not that easy like a “zypper dup” in a terminal where you see all packages that gets upgraded.
If you want to see which packages got upgraded using the DVD you need to search the logfiles of the installation in /var/log/… .
1 Like
The first time I ran zypper dup it crashed mid update. It would not re-run
Subsequently I discovered the sddm problem and also that I had lost the wired connection to the internet
So I did an offline update with a DVD (which found the internet and added a few packages)
It did not occur to me that I would need the logfiles of the DVD upgrade.
I got to the same place with sddm, so I checked the config files, they seemed fine
I ran journalctl after ctl alt F1
I don’t really understand the output (photo) and hoped the problem looked obvious to someone more knowledgeable
I realise one solution would be to archive /home (it’s a two user system, neither login worked) but in the past I have failed to restore the contents of kmail
unfortunately the wired connection no longer works, that’s why I used the DVD to try to fix it via “upgrade” (which ran successfully except that it took me back to a failed sddm.
Did you try a zypper ref && zypper dup from a chroot environment from a live image already?
If you are familiar with setting up chroot and/or tried it already ignore the following instrutions.
chroot changes the apparent root directory so that you are able to do changes on your installed system from the live image environment.
I used the up-to-date live image from here: https://download.opensuse.org/tumbleweed/iso/
Boot the live-image and connect to the internet.
First identify the devices you need to mount, which for me is /, /home, /boot/efi or whatever partitions you are using.
So, open the terminal and get root rights with
su
with
lsblk
you can list your devices. If you don’t know it just like that, the partition size might help you to identify which device is /, /home, /boot/efi, …
Next step is mounting your devices to /mnt, using the correct /dev/devicename
So, for me:
root (/):
mount /dev/sda1 /mnt
/home:
mount /dev/sda2 /mnt/home
/boot/efi (which I installed on an eMMC):
mount /dev/mmcblk0p1 /mnt/boot/efi
You can check if everything is mounted with
ls /mnt
Now proc, sys and dev can be rbind-ed:
for i in proc sys dev; do mount --rbind /$i /mnt/$i ; done
As I experienced that dhcpcd and dhclient didn’t work in the chroot environment you can bind the resolv.conf-path from the live environment to the chroot environment to get DHCP to work:
mount --bind /etc/resolv.conf /mnt/etc/resolv.conf
Now it’s time to switch into the chroot environment:
chroot /mnt
To make sure all partitions are mounted you can run:
mount -a
Now you are in and the internet connection with DHCP should work, so you can run
zypper ref && zypper dup
to update your installed system.
If you didn’t try that yet I hope that can fix your broken system. If there are still issues with sddm you can use the chroot procedure again and reinstall sddm or do other fixes.
Never use only su! Thats an absolute beginner mistake. Mageia has a nice explanation for beginners:
https://wiki.mageia.org/en/Never_use_just_su
Also this is an unecessary doubling of commands as zypper dup automatically refreshes the repos. So you don’t need to do an extra zypper ref. This was also pointed out several times here in the forum…
1 Like
Usually I would agree, but here we are in a live ISO environment, I don’t see any danger. All you could destroy is some temporary config in a live environment and you need to type quite a few commands. For chrooting it’s actually often recommended to log in as root. Also it’s more convenient because one needs to type quite a few commands with root permission.
Thanks for pointing that out. Doesn’t harm either. As I mentioned I was used to pacman (Arch) and therefore didn’t really follow the openSUSE forums.
Are you following me to correct me? It feels a bit strange that you always pop up and correct me whenever I post something.
Don’t get me wrong, I am happy if somebody tells me when I do something wrong. Maybe just coincidence as well…
It is not only about danger. It results in mixed environment which may have unpredictable effects on started programs.
1 Like
True, but all I want to do is chroot. I don’t want to run anything else.
I mean, even here they want to log in as root: How to Chroot in Rescue Mode | Support | SUSE
@404_UsernameNotFound perhaps @hui is just offering a recommendation 
However even in the live environment without the -, the environment is retained for the logged in user, which at times can cause issues, hence in this Forum we do recommend su - more as a prompt for a new user to get into that habit, so to speak. It’s also like sudo, which again in openSUSE is from the default not really configured compared to other distributions, so this may also require checking/adjustment for the end user…
1 Like
Yes, in general I totally agree. I just find it in that particular case more convenient. sudo should of course also work.
It is not meant as offense. But if i see that a beginner gives wrong or dangerous advices to other beginners i feel an urgent need to give a “better” advise. Because the experienced users here need to clean up the mess that is caused by wrong advices.
3 Likes
Yeah, no worries. I didn’t take it as an offense.
1 Like