MEWTWO

Unraid version: 7.1.3、7.1.4 After I upgraded to version 7.1.3, restarting the router would cause unraid to disconnect from the network. Preliminary investigation: unraid could not find the gateway after the router was restarted. So, I upgraded to the latest version 7.1.4. After restarting the router, the bug still existed. I checked the unraid settings in the LAN and it showed that the default gateway was wg0, and the IPv4 default 192.168.124.1 via br0 1010 was set incorrectly. The metric of 192.168.124.1 via br0 should be set to 0. I did not make any changes. I think this problem is caused by a bug in the unraid system. syslog.txt

Unraid Version: Unraid 7.0.0 Summary of the Issue: The Outgoing Proxy Manager setting appears to have no actual effect on Docker's network behavior. Even when disabled, Docker could pull images previously. After rebooting, enabling the proxy causes timeouts, and subsequent tests show that the setting neither enables nor disables proxy usage reliably. Steps to Reproduce: Unraid system previously operated with Outgoing Proxy Manager disabled, yet Docker could successfully pull images from Docker Hub from within mainland China. After I added a new disk to the Array Devices and system reboot, pulling Docker images failed with the following error: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) curl -v https://registry-1.docker.io/v2/ works fine, proving outbound proxy is functional. Manually restarting Docker via /etc/rc.d/rc.docker restart and then re-enabling Outgoing Proxy Manager allows image pulling to work again. docker info | grep -i proxy also confirms proxy is set correctly at this point. Disabling Outgoing Proxy Manager afterward does not remove the proxy from Docker (confirmed via the same docker info command). Restarting the Docker service again after disabling the proxy makes the proxy actually stop working. Trying to reproduce the above behavior again fails — regardless of the Enable/Disable toggle, Docker does not receive or remove the proxy settings. Expected Behavior: Enabling Outgoing Proxy Manager should immediately and consistently apply HTTP proxy settings to Docker Daemon and other relevant services. Disabling it should cleanly remove those proxy settings. These changes should persist and be applied correctly on system or service restart. Environment Details: Network: IPv4 only, no IPv6. Proxy Setup: Unraid connects via a manually provided HTTP proxy, shared from a PC plugin. VPN/Networking Plugins: WireGuard (Unraid native), Tailscale was installed but later removed without use. Hardware: Can provide diagnostics if needed. Diagnostics: Available if necessary, though the above steps should be reproducible.

When attempting to pass through the 8111 network interface (Realtek RTL8111) to a virtual machine running on Unraid, the VM fails to start and QEMU throws an assertion failure related to PCI IRQ handling: internal error: QEMU unexpectedly closed the monitor (vm='openwrt'): qxl_send_events: spice-server bug: guest stopped, ignoring qemu-system-x86_64: ../hw/pci/pci.c:1633: pci_irq_handler: Assertion 0 <= irq_num && irq_num < PCI_NUM_PINS' failed. Steps to Reproduce: Configure a virtual machine in Unraid. Pass through the 8111 network interface (Realtek RTL8111) to the VM. Start the virtual machine. The VM fails to launch, and the error message appears in the log. Expected Behavior: The virtual machine should start successfully with the 8111 network interface passed through, without any errors related to PCI IRQ handling. Actual Behavior: The virtual machine fails to launch, and QEMU throws an assertion failure related to pci_irq_handler in pci.c. Environment: Host OS: Unraid Guest OS: OpenWrt Network Interface: 8125 (used for host connectivity) 8111 (passed through to VM, causing error) Logs: Feb 6 13:54:00 mewtwo rc.docker: Containers started. Feb 6 13:55:40 mewtwo kernel: br0: port 2(vnet0) entered blocking state Feb 6 13:55:40 mewtwo kernel: br0: port 2(vnet0) entered disabled state Feb 6 13:55:40 mewtwo kernel: vnet0: entered allmulticast mode Feb 6 13:55:40 mewtwo kernel: vnet0: entered promiscuous mode Feb 6 13:55:40 mewtwo kernel: br0: port 2(vnet0) entered blocking state Feb 6 13:55:40 mewtwo kernel: br0: port 2(vnet0) entered forwarding state Feb 6 13:55:41 mewtwo kernel: pcieport 0000:00:1c.1: broken device, retraining non-functional downstream link at 2.5GT/s Feb 6 13:55:42 mewtwo kernel: pcieport 0000:00:1c.1: retraining failed Feb 6 13:55:43 mewtwo kernel: pcieport 0000:00:1c.1: Data Link Layer Link Active not set in 1000 msec Feb 6 13:55:44 mewtwo kernel: pcieport 0000:00:1c.1: Data Link Layer Link Active not set in 1000 msec Feb 6 13:55:44 mewtwo kernel: vfio-pci 0000:03:00.0: Unable to change power state from D0 to D3hot, device inaccessible Feb 6 13:55:44 mewtwo kernel: br0: port 2(vnet0) entered disabled state Feb 6 13:55:44 mewtwo kernel: vnet0 (unregistering): left allmulticast mode Feb 6 13:55:44 mewtwo kernel: vnet0 (unregistering): left promiscuous mode Feb 6 13:55:44 mewtwo kernel: br0: port 2(vnet0) entered disabled state Feb 6 13:55:44 mewtwo kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible Feb 6 13:55:44 mewtwo kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible Feb 6 13:55:50 mewtwo kernel: vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible After a while of system startup, the 8111 graphics card displays "Unknown header type 7f" and The error message when creating a virtual machine changes to ‘internal error: Unknown PCI header type '127' for device '0000:03:00.0'