Discussion thread for Leap 42.2 Alpha3

Alpha 3 was announced here:
openSUSE Leap 42.2 Alpha3 released

Here is the request for feedback:
openSUSE Leap 42.2 - Alpha 3 - call for manual testing

Both of those links are to messages in the factory mailing list archives.

I’ll comment on my own experience in a separate reply below.

I downloaded alpha3 on Wednesday. The download went without incident. I wrote that to a USB flash drive, using “dd_rescue”. I then proceeded to install.

The install itself went quite smoothly. Incidentally, this was on a UEFI box with secure-boot enabled. It has Intel graphics. My install was into an existing encrypted LVM, with a separate unencrypted “/boot”.

On the first reboot, I ended up in emergency mode. Apparently there are problems with using LVM.

To proceed, I did:


# vgchange -a y
# --- resume the boot (I used CTRL-D)

That got me running.

I have since edited “/etc/lvm/lvm.conf” and changed

   use_lvmetad = 1

to

   use_lvmetad = 0

After that change, it boots without problem.

I have mainly tried Plasma 5 (at version 5.7). That works until I logout or reboot.

On logout or reboot, the screen dims (this is normal). Then it goes black. Then it comes back as dim. Then it comes back as full brightness. Then it finally does the logout or reboot.

I have not further investigated. My guess is that something is crashing during the logout, and then being restarted before the logout completes.

I also ran into a minor problem with “sddm”. I enter the password and hit ENTER, but nothing happens. So (based on a comment I have seen on another thread), I switched to a command line with CTRL-ALT-F1. Then I switched back to the GUI with CTRL-ALT-F7. And login was now under way. I have since switched to using “lightdm” which does not have the same problem.

I have a second computer, this one with an Nvidia card (GeForce 6150LE). I am hesitant to install alpha3 because I suspect that it won’t run. My experience with Tumbleweed has not been good.

At present, Leap 42.1 is running fine. I originally used the G02 Nvidia driver. That did not work well. I had to force the use of XRender for compositing. I have since switched back to the nouveau driver. And that’s okay as long as I use XRender.

However, trying a recent Tumbleweed live KDE image, it seems to choke up even after forcing the use of XRender. I think Plasma 5 does not like Nvidia graphics – or, at least, does not like older Nvidia graphics.

I have now installed Alpha 3 on my computer with Nvidia graphics. It is using the nouveau driver.

Icewm, Gnome and XFCE are all fine. However, Plasma 5 (KDE) locks up.

If I reboot with “nomodeset”, then Plasma 5 can run and seems stable. While running that way, I set it to use XRender for compositing, and I then turned off desktop effects. Later rebooting to go back to nouveau, it again locks up.

After the lockup, I see a process using 100% of processor time – it is “systemd-coredump”. It seems to be taking a coredump of plasma shell.

Hi Neil, I did a “zypper up” rather than a new install (see Experience with 42.2 Alpha2 - Open Chat - openSUSE Forums ).
On Gnome I see Cheese not finding the UVC webcam, Totem (Videos) complaining about not finding needed plugins (something like “playbin” seems to be missing).
Might be a quirk due to the update process, would be nice to know if they work on a fresh install.

I’m not a Gnome person (though I install Gnome). So I’m not sure how to test these.

Hi
Moving to Chat since it’s not a help request… :wink:

Hi
Moved and re-opened…

If any Gnome user can confirm what I’m seeing, starting the two applications from a terminal should show the following among harmless warnings:


etabeta@linux:~> totem

** (totem:2189): WARNING **: Element 'playbin' is missing, verify your installation

...
etabeta@linux:~> cheese

...
(cheese:2213): GLib-GObject-CRITICAL **: g_object_ref_sink: assertion 'G_IS_OBJECT (object)' failed
** Message: cheese-application.vala:211: Error during camera setup: No device found


(cheese:2213): cheese-CRITICAL **: cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' failed

...
etabeta@linux:~>

It seems sort of a regression, since both worked on Alpha2.
I’m just wondering if reporting such behaviour is worth the effort at this stage. AIUI “Alphas” are for developers to test integration issues with the basic system; accordingly, I already reported against the installer and I’m currently looking at the new Yast and possible HW / kernel / systemd issues.
Maybe I have to wait for “Betas” to report against applications from an “use case” perspective.
Any advice from members familiar with the OpenSUSE development cycle is welcome.

Starting “totem” from a terminal, it say that all plugin paths are invalid. It then complains that it could not find plugin “brillo”.

Starting “cheese” from a terminal, I get a bunch of warnings that look as if they can be ignored. Then it says that it could not find a camera device (probably because I don’t have one on this computer).

I’m never sure what to report as a bug. But if the plugin path is broken, that’s probably worth reporting.

I have not reported the failure of plasma to run under nouveau. That’s probably an upstream issue, and the chances are that kde.org already has reports of the problem.

Thanks, meanwhile I added a few notes of mine on the Alpha3 test spreadsheet https://docs.google.com/spreadsheets/d/1AGKijKpKiJCB616-bHVoNQuhWHpQLHPWCb3m1p6gXPc/edit?pref=2&pli=1#gid=1770305481

Totem starts and plays with only harmless warnings when started from a superuser terminal; so it seems that a permission problem rather than an application bug is at play.

With a fresh user both Totem and Cheese work as expected; apparently both applications were crippled by stale configs from previous versions in the home folder for my test user.

@nrickert : maybe you recycled a test home too?

Actually, no.

I mounted my home file system as “/xhome”. That way home directories are part of the root file system. But I add symlinks to important stuff in “/xhome” (including shell startup files). However, I did not add any symlinks to Gnome configuration (or KDE configuration, for that matter). So, from a Gnome point of view, this was a new user.

Note, however, that I’m not normally a Gnome user, so I don’t know what to expect with “cheese” or “totem”. Maybe all of the messages that I saw on the terminal could be ignored. Both commands did open up GUI windows.

I see, likely the full message you saw was:


(totem:5591): Totem-WARNING **: Failed to load grilo plugins: All configured plugin paths are invalid

These plugins seem still needing an update to 42.2 and are not strictly needed anyway.
Thanks again. Sorry for chasing a phantom “bug”, but as you know that happens now and then while testing…

Actually what is needed is deleting ~.cache/gstreamer-1.0 in the home directory of the affected user.
A similar problem was seen in the past when updating Gnome Apps between releases.

I’ve run into problems with left-over configuration from time to time. So I often delete all files/directories beginning with “.”, except for a few like shell startup files, “.ssh”, “.gnupg” and “.mozilla”. Then I make a fresh start in desktop setup.

And high marks to firefox/mozilla. It’s the one software that has almost never given me problems due to version change.

Graphics performance seems somewhat slower on 42.2 compared to 42.1 on the same system both on Intel integrated graphics and Nvidia bumblebee with primusrun. Optirun seems some 5% faster though.
I don’t really know if the differences are significant, but here is what I got on i7 4720HQ + Geforce GTX960M , 42.2 Alpha3 vs 42.1:

vblank_mode=0 glxspheres (Intel)
282 vs 320 frames/s

optirun glxspheres (Nvidia)
315 vs 299 frames/s

vblank_mode=0 primusrun glxspheres (Nvidia)
385 vs 420 frames/s

If you plan on using OpenCL on NVIDIA you might consider these workarounds
https://bugzilla.opensuse.org/show_bug.cgi?id=991375