[bug#29409] Remove hugetlb control group on ARM32.

[Ludovic Courtès]

Hello!

Tobias Geerinckx-Rice <address@hidden> skribis:

> Mathieu Othacehe wrote on 20/12/17 at 20:15:
>> Mounting %control-groups fails on ARM32 platform because we build a
>> kernel without LPAE support which implies hugetlb control group cannot
>> be supported.
>
> What happens when the mount fails? At first glance, %control-groups
> aren't needed-for-boot. Unfortunately, I'm not able to test it now: it's
> all disgustingly hypothetical from here on.

If ‘mount’ fails with EOPNOTSUPP, we could handle that specifically,
perhaps with an (optional? #t) flag on the file system or something.

>> Like Debian we could have an ARMMP and ARMMP-LPAE kernel but the problem
>> would still exists for ARMMP.
>> 
>> I'm not sure what do about, a workaround could be the ugly hack
>> attached, WDYT ?
>
> So to me your patch implies that mounting the hugetlb cgroup is entirely
> optional, and that no other (known) services will actually break if it's
> not mounted. %control-groups are mounted as part of %base-file-systems,
> about which the manual:
>
>   -- Scheme Variable: %base-file-systems
>       These are essential file systems that are required on normal
>       systems, such as %PSEUDO-TERMINAL-FILE-SYSTEM and %IMMUTABLE-STORE
>       (see below.)  Operating system declarations should always contain
>       at least these.
>
> In practice, %base-file-systems depends on more mounts than it probably
> should, since some of them aren't essential and some can't even exist on
> some platforms. That keeps things simple, and isn't a problem *if*
> mounting optional file systems like %control-groups simply logs the
> error and continues normally with the next mount. A bit dirty, perhaps,
> but there are more places in file-systems.scm that feel that way to me.
>
> If the patch only serves to suppress such an error, I don't think it's
> worth copying details of our kernel configurations around.
>
> If it fixes a broken boot, there's something... off about the way we
> handle mounts.
>
> ...or maybe I am. Thoughts?

‘%base-file-systems’ is loosely defined and it’s a moving target.

Probably ‘%control-groups’ should be part of ‘%elogind-file-systems’ and
not ‘%base-file-systems’, because I think it’s elogind that needs them.

That would solve bare-bones-style configuration that doesn’t use
elogind.  It wouldn’t help for all things desktop, though.

WDYT?

> --- a/gnu/system/file-systems.scm
> +++ b/gnu/system/file-systems.scm
> @@ -21,6 +21,7 @@
>    #:use-module (rnrs bytevectors)
>    #:use-module (srfi srfi-1)
>    #:use-module (guix records)
> +  #:use-module (guix utils)

This is not great because (gnu system file-systems) is also used on the
“build side”, but (guix utils) would pull in (guix config), which is
configuration-dependent (it contains data that can vary from system to
system):

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix modules)
scheme@(guile-user)> (source-module-closure '((guix utils)))
$3 = ((guix utils) (guix config) (guix memoization) (guix profiling) (guix 
build utils) (guix build syscalls))
scheme@(guile-user)> (source-module-closure '((gnu system file-systems)))
$4 = ((gnu system file-systems) (guix records) (gnu system uuid))
--8<---------------cut here---------------end--------------->8---

Thanks,
Ludo’.