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. 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. 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. Looking into the logs it seems that the behaviour from Plasma is due to some regression / change in Mesa and or the way OpenGL is configured: --8<---------------cut here---------------start------------->8--- plasmashell[2330]: MESA: warning: r300: WARNING: Shader is trying to use derivatives, but the hardware doesn't support it. Expect possible misrendering (it's not a bug, do not report it). plasmashell[2330]: r300 FP: Compiler Error: plasmashell[2330]: Too many constants. Max: 32, Got: 262 plasmashell[2330]: Using a dummy shader instead. plasmashell[2330]: shader compilation failed: plasmashell[2330]: QOpenGLShader::link: error: fragment shader uses too many input components (92 > 40) plasmashell[2330]: QOpenGLShaderProgram::uniformLocation(matrix): shader program is not linked plasmashell[2330]: QOpenGLShaderProgram::uniformLocation(opacity): shader program is not linked plasmashell[2330]: QOpenGLShaderProgram::uniformLocation(lineWidth): shader program is not linked plasmashell[2330]: QOpenGLShaderProgram::uniformLocation(aspect): shader program is not linked plasmashell[2330]: QOpenGLShaderProgram::uniformLocation(smoothing): shader program is not linked --8<---------------cut here---------------end--------------->8--- Firefox curiously complained about some environment override of VDPAU settings. I do indeed have "VDPAU_DRIVER=va_gl" in my environment, although I do not know yet where it comes from. I dimly remember that VDPAU was a problem in the past, but not how and where I resolved it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html