GDM status (again)

GDM status (again)

[Timothy Sample]

Hi Guix,

Two months ago, Andy Wingo did a bunch of work on getting GDM working as
a display manager for Guix [1]. Unfortunately, Andy had to step away
from the task before getting everything working.

I’ve been looking at this a bit, and have made some progress. Currently,
GDM starts, lists users, logs in, and launches Gnome. What’s more is
that locking the screen works! Hooray!, right? Well, not quite. There
are two serious problems. The first is that it allows me to log in
without asking for a password. I haven’t looked at why this is. The
second is that Gnome cannot launch applications like “gnome-terminal”
due to a DBUS error. I’ll explain a little bit about the error, but
first I want to write down what I did to get GDM to work at all.

There’s a bug in the GDM package specification, which prevents GDM from
finding its config file. (I think this is why Andy had trouble with the
debug output.) Basically, the “substitute*” call that looks like

    ;; Look for custom GDM conf in /run/current-system.
    (substitute* '("common/gdm-settings-backend.c")
      (("GDM_CUSTOM_CONF")
       "/run/current-system/etc/gdm/custom.conf"))

should be

    ;; Look for custom GDM conf in /run/current-system.
    (substitute* '("common/gdm-settings-desktop-backend.c")
      (("GDM_CUSTOM_CONF")
       "\"/run/current-system/etc/gdm/custom.conf\""))

After clearing that up, I found out that GDM was unable to find the
Gnome Shell. This is pretty tricky because Gnome Shell already depends
on GDM, so you have to avoid a circular dependency. Other distros (I
looked at Debian and Fedora) solve this by slicing out a “libgdm” output
from the GDM sources, so that you can build “libgdm” without Gnome
Shell, have Gnome Shell depend on “libgdm”, and then have GDM depend on
Gnome Shell. AFAIK, GDM does not provide something like an
“install-libgdm” make target, so the other distros just select the files
manually. GDM also requires access to DBUS, since it launches a session
bus for itself and every user who logs in. I skirted doing all the work
of setting this up in the package, and just added

    XDG_DATA_DIRS=/run/current-system/profile/share
    PATH=/run/current-system/profile/bin

to the service environment in the “shepherd-service” definition. This
only works because I am assuming that the system is using the Gnome
service. I thought that I would see how it goes, and then come back to
making it nice ;).

The next two issues were solved with configure flags. By default, GDM
tries to take over the first virtual terminal, which doesn’t work
because mingetty is already using it. This is fixed by passing
“--with-default-vt=7” to the configure script.

With this, GDM runs, but does not let anyone log in. It turns out it
needs an Xsession script, which it only provides if you give the
configure script “--enable-gdm-xsession”. (They said that they put it
behind a configure flag because most distributions ignore it and write a
custom one anyway [2].)

After making these changes, GDM should work and allow you to log
in. This is where the problems I described earlier come it. The DBUS
error happens because GDM never loads any “profile” scripts (e.g.,
“/etc/profile”). This means that DBUS can’t find any “.session” files,
which causes a lot of stuff to break. I tried to fix this by modifying
the GDM source code to launch certain processes through a login shell
(i.e., “bash -l -c "..."”), and indeed this let the DBUS session daemon
find the “.session” files. Sadly, it just revealed fatal locale
errors. (To be sure, I don’t really think it’s a good solution anyway. I
just wanted to see what would happen.) This is where I gave up.

If you’ve read this far, thank you! Sorry for the long story.

I plan to keep looking at this, but these environment problems look to
be pretty far above my pay grade (with respect to Guix expertise). If
any of this reminds anyone of a similar problem that’s already been
solved I’d love to know so I can cheat off the solution! Otherwise, I
hope this might help anyone else who wants to work on GDM.

Finally, some quick info about QEMU and testing GDM/Gnome. Gnome takes
up a lot of memory, so “-m 1024” is a good idea. GDM runs X as non-root
users, which means that X has to use the KMS/DRM system. Currently Guix
sets up the Linux kernel without a direct rendering driver for the
default QEMU graphics setup (“-vga std”). Fortunately, “-vga qxl” seems
to solve this. (It looks like a driver for “-vga std” can be configured
into the kernel with the “CONFIG_DRM_BOCHS” flag, but I have not tested
this.) In QEMU, you can switch VTs by pressing Crtl-Alt-2 to get to the
QEMU shell, and then typing “sendkey ctrl-alt-fN” where N is the VT you
want to switch to.


-- Tim


[1] https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00268.html
[2] https://mail.gnome.org/archives/commits-list/2015-June/msg00115.html

Re: GDM status (again)

[Ludovic Courtès]

Hi Timothy,

Timothy Sample <samplet@ngyro.com> skribis:

> Two months ago, Andy Wingo did a bunch of work on getting GDM working as
> a display manager for Guix [1]. Unfortunately, Andy had to step away
> from the task before getting everything working.

Thanks for taking it over!

> After clearing that up, I found out that GDM was unable to find the
> Gnome Shell. This is pretty tricky because Gnome Shell already depends
> on GDM, so you have to avoid a circular dependency. Other distros (I
> looked at Debian and Fedora) solve this by slicing out a “libgdm” output
> from the GDM sources, so that you can build “libgdm” without Gnome
> Shell, have Gnome Shell depend on “libgdm”, and then have GDM depend on
> Gnome Shell.

Do we really need a compile-time dependency (GDM in master doesn’t
depend on gnome-shell, after all), or can we just have a hard-coded
/run/current-system/bin/gnome-shell somewhere?  Granted, that’s not very
elegant, but it might be good enough?

Also, one can use GDM without using GNOME, so it would be best if GDM
didn’t depend on GNOME.


With this and the other changes you described, it looks like there’s
already a bunch of patches we could apply.  Would you like to send them?
:-)

> After making these changes, GDM should work and allow you to log
> in. This is where the problems I described earlier come it. The DBUS
> error happens because GDM never loads any “profile” scripts (e.g.,
> “/etc/profile”). This means that DBUS can’t find any “.session” files,
> which causes a lot of stuff to break. I tried to fix this by modifying
> the GDM source code to launch certain processes through a login shell
> (i.e., “bash -l -c "..."”), and indeed this let the DBUS session daemon
> find the “.session” files. Sadly, it just revealed fatal locale
> errors. (To be sure, I don’t really think it’s a good solution anyway. I
> just wanted to see what would happen.) This is where I gave up.

The way this was solved for SLiM was to run the window manager in a
login shell: see ‘exec-from-login-shell’ in (gnu services xorg).
Perhaps we could reuse the same approach?  Maybe we can wrap gdm itself
so that it’s launched from a login shell?

> If you’ve read this far, thank you! Sorry for the long story.

Well, thank *you* for the tireless investigation!

> Finally, some quick info about QEMU and testing GDM/Gnome. Gnome takes
> up a lot of memory, so “-m 1024” is a good idea. GDM runs X as non-root
> users, which means that X has to use the KMS/DRM system. Currently Guix
> sets up the Linux kernel without a direct rendering driver for the
> default QEMU graphics setup (“-vga std”). Fortunately, “-vga qxl” seems
> to solve this. (It looks like a driver for “-vga std” can be configured
> into the kernel with the “CONFIG_DRM_BOCHS” flag, but I have not tested
> this.) In QEMU, you can switch VTs by pressing Crtl-Alt-2 to get to the
> QEMU shell, and then typing “sendkey ctrl-alt-fN” where N is the VT you
> want to switch to.

Looks like another patch we could apply: defaulting to “-vga qxl”.  Or
is there any downside?

Thanks for the detailed report, and thanks in advance for the patches
you described!  :-)

Ludo’.

Re: GDM status (again)

[Andy Wingo]

Hi!

On Sun 29 Oct 2017 16:30, ludo@gnu.org (Ludovic Courtès) writes:

> Timothy Sample <samplet@ngyro.com> skribis:
>
>> Two months ago, Andy Wingo did a bunch of work on getting GDM working as
>> a display manager for Guix [1]. Unfortunately, Andy had to step away
>> from the task before getting everything working.
>
> Thanks for taking it over!

OMG yes, thank you!!  Excellent work!

>> After clearing that up, I found out that GDM was unable to find the
>> Gnome Shell. This is pretty tricky because Gnome Shell already depends
>> on GDM, so you have to avoid a circular dependency. Other distros (I
>> looked at Debian and Fedora) solve this by slicing out a “libgdm” output
>> from the GDM sources, so that you can build “libgdm” without Gnome
>> Shell, have Gnome Shell depend on “libgdm”, and then have GDM depend on
>> Gnome Shell.
>
> Do we really need a compile-time dependency (GDM in master doesn’t
> depend on gnome-shell, after all), or can we just have a hard-coded
> /run/current-system/bin/gnome-shell somewhere?  Granted, that’s not very
> elegant, but it might be good enough?
>
> Also, one can use GDM without using GNOME, so it would be best if GDM
> didn’t depend on GNOME.

