Re: guix package: error: build failed: opening lock file?

[myglc2@gmail.com]

Hello Chris and Ludo’,

Thanks for the quick response.

On 04/06/2018 at 10:35 Ludovic Courtès writes:
>
> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> myglc2@gmail.com writes:
>>
>>> I am running a 'guix system vm' and 'guix package -i' fails ...
>>>
>>> g1@server17 ~$ guix package -i icecat
>>> guix package: error: build failed: opening lock file
>>> `/gnu/store/4iznqdzql2cp4l2jkr09jn10xxw861c4-mirrors.lock': Read-only
>>> file system
>>>
>>> Any idea what I am doing wrong? Here are the details ...
>>>
>>> guix system vm -M 4 -c 4 /home/g1/src/vm/vms/server17/server17.scm
>>>
>>> sudo /gnu/store/1vnsn52grzvpzrdndv1f3nkf7mdwd5wk-run-vm.sh -name
>>> server17 -net
>>> tap,ifname=server17,script=/home/g1/src/vm/qemu-ifup,downscript=/home/g1/src/vm/qemu-ifdn
>>> -daemonize -display none
>
> No need to run that as root.  :-)

I found root was needed for the scripts that bridge the TAP to the
outside LAN.

>> I think this is expected behavior.
>
> Yes, it’s a known limitation.

OK. I was confused when I couldn't find this mentioned anywhere.  Unless
a "fix" is imminent, I think we should say something like, "Note: At the
moment 'guix package' is not supported in guix vms. As a result, all
required packages must be included in the system configuration. This
constraint will be relaxed in a future version".

> I was thinking we could have the VM talk to the host daemon socket:
>
>   guix system vm config.scm --share=/var/guix/daemon-socket
>
> However that doesn’t work, I suppose 9p doesn’t support forwarding
> sockets.
>
> The other option would be to make /gnu/store a writable overlayfs, which
> should allow us to run a local guix-daemon with its own store in the VM.

Would the socket approach let vm/container users access all host
guix-daemon threads whereas the overlay approach limits them to the # of
CPUs in the vm/container?  If so, the socket approach seems to make the
vm more like "just another guix user" and the overlay approach seems to
make the vm more like the vm-image.

Am I correct in assuming that the socket approach would add any
vm-installed packages to the store but the overlay approach wouldn't? If
so, it seems more consistent with the (guix) Invoking guix system
statement: "The VM shares its store with the host system."

WDYT?

- George