The installation went smooth and i can boot fine in the system, but i'm having some networking issues.
Making the long story short: i cant get any VM to go online.
I'm no that familiar with the networking in qubes, but i tried to do some troubleshooting myself, and here is what i get.
- The sys-net VM works fine, it gets the IP from DHCP, gateway, DNS and everything and this is the only VM that goes online. i can ping hosts and communicate with the network. I didn't do anything fency in this VM but using some terminal commads to check i could actually go online, and it works.
This network fetches the IPs from my DHCP and is set to a 192.168.1.0/24
- the sys-firewall VM doesn't go online at all. I checked the VM configuration in qubes manager, and according to the configuration, it looks like it's using sys-net as its gateway, but still nothing.
Curious that when i check in the terminal, it has a network interface with class 10.xxx (i dont' remember exactly) and an additional interface for each appVM that i spin up (this is fine).
My question is.. how can this VM masquarade any traffic to the sys-net VM if the class of the network interface is completely different and the gateway is actually not set to the sys-net VM ip?
- As a consequence of the fact that the sys-firewall VM doesn't go online, all the appVMs suffer the same problem.
Can anyone help me out in troubleshooting this problem?
Am i right to assume that this is not an hardware problem? considering that the physical network interface assigned to sys-net works fine?
thanks in advance for your kind reply and support.
try setting debian-8 as your sys-net template.
By swapping the template for the net-vm now internet works, but the problem is only partially solved.
For some odd reasons, which i couldn't giure out myself.. all of a sudden internet stops working again, and the only way to get it back to work is by disabling and reenabling the wired connection (using the network manager icon on the top right corner).
This is really troublesome because i can't get qubes to update or install additional template VMs, as it always stops in the middle of the task and i have to start over.
Typically the Firewall AppVM is not happy to go online if there are problems with the sys-net AppVM. The issue is therefore likely in the sys-net AppVM, and not the firewall AppVM. For example if you take a fully functioning Qubes system, and you kill off the sys-net AppVM, while allowing the firewall AppVM to stay online, and then start up sys-net again, will cause issues with the Firewall AppVM. You'll have to shutdown the firewall AppVM and start it again, to establish a proper tied connection with the sys-net. Something similar is likely happening here, if there is something not properly working in your sys-net.
There are likely two reasons to the problems you face, that I can think of.
- The first issue is the planned premature release of Qubes 4 (kind of alpha release), does not always support PCI passthourgh too well, which might explain why your network card can't be passed through properly. Indeed it might work for a single VM, but if it can't communicate perfectly, it might cause the Firewall AppVM to bug out (A possibility). This major Qubes 4-RC1 issue has very recently been fixed, as early as last week. But since you don't have networking, you can't fetch the patch that fixes it. You're in luck though, Qubes 4-RC2 is planned to be released tomorrow, as you can see here https://www.qubes-os.org/doc/releases/4.0/schedule/
It shouldn't be delayed once more, a major issue holding it back, is exactly the issue up above causing problems with PCI passthrough hardware in Qubes 4. If this still does not work,then you can try turn your Passthrough AppVM's into PV virtualization mode, instead of HVM mode, which Qubes 4 can do with a single command. I believe it should be in terminal dom0: QVM-prefs "AppVM name" -l
somewhere. I don't run Qubes 4 atm, so I can't check, but it should be easy to do, from what I've heard.
- The other issue, that I can think of, is Ryzen. The kernel that almost fully supports Ryzen should be around version 9.12+. For example I've seen Qubes with Ryzen that only partially allow USB passthrough, but not fully passtrough, causing weird issues. Qubes does not run version 9.12 just yet (as far as I know at least), but it should happen soon since 9.12 longterm status is close now. This, as you probably already know, typically happens when newer kernels are pushed out regularly, check https://www.kernel.org/
You might know this already too, but the reason you can boot with Ryzen, is that Ryzen basic support works, but extra features such as PCI devices and such, might not work until you get a proper 9.12+ version kernel. Also be careful, my friend who runs Qubes on Ryzen, has had some kernel issues when upgrading, where earlier kernels allowed Ryzen to boot Qubes, but a newer version did not which resulted in kernel panic. So some kernels are a hit and miss, probably until you reach version 4.12+.
If you boot with Grub, then it's easy to switch to an older kernel. Also you can increase the kernel to be saved to be more than 3, so in case multiple of broken kernels are released, you will still be able to boot.
So a few more days for Qubes 4-RC2, and maybe (perhaps) days or weeks for the kernel 9.12 to reach longterm stability, before the Qubes team will look at it.
Also note, Qubes release kernels in their testing repositories before they make them final releases. But be mindful that they are just that, testing. While it might allow you get a kernel you need a bit earlier, it might also not work.
If any of these 2 issues is the reason for you, perhaps maybe even both of them, then you're just unlucky to be a few days or weeks early. But in Qubes, you can try change your passthrough network VM to PV mode instead of HVM mode, and see if it works. It should hopefully allow you to get networking without having to re-install the new Qubes-RC2, assuming it isn't the Ryzen kernel support that is causing it.
Hi, appearently the problem has been solved by setting the template to debian 8 for the sys-net VM