unofficial mirror of guix-science@gnu.org 
 help / color / mirror / Atom feed
From: Adam McCartney via Guix-Science <guix-science@gnu.org>
To: Adam McCartney via Guix-Science <guix-science@gnu.org>
Subject: Re: guix on a cluster: install into existing mount
Date: Thu, 4 Jul 2024 20:40:54 +0200	[thread overview]
Message-ID: <Zobstvcq75w-mZ7d@mc> (raw)
In-Reply-To: <ZoVEZCKI185JQzHn@mc>

Can also offer a little bit of further clarification:

>+ The recursively mounted subtrees don't survive a reboot, despite there being
>  fstab entries for them.
>+ The guix daemon doesn't want to run, I think this maybe has something to do
>  with the way that the `gnu.mount` service is set up? I guess that unit is
>  maybe not expecting to find a mount under `/gnu/store`?

So, the typical pattern that was being applied when I approached the system was 
append the following two entries to fstab:

```
[HOST_IP]:/gpfs/opt/adm /mnt/adm nfs rw,async,noatime,nodiratime,_netdev 0 0
[HOST_IP]:/gpfs/opt/sw /mnt/sw nfs rw,async,noatime,nodiratime,_netdev 0 0
```

As I mentioned in the thread above, I've recreated the required guix folders
as:
  + `/mnt/sw/dev/guix/gnu/store`
  + `/mnt/sw/dev/guix/var/guix`
  + `/mnt/sw/dev/guix/var/log/guix`

And then used the recursive bind option for mount:

```
mount --rbind /mnt/sw/dev/guix/gnu/store/ /gnu/store
mount --rbind /mnt/sw/dev/guix/var/guix/ /var/guix
mount --rbind /mng/sw/dev/guix/var/log/guix/ /var/log/guix
```

At this point it's possible to start the guix daemon and do a guix pull.

I'm a bit unsure as to how to make these recursive bind mounts persistent in
fstab. I've tried a couple of different options:

As type nfs rbind
```
/mnt/sw/dev/guix/gnu/store /gnu/store nfs rbind
...
```

As type none rbind
```
/mnt/sw/dev/guix/gnu/store /gnu/store none rbind
...
```

Referencing the host directly
```
[HOST_IP]:/gpfs/sw/dev/guix/gnu/store /gnu/store nfs rbind
...
```

Any pointers in the direction of where I might find some more info on making 
recursive bind mounts persistent much appreciated!

cheers,
Adam

p.s. I have considered that a cleaner solution would be to actually export the 
relevant directories from the nfs server rather than creating bind mounts after
it has been mounted. This is probably an option going forward, but for the time
being I probably have to make do with the test setup as described above.



-- 
  Adam McCartney - https://admccartney.mur.at 
/


  reply	other threads:[~2024-07-04 18:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-03 12:30 guix on a cluster: install into existing mount Adam McCartney via Guix-Science
2024-07-04 18:40 ` Adam McCartney via Guix-Science [this message]
2024-07-07 15:44   ` Efraim Flashner
2024-07-08  7:37     ` Adam McCartney via Guix-Science

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zobstvcq75w-mZ7d@mc \
    --to=guix-science@gnu.org \
    --cc=adam@mur.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).