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

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

[Chris Marusich]

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

Hi,

This is follow-up to a help-guix@gnu.org thread in which George asked if
it is expected that "guix system vm" mounts the store read-only in the
VM, and I replied explaining that it is expected:

https://lists.gnu.org/archive/html/help-guix/2018-04/msg00049.html

I dug a little further and discovered behavior that seems undesirable to
me.  If someone can confirm my understanding, I would be happy to try
drafting draft a patch to fix the problem.

Chris Marusich <cmmarusich@gmail.com> writes:

> 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".

Curiously, if you invoke "guix system vm --full-boot", you will get a VM
that sees a read-write store.  In virtualized-operating-system, it says:

    ;; XXX: When FULL-BOOT? is true, do not add a 9p mount for /gnu/store
    ;; since that would lead the bootloader config to look for the kernel and
    ;; initrd in it.
    (file-systems (if full-boot?
                      virtual-file-systems
                      (cons
                       (file-system
                         (inherit (mapping->file-system %store-mapping))
                         (needed-for-boot? #t))
                       virtual-file-systems)))))

I don't understand this comment.  I don't understand why we only map the
store into the VM when full-boot? is #f.  When --full-boot is specified
on the command line (i.e., full-boot? is not #f), not only do we NOT map
the store into the VM, but we also copy the VM's dependencies into the
VM's disk image, so the disk image will contain a subset of the host's
store.  In fact, because we copy the files over, the size of the disk
image produced by "guix system vm --full-boot" is about the same as that
produced by "guix system vm-image".  I don't understand the point of
this; it seems to me like we could always unconditionally map the store
into the VM (without copying the dependencies required by the bootloader
config), regardless of whether --full-boot was specified, and the
bootloader would still successfully find its kernel and initrd.

Am I wrong?  Does anyone understand why we map the store into the VM if
and only if full-boot? is #f?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]