qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fam Zheng
Subject: Re: [Qemu-devel] make vm-test [was: [PATCH] maintainers: Add myself as a OpenBSD maintainer]
Date: Wed, 21 Mar 2018 22:07:34 +0800
User-agent: Mutt/1.9.2 (2017-12-15)

On Wed, 03/21 08:14, Eric Blake wrote:
> 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.

Now I see the problem. I always use V=1 so stdout is different for the spawned
commands (qemu and ssh) in the script. I will send a patch tomorrow. Thanks!

Fam



reply via email to

[Prev in Thread] Current Thread [Next in Thread]