Discussion thread for 42.2 Release Candidate 2 (RC2)

Leap 42.2 Release Candidate 2 (RC2) was released today: <https://news.opensuse.org/2016/11/02/last-release-candidate-for-opensuse-leap-42-2-released/>.

This thread is for discussion.
[HR][/HR]13.2 and Leap 42.1 running on 64-bit AMD 4-Core CPUs with AMD Graphics
Leap 42.2 running in Oracle VirtualBox VMs

Ran ‘zypper dup’ on the installed RC1 with Plasma5

  • there seems to be some improvement in booting, but I could be wrong
  • fired up dolphin, firefox, systemsettings.
    First impression: getting there.

Still installing. The install seems to be going well. It’s currently installing packages. I’ll post back when I have more to say.

The install went well. First boot went well.

I logged into KDE. And that looked fine. But I am using
LIBGL_ALWAYS_SOFTWARE=1
in the environment (set by shell startup file). So I removed that, to see if nouveau graphics now work.

The result - a crash of plasma-shell. So I added back that environment setting, and all looks good.

I ran zypper dup from rc1. seems works fine. I think it consumes less RAM than RC1(about 400MB with default applications and without running any program)

about a week ago, when I installed RC1 on a virtual machine for the first time, I found that there is a bug in application menu. I thought that someone already founded that and they will fix it in RC2 because it’s clearly visible. but it still exist in RC2.

watch the video:


https://www.youtube.com/watch?v=ma7GIGTUZks&feature=youtu.be

tried to reproduce this bug several times on both virtual machine and real hardware, and always I could reproduce it.

hope someone can check it and report that.

I’m now at RC2 on three systems. One uses nvidia graphics, and the other two have Intel graphics.

As mentioned in an earlier post in this thread, Plasma 5 still does not like nouveau.

Apart from that, all seems to be well.

For the install, I downloaded the DVD installer, and wrote that to a USB. My first install was from that USB.

For the other two, I just updated RC1. Before updating, I plugged in that USB (same device as I had used for RC1), and I enabled that as a repo. I then ran “zypper dup”. Most of the packages were updated from the USB.

One problem that I noticed for RC1, was that “Beta” showed up on some of the installer screens. That problem seems to have been fixed.

It has been reported already:
https://bugs.kde.org/show_bug.cgi?id=368473

But yes, I’ve seen that too.

Did a German language Network Install from a CD-ROM .iso into an Oracle VirtualBox VM – also saw some quite long delays when starting/initialising the installation – don’t know if was the Network Installation or something else.

Installation went OK – no issues with the German language text – deleting the existing default Leap 42.2 RC1 partitions and creating new default Leap 42.2 RC2 partitions went perfectly OK and the rest of the installation executed quite fast (50 Mbit/s DSL).

Some issues with KDE Plasma 5 Kontact “freezing” while setting up – I didn’t wait for Btrfs to initialise – will reinstall and check if Btrfs is taking lots of CPU shortly after the initial installation reboots for the 1st time.

Once Kontact was up and running, KMail initialised OK and was able to send and receive test e-Mail.

Akregator went off and found the usual hundreds of unread News items – didn’t inspect closely – only noticed the indication in the System Tray.

You could uninstall Mesa-dri-nouveau instead of setting “LIBGL_ALWAYS_SOFTWARE=1”, would have the same effect…

The network ISO downloads the whole installer from the Internet, that does cause quite some delay before the actual installation starts up.

Thanks. I’ve thought about doing that. I did notice the agreement accepting that package said that it would be done is software if I don’t install.

Yes, it was decided to do it this way (split out nouveau’s OpenGL support into a separate package and showing a warning when it is being installed) because it causes heavy problems on (some) nvidia cards, and disabling it completely would have negative impact on systems where it would work.

We did add patches to QtWebEngine (to use software rendering when nouveau is in use) and kwin (to detect freezes and disable OpenGL in that case) which should highly improbe things, but it wasn’t possible to fix all problems.

I have had no crash problems since I started to use nvidia drivers (“hard way”) with leap 42.1, tumbleweed and now 42.2. The latest driver 367.57 also works with kernel 4.8 without patching.

  • mandb

  • Btrfs

“Clean, new, default” German language install into an Oracle VirtualBox; after the installation completed and the 1st boot was executed, I opened two Terminal Emulator windows, started “top” in one and periodically executed “uptime” in the other; and apart from that, simply waited . . .

  • At about 9 minutes after the boot, a “mandb” process began running with about 41% CPU, sometimes 46% CPU.
  • At about 10 minutes after the boot, a “gzip” process began running with 100% CPU usage.
  • At about 11 minutes after the boot, a “btrfs” process began running, also with 100% CPU usage. After about 40 seconds, about 7 “kworker” processes began running with a total of 70% CPU usage.
  • At about 12 minutes after the boot everything quietened down.

The Btrfs entries in the system log at around 10 or 12 minutes after the 1st boot look like this:


