The former one may fail if happen before qubes-db daemon is started. The
later one will fix it, but in the meantime some services (like whonix
update proxy sanity check) may expect to have already working network
(before are ordered after network.target or even network-online.target).
Delaying udev rules processing seems unreasonable, so introduce another
systemd service responsible for just configuring IP address. This does
not replace udev rule (but during startup will duplicate the same task),
because it is still needed to handle dynamic network switch. Also
the call in qubes-misc-post may be needed to handle DispVM startup
(network needs to be re-configured after restoring savefile).
Another idea would be to order qubes-misc-post.service after
network-online.target.
This commit is work in progres. It doesn't deal with the case where
initial setup-ip call from udev rule succeed. Second call will fail,
marking qubes-setup-ip service as failed. Also the third call (from
qubes-misc-post.service) will almost always fail - probably in every VM
but DispVM.
From the WIP commit message https://github.com/marmarek/qubes-core-agent-linux/commit/7eb75618cbee54d8d986ad70a7646c07db0dd4d6 by @marmarek: