Full Graphics setting breaks networking (Ubuntu ARM guest)

[trbtm]

The Full Graphics display mode seems to break the networking. I stumbled upon this because I installed 18.04 where the installer only works in Console Only mode. After installing I ran dig @1.1.1.1 google.com and it worked. After rebooting and enabling Full Graphics it doesn't work anymore.

This behaviour is independent of the network setting (I tested 'Shared Network' and 'Bridged (Advanced)'). I always used virtio-ramfb-gl Display Card in Full Graphics setting, since the other Cards would either prevent the VM from booting or are terribly slow. Here are the results of my testing:

https://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.5-server-arm64.iso
Ubuntu 18.04 ARM64, command: dig @1.1.1.1 google.com
Full Graphics + Shared Network: Timeout
Full Graphics + Bridged (Advanced)': Timeout
Full Graphics + Emulated VLAN: Timeout
Console Only + Shared Network: Success
Console Only + Bridged (Advanced): Success
Console Only + Emulated VLAN: Success

https://ubuntu.com/download/server/arm
Ubuntu 20.04 ARM64, command: dig @1.1.1.1 google.com
Full Graphics + Shared Network: Timeout
Full Graphics + Bridged (Advanced): Timeout
Full Graphics + Emulated VLAN: Timeout
Console Only + Shared Network: Success
Console Only + Bridged (Advanced): Success
Console Only + Emulated VLAN: Success

I followed this guide https://github.com/utmapp/UTM/wiki/Install-Ubuntu-ARM64-on-Apple-M1 to set them up.

Those settings are the only ones I changed in-between reboots. I think this is clearly a bug, because why would the graphics setting influence my networking, at least from a users perspective.

Kind regards,
Thore

Configuration

• UTM Version: 2.2.3 (beta)
• Host OS Version: macOS 11.5.2
• Guest OS: Ubuntu 18.04 ARM64 / 20.04 ARM64
• MacBook Air M1

[osy]

@conath Can you reproduce this?

[trbtm]

After working with 18.04 VM for a while I noticed that the network / internet access stopped working completely, even in Console Only mode. So if you try to reproduce this, use fresh VMs.

[osy]

Does Emulated VLAN work?

[trbtm]

I updated my answer with the findings from Emulated VLAN. Short answer: No.

[osy]

Interesting, maybe try one of the other network adapters? Maybe virtio works better for Linux?

[trbtm]

Ubuntu 20.04 ARM64, command: dig @1.1.1.1 google.com
Full Graphics + Emulated VLAN: Timeout

I tested all of these Network cards, it timed out every time.

[osy]

Thanks, is this issue newly introduced in 2.2.x beta or does it also happen on 2.1.x? If it's new in 2.2, then does changing the display adapter do anything (I don't think it should have any effect).

[conath]

I'll test this as well.

[trbtm]

Thanks, is this issue newly introduced in 2.2.x beta or does it also happen on 2.1.x? If it's new in 2.2, then does changing the display adapter do anything (I don't think it should have any effect).

I honestly don't know for sure but I used UTM a couple months ago with an Ubuntu 20.04 VM and a desktop environment and I can't remember having any network issues.

[conath]

Testing with 2.2.3 I can reproduce this.

