help-guix
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: PGP signature


reply via email to

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