Introduce a service to wait for network uplink #603
Merged
+24
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Sep 4, 2025
|
Better add "network" somewhere in the service name. |
ben-grande
force-pushed
the
preload-netvm
branch
2 times, most recently
from
bf95730 to
8b1948f
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #603 +/- ##
==========================================
- Coverage 71.10% 70.68% -0.42%
==========================================
Files 3 3
Lines 481 481
==========================================
- Hits 342 340 -2
- Misses 139 141 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This was referenced Sep 5, 2025
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025102219-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025081011-4.3&flavor=update
Failed tests12 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/149225#dependencies 84 fixed
Unstable testsPerformance TestsPerformance degradation:17 performance degradations
Remaining performance tests:163 tests
|
This was referenced Sep 5, 2025
ben-grande
force-pushed
the
preload-netvm
branch
from
8b1948f to
1bc691a
Compare
This fails reliably on Debian 13. I don't see in logs on which side the problem is, might be related to calling as non-root, but might be also something else. |
|
Ah, you found that in the other PR already. |
This was referenced Sep 9, 2025
|
No failure happens if I use So it means it is not waiting for something that would signal that network has been established. |
ben-grande
force-pushed
the
preload-netvm
branch
from
1bc691a to
07c8f9f
Compare
|
Waiting for ping gateway to return seems enough https://github.com/QubesOS/qubes-core-agent-linux/compare/1bc691a9323151aa43793e0c5dc24de7c0a0a60c..07c8f9fe5eafcbe45587abd16656b932f4fcc45e |
|
Except it doesn't always works: |
|
When it fails, it only fails on ipv4, which is tested before ipv6. Ipv6 may not be failing because it takes more time as it tries to ping the gateway of both ipv4 and ipv6 if both are available. |
ben-grande
force-pushed
the
preload-netvm
branch
from
07c8f9f to
b4219a1
Compare
|
Waiting for |
|
Ping is a bad idea, the backend may not necessarily respond to them (I wouldn't be surprised if Whonix blocks them at firewall, or Mirage firewall wouldn't respond either). Maybe add some debug info collection (see what network tests do on failure) before/after wait and see what is actually changing? Could be also some delay on the backend side maybe? If all fails, IMO better to accept that network may start working with some delay (and deal with that in tests), than having forced delay in disposable usage. After all, internet protocols need to deal with unreliable packet transfers anyway. |
Right...
The ping errors are:
Could be some delay on the backend/netvm side, yes. It tends to happen user@dom0:~/qubes-core-admin$ qvm-prefs untrusted netvm ''
user@dom0:~/qubes-core-admin$ qvm-prefs untrusted netvm -D; time qvm-run -p untrusted ping -c1 -W1 -n qubes-os.org
PING qubes-os.org (104.21.48.1) 56(84) bytes of data.
64 bytes from 104.21.48.1: icmp_seq=1 ttl=54 time=13.4 ms
--- qubes-os.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 13.401/13.401/13.401/0.000 ms
real 0m0.314s
user 0m0.110s
sys 0m0.068s
Sure. I will probably move the qvm-prefs untrusted netvm sys-firewall-alt
qvm-pause untrusted
qvm-prefs untrusted netvm -D # sys-firewall
qvm-shutdown --wait sys-firewall-alt
qvm-run -p ping -c1 -W1 -n qubes-os.orgPing works, no packet loss, but a bit worrying: I also get this from journal in tests, see the journal of the client: |
ben-grande
force-pushed
the
preload-netvm
branch
from
b4219a1 to
78e8b6c
Compare
Oh, sorry, you've got experimental kernel. Switch to stable one at least in VMs. |
This was referenced Oct 1, 2025
Merged
This was referenced Oct 10, 2025
Merged
Merged
This was referenced Oct 22, 2025
marmarek
approved these changes
Oct 23, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: QubesOS/qubes-issues#10173
For: QubesOS/qubes-issues#1512