Re: [Qemu-devel] make vm-test [was: [PATCH] maintainers: Add myself as a OpenBSD maintainer]

[Eric Blake]

On 03/21/2018 03:11 AM, Fam Zheng wrote:
> > Thanks for this; today was my first day trying the various vm-build-
> > targets.
> >
> > Question: is this expected behavior?
> >
> > $ make vm-build-ubuntu.i386
> >      VM-IMAGE ubuntu.i386
> > ...
> > Image resized.
> > debconf: unable to initialize frontend: Dialog
> > debconf: (TERM is not set, so the dialog frontend is not usable.)

> > I'm wondering if the image initialized incorrectly, and as a result can't do
> > as much as it's supposed to do, or runs way slower than it needs to?  The
> > command eventually completed with status 0, but failed to find a 32-bit
> > compile error in the rdma code, and the output log does not look like it
> > actually attempted to compile anything in qemu (unless it did compile it,
> > but the logs were not output to stdout/stderr).
> >
> > make vm-build-freebsd was a lot faster at completing for me (but shows that
> > we still have a lot of clang warnings about address of a packed struct
> > member).
>
> Was it a clean repo? Did you try "rm -rf ~/.cache/qemu-vm"? This morning the
> command worked for me from a clean env (on RHEL 7, using a QEMU built from
> qemu.git), and I didn't see the errors/warnings you pasted. (BTW I don't
> understand how sudo has anything to do with the dummy host name.)

I repeated the test twice this morning after 'rm -rf ~/.cache/qemu-vm', 
first after 'rm tests/vm/ubuntu.i386.img' in an incremental tree, and 
second in a fresh git checkout.  Here's a full pastebin of the first try 
(I hit ^C after seeing it look the same as yesterday, even after the 
fresh redownload that took more than 10 minutes):
https://paste.fedoraproject.org/paste/p8Th7AroLAprGY03ffzGHA

The results are the same; debconf is somehow unable to connect to the 
guest, and as a result, the guest is not properly initialized with the 
additional packages it needs, and then everything else about the image 
is broken.

Then on the second try, I got a dreaded message about my /home being 
nearly full, (having multiple .img files in two different build 
directories pushed me over limits), and it died a much harder death due 
to ENOSPC.  Let me resize my /home and retry (thankfully I still have 
some disk space free to throw at the problem), and I'll report back if 
that makes a difference.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org