* origin/pr/267:
fix for ArchLinux: notify dom0 about installed updates The launch of the qubes-update-check service failed on ArchLinux, because the qubes-rpc uses the `service` command which isn't available for this OS.
fix archlinux detection of available upgrades note: checkupdates return 2 when no updates are available (source: man page and source code)
upgrades-installed-check requires pacman-contrib for checkupdates
The network-uplink-wait.sh script may be called before xen-netfront
module is even loaded (by udev). In that case, `get_qubes_managed_iface`
will fail to get the interface name and the wait will be skipped.
Fix this by loading xen-netfront module explicitly (do not try to
synchronize with udev, which is tricky not knowing the device
name).
* origin/pr/268:
Don’t rely on an arbitrary length limit
Don’t assume dom0 will never have a network connection
Add conntrack-tools dependency to qubes-core-agent-networking
Keep shellcheck from complaining
Stop disabling checksum offload
Remove spurious line continuation; add quotes.
vif-route-qubes: Check that the -e flag is set
Purge stale connection tracking entries
Otherwise, if “user” has the SELinux user “staff_u”, the user will
typically need to write “sudo -r unconfined_r -t unconfined_t”, which is
annoying. If SELinux is disabled, these fields are ignored.
Newer versions of qubes-dom0-update will spawn
qubes-download-dom0-updates.sh in an xterm if GUI mode is enabled.
Therefore, we don’t need to spawn our own progress bar.
Make sure NM config for uplink interface (eth0) is created before
starting NetworkManager itself. Otherwise NM helpfully will try to use
automatic DHCP configuration, which will fail and cause delays on
network start.
... if it doesn't exist.
The /qubes-mac qubesdb entry is present on Qubes 4.1, but not 4.0. It is
ok to depend on it here, but keep safer fallback if this code would need
to be backported.
Previously, network uplink (eth0) was configured in two places:
- udev (asynchronously)
- qubes-misc-post.service - at the very end of the boot process
This caused multiple issues:
1. Depending on udev event processing (non-deterministic), network
uplink could be enabled too early, for example before setting up
firewall.
2. Again depending on udev processing, it can be enabled quite late in
the boot process, after network.target is up and services assume
network already configured. This for example causes qubes-firewall to
fail DNS queries.
3. If udev happen try to enable enable networking even earlier, it may
happend before qubesdb-daemon is started, in which case network setup
fill fail. For this case, there was network re-setup in
qubes-misc-post service - much later in the boot.
Fix the above by placing network uplink setup in a dedicated
qubes-network-uplink@${INTERFACE}.service unit ordered after
network-pre.target and pulled in by udev based on vif device existence,
to handle also dynamic network attach/detach.
Then, create qubes-network-uplink.service unit waiting for appropriate
interface-specific unit (if one is expected!) and order it before
network.target.
QubesOS/qubes-issues#5576
