Remounting tmpfs

Remounting tmpfs

[7e9wc56emjakcm]

On a system I'm porting to guix I have 2GB tmpfs with subdirectories
like /tmpfs/etc that I remount to /etc with an overlay filesystem.

The current way I do this in systemd is making a service dependency
between the /tmpfs and /etc mounts that mkdirs /tmpfs/etc and
/tmpfs/etc_work, but AFAICT filesystem definitions in guix can only have
filesystem dependencies.

Are there any other ways I can do this without copying/pasting/modifying
gobs of core guix code into my system definition?  Like somehow
appending (mkdir /tmpfs/etc) onto the tmpfs filesystem service start
procedure or something.

Re: Remounting tmpfs

[Ludovic Courtès]

Hello,

7e9wc56emjakcm@s.rendaw.me skribis:

> On a system I'm porting to guix I have 2GB tmpfs with subdirectories
> like /tmpfs/etc that I remount to /etc with an overlay filesystem.
>
> The current way I do this in systemd is making a service dependency
> between the /tmpfs and /etc mounts that mkdirs /tmpfs/etc and
> /tmpfs/etc_work, but AFAICT filesystem definitions in guix can only have
> filesystem dependencies.
>
> Are there any other ways I can do this without copying/pasting/modifying
> gobs of core guix code into my system definition?  Like somehow
> appending (mkdir /tmpfs/etc) onto the tmpfs filesystem service start
> procedure or something.

In Guix /etc is mostly populated by “activation programs”, which are
generated from your config.  So I’m not sure what you describe would
make much sense.

