[Libguestfs] Problems with Fedora 27 image used by virt-builder

During this last week I fired up some tests using libvirt-tck that haven't been run in awhile and ran into a couple problems with the Fedora 27 image provided by virt-builder (which is used by the libvirt-tck tests). One of them probably has a simple solution, I'm not sure about the other. 1) there is an selinux labeling error with the versions of packages in the Fedora 27 image. There are several (mostly related to iptables and ebtables), but one in particular prevents dhcp from getting an IP address: audit[509]: AVC avc: denied { read } for pid=509 comm="dhclient" name="ld.so.cache" dev="vda4" ino=4513574 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 I'm guessing that redoing the OS install of the image with updates enabled will fix this (and most/all of the other AVCs) 2) The virt-builder images are created using virt-install ..... --nographic which means that no video device is present during the OS install. Because of this, the ethernet device is placed at slot 2, so it is named "ens2" by the kernel, and anaconda creates config for "ens2". But if the image is later booted with a different config that has a graphics device, the graphics device will be put at slot 2 and the ethernet will be put on slot 3, so it will be named ens3. This ends up providing the expected behavior, since the image has NetworkManager enabled, and by default NetworkManager will enable all interfaces it finds with an "in-memory" config for dhcp. But it does mean that if someone decides to change the config to have a static IP, they'll be surprised when just modifying the existing ifcfg file doesn't have any effect. Also, if someone disables NetworkManager.service in the image and enables network.service instead, the config will be incorrect. (On the other hand, if they're doing something like this, they're already messing around with files in the image, so I suppose they could be expected to correct the inconsistency themselves. It may be too late to change this, but in hindsight it may have been good to add "net.ifnames=0 biosdevname=0" to the kickstart file and grub config so that the network device is always named eth0 regardless of PCI addressing. (I remember this previously being the case for virtio devices in Fedora; no idea when it changed).