[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guix package: error: build failed: opening lock file?
From: |
Chris Marusich |
Subject: |
Re: guix package: error: build failed: opening lock file? |
Date: |
Thu, 05 Apr 2018 23:13:53 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
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/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
>
> TIA - George
I think this is expected behavior.
The script produced by the "guix system vm" command maps the host's
store into the guest. This happens in
system-qemu-image/shared-store-script (defined in gnu/system/vm.scm), if
you are curious. I suspect the the intent is to prevent the undesirable
situation in which two Guix daemons (the one in your host and the one in
your guest VM) attempt to manage the same store. Bad things could
happen in that situation. For example, one daemon might garbage collect
some paths that were still valid from the other daemon's perspective.
The store is only intended to be managed by a single daemon, which is
probably why the store is mounted read-only in the guest.
The same is true for the "guix system container" command, also.
Currently, if you need a read-write store in a VM, the easiest solution
is probably to use "guix system vm-image" or "guix system disk-image".
--
Chris
signature.asc
Description: PGP signature