bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-06 Thread Luis Felipe via Bug reports for GNU Guix 
Closing as «not a bug in Guix».

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-06 Thread Luis Felipe via Bug reports for GNU Guix 
Hi,

On Monday, June 6th, 2022 at 20:50, Ludovic Courtès  wrote:

> Hmm OK. I’m not sure what’s going on; are you sure ‘rygel’ is in $PATH
> when shepherd starts?

No, but I know rygel is in my user profile; I can start it from a terminal. And 
it works when I go back to a previous system generation...

> Anyway, this looks like “not-a-bug” from the perspective of Guix.
> WDYT?
> 

> BTW, I’d encourage you to write a service for Guix Home for Rygel and to
> use Guix Home (then if you have problems that’ll be a bug from the
> perspective of Guix :-)).

So yeah, I'm closing this bug then and I'll be starting rygel manually for now.

Thanks,

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-06 Thread Luis Felipe via Bug reports for GNU Guix 
It turns out the problem is related to user services. I just disabled my user 
services, rebooted, and GNOME session started.

I only have one user service defined in ~/.config/shepherd/init.scm as follows

~~~
;;; Definition of my user-level services.
(use-modules (shepherd service))


;;; SERVICE DEFINITIONS
;;; ===

(define rygel
  (make 
#:provides '(rygel)
#:docstring "Run the Rygel media server."
#:start (make-forkexec-constructor '("rygel"))
#:stop (make-kill-destructor)
#:respawn? #t))


;;; REGISTER SERVICES
;;; =

(register-services rygel)


;;; START SERVICES
;;; ==

(start rygel)

;;; Send shepherd to the background.
(action 'shepherd 'daemonize)
~~~

And I call "shepherd" in the ~/.profile file. This never posed a problem until 
my recent system generations from April to date, though, where I was never able 
to start a GNOME session. So I wonder what's going on now...

For what it's worth, the only error I see in ~/.config/shepherd/shepherd.log is 
this

2022-04-07 11:01:57 system-error("getpgid" "~A" ("No existe el proceso") (3))

"No existe el proceso" meaning, "The process doesn't exist". This error has 
occurred several times since 2021, though.

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-05 Thread Luis Felipe via Bug reports for GNU Guix 
Howdy,


On Friday, June 3rd, 2022 at 22:54, Ludovic Courtès  wrote:

> Here’s another debugging trick; would be great if you could try this:
> 

> --8<---cut here---start->8---
> 

> (define strace-syslogd
> (program-file "strace-syslogd"
> #~(apply execl #$(file-append strace "/bin/strace")
> "strace" ;argv[0]
> "-f" "-Tt" "-o" "/syslogd.log" "-s" "80"
> #$(file-append inetutils "/libexec/syslogd")
> (cdr (command-line)
> --8<---cut here---end--->8---
> 

> 

> and then:
> 

> --8<---cut here---start->8---
> 

> (modify-services %desktop-services
> (syslog-service-type
> _ => (syslog-configuration
> 

> (syslogd strace-syslogd
> --8<---cut here---end--->8---
> 

> 

> This creates a log file, /syslogd.log, which will allow us to see the
> time it takes syslogd to read from /proc/kmsg and hopefully to determine
> the origin of delays.

I see you already tried this on the other machine, but I gave this a try too 
just in case and sent the log to you privately. I'll try the other tricks next.

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#55707: bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-04 Thread Ludovic Courtès 
Hi,

Ludovic Courtès  skribis:

> Here’s another debugging trick; would be great if you could try this:
>
> (define strace-syslogd
>   (program-file "strace-syslogd"
> #~(apply execl #$(file-append strace "/bin/strace")
>  "strace" ;argv[0]
>  "-f" "-Tt" "-o" "/syslogd.log" "-s" "80"
>  #$(file-append inetutils "/libexec/syslogd")
>  (cdr (command-line)
>
>
> and then:
>
> (modify-services %desktop-services
>   (syslog-service-type
>_ => (syslog-configuration
>  (syslogd strace-syslogd
>
> This creates a log file, /syslogd.log, which will allow us to see the
> time it takes syslogd to read from /proc/kmsg and hopefully to determine
> the origin of delays.

I tried this on a machine I have access to that exhibits this slowness,
and here’s what I get (excerpt that spans 2+ seconds of syslogd
activity):

--8<---cut here---start->8---
328   18:46:13 openat(AT_FDCWD, "/dev/console", O_WRONLY|O_CREAT|O_APPEND, 
0644) = 4 <0.99>
328   18:46:13 openat(AT_FDCWD, "/var/log/messages", O_WRONLY|O_CREAT|O_APPEND, 
0644) = 5 <0.75>
328   18:46:13 ioctl(5, TCGETS, 0x7ffe23d6c930) = -1 ENOTTY (Inappropriate 
ioctl for device) <0.000261>
328   18:46:13 openat(AT_FDCWD, "/var/log/debug", O_WRONLY|O_CREAT|O_APPEND, 
0644) = 6 <0.000201>
328   18:46:13 ioctl(6, TCGETS, 0x7ffe23d6c930) = -1 ENOTTY (Inappropriate 
ioctl for device) <0.000138>
328   18:46:13 openat(AT_FDCWD, "/dev/tty12", O_WRONLY|O_CREAT|O_APPEND, 0644) 
= 7 <0.001059>
328   18:46:13 ioctl(7, TCGETS, {B38400 opost isig icanon echo ...}) = 0 
<0.000101>
328   18:46:13 openat(AT_FDCWD, "/var/log/secure", O_WRONLY|O_CREAT|O_APPEND, 
0644) = 8 <0.77>
328   18:46:13 ioctl(8, TCGETS, 0x7ffe23d6c930) = -1 ENOTTY (Inappropriate 
ioctl for device) <0.39>
328   18:46:13 openat(AT_FDCWD, "/var/log/maillog", O_WRONLY|O_CREAT|O_APPEND, 
0644) = 9 <0.70>

[…]

328   18:46:13 read(3, "<5>[0.00] Linux version 5.17.11-gnu (guix@guix) 
(gcc (GCC) 10.3.0, GNU l"..., 1024) = 981 <0.83>
328   18:46:13 rt_sigprocmask(SIG_BLOCK, [HUP ALRM], [], 8) = 0 <0.59>
322   18:46:13 +++ exited with 0 +++
328   18:46:13 newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444, 
st_size=2962, ...}, 0) = 0 <0.49>
328   18:46:13 writev(7, [{iov_base="Jun  4 18:46:13", iov_len=15}, {iov_base=" 
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1}, 
{iov_base="vmunix: [0.00] Linux version 5.17.11-gnu (guix@guix) (gcc 
(GCC) 10.3.0, "..., iov_len=124}, {iov_base="\r\n", iov_len=2}], 6) = 152 
<0.86>
328   18:46:13 fsync(7) = -1 EINVAL (Invalid argument) 
<0.36>
328   18:46:13 writev(6, [{iov_base="Jun  4 18:46:13", iov_len=15}, {iov_base=" 
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1}, 
{iov_base="vmunix: [0.00] Linux version 5.17.11-gnu (guix@guix) (gcc 
(GCC) 10.3.0, "..., iov_len=124}, {iov_base="\n", iov_len=1}], 6) = 151 
<0.63>
328   18:46:13 fsync(6) = 0 <0.380857>
328   18:46:13 writev(5, [{iov_base="Jun  4 18:46:13", iov_len=15}, {iov_base=" 
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1}, 
{iov_base="vmunix: [0.00] Linux version 5.17.11-gnu (guix@guix) (gcc 
(GCC) 10.3.0, "..., iov_len=124}, {iov_base="\n", iov_len=1}], 6) = 151 
<0.79>
328   18:46:13 fsync(5) = 0 <0.131763>
328   18:46:13 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 <0.000213>
328   18:46:13 rt_sigprocmask(SIG_BLOCK, [HUP ALRM], [], 8) = 0 <0.000160>
328   18:46:13 newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444, 
st_size=2962, ...}, 0) = 0 <0.49>
328   18:46:13 writev(7, [{iov_base="Jun  4 18:46:13", iov_len=15}, {iov_base=" 
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1}, 
{iov_base="vmunix: [0.00] Command line: 
BOOT_IMAGE=/gnu/store/w8py29cnikbg69jvxhxb3"..., iov_len=314}, 
{iov_base="\r\n", iov_len=2}], 6) = 342 <0.000123>
328   18:46:13 fsync(7) = -1 EINVAL (Invalid argument) 
<0.40>
328   18:46:13 writev(6, [{iov_base="Jun  4 18:46:13", iov_len=15}, {iov_base=" 
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1}, 
{iov_base="vmunix: [0.00] Command line: 
BOOT_IMAGE=/gnu/store/w8py29cnikbg69jvxhxb3"..., iov_len=314}, {iov_base="\n", 
iov_len=1}], 6) = 341 <0.74>
328   18:46:13 fsync(6) = 0 <0.23>
328   18:46:13 writev(5, [{iov_base="Jun  4 18:46:13", iov_len=15}, {iov_base=" 
", iov_len=1}, {iov_base="localhost", iov_len=9}, {iov_base=" ", iov_len=1}, 
{iov_base="vmunix: [0.00] Command line: 
BOOT_IMAGE=/gnu/store/w8py29cnikbg69jvxhxb3"..., iov_len=314}, {iov_base="\n", 
iov_len=1}], 6) = 341 <0.000156>
328   18:46:13 fsync(5) = 0 <0.099143>
328   18:46:14 r

bug#55707: bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-03 Thread Ludovic Courtès 
Hi,

Luis Felipe  skribis:

> It seems nothing changed. I'm still unable to start a GNOME session, and 
> booting time is about the same.

Indeed.

Here’s another debugging trick; would be great if you could try this:

--8<---cut here---start->8---
(define strace-syslogd
  (program-file "strace-syslogd"
#~(apply execl #$(file-append strace "/bin/strace")
 "strace" ;argv[0]
 "-f" "-Tt" "-o" "/syslogd.log" "-s" "80"
 #$(file-append inetutils "/libexec/syslogd")
 (cdr (command-line)
--8<---cut here---end--->8---

and then:

--8<---cut here---start->8---
(modify-services %desktop-services
  (syslog-service-type
   _ => (syslog-configuration
 (syslogd strace-syslogd
--8<---cut here---end--->8---

This creates a log file, /syslogd.log, which will allow us to see the
time it takes syslogd to read from /proc/kmsg and hopefully to determine
the origin of delays.

TIA!

Ludo’.

bug#55707: bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-02 Thread Luis Felipe via Bug reports for GNU Guix 
Salut,

On Thursday, June 2nd, 2022 at 21:02, Ludovic Courtès  wrote:

> In the meantime, could you try the following config, which disables
> logging on tty12, to see if it boots quicker? The config changes is
> twofold; first, after the ‘use-modules’ form of your OS config, add:
> 

> [...]
> 

> Dunno if it’s silly, but at least it’ll allow us to check whether it’s
> just the framebuffer that’s slowing things down or if it’s something
> else.

It seems nothing changed. I'm still unable to start a GNOME session, and 
booting time is about the same. I recorded a new video:

https://luis-felipe.gitlab.io/media/2022/06/guix-system-ab98b51e-boot-TTY12-less.webm

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-02 Thread Ludovic Courtès 
Hola,

Luis Felipe  skribis:

>> Could it be https://issues.guix.gnu.org/55707? At boot time, if you
>> switch to tty12 (by pressing alt-f12) as soon as it’s available, do you
>> see messages that get printed pretty slowly, like 4–5 lines per second?
>
> Maybe? I recorded a video. Image is low quality, but speed is accurate (I 
> changed to tty12 at second 33):
>
> https://luis-felipe.gitlab.io/media/2022/06/guix-system-ab98b51e-boot-TTY12.webm

Oh yes, that’s exactly what I observed on another machine recently.
I’ll trace to investigate further when I can access it.

In the meantime, could you try the following config, which disables
logging on tty12, to see if it boots quicker?  The config changes is
twofold; first, after the ‘use-modules’ form of your OS config, add:

--8<---cut here---start->8---
(define %syslog.conf
  ;; Custom syslog.conf without /dev/tty12 logging.
  (plain-file "custom-syslog.conf"
  (let loop ((lines (string-split (plain-file-content 
%default-syslog.conf)
  #\newline))
 (result '()))
(match lines
  (()
   (string-join (reverse result) "\n"))
  ((head . tail)
   (if (string-contains head "/dev/tty12")
   (loop tail result) ;drop this line
   (loop tail (cons head result
--8<---cut here---end--->8---

Second, in the ‘services’ field of your config, replace
‘%desktop-services’ with:

--8<---cut here---start->8---
(modify-services %desktop-services
  (syslog-service-type
   _ => (syslog-configuration
 (config-file %syslog.conf
--8<---cut here---end--->8---

Dunno if it’s silly, but at least it’ll allow us to check whether it’s
just the framebuffer that’s slowing things down or if it’s something
else.

Thanks for your help!

Ludo’.

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-02 Thread Luis Felipe via Bug reports for GNU Guix 
Hello again,

On Wednesday, June 1st, 2022 at 19:55, Ludovic Courtès  wrote:

> So it has to do with elogind taking too long to start. Same with
> polkit:

Timeouts are common here...


> --8<---cut here---start->8---
> 

> 854:May 31 12:24:10 localhost polkitd[426]: Started polkitd version 0.120
> 925:May 31 12:24:31 localhost shepherd[1]: [dbus-daemon] ** 
> (accounts-daemon:421): CRITICAL **: 12:24:28.105: error getting polkit 
> authority: Error initializing authority: Error calling StartServiceByName for 
> org.freedesktop.PolicyKit1: Timeout was reached
> --8<---cut here---end--->8---
> 

> Now, something’s wrong with those timestamps, where shepherd’s message,
> which came first, has a timestamp in the future.

Ooh...

> Could it be https://issues.guix.gnu.org/55707? At boot time, if you
> switch to tty12 (by pressing alt-f12) as soon as it’s available, do you
> see messages that get printed pretty slowly, like 4–5 lines per second?

Maybe? I recorded a video. Image is low quality, but speed is accurate (I 
changed to tty12 at second 33):

https://luis-felipe.gitlab.io/media/2022/06/guix-system-ab98b51e-boot-TTY12.webm

At 01:57, it takes a while to start GDM session (that's common; always been 
like that, I think).


> Sorry for not having clearer ideas, but maybe we have a lead…

No worries, thanks again for taking a look at it.

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-06-01 Thread Ludovic Courtès 
Hi Luis,

The parts related to elogind I see from the log are the following:

--8<---cut here---start->8---
190:May 31 12:23:27 localhost shepherd[1]: Service elogind has been started.
220:May 31 12:23:14 localhost elogind[382]: New seat seat0.
264:May 31 12:23:15 localhost elogind[382]: Watching system buttons on 
/dev/input/event2 (Power Button)
280:May 31 12:23:16 localhost dbus-daemon[349]: [system] Activating service 
name='org.freedesktop.login1' requested by ':1.1' (uid=0 pid=383 
comm="/gnu/store/qpaw2f734zlsq153fkn5afcv4k4fk63z-upower") (using servicehelper)
343:May 31 12:23:20 localhost elogind[382]: Watching system buttons on 
/dev/input/event1 (Power Button)
415:May 31 12:23:26 localhost elogind[382]: Watching system buttons on 
/dev/input/event0 (Sleep Button)
604:May 31 12:23:41 localhost dbus-daemon[349]: [system] Failed to activate 
service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
643:May 31 12:23:45 localhost elogind[382]: Watching system buttons on 
/dev/input/event6 (HUION Huion Tablet_HS611 Consumer Control)
684:May 31 12:23:49 localhost gdm: Gdm: GdmLocalDisplayFactory: Failed to issue 
method call: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to 
activate service 'org.freedesktop.login1': timed out 
(service_start_timeout=25000ms)
752:May 31 12:24:18 localhost vmunix: [   17.648359] shepherd[1]: Service 
file-system-/sys/fs/cgroup/elogind has been started.
959:May 31 12:24:33 localhost elogind[382]: New session c1 of user gdm.
--8<---cut here---end--->8---

So it has to do with elogind taking too long to start.  Same with
polkit:

--8<---cut here---start->8---
854:May 31 12:24:10 localhost polkitd[426]: Started polkitd version 0.120
925:May 31 12:24:31 localhost shepherd[1]: [dbus-daemon] ** 
(accounts-daemon:421): CRITICAL **: 12:24:28.105: error getting polkit 
authority: Error initializing authority: Error calling StartServiceByName for 
org.freedesktop.PolicyKit1: Timeout was reached
--8<---cut here---end--->8---

Now, something’s wrong with those timestamps, where shepherd’s message,
which came first, has a timestamp in the future.

Could it be ?  At boot time, if you
switch to tty12 (by pressing alt-f12) as soon as it’s available, do you
see messages that get printed pretty slowly, like 4–5 lines per second?

Sorry for not having clearer ideas, but maybe we have a lead…

Thanks,
Ludo’.

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-05-31 Thread Luis Felipe via Bug reports for GNU Guix 
Hi Ludo,

Since its been a while, lots of commits have gone into master and 
https://issues.guix.gnu.org/55444 is solved, I decided to reconfigure the 
system, and try again. Unfortunately, I still can't start a GNOME session. I 
update the system information below and provide the data you asked for in the 
last message.

My current system generation that presents the same issue is this one:

~~~
Generation 86   May 31 2022 11:42:31(current)
  file name: /var/guix/profiles/system-86-link
  canonical file name: /gnu/store/pfaj2d8w7vwg1ywrb7pib958angiys2r-system
  label: GNU with Linux-Libre 5.17.11
  bootloader: grub-efi
  root device: UUID: 3f651226-f53e-4944-8bf8-a0b8c28cfac5
  kernel: 
/gnu/store/w8py29cnikbg69jvxhxb33cp86vx4lxc-linux-libre-5.17.11/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: d11d27e2e4a0e6d132127f5130533b0ce9d04481
  configuration file: 
/gnu/store/7s2xwvwvsa6nv3mmn6g65vra4mlmlw0w-configuration.scm
~~~

Checking /var/log/messages for the restart after system reconfigure, I see 
several lines that have errors, one of which is CRITICAL:

~~~
...
May 31 12:23:57 localhost vmunix: [0.343582] ACPI BIOS Error (bug): Could 
not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
May 31 12:23:57 localhost vmunix: [0.343589] ACPI Error: Aborting method 
\_SB.PR01._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
May 31 12:23:57 localhost vmunix: [0.343616] ACPI BIOS Error (bug): Could 
not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
May 31 12:23:58 localhost vmunix: [0.343619] ACPI Error: Aborting method 
\_SB.PR02._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
May 31 12:23:37 localhost NetworkManager[380]:   [1654017817.5747] 
manager[0x12a9000]: monitoring kernel firmware directory '/lib/firmware'.
May 31 12:23:58 localhost vmunix: [0.343644] ACPI BIOS Error (bug): Could 
not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)
May 31 12:23:58 localhost vmunix: [0.343648] ACPI Error: Aborting method 
\_SB.PR03._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529)
...
May 31 12:23:49 localhost gdm: Gdm: GdmLocalDisplayFactory: Failed to issue 
method call: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to 
activate service 'org.freedesktop.login1': timed out 
(service_start_timeout=25000ms)
...
May 31 12:24:24 localhost vmunix: [   24.524488] Error: Driver 'pcspkr' is 
already registered, aborting...
...
May 31 12:24:20 localhost gdm: Gdm: Failed to contact accountsservice: Error 
calling StartServiceByName for org.freedesktop.Accounts: Timeout was reached
...
May 31 12:24:31 localhost shepherd[1]: [dbus-daemon] ** (accounts-daemon:421): 
CRITICAL **: 12:24:28.105: error getting polkit authority: Error initializing 
authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: 
Timeout was reached
...
May 31 12:24:47 localhost gnome-session-binary[488]: WARNING: Failed to upload 
environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: 
Name "org.freedesktop.systemd1" does not exist
...
May 31 12:25:00 localhost pulseaudio[552]: [pulseaudio] bluez5-util.c: 
GetManagedObjects() failed: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.bluez was not provided by any .service files
~~~

But I sent the whole log to you privately just in case.

After trying to log in to GNOME, running "sudo herd status" displays pretty 
much the same as before:

~~~
Iniciado:
 + avahi-daemon
 + console-font-tty1
 + console-font-tty2
 + console-font-tty3
 + console-font-tty4
 + console-font-tty5
 + console-font-tty6
 + dbus-system
 + elogind
 + file-system-/boot/efi
 + file-system-/dev/pts
 + file-system-/dev/shm
 + file-system-/gnu/store
 + file-system-/run/systemd
 + file-system-/run/user
 + file-system-/sys/firmware/efi/efivars
 + file-system-/sys/fs/cgroup
 + file-system-/sys/fs/cgroup/blkio
 + file-system-/sys/fs/cgroup/cpu
 + file-system-/sys/fs/cgroup/cpuacct
 + file-system-/sys/fs/cgroup/cpuset
 + file-system-/sys/fs/cgroup/devices
 + file-system-/sys/fs/cgroup/elogind
 + file-system-/sys/fs/cgroup/freezer
 + file-system-/sys/fs/cgroup/memory
 + file-system-/sys/fs/cgroup/perf_event
 + file-system-/sys/fs/cgroup/pids
 + file-system-/sys/kernel/debug
 + file-system-/var/cache/fontconfig
 + file-systems
 + guix-daemon
 + loopback
 + mcron
 + networking
 + nscd
 + ntpd
 + root
 + root-file-system
 + swap-/dev/sda2
 + syslogd
 + term-tty1
 + term-tty2
 + term-tty3
 + term-tty4
 + term-tty5
 + term-tty6
 + udev
 + upower-daemon
 + urandom-seed
 + user-file-systems
 + user-processes
 + virtual-terminal
 + wpa-supplicant
 + xorg-server
Detenido:
 - term-console
Ejecución única (one-shot):
 * host-name
 * sysctl
 * user-homes
~~~

Running "guix system vm config.scm", where config.scm is the same minimal 
config in comment 2 (https://issues.guix.gnu.org/55488#2

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-05-31 Thread Ludovic Courtès 
Hi Luis,

Luis Felipe  skribis:

> On Wednesday, May 18th, 2022 at 8:44 AM, Ludovic Courtès  wrote:
>
>> This is a config that uses Xorg, not Wayland, right?
>
> Right.

[...]

>> What does ‘sudo herd status’ show at that point?

Looks as if everything was started.

Could you share bits of /var/log/messages starting from the line that
reads “syslogd (GNU inetutils 2.0): restart” (the last boot)?  This
could contain sensitive information so you can redact it or share it
privately if you prefer.

>> I wonder if it might be https://issues.guix.gnu.org/55488.
>
> Did you mean another bug number? 55488 is the one I reported :)

Oops, I meant , which is now fixed.

>> If not, could you provide a minimal config that reproduces the problem?
>
> Here's one:

It works fine in ‘guix system vm’.  :-/
(Same for you?)

So it could be a stateful issue, such as stale files in /var/lib/gdm.
One way to test that hypothesis would be, for instance, to run:

  sudo mv /var/lib/gdm/.cache{,.bak}
  sudo herd restart xorg-server

Thanks,
Ludo’.

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-05-18 Thread Luis Felipe via Bug reports for GNU Guix 
Hi Ludo,

On Wednesday, May 18th, 2022 at 8:44 AM, Ludovic Courtès  wrote:

> This is a config that uses Xorg, not Wayland, right?

Right.

> > In the real machine, only a black screen appears. After hours, there is no 
> > change. There is no mouse pointer or any indication that the desktop has 
> > loaded.
> > 

> > In the virtual machine, you see a black screen and the mouse pointer 
> > appearing sometimes and then disappearing. After a minute, you are taken 
> > back to the log in screen, which now behaves erratically: when you click on 
> > your user to log in again, it shows the username input box, and, once you 
> > move the pointer to enter your username, the view is changed back to the 
> > list of users. The same happens everytime you try to log in again.
> 

> 

> What does ‘sudo herd status’ show at that point?

~~~
Iniciado (Started):
 + avahi-daemon
 + console-font-tty1
 + console-font-tty2
 + console-font-tty3
 + console-font-tty4
 + console-font-tty5
 + console-font-tty6
 + dbus-system
 + elogind
 + file-system-/boot/efi
 + file-system-/dev/pts
 + file-system-/dev/shm
 + file-system-/gnu/store
 + file-system-/run/systemd
 + file-system-/run/user
 + file-system-/sys/firmware/efi/efivars
 + file-system-/sys/fs/cgroup
 + file-system-/sys/fs/cgroup/blkio
 + file-system-/sys/fs/cgroup/cpu
 + file-system-/sys/fs/cgroup/cpuacct
 + file-system-/sys/fs/cgroup/cpuset
 + file-system-/sys/fs/cgroup/devices
 + file-system-/sys/fs/cgroup/elogind
 + file-system-/sys/fs/cgroup/freezer
 + file-system-/sys/fs/cgroup/memory
 + file-system-/sys/fs/cgroup/perf_event
 + file-system-/sys/fs/cgroup/pids
 + file-system-/sys/kernel/debug
 + file-system-/var/cache/fontconfig
 + file-systems
 + guix-daemon
 + loopback
 + mcron
 + networking
 + nscd
 + ntpd
 + root
 + root-file-system
 + swap-/dev/sda2
 + syslogd
 + term-tty1
 + term-tty2
 + term-tty3
 + term-tty4
 + term-tty5
 + term-tty6
 + udev
 + upower-daemon
 + urandom-seed
 + user-file-systems
 + user-processes
 + virtual-terminal
 + wpa-supplicant
 + xorg-server
Detenido (Stopped):
 - term-console
Ejecución única (one-shot):
 * host-name
 * sysctl
 * user-homes
~~~


> I wonder if it might be https://issues.guix.gnu.org/55488.

Did you mean another bug number? 55488 is the one I reported :)


> If not, could you provide a minimal config that reproduces the problem?

Here's one:

~~~
(use-modules (gnu)
 (gnu packages dns))
(use-service-modules admin desktop networking ssh xorg)


;;; CONSTANTS
;;; =

(define DESKTOP_USER_GROUPS
  (list "wheel"
"netdev"
"audio"
"video"
"cdrom"
"kvm"))



;;; SYSTEM CONFIGURATION
;;; 

(operating-system
  (locale "es_CO.utf8")
  (timezone "America/Bogota")
  (keyboard-layout
   (keyboard-layout "latam" #:model "pc104" #:options '("ctrl:nocaps")))
  (kernel-arguments (list "quiet" "pci=noaer"))
  (bootloader
(bootloader-configuration
  (bootloader grub-efi-bootloader)
  (targets (list "/boot/efi"))
  (keyboard-layout keyboard-layout)))
  (swap-devices
   (list (swap-space
  (target "/dev/sda2"
  (file-systems
(cons* (file-system
 (mount-point "/")
 (device
   (uuid "3f651226-f53e-4944-8bf8-a0b8c28cfac5"
 'ext4))
 (type "ext4"))
   (file-system
 (mount-point "/boot/efi")
 (device (uuid "A0CA-050E" 'fat32))
 (type "vfat"))
   %base-file-systems))
  (host-name "gnu")
  (users
   (cons*
(user-account
 (name "someone")
 (comment "some person")
 (group "users")
 (home-directory "/home/someone")
 (supplementary-groups DESKTOP_USER_GROUPS)
 (password (crypt "InitialPassword!" "$6$abc")))
%base-user-accounts))
  (packages
   (cons*
;; Locales (all locales).
(specification->package "glibc-locales")
;; For HTTPS access.
(specification->package "nss-certs")
%base-packages))
  (services
   (cons*
(service gnome-desktop-service-type)
(set-xorg-configuration
 (xorg-configuration
  (keyboard-layout keyboard-layout)))
%desktop-services)))
~~~

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-05-18 Thread Ludovic Courtès 
Hi Luis,

Luis Felipe  skribis:

> I'm using the Guix system. After upgrading it to recent versions of Guix 
> (e.g. guix 1110479), I can't access the GNOME desktop. The problem is also 
> present when creating a virtual machine with the same configuration file used 
> for the real machine (guix system vm config.scm).

This is a config that uses Xorg, not Wayland, right?

> In the real machine, only a black screen appears. After hours, there is no 
> change. There is no mouse pointer or any indication that the desktop has 
> loaded.
>
> In the virtual machine, you see a black screen and the mouse pointer 
> appearing sometimes and then disappearing. After a minute,  you are taken 
> back to the log in screen, which now behaves erratically: when you click on 
> your user to log in again, it shows the username input box, and, once you 
> move the pointer to enter your username, the view is changed back to the list 
> of users. The same happens everytime you try to log in again.

What does ‘sudo herd status’ show at that point?

I wonder if it might be .

If not, could you provide a minimal config that reproduces the problem?

Thanks,
Ludo’.

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

2022-05-17 Thread Luis Felipe via Bug reports for GNU Guix 
I'm using the Guix system. After upgrading it to recent versions of Guix (e.g. 
guix 1110479), I can't access the GNOME desktop. The problem is also present 
when creating a virtual machine with the same configuration file used for the 
real machine (guix system vm config.scm).


STEPS TO REPRODUCE

I guess these:

1. guix pull --commit=1110479d2d4dc69fc66eadb4a6c24ca2f13afa93
2. guix package -m MANIFEST.scm
3. sudo guix system reconfigure CONFIG.scm
4. sudo reboot
5. Log in in GDM

(MANIFEST and CONFIG available on request if necessary)


EXPECTED RESULT

After a few seconds, the GNOME desktop shows up, and you can start working 
normally.


UNEXPECTED RESULT

In the real machine, only a black screen appears. After hours, there is no 
change. There is no mouse pointer or any indication that the desktop has loaded.

In the virtual machine, you see a black screen and the mouse pointer appearing 
sometimes and then disappearing. After a minute,  you are taken back to the log 
in screen, which now behaves erratically: when you click on your user to log in 
again, it shows the username input box, and, once you move the pointer to enter 
your username, the view is changed back to the list of users. The same happens 
everytime you try to log in again.


ADDITIONAL INFORMATION

The most recent system generation where this problem does not occur for me is

~~~
Generation 81   Mar 24 2022 12:31:43
  file name: /var/guix/profiles/system-81-link
  canonical file name: /gnu/store/lwaf0xhp93k7l9yibxfyiwwm5rv5d52q-system
  label: GNU with Linux-Libre 5.16.17
  bootloader: grub-efi
  root device: UUID: 3f651226-f53e-4944-8bf8-a0b8c28cfac5
  kernel: 
/gnu/store/0bx2k3qslb9hw9cf52hl9xal39455maa-linux-libre-5.16.17/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: ab98b51ef1304e975da127e3092d01dcc7f02657
  configuration file: 
/gnu/store/64rz9n8hd1np1aljjiwvy2347abjv04w-configuration.scm
~~~

The oldest generation where the problem still occurs is

~~~
Generation 83   Apr 18 2022 13:37:16
  file name: /var/guix/profiles/system-83-link
  canonical file name: /gnu/store/y78s36kn6h4cnz50a11gi6zv662x2f95-system
  label: GNU with Linux-Libre 5.16.20
  bootloader: grub-efi
  root device: UUID: 3f651226-f53e-4944-8bf8-a0b8c28cfac5
  kernel: 
/gnu/store/ai4r464i09bay67f33qlmgxd7kdqjv5f-linux-libre-5.16.20/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 237d90a7808cfdced34b34595eba16632cbcb89e
  configuration file: 
/gnu/store/7s2xwvwvsa6nv3mmn6g65vra4mlmlw0w-configuration.scm
~~~


WORKAROUND

Personally, I choose one of these options:

1. Use Sway as an emergency desktop (which is always in my system config file).
2. Roll back to a generation of the system that works (e.g. guix ab98b51e). 
This usually requires to roll back to a previous generation of the user profile 
as well to avoid other errors when logging in to GNOME.


SYSTEM INFORMATION

Guix system:

~~~
guix system describe
Generation 84   May 16 2022 22:04:49(current)
  file name: /var/guix/profiles/system-84-link
  canonical file name: /gnu/store/hy2r1ff491v5rlscwz26880sx87a50la-system
  label: GNU with Linux-Libre 5.17.7
  bootloader: grub-efi
  root device: UUID: 3f651226-f53e-4944-8bf8-a0b8c28cfac5
  kernel: /gnu/store/0yl7hq7aca9dvlc514mj97f9f7s5vns4-linux-libre-5.17.7/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 1110479d2d4dc69fc66eadb4a6c24ca2f13afa93
  configuration file: 
/gnu/store/7s2xwvwvsa6nv3mmn6g65vra4mlmlw0w-configuration.scm
~~~

Guix:

~~~
guix describe
Generation 56   May 15 2022 08:04:22(current)
  guix 1110479
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1110479d2d4dc69fc66eadb4a6c24ca2f13afa93
~~~



---
Luis Felipe López Acevedo
https://luis-felipe.gitlab.io/

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature