I just downloaded and installed Qubes.
I have no internet and no clue how to trouble shoot this.
Domain sys-net has failed to start: internal error: Unable to reset PCI device 0000:00:1f.6: no FLR, PM reset or bus reset avaliable
1 Like
pc spec ?
what qubes version, 4.0.4 or 4.1 ?
are you using wifi / ethernet ?
can you confirm that internet is worked with another device ?
do you have sys-net and sys-firewall started ?
how do you know you have not internet worked on qubes ?
1 Like
Version 4.04, ethernet, yes it works
In sys-net settings, bottom of devices tab, “Configure strict reset for PCI devices”, choose “PCI device 0000:00:1f.6” and try starting sys-net again.
How do I start sys-net and sys-firewall?
i’ve seen that you are editing post after i replying, i don’t remember exactly with 4.0.4 installer, but do you have sys-usb qube?
Welcome to Qubes.
My psychic abilities are at an all time low, so I am working blind.
Networking in Qubes is provided through the sys-net qube.
You should check in the Qube Settings, (in Qube Manager), that whatever NIC you have is
attached to that qube.
If sys-net is running, open a terminal in sys-net, run journalctl -b,
and look for any messages that relate to your network devices.
If sys-net is not running, then get it to work. Try starting it, and
look for any errors.
1 Like
If that is in System Tools of main menu I do not see it.
I do not see a way to start sys-net.
There is nothing in Service:sys-net that allows me to start it, where it says Networking: (none) I cannot change that setting.
In a terminal I cannot start it, or run it.
I’m guessing I’ll never get wifi going if I cannot get the ethernet working.
1 Like
In the Qube Manager I cannot start or run sys-net
In Service: sys-net same thing, I thought qube was supposed to work with a Nuc i5.
I seriously do not know what to do at this point, my phone is all I have right now.
1 Like
No sir
Try this in a dom0 terminal:
$ qvm-pci detach sys-net dom0:00_1f.6
$ qvm-pci attach --persistent --option permissive=true \
--option no-strict-reset=true sys-net dom0:00_1f.6
Out of curiosity, what machine are you trying to run Qubes on? My guess would be a Thinkpad…
1 Like
Nuc 8i5BEH1
Got this reply from the second line,
usage: qvm-pci [–verbose] [–quiet] [–help] [–list-device-classes] {list,ls,l,attach,at,a,detach,d,dt} …
qvm-pci: error: unrecognized arguments: sys-net dom0:00_1f.6
No kidding, cool! I’ve never heard of Qubes installed on a NUC! I guessed a Thinkpad because my Thinkpad uses the same ethernet controller. (Maybe it’s a common device or something… I’m not too familiar with hardware.)
I’m going to be straight with you, just pasting in your output from a command is really, really unhelpful, especially since this is just a parsing error, which means typo.
It looks like it’s interpreting our VM name and device as arguments. As typed, it should work, and I’m gonna walk through how to self-diagnose this. You don’t have to read it and can just try to find your typo, but if you’re curious:
$ qvm-pci attach --persistent --option permissive=true \
--option no-strict-reset=true sys-net dom0:00_1f.6
You can follow along by running man qvm-pci. (Note here that the man brought up is for qvm-device and qvm-device has a command, qvm-*DEVICE CLASS*, which we are issuing, where our device class is pci.)
qvm-pci is the command we are issuing.
attach is a command of qvm-pci. (maybe these are called subcommands?)
--persistent is the first argument (also called a flag) we are issuing. Arguments modify the behavior of commands, and we can tell this is an argument because it starts with --. (aliases for arguments start with one dash, but do the same thing. An alias looks like me writing -p in the place of --persistent, but works exactly the same.) --persistent takes no fields (also called items).
...--option permissive=true \
--option no-strict-reset=true...
--option must be followed by a field in the format of name=value. For PCI buses, those names are no-strict-reset and permissive. The values they take are booleans; true or false. We set both to true, because by default they are false.
The backslash is unnecessary, and just helps break the command up into two lines. This is for if you need to issue a longer command, and don’t want to scroll along your terminal emulator. Bash does this when you hit enter after a backslash:
$ foo a b c \
> d e f
But this is the same as:
$ foo a b c d e f
Finally, we come to attach’s two fields: VMNAME and BACKEND_DOMAIN:DEVICE_ID. This is where we write sys-net dom0:00_1f.6. Self-explanatory. Options usually go before fields\items, but sometimes can or have to go after. Consult your manual.
1 Like
I plan on picking up a system 76 meerkat in the near future.
Unfortunatly I did not copy and paste that I had to peck it into my phone. I called myself proofing my typing befor I hit enter but a typo does not surprise me I’ll try again. Thanks for the explanation.
Once I get internet working I will thoroughly RTFM.
2 Likes
Nice!
No probem. dom0 commands are the worst because you can’t (and shouldN’T) copy into dom0. That explanation was mostly me making sure I knew what-the-f**k I was talking about before I called “typo”. I have no clue what the circumstances are that you’re typing into your phone because I know you didn’t SSH into dom0… is your phone your NUC’s keyboard/display in some ungodly setup?
lol
Fantastic, corrected my typo, rebooted and watched it turn on sys-net while booting, it is updating now. Thanks for yor help.
1 Like
Awesome! I believe I read somewhere that this issue is corrected in 4.1 but I’m not 100% on that.
Note: I renamed the topic
1 Like