Ubuntu 20.04 installed via console works (emulated network; I chose manual IPv4 setup so that I can be sure it's not changing on its own).

Here's a debug log from when it is working in console mode.
debug-consolemode.log

QEMU command

```bash qemu-system-aarch64 -L /Applications/UTM/UTM-2.2.3.app/Contents/Resources/qemu -S -qmp tcp:127.0.0.1:4444,server,nowait -nodefaults -vga none -nographic -chardev "pipe,id=term0,path=/Users/chris/Library/Group Containers/WDNLXAD4W8.com.utmapp.UTM/BD6A0F56-6F81-4852-8169-2A5309AEAE2A.terminal" -serial chardev:term0 -cpu host -smp cpus=2,sockets=1,cores=2,threads=1 -machine virt,highmem=off -accel hvf -accel tcg,tb-size=512 -drive if=pflash,format=raw,unit=0,file=/Applications/UTM/UTM-2.2.3.app/Contents/Resources/qemu/edk2-aarch64-code.fd,readonly=on -drive "if=pflash,format=raw,unit=1,file=/Users/chris/Library/Containers/com.utmapp.UTM/Data/Documents/TEST Ubuntu 20.04 ARM64.utm/Images/efi_vars.fd" -boot menu=on -m 2048 -name "TEST Ubuntu 20.04 ARM64" -device qemu-xhci,id=usb-bus -device usb-tablet,bus=usb-bus.0 -device usb-mouse,bus=usb-bus.0 -device usb-kbd,bus=usb-bus.0 -device ich9-usb-ehci1,id=usb-controller-0 -device ich9-usb-uhci1,masterbus=usb-controller-0.0,firstport=0,multifunction=on -device ich9-usb-uhci2,masterbus=usb-controller-0.0,firstport=2,multifunction=on -device ich9-usb-uhci3,masterbus=usb-controller-0.0,firstport=4,multifunction=on -chardev spicevmc,name=usbredir,id=usbredirchardev0 -device usb-redir,chardev=usbredirchardev0,id=usbredirdev0,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=usb-controller-0.0 -device usb-storage,drive=drive0,removable=true,bootindex=0 -drive if=none,media=cdrom,id=drive0 -device virtio-blk-pci,drive=drive1,bootindex=1 -drive "if=none,media=disk,id=drive1,file=/Users/chris/Library/Containers/com.utmapp.UTM/Data/Documents/TEST Ubuntu 20.04 ARM64.utm/Images/disk-0.qcow2,cache=writethrough" -device virtio-net-pci,mac=42:6C:78:FF:6C:10,netdev=net0 -netdev user,id=net0 -uuid BD6A0F56-6F81-4852-8169-2A5309AEAE2A -rtc base=localtime ```

After shutting down the VM normally, changing to using graphics (default virtio-ramfb-gl) and starting the VM again, it isn't working anymore.

debug-graphicsmode.log

[conath]

Same on 2.2.2 and 2.2.1.

[conath]

Actually, this also occurs on 2.1.2! So it might be a QEMU 6.0+ problem.

[osy]

@conath If it's also an issue in 2.1.2, do you agree it shouldn't hold up the 2.2.x release?

[conath]

I agree.

[osy]

Also, it only happens when you switch graphics settings? i.e. a fresh install on graphics don't exhibit the error? Last I tried, network was working but I didn't use console mode.

[conath]

It seems like switching between the two is what causes the issue. I just reinstalled Ubuntu 20.04 ARM in UTM 2.1.2 graphics mode, then switched to console mode, and that broke the networking.

[conath]

What's weird is that there is no change between the networking parameters when switching between the modes. (I diffed the debug log, only the chardev and graphics parameters differ)

What I did notice is that it seems SPICE is not in use at all in console mode, could that be causing the issue?

[osy]

I don't know; I can't see why SPICE would affect networking at all though... I do plan to move console mode to use SPICE as well (as a SPICE serial port) which would enable shared directories and other SPICE features, but that'll be a later milestone.

[trbtm]

I can confirm that with 2.2.3, installed 20.04 in Full Graphics and the network works. Switched the mode to Console and now the network doesn't work in Console Mode.

[trbtm]

I don't know; I can't see why SPICE would affect networking at all though... I do plan to move console mode to use SPICE as well (as a SPICE serial port) which would enable shared directories and other SPICE features, but that'll be a later milestone.

On my VMs I didn't install SPICE. So if it doesn't come preinstalled it should have no influence on the tests that I did.

[conath]

@trbtm SPICE is a "behind the scenes" technology used by UTM. It doesn't get installed in the guest. (spice guest tools is something else)

[trbtm]

@conath Thanks for pointing that out. I also tested some more and switched back and forth between Full Graphics and Console and it seems like the switching is breaks networking at some point. If I switch back and forth "enough" I send up with a VM that doesn't has networking in neither of the two modes.

[santicalcagno]

I can reproduce this in a NixOS VM that I've been using since 2.1.something, created as console only.

Interestingly enough, I can't seem to reproduce it in an Alpine Linux VM that I created using this iso. Going back and forth between console and graphics and the network always works.

EDIT: In both VMs I'm using the virtio-ramfb-gl adapter when in graphical mode and the shared network mode with the virtio-net-pci card. Both systems are virt-6.1.

[MPC-GH]

For me, using Debian 11 (debian-11.0.0-arm64-netinst.iso) and UTM 2.2.4 in bridged mode, using dhcp, I was seeing similar behaviour - the mac mini m1 was unable to reliably ping the IP4 address of the VM when it was running the installer.

This turned out to be an IP6 duplicate address.

The quick workaround was to: echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Not sure whether this is something specific to my home network setup or something else, but it changed the behaviour from mostly not able to be pinged from the mac mini m1 to being solid enough to do a network install.

====

The workaround can be made permanent by creating /etc/sysctl.d/50_disable_ipv6.conf that contains:

net.ipv6.conf.all.disable_ipv6 = 1

====

Testing above was done using virtio-net-device. First hour of playing with UTM so apologies if the IP6 issue is an FAQ. This thread was the first hit for the lack of networking during installation.

[osy]

@trbtm in #3051 we resolved the issue because when the VM boots in GUI mode, the network interface got a different name and Ubuntu wasn't configured to use that interface. The fix was to modify /etc/netplan/00-installer-config.yaml and add both interface names. Can you see if this fixes the issue for you as well?

[osy]

Added the troubleshooting tip to https://mac.getutm.app/gallery/ubuntu-20-04#networking-is-unavailable-after-switching-between-console-only-and-full-graphics-modes

[trbtm]

@trbtm in #3051 we resolved the issue because when the VM boots in GUI mode, the network interface got a different name and Ubuntu wasn't configured to use that interface. The fix was to modify /etc/netplan/00-installer-config.yaml and add both interface names. Can you see if this fixes the issue for you as well?

Yes that works, on Ubuntu 18.04 the file is called /etc/netplan/01-netcfg.yaml, maybe you could add that to the troubleshooting tip, the rest is the same as on 20.04.