There is a possiblilty of the apt-get post hook getting triggered
more than once for each apt-get session, therefore we only notify
dom0 that there are no updates available and do not perform an
apt-get update.
The qubes-update-check.service will still perform an update so even
if the dist-upgrade failed and there was actually more files to update
the qubes-update-check.serivce would then at some point notify dom0
about those updates being available
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVO0XmAAoJEBu5sftaTG2tTpsQAJaSV/4vUt1R+HloAxpiAkQQ
ai6C9r0jXEDOggO+jqeNLhM6ZaFxPOqI7+O09EXoRQXnFjtXPq6V4Yj8vr7urh5Z
ozg3K2atQ6htvoDjqktSHuMwJLTGCHDCKzHV/uvZlFT0o90XomGLAJ+3RuWqgZu7
5h+jnzfo+pLxme2jiCFQvFQ+p6Y+yZiphiUc5HbnIs4aTvDJxKmhZHMXVshbFJQe
wPr1kp4xdefiys5A5agKejPOdQm8z4PVzZfnehfQZholkKlYFSgOLc7s4qJ+WOFl
Bwl8B0Nm4LqIr0hkyEvPBX7PwmAu8/2aHeEj423rLXCDvHjGbmDWE99LSRvDYFK4
nuZkrR+dI0kbYqtfkWH8MMfu/YHcC+uHrkVbLpqV4r8F8jT/f6ysyJ/kb76WoVEK
B2q/nfBjtcHXOb/7GT/Q8MIvIXDsAVNp9jtEiQ/u/Jr8T7t9GtuQbgy1Y+eDOl4G
Hg5635qfj6SImKtj6e4VqOb968TqeE0qoqBeLFEG2boqyVOjHbfk8gj5IZParp3R
WfZDAS6OpY95W+gJzH0rBUh0h5fcuB+aN16ak4snaDxwd6gl9NfdPOydt4zQTs4q
tmKnyuXig5age0IgGFliubdWlAL72GSN8M+uBp+Pe0QoEoJRPN3AiaY63OgUBk9S
ID6TzMI990IRIxGTQnho
=nJSZ
-----END PGP SIGNATURE-----
Merge tag 'jm_21d89335'
Tag for commit 21d89335fe
# gpg: Signature made Sat Apr 25 09:44:38 2015 CEST using RSA key ID 5A4C6DAD
# gpg: Good signature from "Jason Mehring (Qubes OS Signing Key) <nrgaway@gmail.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: E0E3 2283 FDCA C1A5 1007 8F27 1BB9 B1FB 5A4C 6DAD
* tag 'jm_21d89335':
debian: Update notification now notifies dom0 when an upgrade is completed
A file is created in /var/lib/qubes/protected-files. Scripts can grep this file before modifying
known files to be protected and skip any modifications if the file path is within protected-files.
Usage Example:
if ! grep -q "^/etc/hostname$" "${PROTECTED_FILE_LIST}" 2>/dev/null; then
Also cleaned up maintainer scripts removing unneeded systemd status functions and streamlined
the enable/disable systemd unit files functions
vif-route-qubes can be called simultaneously, for example in case of:
- multiple domains startup
- HVM startup (two interfaces: one to the target domain, second one to
stubdom)
If that happens, one of calls can fail because of iptables lock.
Offline resize requires to run fsck -f first. Because we support only
growing that image, we can simply use online resize instead.
This finally fixesqubesos/qubes-issues#772
Apparently it doesn't help much with DispVM startup time, but causes a
lot of problems when such app do not close in time (either can be killed
forcibly and will complain about it at next run, or will spontaneously
show itself when DispVM is started).
This will probably break some user configuration. Do that only when
installing for the first time (during template build), during upgrade
set only those installed by this package instead of all.
systemctl is-enabled always reports "disabled" for them (actually not a
real "disabled", but and error, but exit code is the same). So simply
always disable the unit, it is no-op for already disabled ones.
BTW systemctl preset also do not work for them.
Simply forget about that connection, instead of waiting for further
messages. If that connection is no longer available, select would return
EBADF, which would cause qrexec-agent termination.
/usr/local resides in private.img, so it is possible to define per-appvm RPC
Also, with the upcoming 3.0 release support for old (R1) paths is
removed.
In case of remote process exit even when some messages are still
waiting, vchan connection can be already closed. If we try to send some
data in this case (for example stdout of local process), there will be
an error, which will terminate qrexec-client-vm/qrexec-agent child. So
first check vchan data (where could be MSG_EXIT_CODE queued) , then
local process.
There is still some race condition in this code - remote process could
exit just after we check vchan, but before we send some data. But this
is much less probable and in the worst case we only loose remote process
exit code.
