[bug#73494,v3,0/3] tmpfs /run

  V2 -> V3:

  For file-system-mapping->bind-mount, drop the first 4 characters in source
  when it's a string starting with "/var/run", instead of using canonicalized
  source (as in V2), since the source can't be ensured to exist at evaluation
  time.

Hilton Chain (3):
  file-systems: %base-file-systems: Add tmpfs /run.
  services: cleanup: Make /var/run a symlink of /run.
  services: activation: Continue on exceptions.

 doc/guix.texi               |  8 +++++++
 gnu/services.scm            | 42 +++++++++++++++++++++++++++----------
 gnu/services/dbus.scm       | 31 ---------------------------
 gnu/system/file-systems.scm | 24 +++++++++++++++++++--
 4 files changed, 61 insertions(+), 44 deletions(-)


base-commit: 18e6031f7405b8b9c38255db1957e1eb064d4632
prerequisite-patch-id: d239751bbc956c6055d0a7c7caf8b3bb3ec6a623
--
2.48.1
  

Hi,

Hilton Chain <hako@ultrarare.space> writes:

> V2 -> V3:
>
>   For file-system-mapping->bind-mount, drop the first 4 characters in source
>   when it's a string starting with "/var/run", instead of using canonicalized
>   source (as in V2), since the source can't be ensured to exist at evaluation
>   time.
>
> Hilton Chain (3):
>   file-systems: %base-file-systems: Add tmpfs /run.

This one looks good to me.

>   services: cleanup: Make /var/run a symlink of /run.

This still has the jami system test failing (make check-system
TESTS=jami).  This must be resolved before we can merge this.

>   services: activation: Continue on exceptions.

I like it, but I think you can't use the i18n or diagnostics user-facing
modules on the build side, as their closure is too big to be reasonably
imported.  Most modules intended to be used on the builder side are
namespaced under (guix build ...), but there are a few excptions.

I'll try to understand the jami test failure, but my last experiments
were not successful.  Help welcome.
  

On Sun, 09 Mar 2025 15:34:58 +0800,
Maxim Cournoyer wrote:
>
> Hi,
>
> Hilton Chain <hako@ultrarare.space> writes:
>
> > V2 -> V3:
> >
> >   For file-system-mapping->bind-mount, drop the first 4 characters in source
> >   when it's a string starting with "/var/run", instead of using canonicalized
> >   source (as in V2), since the source can't be ensured to exist at evaluation
> >   time.
> >
> > Hilton Chain (3):
> >   file-systems: %base-file-systems: Add tmpfs /run.
>
> This one looks good to me.
>
> >   services: cleanup: Make /var/run a symlink of /run.
>
> This still has the jami system test failing (make check-system
> TESTS=jami).  This must be resolved before we can merge this.
>
> >   services: activation: Continue on exceptions.
>
> I like it, but I think you can't use the i18n or diagnostics user-facing
> modules on the build side, as their closure is too big to be reasonably
> imported.  Most modules intended to be used on the builder side are
> namespaced under (guix build ...), but there are a few excptions.

Just checked, these two modules are already inside (gnu build activation)'s
closure.

> I'll try to understand the jami test failure, but my last experiments
> were not successful.  Help welcome.

Did your have a luck with the dbus change you mentioned on IRC?
  

On Thu, 13 Mar 2025 10:06:35 +0800,
Hilton Chain wrote:
>
> > I'll try to understand the jami test failure, but my last experiments
> > were not successful.  Help welcome.
>
> Did your have a luck with the dbus change you mentioned on IRC?

Found out it's ‘mkdir-p/perms’ failed, from its docstring: "Additionally, verify
no component of DIRECTORY is a symbolic link".

Changing it to mkdir-p + chown + chmod passes the test.
  

Hi,

Hilton Chain <hako@ultrarare.space> writes:

[...]

>> I like it, but I think you can't use the i18n or diagnostics user-facing
>> modules on the build side, as their closure is too big to be reasonably
>> imported.  Most modules intended to be used on the builder side are
>> namespaced under (guix build ...), but there are a few excptions.
>
> Just checked, these two modules are already inside (gnu build activation)'s
> closure.

Oh, indeed:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (set! %load-hook (lambda (filename)
                   (format #t "Loading ~a ...\n" filename)))

scheme@(guile-user)> ,use (gnu build activation)
Loading /run/current-system/profile/share/guile/site/3.0/gnu/build/activation.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/gnu/system/accounts.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/guix/records.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/gnu/system/privilege.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/gnu/build/accounts.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/guix/combinators.scm ...
Loading /gnu/store/ylwk2vn18dkzkj0nxq2h4vjzhz17bm7c-guile-3.0.9/share/guile/3.0/srfi/srfi-19.scm ...
[...]
Loading /run/current-system/profile/share/guile/site/3.0/gnu/build/file-systems.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/gnu/system/uuid.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/gnu/system/file-systems.scm ...
Loading /gnu/store/ylwk2vn18dkzkj0nxq2h4vjzhz17bm7c-guile-3.0.9/share/guile/3.0/srfi/srfi-2.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/guix/diagnostics.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/guix/colors.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/guix/memoization.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/guix/profiling.scm ...
Loading /run/current-system/profile/share/guile/site/3.0/guix/i18n.scm ...
[...]
--8<---------------cut here---------------end--------------->8---

It comes from (gnu system file-systems), which has in a comment:

--8<---------------cut here---------------start------------->8---
;;; Note: this file system is used both in the Shepherd and on the "host
;;; side", so it must not include (gnu packages …) modules.
--8<---------------cut here---------------end--------------->8---

I guess that's fine then.

>> I'll try to understand the jami test failure, but my last experiments
>> were not successful.  Help welcome.
>
> Did your have a luck with the dbus change you mentioned on IRC?

The jami-dbus-session service now runs, but it errors starting the
actual jami service.  To be investigated.
  

On Thu, 13 Mar 2025 21:20:40 +0800,
Maxim Cournoyer wrote:
>
> >> I'll try to understand the jami test failure, but my last experiments
> >> were not successful.  Help welcome.
> >
> > Did your have a luck with the dbus change you mentioned on IRC?
>
> The jami-dbus-session service now runs, but it errors starting the
> actual jami service.  To be investigated.

I think we can actually get rid of the symlink issue, by using a bind mount.

I actually thought about this even before trying to use a symlink, but it fails
at initrd stage, not sure why.

I just tried to add the bind mount in cleanup-service-type, which is executed
after initrd and before activation, and succeeded :)