Hi Konrad, I wanted to try specifying currently used version of Guix in some other way to avoid computing Guix inside the container. I tested first without a container guix shell -e '((@ (gnu packages package-management) current-guix))' -- guix describe and the result is also bad — it still tries to compute Guix from scratch every time. So it seems exposing of folders is unlikely to help here because the problem lies elsewhere :/ Perhaps someone else will be able to give a solution? Wojtek -- (sig_start) website: https://koszko.org/koszko.html PGP: https://koszko.org/key.gpg fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Fri, 03 Feb 2023 17:52:22 +0100 Konrad Hinsen wrote: > Hi Guix, > > I have been playing with nested Guix containers recently, with some > suprising findings, and I am wondering if what I am doing is considered > officially supported or not. > > First: why? My use case is scientific workflows, for example using > snakemake. I want to run my workflows in Guix containers, for > reproducibility plus other reasons. But my workflows run other programs > in their tasks (basically just "shelling out"), and those tasks may use > their own Guix containers. > > Superficially, this works fine if I add the "guix" package to my "outer" > container and expose the store plus the daemon's socket: > > guix shell -C guix \ > --expose=/var/guix/daemon-socket/socket \ > --expose=/gnu/store \ > -- \ > guix shell -C coreutils -- ls / > > But now for the first surprise: > > $ guix describe > Generation 35 janv. 19 2023 12:34:57 (current) > guix 8221cb6 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 8221cb6d2ae5624829bf514d25ae234c073e35d5 > > $ guix shell -C guix -- guix describe > guix 9fe5b49 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 9fe5b490df83ff32e2e0a604bf636eca48b9e240 > > The Guix in my container is an older one, apparently the 1.4.0 release. > Why? Can I change this? > > My first attempt was time-machine: > > guix shell -C -N guix nss-certs \ > --expose=/var/guix/daemon-socket/socket \ > --expose=/gnu/store \ > -- \ > guix time-machine -C channels.scm -- describe > > Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... > Authenticating channel 'guix', commits 9edb3f6 to 8221cb6 (331 new commits)... > Computing Guix derivation for 'x86_64-linux'... | > guix 8221cb6 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 8221cb6d2ae5624829bf514d25ae234c073e35d5 > > Great! Except that every time I run this command, it does the channel > update from scratch, so it's prohibitively slow. Sharing > ${HOME}/.cache/guix seems to fix that. So... finally... > > guix shell -C -N guix nss-certs \ > --expose=/var/guix/daemon-socket/socket \ > --expose=/gnu/store \ > --share=${HOME}/.cache/guix \ > -- \ > guix time-machine -C channels.scm \ > -- \ > shell -C coreutils \ > -- \ > ls / > > guix shell: error: mount: mount "none" on > "/tmp/guix-directory.vpOEDC/sys": Operation not permitted > > Now I am lost. It doesn't matter which command I put on the last line, > it's creating a container via time-machine running in another container > that leads to the error. > > Any ideas? > > Cheers, > Konrad. >