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. 


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
>>> - 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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to