On 2022-09-11 10:27, Achim Gratz wrote:
Achim Gratz writes:
Now I'd really like a way of running zypper from the install DVD image targeted at the inactive system root, but it seems zypper is not available there.
I ended up putting the snapshot DVD on a new USB stick and doing an "Update" from there. It hit two more stops because some assumptions about how the file system should look were no longer true, but these could be ignored and the install finished after a few hours.
The next reboot ended up at the rescue prompt because no default target had been set up. Fixing that and booting into graphical target triggered extremely high and prolonged disk activity that didn't really subside. It turns out more systemd units were set up wrongly, network and sshd were not starting correctly and syslog-ng was conflicting with journald.
syslog-ng seems to be a leftover from long ago. I think you should have syslog instead. Telcontar:~ # systemctl status syslog-ng.service Unit syslog-ng.service could not be found. Telcontar:~ # locate syslog-ng.service Telcontar:~ # Telcontar:~ # systemctl status syslog ● rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2022-09-09 18:21:21 CEST; 1 day 17h ago TriggeredBy: ● syslog.socket Docs: man:rsyslogd(8) http://www.rsyslog.com/doc/ Process: 2302 ExecStartPre=/usr/sbin/rsyslog-service-prepare (code=exited, status=0/SUCCESS) Process: 11327 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 2350 (rsyslogd) Tasks: 6 (limit: 4915) CGroup: /system.slice/rsyslog.service └─2350 /usr/sbin/rsyslogd -n -iNONE ...
It was also immediately clear that there was a problem with the RV350 graphics card in that system, since the login screen from sddm did not appear until a bit of switching back and forth between VT1 and VT7, then I've had to stop.
I took to the system again yesterday, and Tumbleweed presented me with another full update of roughly 7500 packages, which consumed most of the day.
Maybe during the DVD upgrade the network repositories were not enabled?
When I was finally logging into my KDE/Plasma/X11 desktop plasmashell slowly exhausted the memory and then also the swap and wedged the system pretty hard. I've let it continue overnight to see if it would finish whatever it was trying to do, but no dice (except thoroughly stressing the HD of course, which did survive). After the hard reset and reboot I switched off swap and logged into the KDE session again. Plasmashell again started to consume memory at a relatively slow, but constant rate, so I eventually killed it when it hit max. memory. While I did lose the desktop features, the window manager kept running and the memory consumption was back to its previous (before the update) value of ~1.2GiB, I could even start Firefox.
Disabling swap in this status is not correct. The idea is that when memory runs away and hits swap you have time to kill some process. Without swap the time limit is shorter, and the kernel may kill processes on its own, not necessarily choosing the correct one. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)