Yup... All Clear! I was able to run qemu image with qemu-system-x86_64
exe, and there I found the (networking/proxies) problem.

QEMU itself does not have proxies setup. ;-)

4 levels of redirections: from
[1] corporate firewall;
[2] host notebook connected to it, running VM;
[3] VM running Lava inside;
[4] Lava inside running qemu;
[5] qemu itself with proper routing table set (but sans proxies)! :-))

So, the obvious solution is to set up the local mirrors (from
http://mirror.bytemark.co.uk/debian/) in host and/or VM.

Best Regards,
Zoran
_______

On Thu, Feb 15, 2018 at 9:51 AM, Zoran S
<zoran.stojsavljevic.de@gmail.com> wrote:
> Hello Steve,
>
> Thank you for the reply. I think I know what/why the mess is. NOT the
> proxies in Lava Server, they are set correctly.
>
> The following exactly describes the situation: I have three separate
> entities, working altogether:
> [1] Host;
> [2] VM with Lava;
> [3] QEMU, which is EXTERNAL entity to Lava (inside the Lava, supposed
> to be/emulate HW target connected to the host)!
>
> How I can login to QEMU from Lava/actually from VM? This is a path to
> the solution of this problem.
>
> Zoran
> _______
>
> On Wed, Feb 14, 2018 at 5:27 PM, Steve McIntyre
> <steve.mcintyre@linaro.org> wrote:
>> On Wed, Feb 14, 2018 at 04:42:02PM +0100, Zoran S wrote:
>>>Hello Steve,
>>>
>>>I am not reaching mirror.bytemark.co.uk :
>>>Unable to connect to mirror.bytemark.co.uk:http: [IP:>2001:41c8:20:5e6::10 80]
>>>
>>>No, my VM is set to use IPV4. And my VM does reach all other external
>>>sites, except mirror.bytemark.co.uk. You can see this from the
>>>pastebin log: https://pastebin.com/334xHvX8
>>>
>>>Do I have authorization issue here? Do I need to have some more
>>>authorization to reach this server?
>>
>> No, that's not your problem.
>>
>> apt-get inside the VM is looking up "mirror.bytemark.co.uk" in DNS and
>> getting back both the IPv4 and IPv6 addresses. It's preferring v6 (as
>> most things will these days) and trying to connect to
>> 2001:41c8:20:5e6::10. That's failing. It's then reporting that
>> error. This is not normally a problem - apt will fall back to v4 if v6
>> doesn't work. But I'm guessing that also didn't work, so it's
>> reporting the first error.
>>
>> I've seen in your previous mails to the list that you've needed to
>> configure a proxy for the dispatcher (so that works for downloading
>> the image in the first place). Unfortunately, the proxy settings are
>> not passed on into the network setup inside the VM and that's probably
>> the problem you're seeing. It will be trying to connect directly to
>> the remote web server. If your network doesn't allow that at all, then
>> you'll either need to reconfigure the test image to use your proxy, or
>> set up a transparent proxy to control things as needed.
>>
>> I've specifically tried to reproduce this problem on my local network
>> using the same image as you (the standard one from images.v.l.o) and I
>> can't. I've tried various configurations on the host machine and VM,
>> (no network, v4 only, v6 only, both v4 and v6) and I don't get the
>> same error messages. Thst's what tells me it must be your network with
>> the proxy setup, I'm afraid.
>>
>> Hope that helps!
>>
>> Cheers,
>> --
>> Steve McIntyre                                steve.mcintyre@linaro.org
>> <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
>>
_______________________________________________
Lava-users mailing list
Lava-users@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lava-users