From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2@gmail.com Subject: Re: guix package: error: build failed: opening lock file? Date: Fri, 06 Apr 2018 12:24:34 -0400 Message-ID: <874lkomhfh.fsf@gmail.com> References: <877eplv3pl.fsf@gmail.com> <87bmewc15q.fsf@gmail.com> <87r2ns20mz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4UAM-0000Fc-Ol for help-guix@gnu.org; Fri, 06 Apr 2018 12:24:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4UAH-000856-Q0 for help-guix@gnu.org; Fri, 06 Apr 2018 12:24:42 -0400 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: help-guix@gnu.org Hello Chris and Ludo=E2=80=99, Thanks for the quick response. On 04/06/2018 at 10:35 Ludovic Court=C3=A8s writes: > > Chris Marusich 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=3Dserver17,script=3D/home/g1/src/vm/qemu-ifup,downscript=3D/= 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=E2=80=99s 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=3D/var/guix/daemon-socket > > However that doesn=E2=80=99t work, I suppose 9p doesn=E2=80=99t support f= orwarding > 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