- /var/run/qubes/this-is-appvm
- /var/run/qubes/this-is-netvm
- /var/run/qubes/this-is-proxyvm
- /var/run/qubes/this-is-templatevm
This is useful for checking ConditionPathExists from within systemd units.
(Came up in https://phabricator.whonix.org/T432#7206.)
Because those services do not yet support being restarted.
Extended variable `$nrconf{override_rc}`, i.e. packages only reported to need
restart, but blacklisted from default/suggested automatic restarted with
`qubes-core-agent` and `qubes-gui-agent`.
See also `$nrconf{override_rc}`:
10bd2db5e2/ex/needrestart.conf (L65)
Thanks to @liske for helping with this.
https://github.com/liske/needrestart/issues/13#issuecomment-136804625
Since this proxy is used only when explicitly configured in application
(package manager), there is no point in worrying about user
_erroneously_ using web browser through this proxy. If the user really
want to access the network from some other application he/she can always
alter firewall rules for that.
FixesQubesOS/qubes-issues#1188
Among other things this also fixes build failure - those scripts were
installed but not listed in spec file.
Actual check doesn't perform 'apt-get update', so do that when running
"standalone" (not as a hook from 'apt-get').
QubesOS/qubes-issues#1066
Previously even if NetworkManager was enabled, our script manually
configured network parameters. This apparently have negative effects,
because NetworkManager tries to configure some things differently - for
example use metric 1024 for default gateway.
FixesQubesOS/qubes-issues#1052
* origin/pr/48:
Allow to provide customized DispVM home directly in the template VM
This allows to put a customized DispVM home directly in /home_volatile
in the template instead of placing it in the -dvm internal AppVM.
This significantly speeds up DispVM startup for large customized homes,
since none of the home data has to be copied out from saved_cows.tar to
volatile.img, and instead CoW is used.
It's not a very user friendly or discoverable solution, but it only
takes a few lines of code, and so seems a reasonable stopgap until a
much more complex solution with copy-on-write for the private.img is
written.
Each time some arbitrary package was installed using dpkg or apt-get, the update notification in Qubes VM Manager was cleared.
No matter if there were still updates pending. (Could happen even after the user running `apt-get dist-upgrade` in case of package manager issues.)
No longer clear upgrade notification in QVMM on arbitrary package installation.
Check if upgrades have been actually installed before clearing the notifications.
https://github.com/QubesOS/qubes-issues/issues/1066#issuecomment-150044906
Depending on yum version, adding '-q' option may hide not only
informational messages, but also updates list. This is especially the
case for yum-deprecated in Fedora 22.
So instead of '-q' option, filter the output manually.
QubesOS/qubes-issues#1282
Since /lib/modules is not mounted read-only anymore (only a selected
subdirectory there), it is no longer required to prevent kernel package
installation. Even more - since PV Grub being supported, it makes sense
to have kernel installed in the VM.
QubesOS/qubes-issues#1354
Don't use ${CONF_PATH}.qubes, because it may override some existing
file, and is racy approach (even if not against user, but another script
instance).
QubesOS/qubes-issues#1282
Fix for d44c8ac "dom0-updates: prefer yum-deprecated over dnf"
Because of slightly different options and config syntax, it needs to be
used in call calls, not only the one with --downloaddir option.
QubesOS/qubes-issues#1282
Initramfs created in TemplateVM may be used also in AppVMs based on it, so
technically it is different system. Especially it has different devices
mounted (own /rw, own swap etc), so prevent hardcoding UUIDs here.
QubesOS/qubes-issues#1354
