bug#24943: Error when starting a vm-image in qemu

bug#24943: Error when starting a vm-image in qemu

[dian_cecht]

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

I've recently created a VM using guix system vm-image using

$ guix system vm-image --image-size=16G ~/doc/vimwiki/liveusb-guix-sys-conf.wiki

(I will attach the conf file later on). After copying the image to $HOME and
changing perms to 0600, I tried running it using:

history | grep qemu-system
  501  qemu-system-x86_64 --enable-kvm -cpu host -net nic -net user -usb -usbdevice tablet guix-img.qcow 
  502  qemu-system-x86_64 --enable-kvm -cpu host -net help -net user -usb -usbdevice tablet guix-img.qcow 
  505  qemu-system-x86_64 --enable-kvm -cpu host -usb -usbdevice tablet guix-img.qcow 

and in each instance, the system failed to boot (screenshots should be attached
in .png format). The error was related to the network interface. Especially with
command 505, I'd have expected that to resolve the issue since there was no
network interface, but it didn't fix things. Image error.png is the output, and
error2.png is the backtrace (,bt from the prompt).

This is all done with the stable release

$ guix --version
guix (GNU Guix) 20161115.02
Copyright (C) 2016 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

installed on a Gentoo system with qemu compiled with

[ebuild     U  ] app-emulation/qemu-2.7.0-r7::gentoo [2.7.0-r5::gentoo] USE="aio
alsa bluetooth bzip2 caps curl fdt filecaps gnutls gtk jpeg ncurses nls opengl
pin-upstream-blobs png sdl seccomp ssh threads usb uuid vde vhost-net virtfs vnc
xattr -accessibility -debug (-glusterfs) -gtk2 -infiniband -iscsi -lzo -nfs
-numa -pulseaudio -python -rbd -sasl -sdl2 (-selinux) -smartcard -snappy -spice
-static -static-softmmu -static-user -systemtap -tci {-test} -usbredir -virgl
-vte -xen -xfs" LINGUAS="-bg -de_DE -fr_FR -hu -it -tr -zh_CN"
PYTHON_TARGETS="python2_7" QEMU_SOFTMMU_TARGETS="aarch64 arm i386 ppc ppc64
ppcemb x86_64 -alpha -cris -lm32 -m68k -microblaze -microblazeel -mips -mips64
-mips64el -mipsel -moxie -or32 -s390x -sh4 -sh4eb -sparc -sparc64 -tricore
-unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="aarch64 arm i386 ppc ppc64
ppc64abi32 x86_64 -alpha -armeb -cris -m68k -microblaze -microblazeel -mips
-mips64 -mips64el -mipsel -mipsn32 -mipsn32el -or32 -ppc64le -s390x -sh4 -sh4eb
-sparc -sparc32plus -sparc64 -tilegx -unicore32"

The config file used is:

;; This is an operating system configuration template
;; for a "bare bones" setup, with no X11 display server.

(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules admin)

