[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: myglc2
Subject: Re: guix package: error: build failed: opening lock file?
Date: Fri, 06 Apr 2018 12:24:34 -0400

Hello Chris and Ludo’,

Thanks for the quick response.

On 04/06/2018 at 10:35 Ludovic Courtès writes:
> Chris Marusich <address@hidden> skribis:
>> address@hidden writes:
>>> I am running a 'guix system vm' and 'guix package -i' fails ...
>>> address@hidden ~$ 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/ -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."


- George

reply via email to

[Prev in Thread] Current Thread [Next in Thread]