Bug 1102563

/etc/sysconfig/displaymanager and /etc/gdm/custom.conf files are identical on x86_64 and aarch64.

To make autologin work on aarch64, we must edit /etc/gdm/custom.conf and uncomment the following line which force the login screen to use Xorg:
  WaylandEnable=false

Created attachment 777999 [details]
journalctl log

(In reply to Guillaume GARDET from comment #1)
> /etc/sysconfig/displaymanager and /etc/gdm/custom.conf files are identical
> on x86_64 and aarch64.
> 
> To make autologin work on aarch64, we must edit /etc/gdm/custom.conf and
> uncomment the following line which force the login screen to use Xorg:
>   WaylandEnable=false

I guess you could do that in the spec file of the package that owns this file, e.g. gdm, based on an arch-specific branch. Or require an additional fix-package which does this change? Have you checked for any upstream bugs describing this problem?

Regarding the openQA test, as we have support for logging in users, e.g. see the use of the variable NOAUTOLOGIN, you might be able to detect the problem and workaround it in first_boot (or the helper function wait_boot)

(In reply to Oliver Kurz from comment #3)
> (In reply to Guillaume GARDET from comment #1)
> > /etc/sysconfig/displaymanager and /etc/gdm/custom.conf files are identical
> > on x86_64 and aarch64.
> > 
> > To make autologin work on aarch64, we must edit /etc/gdm/custom.conf and
> > uncomment the following line which force the login screen to use Xorg:
> >   WaylandEnable=false
> 
> I guess you could do that in the spec file of the package that owns this
> file, e.g. gdm, based on an arch-specific branch. Or require an additional
> fix-package which does this change? Have you checked for any upstream bugs
> describing this problem?

It is more a workaround than a fix. 
I did not find any upstream bug for this. Just an old openSUSE bug: https://bugzilla.suse.com/show_bug.cgi?id=1011356

> 
> Regarding the openQA test, as we have support for logging in users, e.g. see
> the use of the variable NOAUTOLOGIN, you might be able to detect the problem
> and workaround it in first_boot (or the helper function wait_boot)

Yes, I am testing an update of the first_boot test to record a soft failure for this bug, to be able to continue the tests.

A sanity check: Does manual login work with WaylandEnable=true on AArch64?

It sounds strange that Wayland + AArch64 would somehow affect autologin. But it is fairly possible that it tries to do autologin, the session crashes and then it goes back to the login screen.

(In reply to Michal Srb from comment #5)
> A sanity check: Does manual login work with WaylandEnable=true on AArch64?

With WaylandEnable=true on AArch64 I am able to login but loginctl still tell me that it is an X11 session.

> It sounds strange that Wayland + AArch64 would somehow affect autologin. But
> it is fairly possible that it tries to do autologin, the session crashes and
> then it goes back to the login screen.

I noticed that login screen appears for 1 second, then a black screen for 1 second and the login screen appears again.
It seems that login screen using Wayland is shown, crashes and the login screen using X11 is finally loaded. Is it possible?

(In reply to Guillaume GARDET from comment #6)
> With WaylandEnable=true on AArch64 I am able to login but loginctl still
> tell me that it is an X11 session.

That is ok. You can log into both X11 and Wayland sessions from GDM that is itself running in Wayland mode. It seems that the default session type is a X11 session.

> I noticed that login screen appears for 1 second, then a black screen for 1
> second and the login screen appears again.
> It seems that login screen using Wayland is shown, crashes and the login
> screen using X11 is finally loaded. Is it possible?

Maybe yes. The black screen could be also the failed attempt for autologin.

Please delete any ~/.xsession-errors* files in the home directory of the user that was supposed to be autologged-in, then reboot. When you get the login screen instead of the expected autologin, check if any such files were recreated. If yes, please attach them.

(In reply to Michal Srb from comment #7)
> Please delete any ~/.xsession-errors* files in the home directory of the
> user that was supposed to be autologged-in, then reboot. When you get the
> login screen instead of the expected autologin, check if any such files were
> recreated. If yes, please attach them.

There is no such file.

virgl has been enabled on ARM to get /usr/lib64/dri/virtio_gpu_dri.so file on ARM:
https://build.opensuse.org/package/rdiff/X11:XOrg/Mesa?linkrev=base&rev=761

We must wait that it reaches Factory:ARM to check if it fixes this bug or not.

*** Bug 1102735 has been marked as a duplicate of this bug. ***

I came into Tumbleweed with snapshot 20180807, so you can give it a try.

New Tumbleweed snapshot 20180807 released!
[...]
Packages changed:
  Mesa (18.1.4 -> 18.1.5)
  Mesa-drivers (18.1.4 -> 18.1.5)

Mesa.changes
[...]
-------------------------------------------------------------------
Thu Aug  2 20:13:36 UTC 2018 - mimi.vx@gmail.com

- update to 18.1.5
  * several fixes for radv
  * A few fixes for virgil, spirv, radeonsi, nir, disk cache and build
     systems

-------------------------------------------------------------------
Thu Jul 26 10:30:26 UTC 2018 - guillaume.gardet@opensuse.org

- Enable virgl on ARM

Created attachment 779693 [details]
journalctl with virtio_gpu_dri.so installed

The interesting part seems to be:

  gdm[1695]: gdm_session_handle_secret_info_query: assertion 'self->priv->user_verifier_interface != NULL' failed
  gdm-autologin][1723]: gkr-pam: couldn't get the password from user: Conversation error

(In reply to Stefan Dirsch from comment #11)
> I came into Tumbleweed with snapshot 20180807, so you can give it a try.

I uploaded the new log. There is no more the message complaining about virtio_gpu_dri.so file missing, but auto-login is still broken.

This part of the log seems to be relevant:
  gdm[1695]: gdm_session_handle_secret_info_query: assertion 'self->priv->user_verifier_interface != NULL' failed
  gdm-autologin][1723]: gkr-pam: couldn't get the password from user: Conversation error

I just tested ready to boot openSUSE-Tumbleweed-ARM-GNOME-raspberrypi3.aarch64-2018.08.13-Build.raw image on my Raspberry Pi 3 and when I enable autologin, it does work fine.

On RPi3, loginctl states it uses X11.

According to openQA, with an upgrade from Leap 15.0 to Tumbleweed, auto-login works: https://openqa.opensuse.org/tests/853602#step/first_boot/2

(In reply to Guillaume GARDET from comment #27)
> According to openQA, with an upgrade from Leap 15.0 to Tumbleweed,
> auto-login works: https://openqa.opensuse.org/tests/853602#step/first_boot/2

This comment is probably wrong as Leap 15.0 image has wayland disable to make auto-login works.

openQA test without gnome Wayland, but only with gnome X11, autologin passes:
https://openqa.opensuse.org/tests/858692

So, it is really Wayland specific.

Anything to do to move forward?

In the log there is:
  Failed to create backend: Could not find a primary drm kms device


Whereas X uses a drm kms driver after Wayland failed.

Is there any known incompatibilities with virtio-gpu-pci?

Maybe drm kms just load too late, as suggested here: https://nrhodes91.github.io/2018/11/25/archlinux-gnome-wayland-session/

(In reply to Guillaume GARDET from comment #33)
> Maybe drm kms just load too late, as suggested here:
> https://nrhodes91.github.io/2018/11/25/archlinux-gnome-wayland-session/

I tried to force the load the drm/kms modules earlier and drm/kms is up after 3 seconds (vs 7 seconds previously), so way earlier before Wayland try to start. But it did not change anything.

It is fixed in Tumbleweed 20190508.
Snapshot 20190428 was still broken.

I think there was an update regarding tty numbering in gnome wayland, but I cannot find it again. Maybe this is the update which fixed it?

Probably fixed by http://bugzilla.opensuse.org/show_bug.cgi?id=1116011

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: gnome
https://openqa.opensuse.org/tests/1686787

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: create_hdd_cryptlvm
https://openqa.opensuse.org/tests/1755934

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

judging from the openQA reminder comments this was never fixed just *assumed* to be fine when apparently it's not

(In reply to Oliver Kurz from comment #67)
> judging from the openQA reminder comments this was never fixed just
> *assumed* to be fine when apparently it's not

According to the test history https://openqa.opensuse.org/tests/1755934#next_previous until snapshot 152.1 it was fine but it started to fail with latest snapshot, 160.3

(In reply to Guillaume GARDET from comment #68)
> (In reply to Oliver Kurz from comment #67)
> > judging from the openQA reminder comments this was never fixed just
> > *assumed* to be fine when apparently it's not
> 
> According to the test history
> https://openqa.opensuse.org/tests/1755934#next_previous until snapshot 152.1
> it was fine but it started to fail with latest snapshot, 160.3

At the same time create_hdd-gnome-wayland is fine: https://openqa.opensuse.org/tests/1755936

oh, ok. Interesting. Do you have an idea of the change in the latest build that could explain such regression?

(In reply to Oliver Kurz from comment #70)
> oh, ok. Interesting. Do you have an idea of the change in the latest build
> that could explain such regression?

No idea. Max may know.

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: create_hdd_cryptlvm
https://openqa.opensuse.org/tests/1755934

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: create_hdd_cryptlvm
https://openqa.opensuse.org/tests/1755934

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: create_hdd_cryptlvm
https://openqa.opensuse.org/tests/1755934

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: create_hdd_cryptlvm
https://openqa.opensuse.org/tests/1755934

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: create_hdd_cryptlvm
https://openqa.opensuse.org/tests/1755934

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

Tumbleweed is fixed since a while, but Leap 15.3 is still affected.

Leap 15.3 EOL.