(operating-system
  (host-name "livesystem")
  (timezone "")
  (locale "en_US.UTF-8")

  ;; Assuming /dev/sdX is the target hard disk, and "my-root" is
  ;; the label of the target root file system.
  (bootloader (grub-configuration (device "/dev/sdX")))
  (file-systems (cons (file-system
                        (device "")
                        (title 'label)
                        (mount-point "/")
                        (type "ext4"))
                      %base-file-systems))

  ;; This is where user accounts are specified.  The "root"
  ;; account is implicit, and is initially created with the
  ;; empty password.
  (users (cons* (user-account
                (name "user")
                (comment "")
                (group "users")

                ;; Adding the account to the "wheel" group
                ;; makes it a sudoer.  Adding it to "audio"
                ;; and "video" allows the user to play sound
                ;; and access the webcam.
                (supplementary-groups '("wheel" "audio" "video" "kvm"))
                (home-directory "/home/user"))
               %base-user-accounts))

  ;; Globally-installed packages.
  (packages (cons* tcpdump %base-packages))

  ;; Add services to the baseline: a DHCP client and
  ;; an SSH server.
  (services (cons* (dhcp-client-service)
                   (lsh-service #:port-number 2222)
                   %base-services)))

[-- Attachment #2: error.png --]
[-- Type: image/png, Size: 25080 bytes --]

[-- Attachment #3: error2.png --]
[-- Type: image/png, Size: 24943 bytes --]

bug#24943: Error when starting a vm-image in qemu

[Ludovic Courtès]

dian_cecht@zoho.com skribis:

> I've recently created a VM using guix system vm-image using
>
> $ guix system vm-image --image-size=16G ~/doc/vimwiki/liveusb-guix-sys-conf.wiki
>
> (I will attach the conf file later on). After copying the image to $HOME and
> changing perms to 0600, I tried running it using:
>
> history | grep qemu-system
>   501  qemu-system-x86_64 --enable-kvm -cpu host -net nic -net user -usb -usbdevice tablet guix-img.qcow 
>   502  qemu-system-x86_64 --enable-kvm -cpu host -net help -net user -usb -usbdevice tablet guix-img.qcow 
>   505  qemu-system-x86_64 --enable-kvm -cpu host -usb -usbdevice tablet guix-img.qcow 
>
> and in each instance, the system failed to boot (screenshots should be attached
> in .png format). The error was related to the network interface. Especially with
> command 505, I'd have expected that to resolve the issue since there was no
> network interface, but it didn't fix things. Image error.png is the output, and
> error2.png is the backtrace (,bt from the prompt).

‘guix system vm-image’ produces an image that expects QEMU’s networking
interface available as eth0 inside the host, hence the error you were
getting.

To enable that, I think you need to do:

  qemu-system-x86_64 -net user -net nic,model=virtio …

See:

  https://www.gnu.org/software/guix/manual/html_node/Running-GuixSD-in-a-VM.html

Could you try and report back?

Thanks,
Ludo’.

bug#24943: Error when starting a vm-image in qemu

[dian_cecht]

I thought I had included that info, but yes that does work. Part of the reason
for filing the bugreport was so that this case could be handled more elegantly
instead of bugging out and dropping a user in the REPL. Unless one is a dev, the
REPL might as well be a kernel panic, only without the (potentially) useful
timeout.

I'd personally prefer it if the image generated by vm-image could either

A) Spit out an error that there isn't a networking device found and shutdown
(not a fan, but if there is a reason vm-image /has/ to have a working network
connection, this would likely be better. Including a chance to hit a key to drop
a dev/advanced user into the REPL would be nice as well) or
B) Spit out an error and finish the booting process, with guix complaining about
no network connection any time it's needing to download something (easily the
better option).

Another option would be a a command for the REPL that would simply shut things
down (which would likely be useful in more cases than just this, depending on
how often a user might be staring at the REPL in case of critical errors).

On Tue, Nov 15, 2016 at 11:08:40AM +0100, Ludovic Courtès wrote:
> 
> ‘guix system vm-image’ produces an image that expects QEMU’s networking
> interface available as eth0 inside the host, hence the error you were
> getting.
> 
> To enable that, I think you need to do:
> 
>   qemu-system-x86_64 -net user -net nic,model=virtio …
> 
> See:
> 
>   https://www.gnu.org/software/guix/manual/html_node/Running-GuixSD-in-a-VM.html
> 
> Could you try and report back?
> 
> Thanks,
> Ludo’.

bug#24943: Error when starting a vm-image in qemu

[Ludovic Courtès]

dian_cecht@zoho.com skribis:

> I thought I had included that info, but yes that does work. Part of the reason
> for filing the bugreport was so that this case could be handled more elegantly
> instead of bugging out and dropping a user in the REPL. Unless one is a dev, the
> REPL might as well be a kernel panic, only without the (potentially) useful
> timeout.
>
> I'd personally prefer it if the image generated by vm-image could either
>
> A) Spit out an error that there isn't a networking device found and shutdown
> (not a fan, but if there is a reason vm-image /has/ to have a working network
> connection, this would likely be better. Including a chance to hit a key to drop
> a dev/advanced user into the REPL would be nice as well) or
> B) Spit out an error and finish the booting process, with guix complaining about
> no network connection any time it's needing to download something (easily the
> better option).

Yes, that makes sense.

On closer inspection, that feature (setting up QEMU guest networking
directly from the initrd) is something we need in only 1 situation,
which is ‘expression->derivation-in-linux-vm’, so commit
6129dd8b5989f77b2976c68ecdf1f7dbfa63ec46 removed that feature for images
produced by ‘guix system vm’ and ‘guix system vm-image’.

So now you should no longer have this problem when networking is
missing.

Thank you,
Ludo’.