bug#62890: StumpWM fails to start - Read only file system

bug#62890: StumpWM fails to start - Read only file system

[Kjartan Óli Águstsson]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

I just started experiencing an issue with stumpwm where it fails to
start, complaining about a read only file system.  A web search for the
error message leads me to
https://lists.gnu.org/archive/html/help-guix/2021-02/msg00080.html,
which sounds exactly like the problem I'm experiencing.  I'm unsure how
to get the backtrace shared in that thread, or in general how to proceed
with debugging this.

guix describe shows:
  guix 9a5e1dc
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 9a5e1dc1f16f5f8c056e64f2077b035784003673
but I tried rolling back to an earlier system generation:
  guix:
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: d513ba83ebca347164098bb0fa1354f3657bc7e2
to no success so I doubt it is a new change in Guix.

Unless I'm missing something in the help-guix thread there is no
solution discussed there, so any help in debugging this would be greatly
appreciated.

-- 
Kjartan Oli Agustsson
GPG Key fingerprint: 4801 0D71 49C0 1DD6 E5FD  6AC9 D757 2FE3 605E E6B0

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 691 bytes --]

bug#62890: StumpWM fails to start - Read only file system

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

Kjartan Óli Águstsson <kjartanoli@outlook.com> skribis:

> I just started experiencing an issue with stumpwm where it fails to
> start, complaining about a read only file system.  A web search for the
> error message leads me to
> https://lists.gnu.org/archive/html/help-guix/2021-02/msg00080.html,
> which sounds exactly like the problem I'm experiencing.  I'm unsure how
> to get the backtrace shared in that thread, or in general how to proceed
> with debugging this.
>
> guix describe shows:
>   guix 9a5e1dc
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 9a5e1dc1f16f5f8c056e64f2077b035784003673
> but I tried rolling back to an earlier system generation:
>   guix:
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: d513ba83ebca347164098bb0fa1354f3657bc7e2
> to no success so I doubt it is a new change in Guix.
>
> Unless I'm missing something in the help-guix thread there is no
> solution discussed there, so any help in debugging this would be greatly
> appreciated.

Hi,

I just got the same problem after reconfiguring a machine (using
guix-home, but I'm not sure if it is relevant). It only happens when
I try to load extra modules from the ".stumpwm/init.lisp" file.

It looks like the configuration indicating where to search for the
compiled Common Lisp files (ASDF's source-registry and
output-translations) is not taken into consideration by Stumpwm
anymore... so it tries to recompile them in the wrong place.

As a workaround, replacing:
  exec stumpwm
by:
  exec sbcl --no-userinit --non-interactive --eval '(require :asdf)' --eval '(asdf:load-system "stumpwm")' --eval '(stumpwm:stumpwm)'
in my ".xsession" file seems to work...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#62890: StumpWM fails to start - Read only file system

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]

I think the issue comes from grafts.

Without grafts, the ASDF configuration is coherent; the path for
stumpwm's sources and libraries is the same everywhere (here in
stumpwm:lib and sbcl-stumpwm-cpu):

--8<---------------cut here---------------start------------->8---
$ cat $(guix build --no-grafts stumpwm | grep 'lib$')/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 ("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree "/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

$ cat $(guix build --no-grafts sbcl-stumpwm-cpu)/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 ("/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree "/gnu/store/v18hzbid3rjblz35s69w4c0gcsx9f9w9-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")
--8<---------------cut here---------------end--------------->8---


With grafts, we get different paths, which probably explains why ASDF
fails to find the compiled Lisp files it is looking for:

--8<---------------cut here---------------start------------->8---
$ cat $(guix build stumpwm | grep 'lib$')/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 ("/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree "/gnu/store/wsjyjqf20ldbmgdq96h73qikmwhxv36c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

$ cat $(guix build sbcl-stumpwm-cpu)/etc/common-lisp/*/50-stumpwm.conf
(("/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 ("/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree "/gnu/store/h8i8mwsgjb96r407xqa2sf56clgy7r7c-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#62890: StumpWM with --no-grafts and System/Home mismatches

[Richard Sent]

I've noticed the same behavior and was able to resolve it by adding 
--no-grafts whenever I reconfigure my system and home profiles. Likely 
just the former is necessary, but I haven't tested it.

I've also noticed this behavior (SBCL trying to place .fasl in 
/gnu/store) once when I pulled, reconfigured system, and didn't 
reconfigure home. I have my setup configured such that StumpWM is 
installed at the system level, while contrib packages are installed via 
guix home.

I ran a git bisect and continually reconfigured my system to try and 
narrow down what commit it was, and was able to isolate it to either an 
xorgproto or Mesa update. Home was built before (49a7a95ba4) the commit, 
System after (d55a4431f3). The offending commit in this particular case 
lies somewhere between d55a4431f3 and 17c3a3bfff. (This probably isn't 
actually a bug, but I'm posting it in case anyone else runs into a 
similar issue in the future.)

If anyone else has a similar setup, encounters this issue, and already 
uses --no-grafts, be sure both the system and home profiles are built 
with the same version of Guix.

Richard Sent

bug#62890: Specific graft that's at fault

[Richard Sent]

Hi Guix!

The issue is likely caused by the glibc/fixed graft in (gnu packages
base). When this graft is removed, the the path discussed earlier is
coherent. Other grafts do not appear relevant.

--8<---------------cut here---------------start------------->8---
Building stumpwm
(("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 ("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree "/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")

Building sbcl-stumpwm-cpu
(("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*)
 ("/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/lib/common-lisp/sbcl/stumpwm"
  :**/
  :*.*.*))

(:tree "/gnu/store/w2jw4s7dnw0yfsp5125dpxiyz6lp7v3w-stumpwm-22.11-lib/share/common-lisp/sbcl/stumpwm")
--8<---------------cut here---------------end--------------->8---

Unfortunately stumpwm currently doesn't build on core-updates so I can't
check if the discrepency would occur there where glibc isn't grafted.

How exactly does that graft causes the problem? No clue.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.