GNU bug report logs -
#39281
gdm doesn't start
Previous Next
Reported by: Jack Hill <jackhill <at> jackhill.us>
Date: Sat, 25 Jan 2020 20:33:01 UTC
Severity: normal
Done: Danny Milosavljevic <dannym <at> scratchpost.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39281 in the body.
You can then email your comments to 39281 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Sat, 25 Jan 2020 20:33:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jack Hill <jackhill <at> jackhill.us>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sat, 25 Jan 2020 20:33:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Guix,
After a recent pull and system reconfigure, gdm does not start at boot.
Instead, I am left with a text console login. sirgazil also described the
problem on irc, "I just did guix pull and sudo system reconfigure, and GDM
never started after waiting for about 10 minutes. This may be the same
problem gnutec was having yesterday..."
The last known good guix for me is
7842ddcbc118cbc2799e22651732b7cdc06b93ee and the first known bad commit is
df6ce9fcb455ac59372f1025e450005ea3190614.
My operating system config is included below:
Best,
Jack
(use-modules (gnu) (gnu system nss) (gnu services xorg)
(gnu packages linux))
(use-service-modules desktop)
(use-package-modules certs gnome scanner security-token)
(operating-system
(host-name "alperton")
(timezone "America/New_York")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))
;; Specify a mapped device for the encrypted root partition.
;; The UUID is that returned by 'cryptsetup luksUUID'.
(mapped-devices
(list (mapped-device
(source (uuid "f7776767-70c9-44e3-9973-c1334d301348"))
(target "alperton_root")
(type luks-device-mapping))))
(file-systems (cons
(file-system
(device (file-system-label "alperton_root"))
(mount-point "/")
(type "ext4")
(dependencies mapped-devices))
%base-file-systems))
(swap-devices (list "/root/swap"))
(users (cons (user-account
(name "jackhill")
(comment "Jack Hill")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "lp" "video"))
(home-directory "/home/jackhill"))
%base-user-accounts))
;; This is where we specify system-wide packages.
(packages (cons* nss-certs ;for HTTPS access
fuse-exfat
bluez
gvfs ;for user mounts
%base-packages))
;; Add GNOME and/or Xfce---we can choose at the log-in
;; screen with F1. Use the "desktop" services, which
;; include the X11 log-in service, networking with
;; NetworkManager, and more.
(services (cons* (service gnome-desktop-service-type)
(bluetooth-service)
(simple-service 'custom-udev-rules udev-service-type (list sane-backends libu2f-host))
%desktop-services))
(firmware %base-firmware)
;; Allow resolution of '.local' host names with mDNS.
(name-service-switch %mdns-host-lookup-nss))
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Sat, 25 Jan 2020 22:34:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 39281 <at> debbugs.gnu.org (full text, mbox):
For what is worth, I saw the following warnings when guix system reconfigure was running:
https://multimedialib.files.wordpress.com/2020/01/guix-system-reconfigure-2020-01-25.png
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Sun, 26 Jan 2020 03:34:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 39281 <at> debbugs.gnu.org (full text, mbox):
I've started bisecting between my known bad and good commits.
Unfortunately, this will be a slow process both because my computer is
only so fast, and because rebooting to check a commit disrupts other work.
That said, why checking one of the bad commits, I noticed that the gdm
process was indeed started by shepherd and hadn't died, but it was not
making any progress for some reason. Running `sudo herd restart
xorg-server` caused it to bring up the gdm greater, and work normally.
I did notice the following in /var/log/gdm/greeter.log There was not
anything interesting in the xorg log. Unfortunately, I didn't think to
strace the gdm process before restarting it.
(EE)gnome-session-binary[837]: WARNING: Lost name on bus: org.gnome.SessionManager
(gsd-screensaver-proxy:927): GLib-GIO-WARNING **: 22:00:51.322: Error releasing name org.freedesktop.ScreenSaver: The connection is closed
(gsd-housekeeping:924): GLib-GIO-WARNING **: 22:00:51.322: Error releasing name org.gnome.SettingsDaemon.Housekeeping: The connection is closed
Fatal server error:
(EE) systemd-logind disappeared (stopped/restarted?)
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/lib/gdm/.local/share/xorg/Xorg.0.log" for additional information.
(EE)
(EE) systemd-logind: ReleaseControl failed: Connection was disconnected before a reply was received
(EE) Server terminated with error (1). Closing log file.
Gdk-Message: 22:00:51.636: gsd-power: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 22:00:51.636: gsd-clipboard: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 22:00:51.636: gsd-keyboard: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 22:00:51.636: gsd-media-keys: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 22:00:51.636: .gnome-shell-real: Fatal IO error 4 (Interrupted system call) on X server :0.
Gdk-Message: 22:00:51.636: gsd-wacom: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 22:00:51.638: gsd-xsettings: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 02:27:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 39281 <at> debbugs.gnu.org (full text, mbox):
According to my git bisect, d36fa50fbf8169018193774782fd21f1b13b9c0e [0]
is the culprit. It makes some sense that the commit is gnome-related, but
I have no idea why adding more packages to the environment should cause
gdm to fail to run properly. Therefore, I am inclined to believe that it is
a weird timing issue as Leo suspects.
[0] http://git.savannah.gnu.org/cgit/guix.git/commit/?id=d36fa50fbf8169018193774782fd21f1b13b9c0e
On Sun, 26 Jan 2020, Leo Prikler wrote:
> I saw the same warnings on one of my systems as well, but it boots
> fine. On another one, the same behaviour occurs, but GDM can be
> started manually by restarting xorg-server from a TTY. Note, that I
> can not do so from an SSH remote, because SSH fails to start in a
> similar manner.
My system does indeed have a really slow disk, so perhaps this makes the
problem more likely to happen. Obviously, it would be nice if gdm started
correctly, but in a bigger picture, it would be nice if shepherd had a
better way of dealing with misbehaving services. For example, if shepherd
know how to check the health of a service and restarted it wasn't
responding correctly.
I don't know where to go from here. Hopefully someone more knowledgeable
about gnome and gdm can help us out.
Best,
Jack
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 03:31:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 39281 <at> debbugs.gnu.org (full text, mbox):
> According to my git bisect, d36fa50fbf8169018193774782fd21f1b13b9c0e [0] is the culprit. It makes
> some sense that the commit is gnome-related, but I have no idea why adding more packages to the
> environment should cause gdm to fail to run properly. Therefore, I am inclined to believe that it
> is a weird timing issue as Leo suspects.
Interesting! Thanks for the info. Yeah, technically adding those package shouldn't affect gdm, as they are independent of each other. So could be the timing or something else.
Regards,
RG.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 04:51:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 39281 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I believe that I've found the problem!
Using the technique that Ludo’ described in
<https://issues.guix.gnu.org/issue/34580#17>, I was able to grab an strace
of gdm (attached) while it was failing to start properly. I was suspicious
of the following line:
"""
418 22:46:10 sendto(8, "<13>Jan 26 22:46:10 gdm: GdmManager: couldn't
look up username gnome-initial-setup\n", 83, MSG_NOSIGNAL, NULL, 0) = 83
<5.487224>
"""
so I removed gnome-initial-setup from the propagated-inputs with the
following patch, and, indeed, that resolved the problem with gdm on my
system.
While I'm still not exactly sure why this was causing gdm problems, and
why `herd restart xorg-server` caused gdm to start working correctly, I
think that removing gnome-initial-setup from the gnome meta-package is the
right thing to do. Instead, perhaps it could be provided via its own
service, auto-selected by the installer. If I recall correctly from other
distros (e.g. Fedora), the gnome-initial-setup wizard is run from its own
user on first boot, and after it finishes, the user is logged in as
themselves. That said, gnome-initial-setup did seem to run fine for me the
first time I logged into gnome after it was installed, and hasn't stared
again.
Thoughts?
Jack
P.S. Thanks Raghav for your work on making gnome in guix a better
experience!
[gdm.log (application/octet-stream, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 04:54:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 39281 <at> debbugs.gnu.org (full text, mbox):
Fixes bug#39281
* gnu/packages/gnome.scm (gnome)[propagated-inputs]:
remove gnome-initial-setup
---
gnu/packages/gnome.scm | 1 -
1 file changed, 1 deletion(-)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index e843bdfe08..9db379744a 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -7865,7 +7865,6 @@ world.")
("gnome-control-center" ,gnome-control-center)
("gnome-desktop" ,gnome-desktop)
("gnome-getting-started-docs" ,gnome-getting-started-docs)
- ("gnome-initial-setup" ,gnome-initial-setup)
("gnome-keyring" ,gnome-keyring)
("gnome-menus" ,gnome-menus)
("gnome-session" ,gnome-session)
--
2.25.0
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 05:25:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 39281 <at> debbugs.gnu.org (full text, mbox):
Am Sonntag, den 26.01.2020, 23:50 -0500 schrieb Jack Hill:
> I believe that I've found the problem!
>
> Using the technique that Ludo’ described in
> <https://issues.guix.gnu.org/issue/34580#17>;, I was able to grab an
> strace
> of gdm (attached) while it was failing to start properly. I was
> suspicious
> of the following line:
>
> """
> 418 22:46:10 sendto(8, "<13>Jan 26 22:46:10 gdm: GdmManager:
> couldn't
> look up username gnome-initial-setup\n", 83, MSG_NOSIGNAL, NULL, 0) =
> 83
> <5.487224>
> """
>
> so I removed gnome-initial-setup from the propagated-inputs with the
> following patch, and, indeed, that resolved the problem with gdm on
> my
> system.
>
> While I'm still not exactly sure why this was causing gdm problems,
> and
> why `herd restart xorg-server` caused gdm to start working correctly,
> I
> think that removing gnome-initial-setup from the gnome meta-package
> is the
> right thing to do. Instead, perhaps it could be provided via its own
> service, auto-selected by the installer. If I recall correctly from
> other
> distros (e.g. Fedora), the gnome-initial-setup wizard is run from its
> own
> user on first boot, and after it finishes, the user is logged in as
> themselves. That said, gnome-initial-setup did seem to run fine for
> me the
> first time I logged into gnome after it was installed, and hasn't
> stared
> again.
The problem is, that adding gnome-initial-setup in any way to the
operating-system config will likely trigger this bug as well, and not
adding it at all will skip the initial setup until it is installed at
user level (at this point, I'd argue it to be no longer necessary).
You could try creating a file named "/var/lib/gdm/.config/gnome-
initial-setup-done" with the contents "yes" to skip the initial setup,
but I'm pretty sure, that it will be looked up regardless.
Perhaps some GNOME people know how to disable this in other ways, but
it's the first time I've even seen the dialog, so there's not much else
I can say. Btw. are there more logs regarding gnome-initial-setup than
this one? At least in my case none of them seem to land in greeter.log
or messages.
Regards,
Leo
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 08:52:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 39281 <at> debbugs.gnu.org (full text, mbox):
> I believe that I've found the problem!
Nice!
> Using the technique that Ludo’ described in <https://issues.guix.gnu.org/issue/34580#17>, I was
> able to grab an strace of gdm (attached) while it was failing to start properly. I was suspicious
> of the following line:
>
> """
> 418 22:46:10 sendto(8, "<13>Jan 26 22:46:10 gdm: GdmManager: couldn't look up username
> gnome-initial-setup\n", 83, MSG_NOSIGNAL, NULL, 0) = 83 <5.487224>
> """
>
> so I removed gnome-initial-setup from the propagated-inputs with the following patch, and, indeed,
> that resolved the problem with gdm on my system.
That's strange. Both our system share similar configuration. But for me gdm works fine with gnome-initial-setup being present. This is confusing.
> While I'm still not exactly sure why this was causing gdm problems, and why `herd restart
> xorg-server` caused gdm to start working correctly, I think that removing gnome-initial-setup from
> the gnome meta-package is the right thing to do. Instead, perhaps it could be provided via its own
> service, auto-selected by the installer. If I recall correctly from other distros (e.g. Fedora),
> the gnome-initial-setup wizard is run from its own user on first boot, and after it finishes, the
> user is logged in as themselves. That said, gnome-initial-setup did seem to run fine for me the
> first time I logged into gnome after it was installed, and hasn't stared again.
>
> Thoughts?
I would say debugging and fixing would be better than removing. Let me see what I can do.
> P.S. Thanks Raghav for your work on making gnome in guix a better experience!
10-4 on the sarcasm. ;-)
Regards,
RG.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 19:09:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 39281 <at> debbugs.gnu.org (full text, mbox):
On Mon, 27 Jan 2020, Raghav Gururajan wrote:
>> so I removed gnome-initial-setup from the propagated-inputs with the following patch, and, indeed,
>> that resolved the problem with gdm on my system.
>
> That's strange. Both our system share similar configuration. But for me
> gdm works fine with gnome-initial-setup being present. This is
> confusing.
Indeed, my system does have a really slow disk, so it would not surprise
me if that contributed to it. Of course that shouldn't matter, but that's
the only thing I can think it. It would be nice to hear if sirgazil can
reproduce the fix since I think they were having the same problem on their
computer.
>> While I'm still not exactly sure why this was causing gdm problems, and why `herd restart
>> xorg-server` caused gdm to start working correctly, I think that removing gnome-initial-setup from
>> the gnome meta-package is the right thing to do. Instead, perhaps it could be provided via its own
>> service, auto-selected by the installer. If I recall correctly from other distros (e.g. Fedora),
>> the gnome-initial-setup wizard is run from its own user on first boot, and after it finishes, the
>> user is logged in as themselves. That said, gnome-initial-setup did seem to run fine for me the
>> first time I logged into gnome after it was installed, and hasn't stared again.
>>
>> Thoughts?
>
> I would say debugging and fixing would be better than removing. Let me see what I can do.
I agree that fixing is better than removing. Good luck debugging. I'm
happy to test, but am currently out of ideas.
>> P.S. Thanks Raghav for your work on making gnome in guix a better experience!
>
> 10-4 on the sarcasm. ;-)
I'm glad that you took this well :). However, while I'm often sarcastic, I
wasn't trying to be here. What I was trying to express was that while I'm
currently running my system with gnome-initial-setup removed doesn't mean
that I don't appreciate the change to make it present by default.
Fortunately for me, Guix makes this easy compared to other systems!
Best,
Jack
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 19:55:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 39281 <at> debbugs.gnu.org (full text, mbox):
---- On Mon, 27 Jan 2020 14:08:44 -0500 Jack Hill <jackhill <at> jackhill.us> wrote ----
> On Mon, 27 Jan 2020, Raghav Gururajan wrote:
>
> >> so I removed gnome-initial-setup from the propagated-inputs with the following patch, and, indeed,
> >> that resolved the problem with gdm on my system.
> >
> > That's strange. Both our system share similar configuration. But for me
> > gdm works fine with gnome-initial-setup being present. This is
> > confusing.
>
> Indeed, my system does have a really slow disk, so it would not surprise
> me if that contributed to it. Of course that shouldn't matter, but that's
> the only thing I can think it. It would be nice to hear if sirgazil can
> reproduce the fix since I think they were having the same problem on their
> computer.
Was the patch already applied? Because I just pulled, reconfigured and I have the same problem: After a message like this
Jan 27 14:24:57 localhost dbus-daemon[446]: [system] Failed to activate service 'org.freedesktop.Accounts': timed out (service_start_timeout=25000ms)
I only see a flashing caret that makes me think something is going to happen next, but after waiting for more than five minutes, nothing happens. If I go to TTY2, for example, I can log in and "sudo herd restart xorg-server"; then, after a few seconds, GDM is ready in TTY7, and I can log in to the desktop.
For what is worth, my computer has a HDD. I also see this message in /var/log/debug:
Jan 27 14:24:57 localhost gdm: Failed to contact accountsservice: Error calling StartServiceByName for org.freedesktop.Accounts: Timeout was reached
My current Guix:
$ LANG=C guix describe
Generation 11 Jan 27 2020 14:18:01 (current)
guix fcb510c
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: fcb510c541e83291ea6682cba87020a913c64914
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 20:14:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 39281 <at> debbugs.gnu.org (full text, mbox):
On Mon, 27 Jan 2020, sirgazil wrote:
> Was the patch already applied? Because I just pulled, reconfigured and I have the same problem: After a message like this
No, the patch wasn't applied, as we're still not sure if there is a better
fix. I applied it to my local copy of guix [0] to test. If you could apply
it locally as well (or just pull from my tree with `guix pull
--url="https://gitab.oit.duke.edu/jackhill/guix.git" --branch="gdm-fix"`)
and confirm that it fixes the problem for you as well, that would be
great.
[0] https://gitlab.oit.duke.edu/jackhill/guix/tree/gdm-fix
Best,
Jack
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 20:25:01 GMT)
Full text and
rfc822 format available.
Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
hmm, if you want to find out whether we could fix it, could you invoke:
useradd gnome-initial-setup
(on the console via ctrl-alt-f1) and then reboot?
If that doesn't fix it I'm all for removing gnome-initial-setup for the time being...
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 20:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 20:30:02 GMT)
Full text and
rfc822 format available.
Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Patch applied to guix master as commit 4fc4e5fdd9da6320aa94eeec61cbb84a7dc9460e
for now.
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 20:30:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 21:08:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 39281 <at> debbugs.gnu.org (full text, mbox):
On Mon, 27 Jan 2020, Danny Milosavljevic wrote:
> Hi,
>
> hmm, if you want to find out whether we could fix it, could you invoke:
>
> useradd gnome-initial-setup
I added gnome-initial-setup to my operating system config and reconfigured
with 94600c3960d7e2f12a3a9b6d2ed0d98ddacdd055 (the commit before you
appled the patch).
This did not solve the problem for me.
However, the following messages on the console (presumably from logind):
new session c1 for user gnome-initial-setup
followed a little while later by
removed session c1.
During a successful boot, I see
new session c1 for user gdm
followed by the gdm login screen appearing.
Best,
Jack
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 22:08:02 GMT)
Full text and
rfc822 format available.
Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):
---- On Mon, 27 Jan 2020 15:29:05 -0500 Danny Milosavljevic <dannym <at> scratchpost.org> wrote ----
> Patch applied to guix master as commit 4fc4e5fdd9da6320aa94eeec61cbb84a7dc9460e
> for now.
>
Problem solved for me :)
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Mon, 27 Jan 2020 22:08:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Tue, 28 Jan 2020 05:22:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 39281 <at> debbugs.gnu.org (full text, mbox):
> Indeed, my system does have a really slow disk, so it would not surprise me if that contributed to
> it. Of course that shouldn't matter, but that's the only thing I can think it. It would be nice to
> hear if sirgazil can reproduce the fix since I think they were having the same problem on their
> computer.
I see.
> I agree that fixing is better than removing. Good luck debugging. I'm happy to test, but am
> currently out of ideas.
Cool! I'll keep you posted.
> I'm glad that you took this well :). However, while I'm often sarcastic, I wasn't trying to be
> here. What I was trying to express was that while I'm currently running my system with
> gnome-initial-setup removed doesn't mean that I don't appreciate the change to make it present by
> default. Fortunately for me, Guix makes this easy compared to other systems!
Haha. All good then. :-)
Regards,
RG.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Tue, 28 Jan 2020 09:38:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 39281 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Am Montag, den 27.01.2020, 06:24 +0100 schrieb Leo Prikler:
> Perhaps some GNOME people know how to disable this in other ways, but
> it's the first time I've even seen the dialog, so there's not much
> else I can say.
Welp, I found the culprit. It appears to be a bug in gdm-service-type
rather than the gnome meta-package. Specifically, the default GDM
setting appears to be to launch the initial-setup inside GDM "on first
boot", whatever GDM interprets that to be. This can be disabled by
setting "daemon/InitialSetupEnable=false".
Adding this setting to GDM does not affect the initial user setup,
which is probably what raghavgururajan wanted to achieve with the
inclusion of this package into gnome. It only skips the initial system
setup -- a step that Guix should already take care of on its own.
I've attached a patch, that should take care of this bug. So far, I've
only tested it in a VM (with the package added back into gnome), so it
would be nice if one of you could test this with a real reboot before
commiting.
Regards,
Leo
[0001-services-Disable-initial-setup-in-GDM.patch (text/x-patch, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Tue, 28 Jan 2020 18:04:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 39281 <at> debbugs.gnu.org (full text, mbox):
On Tue, 28 Jan 2020, Leo Prikler wrote:
> I've attached a patch, that should take care of this bug. So far, I've
> only tested it in a VM (with the package added back into gnome), so it
> would be nice if one of you could test this with a real reboot before
> commiting.
I'm happy to report that after applying this patch on top of
94600c3960d7e2f12a3a9b6d2ed0d98ddacdd055 (i.e. with gnome-initial-setup
still part of the gnome meta-package), reconfiguring, and rebooting,
everything works as expected. GDM starts up, and after I log it, I'm
presented with the initial setup wizard.
Thanks everyone,
Jack
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Tue, 28 Jan 2020 18:19:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 39281 <at> debbugs.gnu.org (full text, mbox):
---- On Tue, 28 Jan 2020 13:03:08 -0500 Jack Hill <jackhill <at> jackhill.us> wrote ----
> On Tue, 28 Jan 2020, Leo Prikler wrote:
>
> > I've attached a patch, that should take care of this bug. So far, I've
> > only tested it in a VM (with the package added back into gnome), so it
> > would be nice if one of you could test this with a real reboot before
> > commiting.
I uncommented gnome-initial-setup, applied Leo's patch, and GDM works as expected.
> I'm happy to report that after applying this patch on top of
> 94600c3960d7e2f12a3a9b6d2ed0d98ddacdd055 (i.e. with gnome-initial-setup
> still part of the gnome meta-package), reconfiguring, and rebooting,
> everything works as expected. GDM starts up, and after I log it, I'm
> presented with the initial setup wizard.
>
The initial setup window did not appear in my case, but I assume it is because somewhere in my system something says I already went through the setup (I did see the window in a previous boot).
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Tue, 28 Jan 2020 18:22:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 39281 <at> debbugs.gnu.org (full text, mbox):
On Tue, 28 Jan 2020, sirgazil wrote:
> The initial setup window did not appear in my case, but I assume it is
> because somewhere in my system something says I already went through the
> setup (I did see the window in a previous boot).
I beilieve this it tell if it has already run by looking for by
~/.config/gnome-initial-setup-done
Best,
Jack
Information forwarded
to
bug-guix <at> gnu.org
:
bug#39281
; Package
guix
.
(Tue, 28 Jan 2020 18:27:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 39281 <at> debbugs.gnu.org (full text, mbox):
---- On Tue, 28 Jan 2020 13:21:40 -0500 Jack Hill <jackhill <at> jackhill.us> wrote ----
> On Tue, 28 Jan 2020, sirgazil wrote:
>
> > The initial setup window did not appear in my case, but I assume it is
> > because somewhere in my system something says I already went through the
> > setup (I did see the window in a previous boot).
>
> I beilieve this it tell if it has already run by looking for by
> ~/.config/gnome-initial-setup-done
Yep, that file is present.
I also tried with a new user, and the initial setup window was shown as expected.
Thanks,
Reply sent
to
Danny Milosavljevic <dannym <at> scratchpost.org>
:
You have taken responsibility.
(Tue, 28 Jan 2020 20:18:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jack Hill <jackhill <at> jackhill.us>
:
bug acknowledged by developer.
(Tue, 28 Jan 2020 20:18:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 39281-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
thanks for the investigation and patch.
Pushed to guix master as commit 9111f9750084cbc214d36e2ee16308f8edabf11d.
Re-added gnome-initial-setup to gnome with
commit 24882d3d9a0529f34217aac2da2c8d6e2a076a63.
Closing bug report.
[Message part 2 (application/pgp-signature, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 26 Feb 2020 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 60 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.