Now, you could try to add a file system declaration that mounts /etc,
with (needed-for-boot? #t).

HTH,
Ludo’.

Re: Remounting tmpfs

[7e9wc56emjakcm]

On 4/9/19 11:58 PM, Ludovic Courtès wrote:
> Hello,
>
> 7e9wc56emjakcm@s.rendaw.me skribis:
>
>> On a system I'm porting to guix I have 2GB tmpfs with subdirectories
>> like /tmpfs/etc that I remount to /etc with an overlay filesystem.
>>
>> The current way I do this in systemd is making a service dependency
>> between the /tmpfs and /etc mounts that mkdirs /tmpfs/etc and
>> /tmpfs/etc_work, but AFAICT filesystem definitions in guix can only have
>> filesystem dependencies.
>>
>> Are there any other ways I can do this without copying/pasting/modifying
>> gobs of core guix code into my system definition?  Like somehow
>> appending (mkdir /tmpfs/etc) onto the tmpfs filesystem service start
>> procedure or something.
> In Guix /etc is mostly populated by “activation programs”, which are
> generated from your config.  So I’m not sure what you describe would
> make much sense.

So if /etc can be read-only and boot I'm probably fine... my experience
with other distros was that some other processes needed to write to it. 
Ex: modifying resolv.conf.

> Now, you could try to add a file system declaration that mounts /etc,
> with (needed-for-boot? #t).

My goal is to have a read-only / mount with the ability for programs to
make temporary modifications for operational purposes when necessary, in
limited scopes (like /etc).  Can you elaborate on what you're suggesting
here?  Mounting something other than the overlayfs on /etc would hide
the system config files.  I might be able to use another mount to create
a pseudo- /tmpfs/etc_work subdirectory but it sounds kind of wormy and
overlayfs requires the upper dir and workdir to be the same filesystem
which I think precludes doing any mounting for those subdirectories.

Thanks for the suggestions!

Re: Remounting tmpfs

[rendaw]

On 4/10/19 12:24 AM, 7e9wc56emjakcm@s.rendaw.me wrote:
> On 4/9/19 11:58 PM, Ludovic Courtès wrote:
>> Hello,
>>
>> 7e9wc56emjakcm@s.rendaw.me skribis:
>>
>>> On a system I'm porting to guix I have 2GB tmpfs with subdirectories
>>> like /tmpfs/etc that I remount to /etc with an overlay filesystem.
>>>
>>> The current way I do this in systemd is making a service dependency
>>> between the /tmpfs and /etc mounts that mkdirs /tmpfs/etc and
>>> /tmpfs/etc_work, but AFAICT filesystem definitions in guix can only have
>>> filesystem dependencies.
>>>
>>> Are there any other ways I can do this without copying/pasting/modifying
>>> gobs of core guix code into my system definition?  Like somehow
>>> appending (mkdir /tmpfs/etc) onto the tmpfs filesystem service start
>>> procedure or something.
>> In Guix /etc is mostly populated by “activation programs”, which are
>> generated from your config.  So I’m not sure what you describe would
>> make much sense.
> So if /etc can be read-only and boot I'm probably fine... my experience
> with other distros was that some other processes needed to write to it. 
> Ex: modifying resolv.conf.
>
>> Now, you could try to add a file system declaration that mounts /etc,
>> with (needed-for-boot? #t).
> My goal is to have a read-only / mount with the ability for programs to
> make temporary modifications for operational purposes when necessary, in
> limited scopes (like /etc).  Can you elaborate on what you're suggesting
> here?  Mounting something other than the overlayfs on /etc would hide
> the system config files.  I might be able to use another mount to create
> a pseudo- /tmpfs/etc_work subdirectory but it sounds kind of wormy and
> overlayfs requires the upper dir and workdir to be the same filesystem
> which I think precludes doing any mounting for those subdirectories.
>
> Thanks for the suggestions!
>
So I think the short answer I was looking for is that

1. guix already does something like this - it mounts root read only and
overlays a tempfs on top (it's still writable though somehow)

2. guix has a complicated mounting process that isn't amenable to
changes like this


Since my question about disk-image gets into the root filesystem tree
I'll move this discussion there entirely.

Re: Remounting tmpfs

[Ludovic Courtès]

Hi,

7e9wc56emjakcm@s.rendaw.me skribis:

> On 4/9/19 11:58 PM, Ludovic Courtès wrote:
>> Hello,
>>
>> 7e9wc56emjakcm@s.rendaw.me skribis:
>>
>>> On a system I'm porting to guix I have 2GB tmpfs with subdirectories
>>> like /tmpfs/etc that I remount to /etc with an overlay filesystem.
>>>
>>> The current way I do this in systemd is making a service dependency
>>> between the /tmpfs and /etc mounts that mkdirs /tmpfs/etc and
>>> /tmpfs/etc_work, but AFAICT filesystem definitions in guix can only have
>>> filesystem dependencies.
>>>
>>> Are there any other ways I can do this without copying/pasting/modifying
>>> gobs of core guix code into my system definition?  Like somehow
>>> appending (mkdir /tmpfs/etc) onto the tmpfs filesystem service start
>>> procedure or something.
>> In Guix /etc is mostly populated by “activation programs”, which are
>> generated from your config.  So I’m not sure what you describe would
>> make much sense.
>
> So if /etc can be read-only and boot I'm probably fine... my experience
> with other distros was that some other processes needed to write to it. 
> Ex: modifying resolv.conf.

/etc is writable because of things like ‘resolv.conf’.

/etc consists mostly of immutable files derived directly from your OS
config (/etc/passwd, /etc/hosts, /etc/polkit-1, /etc/pam.d, etc.), along
with files that contains bits of state (/etc/shadow, /etc/resolv.conf.)

The former are directly managed by Guix, while the latter are either
left as is or touched with care by Guix (/etc/shadow in particular.)

>> Now, you could try to add a file system declaration that mounts /etc,
>> with (needed-for-boot? #t).
>
> My goal is to have a read-only / mount with the ability for programs to
> make temporary modifications for operational purposes when necessary, in
> limited scopes (like /etc).  Can you elaborate on what you're suggesting
> here?  Mounting something other than the overlayfs on /etc would hide
> the system config files.  I might be able to use another mount to create
> a pseudo- /tmpfs/etc_work subdirectory but it sounds kind of wormy and
> overlayfs requires the upper dir and workdir to be the same filesystem
> which I think precludes doing any mounting for those subdirectories.

The overlay makes a lot of sense.  This is what ‘guix system vm’ does:
see the #:volatile-root? parameter of ‘raw-initrd’.

Perhaps you could simply set #:volatile-root? #t in your initrd to
obtain what you want?

Thanks,
Ludo’.

Re: Remounting tmpfs

[rendaw]

On 4/18/19 5:31 AM, Ludovic Courtès wrote:
> Hi,
>
> 7e9wc56emjakcm@s.rendaw.me skribis:
>
>> On 4/9/19 11:58 PM, Ludovic Courtès wrote:
>>> Hello,
>>>
>>> 7e9wc56emjakcm@s.rendaw.me skribis:
>>>
>>>> On a system I'm porting to guix I have 2GB tmpfs with subdirectories
>>>> like /tmpfs/etc that I remount to /etc with an overlay filesystem.
>>>>
>>>> The current way I do this in systemd is making a service dependency
>>>> between the /tmpfs and /etc mounts that mkdirs /tmpfs/etc and
>>>> /tmpfs/etc_work, but AFAICT filesystem definitions in guix can only have
>>>> filesystem dependencies.
>>>>
>>>> Are there any other ways I can do this without copying/pasting/modifying
>>>> gobs of core guix code into my system definition?  Like somehow
>>>> appending (mkdir /tmpfs/etc) onto the tmpfs filesystem service start
>>>> procedure or something.
>>> In Guix /etc is mostly populated by “activation programs”, which are
>>> generated from your config.  So I’m not sure what you describe would
>>> make much sense.
>> So if /etc can be read-only and boot I'm probably fine... my experience
>> with other distros was that some other processes needed to write to it. 
>> Ex: modifying resolv.conf.
> /etc is writable because of things like ‘resolv.conf’.
>
> /etc consists mostly of immutable files derived directly from your OS
> config (/etc/passwd, /etc/hosts, /etc/polkit-1, /etc/pam.d, etc.), along
> with files that contains bits of state (/etc/shadow, /etc/resolv.conf.)
>
> The former are directly managed by Guix, while the latter are either
> left as is or touched with care by Guix (/etc/shadow in particular.)
>
>>> Now, you could try to add a file system declaration that mounts /etc,
>>> with (needed-for-boot? #t).
>> My goal is to have a read-only / mount with the ability for programs to
>> make temporary modifications for operational purposes when necessary, in
>> limited scopes (like /etc).  Can you elaborate on what you're suggesting
>> here?  Mounting something other than the overlayfs on /etc would hide
>> the system config files.  I might be able to use another mount to create
>> a pseudo- /tmpfs/etc_work subdirectory but it sounds kind of wormy and
>> overlayfs requires the upper dir and workdir to be the same filesystem
>> which I think precludes doing any mounting for those subdirectories.
> The overlay makes a lot of sense.  This is what ‘guix system vm’ does:
> see the #:volatile-root? parameter of ‘raw-initrd’.
>
> Perhaps you could simply set #:volatile-root? #t in your initrd to
> obtain what you want?
>
> Thanks,
> Ludo’.

Thanks, yeah, that sounds exactly like what I want!  TBH I think
something's going on strange with my threads, perhaps because I messed
up the replies -- after much source reading I found volatile-root and
asked about it in my disk-image thread.  TBH I'm not clear how that
would be set in the config to use with disk-image to get a whole system.