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

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

[myglc2]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

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

TIA - George


[-- Attachment #2: server17.scm --]
[-- Type: application/octet-stream, Size: 2176 bytes --]

;; -*-Scheme-*-
;;; server server17 config
(use-modules (gnu))
(use-modules (gnu system nss))
(use-service-modules
 avahi
 networking ; dhcp-client-service
 ssh ; openssh-service-type
 ) 
(use-modules (gnu packages))
(operating-system
  (host-name "server17")
  (timezone "America/New_York")
  (locale "en_US.utf8")
  (bootloader (grub-configuration (target "/dev/sda")))
  (file-systems (cons (file-system
			(device "g1sd")
			(title 'label)
			(mount-point "/")
			(type "ext4"))
		      %base-file-systems))
  (users (cons*
	  (user-account
	   (name "g1")
	   (group "users")
	   (supplementary-groups '("wheel"))
	   (home-directory "/home/g1"))
	  (user-account
	   (name "al")
	   (group "users")
	   (supplementary-groups '("wheel"))
	   (home-directory "/home/al"))
	  %base-user-accounts))
  (packages (append (map specification->package
			 '(
			   "aspell"
			   "aspell-dict-en"
			   "automake"
			   "conkeror"
			   "cups"
			   "emacs"
			   "emacs-ag"
			   "emacs-bui" ; to build emacs-guix from git checkout
			   "emacs-debbugs" ; so we can map C-c d >> guix bugs
			   "emacs-flycheck"
			   "emacs-guix"
			   "emacs-git-modes"
			   "emacs-highlight-symbol"
			   "emacs-highlight-sexp"
			   "emacs-pdf-tools"
			   "emacs-with-editor"
			   "emacs-paredit"
			   "font-dejavu"
			   "font-gnu-freefont-ttf"
			   "geiser"
			   "gettext-minimal"
			   "git"
			   "graphviz"
			   "gs-fonts"
			   "guile"
			   "guile-charting"
			   "help2man"
			   "icecat"
			   "isync"
			   "magit"
			   "make"
			   "nss-certs"
			   "openssh"
			   "screen"
			   "rsync"
			   "sicp"
			   "strace"
			   "the-silver-searcher"
			   "time"
			   "tree"
			   "wget"
			   "xauth"
			   "xeyes"
			   )) %base-packages))
  (services (cons*
	     (dhcp-client-service)
	     (service openssh-service-type
		      (openssh-configuration
		       (x11-forwarding? #t)
		       (permit-root-login #t)
		       (authorized-keys
			`(
			  ("g1" ,(local-file "glc.pub"))
			  ("al" ,(local-file "glc.pub"))
			  ("root" ,(local-file "glc.pub"))))))
	     (avahi-service)
	     (ntp-service)
	     %base-services))
  (name-service-switch %mdns-host-lookup-nss))

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

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

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
>
> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[Ludovic Courtès]

Hello,

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.  :-)

>> TIA - George
>
> I think this is expected behavior.

Yes, it’s a known limitation.

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.

Ludo’.

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

[myglc2]

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