Nov 02 18:46:02 linux-182i dbus[954]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Nov 02 18:46:02 linux-182i dbus[954]: [system] Successfully activated service 'org.opensuse.Snapper'
Nov 02 18:46:07 linux-182i kernel: BTRFS info (device sda2): qgroup scan completed (inconsistency flag cleared)
Nov 02 18:46:09 linux-182i kernel: BTRFS info (device sda2): relocating block group 20971520 flags 34
Nov 02 18:46:09 linux-182i kernel: BTRFS info (device sda2): relocating block group 6471811072 flags 34
Nov 02 18:46:09 linux-182i kernel: BTRFS info (device sda2): relocating block group 6505365504 flags 34
Nov 02 18:46:09 linux-182i kernel: BTRFS info (device sda2): relocating block group 6538919936 flags 34
Nov 02 18:46:10 linux-182i kernel: BTRFS info (device sda2): relocating block group 6572474368 flags 34
Nov 02 18:46:10 linux-182i kernel: BTRFS info (device sda2): relocating block group 29360128 flags 36
Nov 02 18:46:31 linux-182i kernel: BTRFS info (device sda2): found 13106 extents

Bug report will be raised tomorrow.

Performed a clean install, with default settings, from Network iso. Everything went well.
Only one package failed (k3b), but this did not stop the installation.

With regard to the Nouveau issue, do you know how long a fix is likely to be forthcoming? I read the release notes and the bug reports that have been raised regarding this but I must admit they confused me as to what is happening! I’m not sure if the devs are trying to fix this or waiting for upstream… I realise you probably don’t have a crystal ball but you have more of an idea than me. I have an install also on an AMD Laptop and was confused when the message regarding nouveau appeared. Why would nouveau be installed when it isn’t needed?

Even a (the only?) upstream nouveau developer recommends to rather use intel or AMD graphics cards at this point…
See https://bugs.freedesktop.org/show_bug.cgi?id=98039#c3

But as I said, some fixes for severe problems have been added to other parts (kwin, QtWebEngine), but that doesn’t mean that nouveau itself (or other applications that use OpenGL) will work fine on every system.

Actually not really a new situation though, nouveau was always more or less problematic (depending on your exact graphics card and the version in use), but changes in Qt/KDE trigger additional problems now that will probably take quite some time to fix as they are deep inside nouveau’s design.

Basically it affects every multi-threaded application that uses OpenGL, see e.g.:
https://bugs.freedesktop.org/show_bug.cgi?id=94727
https://bugs.freedesktop.org/show_bug.cgi?id=91632
https://bugs.freedesktop.org/show_bug.cgi?id=92438

There are some work-in-progress patches to address those multi-threading issues, and they had been added to openSUSE’s Mesa package, but although they are reported to improve things the upstream author does not want to see them published as they are not finished yet and may cause problems (hard-locks) too.

openSUSE specific bug reports about these problems:
https://bugzilla.opensuse.org/show_bug.cgi?id=997171
https://bugzilla.opensuse.org/show_bug.cgi?id=1005323

And there also are a lot of them in KDE’s bugzilla… (most closed as upstream by now)

Why would nouveau be installed when it isn’t needed?

Because it is recommended by xorg-x11-server. This will be improved in the future, but there wasn’t enough time to do it for 42.2.

But if you don’t have an nvidia card, you don’t have to worry about the nouveau problems at all anyway, regardless whether nouveau is installed or not.
And if you have an nvidia card there’s of course the alternative to use the nvidia driver.

@Wolfi323 Thank you very much for clarifying the current situation and such a detailed response. I will now read through those bugs to get a better understanding.

Again thank you.

another strange visual problem:


https://youtu.be/j7ydX8kaj-I

Checked it and I can reproduce this bug with both 42.2 RC1 and RC2. (also tried with gimp).

Although this is not related to Leap 42.2, but nobody like see such bugs in the upcoming release. hope they fix these bugs soon, not much time left…

From what I can see on the video you placed with the Google folks, you seem to be mentioning an issue with an application named “Pinta” which is written in C# (GTK#) (“C” sharp –>> Redmond .NET . . . ). From what I’m seeing in the openSUSE software search, there’s a “Pinta” packages available in the official Leap 42.1, Tumbleweed and 13.2 repositories – there is however, no mention of Leap 42.2 support for the “Pinta” package.

  • If you were to look at other packages such as “LibreOffice” or “GIMP”, you would notice that, “official” Leap 42.2 Release Candidate support is available for such packages.

Due to the rather low resolution of the video available from the Google folks, I’m having extreme difficulty seeing what the issue is that you’re experiencing.

  • Could you possibly, describe in words what the behaviour is that is causing the issue which you wish to raise?

You will have to raise a Bug Report with the “Pinta” folks – I haven’t the faintest idea where but, you could begin searching from the Wikipedia page: <https://en.wikipedia.org/wiki/Pinta_(software)&gt;.

Are you also experiencing a similar behaviour with GIMP?

If you like (Redmond) .NET things then, I guess applications such as “Pinta” could be used.