Re: runqemu + dhcp server

[Patrick Ohly <patrick.ohly@intel.com>]

On Mon, 2014-11-10 at 22:57 +0100, Adrian Freihofer wrote:
> > I haven't tried NFS rootfs. My hope is that it would still work because the
> > ip parameter and the DHCP server assign the same IP address and thus nothing
> > changes inside the guest when switching from one to the other.
> > 
> 
> I see, the patch you are working on will provide just another option
> to get eth0 configured. This would definitely be an improvement.

I had to put this aside for a while, but I'm still interested in getting
this merged.

> Did you ever run the automated image tests? If I remember correctly
> the image tests are somehow related to the current implementation of
> the network configuration. At least the tests require a hostname
> starting with "qemu" and probably they run from NFS rootfs.

Where do I find more information about these tests, in particular how to
run them?

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#testing-packages-with-ptest describes how to add tests to an image, but leaves it open how one invokes ptest-runner. What you describe sounds like a mechanism built on top of that which automatically boots up a machine and captures the output of ptest-runner.

> Would be nice, if you get the DHCP based network configuration
> fulfilling these requirements. An alternative approach is implemented
> in systemd networkd. I guess it does not touch interfaces which are
> already configured e.g. by kernel boot parameters. This could be done
> in connman as well. It would allow you to run the productive image in
> qemu.

There might be also other improvements. For example, I just booted a
core-image-minimal with systemd as init with runqemu. eth0 is
configured, but /etc/resolv.conf is missing, so ptests like the one for
wget fail because www.google.com cannot be resolved.

This was without the DHCP server patches. My expectation is that
bringing up eth0 with DHCP-supplied information about DNS servers would
have created (or could be made to create) resolv.conf.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.