This might be fine (and is what I was trying to do).  However this would
mean that the GDM service should ensure that gnome-shell is there, which
in practice is like having a dependency on GNOME or at least on
gnome-shell.  My understanding is that GDM uses gnome-shell as the login
greeter process, so you really can't use GDM without GNOME -- of course
you can log in to some non-GNOME session but GDM itself will use
gnome-shell.  Given that's the case, might as well depend on gnome-shell
explicitly.

> With this and the other changes you described, it looks like there’s
> already a bunch of patches we could apply.  Would you like to send them?
> :-)

I'd be happy to review.  I'd also be happy to apply them :)  There's no
currently-working thing to break -- we can only get better -- so I think
it's OK to noodle on the problem in master.

> Thanks for the detailed report, and thanks in advance for the patches
> you described!  :-)

Yes, looking forward to the patches :-))

Andy

Re: GDM status (again)

[Timothy Sample]

Andy Wingo <wingo@igalia.com> writes:

>> Do we really need a compile-time dependency (GDM in master doesn’t
>> depend on gnome-shell, after all), or can we just have a hard-coded
>> /run/current-system/bin/gnome-shell somewhere?  Granted, that’s not very
>> elegant, but it might be good enough?
>>
>> Also, one can use GDM without using GNOME, so it would be best if GDM
>> didn’t depend on GNOME.
>
> This might be fine (and is what I was trying to do).  However this would
> mean that the GDM service should ensure that gnome-shell is there, which
> in practice is like having a dependency on GNOME or at least on
> gnome-shell.  My understanding is that GDM uses gnome-shell as the login
> greeter process, so you really can't use GDM without GNOME -- of course
> you can log in to some non-GNOME session but GDM itself will use
> gnome-shell.  Given that's the case, might as well depend on gnome-shell
> explicitly.

That’s my understanding too. GDM needs gnome-shell to run the greeter
interface. (I think that “gnome shell” at different times means both a
framework for making interfaces – like GDM’s greeter – and the
particular desktop interface used by Gnome 3. It’s a little confusing.)
Therefore, it should probably be one of GDM’s inputs. That being said,
to do it well would be a ton of work. First we would have to slice out
the library to avoid the circular dependency (like I mentioned earlier),
then we would probably want to revisit gnome-shell’s inputs because I
doubt it /needs/ libgweather (for instance) and I assume that people who
want to use GDM with i3 or whatever would like gnome-shell to be as slim
as possible.

Anyway, for now I am sprinkling references to “/run/current-system” in
the service definitions to make sure all the components find what they
are looking for. Later, when I can /actually/ start a usable session
with GDM :), I will try to clean things up a bit.

>> With this and the other changes you described, it looks like there’s
>> already a bunch of patches we could apply.  Would you like to send them?
>> :-)
>
> I'd be happy to review.  I'd also be happy to apply them :)  There's no
> currently-working thing to break -- we can only get better -- so I think
> it's OK to noodle on the problem in master.
>

OK. I will try and send a proper patch this evening. Thanks for the
encouragement.


-- Tim

Re: GDM status (again)

[Ludovic Courtès]

Hi!

Timothy Sample <samplet@ngyro.com> skribis:

> Andy Wingo <wingo@igalia.com> writes:
>
>>> Do we really need a compile-time dependency (GDM in master doesn’t
>>> depend on gnome-shell, after all), or can we just have a hard-coded
>>> /run/current-system/bin/gnome-shell somewhere?  Granted, that’s not very
>>> elegant, but it might be good enough?
>>>
>>> Also, one can use GDM without using GNOME, so it would be best if GDM
>>> didn’t depend on GNOME.
>>
>> This might be fine (and is what I was trying to do).  However this would
>> mean that the GDM service should ensure that gnome-shell is there, which
>> in practice is like having a dependency on GNOME or at least on
>> gnome-shell.  My understanding is that GDM uses gnome-shell as the login
>> greeter process, so you really can't use GDM without GNOME -- of course
>> you can log in to some non-GNOME session but GDM itself will use
>> gnome-shell.  Given that's the case, might as well depend on gnome-shell
>> explicitly.
>
> That’s my understanding too. GDM needs gnome-shell to run the greeter
> interface.

Oh I didn’t know that.  I agree then, it’s best to explicitly depend on it.

Thank you!

Ludo’.