Fedora works just fine for me as the template for sys-net in 4rc1 here. As a first step what I would do is if sys-net can get online, set sys-net as updatevm for dom0, apply all the dom0 updates, then open a terminal in whatever you’re using as template for sys-net and apply all updates there (first set sys-net as updatevm there too). Then shutdown that template vm and restart sys-net and sys-firewall so they get the updates.
Once that’s working remember to set the updatevms back to sys-firewall. Sean Sent from my phone. Sorry if brief. > On 22 Oct 2017, at 23:15, Francesco Rmp <atomikr...@gmail.com> wrote: > > Il giorno domenica 22 ottobre 2017 16:29:14 UTC-4, yura...@gmail.com ha > scritto: >> On Sunday, October 22, 2017 at 5:27:17 PM UTC, Francesco Rmp wrote: >>> Hello everyone, >>> i've just installed qubes 4.0 RC1 on my ryzen system ( i couldn't get the >>> 3.2 to install because of the kernel compatibility). >>> >>> 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. >> >> >> 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 > > -- > You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-users+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/b00aa951-b532-4a36-8a23-d39ccae9311d%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/D5B51BA1-F420-4B4E-922B-C715193C0217%40uncarved.com. For more options, visit https://groups.google.com/d/optout.
