This doesn't yet prevent appvms from starting with invalid template during the reinstall, and doesn't deal with the Netvm setting problem.
For issue #2061
The entry may be already present for example when reinstalling package,
or calling the script multiple times (which apparently is the case
during system installation).
/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.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
This will allow to use some different shell/language for a service (for
example python).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
In non-EFI installation /boot/efi/EFI/qubes may not exists. In this case
do not try to touch (non-existing) files there.
FixesQubesOS/qubes-issues#1829
After installing "codeblocks" app in TemplateVM it doesn't appear in Qubes VM Manager's available app shortcuts.
If I run in a Dom0 Terminal: /usr/libexec/qubes-appmenus/qubes-receive-appmenus fedora-23
I get this: "Warning: ignoring key 'Name' of codeblocks.desktop"
The "Name" key in that file has value "Code::Blocks"
The problem comes from line 168, because of the colons in the app Name.
By adding the colon ":" to the std_re used to match valid characters for "Name", the app is correctly parsed and I can add the shortcut to AppVMs
Host suspend notification may be useful not only to driver domains. For
example Whonix needs to resync time after suspend.
Thanks @adrelanos for help.
FixesQubesOS/qubes-issues#1663
qvm-sync-clock running in background is killed as soon as
qubes-suspend.service is terminated.
Additionally restore --verbose option, which was the case (implicitly)
in previous qvm-run based code.
FixesQubesOS/qubes-issues#1795
* qubesos/pr/5:
Use #!/bin/bash and && in qvm-move-to-vm
qvm-copy-to-vm: Fix running with multiple file arguments
qvm-move-to-vm: Remove duplicated code
After suspend VMs clocks are desynchronized in most cases (because VMs
were paused). Since directly after suspent there may be no network
access, normal `qvm-sync-clock` call isn't good (it aborts if NTP call
fails). But with new `qvm-sync-clock --force` switch, it sync VMs even
if NTP is unreachable.
QubesOS/qubes-issues#1728
When qrexec-agent crashes for any reason (for example
QubesOS/qubes-issues#1389), it will never connect back and qrexec-client
will wait forever. In worst case it may happen while holding qubes.xml
write lock (in case of DispVM startup) effectively locking the whole
system.
FixesQubesOS/qubes-issues#1636
#!/bin/bash because qvm-move-to-vm sources qvm-copy-to-vm, which has
a bashism (-o pipefail).
&& is safer in case qvm-*copy*-to-vm is ever changed to call 'set +e'.