qubes-firewall.service have Before=qubes-network.service. The latter
enable ip_forwarding. Make sure the ordering cover not only service
fork, but all its startup sequence, including initial rules and user
scripts.
Reported-by: @tasket
It doesn't make sense in Qubes to rebuild modules at every VM startup.
Especially when modules dir is either read-only, or on non-persistent
root volume (TemplateBasedVM).
This is especially uneeded for dom0-provided kernels, which already have
u2mfn module built, but DKMS try to rebuild it anyway (and fails,
because of missing/broken kernel-devel package).
DKMS already have appropriate (rpm/dpkg) hooks for new kernel
installation, so actually needed modules should be build in template on
kernel update/install anyway.
This saves about 2s from VM startup time.
If IPv6 gateway address provided by dom0 isn't a link local address, add
a /128 route to it. Also, add this address on backend interfaces (vif*).
This is to allow proper ICMP host unreachable packets forwarding - if
gateway (address on vif* interface) have only fe80: address, it will be
used as a source for ICMP reply. It will be properly delivered to the VM
directly connected there (for example from sys-net to sys-firewall), but
because of being link-local address, it will not be forwarded any
further.
This results timeouts if host doesn't have IPv6 connectivity.
Since fixing QubesOS/qubes-issues#3213, launch function correctly waits
for some applications exit. This is undesirable for
qubes-session-autostart service, which should just start the
applications and exit.
This is especially important for qubes-desktop-run used inside DispVM.
The DesktopAppInfo.launch() method returns after just launching the
application. In DispVM case it worked by a coincidence - because the
launched application was keeping stdin/out open, which also prevented
DispVM killing. Use DesktopAppInfo.launch_uris_as_manager which at least
allows to learn PIDs of spawned processes, to track them manually.
This still doesn't fix gnome-terminal issue, or any other application
using either DBus activation, or any other client-server model. But at
least fix basic apps like firefox and xterm.
FixesQubesOS/qubes-issues#3213
Since we have proper python package, use it instead of hacky one-file
package. This will ease installation and packaging, including switching
to python3.
Add an option for custom vchan buffer size, to override default 64k (for
each direction). This is especially useful when the other side of
connection is MirageOS based, because of limited memory and default
grant table size (128 entries).
The dconf package isn't required by qubes-core-agent - the package ships
a configuration for it, useful if user have it installed for other
reasons. Don't try to rebuild dconf database if dconf isn't installed -
avoid misleading error message.
FixesQubesOS/qubes-issues#3492
On first VM's boot, setup-rwdev.sh script create filesystem on
/dev/xvdb. But it does so only after checking if /dev/xvdb is really
empty, by comparing it to /dev/zero. Speed up reads from /dev/zero bu
using larger blocks (default of head - 8k, instead of explicit 512).
This speed up the check over 5 times.
* qubesos/pr/94:
Drop fakeroot for list/search actions on Debian
dom0-update: add some approximation of 'list', 'search' and 'reinstall'
dom0-updates: refactor for ease adding new actions with old yum
Previously the script was called through shell as:
execl(shell, "-sh", "-c", "/usr/lib/qubes/qubes-rpc-multiplexer
...", 0);
This tells the shell to load login scripts, including /etc/profile.
Since 5512e4eada this is no longer the
case and the script is called directly. Since most services do expect
proper user session initialized (/etc/profile loaded etc), adjust the
script's shebang to behave like a login shell and load those startup
scripts.
FixesQubesOS/qubes-issues#3615
This avoids duplicating service call parsing in multiple places.
Further improvements to that code (like avoid using shell) can be
implemented in one place.
