qrexec-client -t/-T (and therefore, qvm-run --pass-io) only handled the
escape character, \033. Everything else, such as Unicode and obscure
control characters, was passed through from the VM to the dom0 terminal.
Instead, replace all bytes except for a benign subset of ASCII. That's
still enough to allow progress bars to be drawn (tested using
"wget --progress=bar:force" and "pv --force").
This will ease filtering entries when constructing applications menu.
For example '<OnlyUnallocated/>' key used in Xfce4 before looks to
introduce some problems.
FixesQubesOS/qubes-issues#2129
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
