Unknown Host QEMU IFLA Type

[kutschkem]

I have one application that I compile in an ubuntu-core:arm64 container that, when run inside that container, causes the following errors:

Unknown host QEMU_IFLA type: 47
Unknown host QEMU_IFLA type: 48
Unknown host QEMU_IFLA type: 43

Copying the executable to an arm64 allows me to run it correctly, but on the x86_64 host, it runs but causes this error (and seems to have problems with network communication, although I am not sure it is related to this problem).

[kutschkem]

If that is any indication of problem, it also seems to have a network interface "��@" (sic) which looks a bit strange.

[eine]

@kutschkem, did you submit this issue to QEMU's bug tracker?

[kutschkem]

@1138-4eb No, I don't think so.

[umarcor]

@kutschkem, I tried with version 4.0.0, and those errors seem to be fixed. Still, I get:

Unknown QEMU_IFLA_INFO_KIND ipip
Unknown QEMU_IFLA_INFO_KIND ip6tnl

[junaruga]

Now the qemu version is 4.1.0. Could you check it?

[junaruga]

@kutschkem by the way, you do not have to use multiarch project's "multiarch/ubuntu-core:arm64" container anymore. You can run standard multiarch container like this.

$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
$ docker run --rm -t arm64v8/ubuntu uname -m
aarch64

Could you check it on your environment?
If you like, I want to know the reproducing steps with command lines level.

[ZhenshengLee]

Now the qemu version is 4.1.0. Could you check it?

@junaruga Now the version is 4.2 in ubuntu 20.04, and errors exist.

Unknown host QEMU_IFLA type: 54
Unknown host QEMU_IFLA type: 32820
Unknown host QEMU_IFLA type: 54
Unknown host QEMU_IFLA type: 54

BTW, The cpp compiling consumes much more time than that in host x86 PC, I don't know if it has something to do with the qemu runtime.

The docker image is nvcr.io/nvidia/l4t-base:r32.4.4

Thanks.

[junaruga]

@ZhenshengLee I don't have time to check your issue. But assuming your host environment is Ubuntu 20.04 (focal), and you are trying to run nvcr.io/nvidia/l4t-base:r32.4.4.

Which CPU architecture the container image is? I cannot find it, and I cannot access to the container image info page. I found this page: https://forums.developer.nvidia.com/t/tensorrt-with-nvcr-io-nvidia-l4t-base-r32-3-1-docker-image/111081 .

I expect you are trying to run non-x86 container image. right?

You can run it without multiarch/qemu-user-static containers. Those are just a wrapper of installing binfmt_misc files and QEMU bianries.

Reading this document to install binfmt_misc,

Here are the possible steps

1. Clean the binfmt_misc files and multiarch containers you installed. See The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested #134 (comment) .

2. Install the following Ubuntu packages binfmt-support, qemu-user-static, following above document.

   $ sudo apt-get update -y
   
   $ sudo apt-get install -y binfmt-support qemu-user-static
   

3. Check if the /proc/sys/fs/binfmt_misc/* and /usr/bin/qemu-*-static files are installed. For example, if you want to run the aarch64 (arm64) container, you can use /usr/bin/qemu-aarch64-static installed on your host environment by qemu-user-static deb package. For example if your container is aarch64 (arm64), I expect the following file includes the F flag in flags:. If your container is another non-x86 container, check another /proc/sys/fs/binfmt_misc/qemu-XXXX file used internally.

   $ cat /proc/sys/fs/binfmt_misc/qemu-aarch64
   ...
   flags: F
   ...
   

4. You can run the container image without multiarch containers like this. See sh: write error: Invalid argument - Centos 7 #100 (comment) . Check if the following command works.

   $ docker run --rm -t arm64v8/ubuntu uname -m
   aarch64
   

5. Try your case like this.

   $ docker run --rm -t nvcr.io/nvidia/l4t-base:r32.4.4 uname -m
   XXXXX
   

6. If you reproduce the error, you can ask on the QEMU mailing list or an issue ticket: https://www.qemu.org/support/ .

[kutschkem]

This is super old, so for me it's fine to close the issue. You can also keep it open for @ZhenshengLee 's issue