[cfarm-users] having a bit of trouble with getting into the new netbsd and freebsd virtual machines

[CM Graff]

Hey again everyone!

I got into the NetBSD VM and am working on NetBSD support for hlibc.
This is just a fairly naive trial run using the syscall numbers from
freebsd's syscall.master. Something is a bit odd, as if NetBSD needs
ELF or some type of linux emulation layer. Here is what I got:

gcc300$ ./usr/bin/compiler ../some.c
cc = + exec gcc -fno-pie -fno-stack-protector -static '-D_GNU_SOURCE'
'../some.c' -specs '/home/cgraff1/hlibc/usr/lib/gcc-wrap.specs'
gcc300$ ./a.out
-sh: Cannot execute ELF binary ./a.out


I am not sure that we should contaminate the NetBSD VM with different
compat layers. I can try doing a NetBSD "build.sh" within my /home and
then rearrange the PATHs. Any suggestions?

Thanks!
Graff


On 10/6/18, Olly Betts via cfarm-users
<cfarm-users at lists.tetaneutral.net> wrote:
> On Sat, Oct 06, 2018 at 04:04:52PM -0500, Segher Boessenkool wrote:
>> On Sat, Oct 06, 2018 at 09:25:25PM +0100, Olly Betts via cfarm-users
>> wrote:
>> > gcc300$ getaddrinfo -f inet -t stream ::1
>> > stream inet tcp 192.168.66.50 0
>>
>> $ route -n show
>>
>> tells you why this is.
>
> Thanks, but I'm failing to understand the explanation if it is there
> (I'd actually even already tried that command).
>
> On Sat, Oct 06, 2018 at 03:14:12PM -0600, Assaf Gordon wrote:
>> On 06/10/18 03:06 PM, Assaf Gordon wrote:
>> > The physical server hosting the VMs is 192.168.66.50.
>
> OK, so it isn't just an arbitrary IPv4 address on the same network.
>
>> > The NetBSD VM is 192.168.66.202.
>> > The public IP (184.68.105.38) machine forwards the TCP ports (e.g. 2400)
>> > to the internal VMs.
>> >
>> > This seems pretty standard to me, but if there are possible
>> > improvements to the VM's configuration I'm happy to try them.
>
> It sounds like an entirely reasonable configuration to me.
>
>> I should add that the physical server is a Debian 9 (stretch),
>> using libvirt as the virtual machine infrastructure,
>> and the networking is setup to "bridge" mode, as explained here:
>>
>> https://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29
>>
>> Perhaps that is why, under certain circumstances, you get areply
>> with the physical host IP (192.168.66.50) instead of the VM's IP.
>
> Perhaps, though it seems very odd that IPv6 addresses get resolved
> with "-f inet" at all.  E.g. on the FreeBSD VM (gcc303):
>
> $ getaddrinfo -f inet -t stream ::1
> getaddrinfo: Non-recoverable failure in name resolution
>
> And based on what I see in my code calling the getaddrinfo() function,
> Linux fails with EAI_ADDRFAMILY and macOS with EAI_NONAME.
>
>> Hope this helps,
>
> Somewhat.  I'm still not really understanding why this happens, but
> it makes a certain amount of sense that it's the IP for the host the VM
> networking is bridged to, and I can easily avoid trying to resolve IPv6
> addresses with AF_INET without knowing exactly what is happening here.
> Mostly I'm just happier when I actually understand stuff.
>
> Cheers,
>     Olly
>
> P.S.  Thanks very much for hosting these VMs.  Having access to a
> variety of platforms just an ssh away is really useful for debugging
> portability issues.
> _______________________________________________
> cfarm-users mailing list
> cfarm-users at lists.tetaneutral.net
> https://lists.tetaneutral.net/listinfo/cfarm-users
>