For various reasons, decryption may be slower than initial encryption
(different hardware, different system load etc). Do not fail the restore
operation if scrypt anticipate it will take considerably more time or
memory, than while creating the backup (where the scrypt parameters were
originally set).
Thanks to @jharveyb for the report and suggested solution.
FixesQubesOS/qubes-issues#4683
* origin/pr/84:
Fixed typo in documentation
Documentation is important! Added shortcuts to manpages
added tests for shortcuts
diff doesn't set template
added --standalone and --disp shortcuts
* origin/pr/85:
isinstance instead of type
reverted to comparing .index
forgot braces
forgot braces
get_label now accepts integer and has correct return-type
Pylint complains that main() is too long and that's indeed true. Factor
out single process call (together with all the prepartion) into separate
function and keep only common code in main().
When cloning VM, create it in the same pool as the source one.
Previously it always used default pool, which means for example renaming
a VM in non-default pool moved it back to the default one.
FixesQubesOS/qubes-issues#4145FixesQubesOS/qubes-issues#4523
Print some error even without --pass-io, otherwise the only way to learn
the failure is checking $?, as no other visual sign is there.
FixesQubesOS/qubes-issues#4533
qubes.VMShell service, used by qvm-run, expects the command on the first
input line. Previously, when --localcmd was used, the command wasn't
written anywhere and the local command was connected directly to
qubes.VMShell service. And the first line of its output was interpreted
as a command.
Fix this by starting the local command separately, after sending the
command to qubes.VMShell service.
While at it, unify handling shell command and service calls in the process.
vm.run_service(..., localcmd= ) isn't that useful in general case,
because for qubes.VMShell the caller first need to send the command
before starting local process. Since the qvm-run tool needs to implement
manual starting localcmd anyway, don't use localcmd= run_service's
argument at all to unify calling methods.
There is slight behavior change: previously localcmd was started only
after establishing service connection (for example only if qrexec policy
allows), now it is started in all the cases.
FixesQubesOS/qubes-issues#4040
Add note in QubesBase docstring it shouldn't be used directly.
Additionally add base qubesd_call and run_service methods raising
NotImplementedError with helpful message. Lack of qubesd_call in
QubesBase leads to infinite recursion, because one in PropertyHolder
calls itself then.
FixesQubesOS/qubes-issues#4568
The qubesd daemon have no information about clone source - from that
side it looks like a new VM. This means application menu is created as
for a new VM.
To fix this re-initialize menu with --source option as part of the clone
operation. It will copy both list of available applications (if
applicable) and selected applications.
This fixes both qvm-clone case and rename.
FixesQubesOS/qubes-issues#3902FixesQubesOS/qubes-issues#4124
By definition StandaloneVM is not linked to the template. Creating one
from a template is a clone operation. It's already possible using
qvm-clone tool, but it's logical to do that using qvm-create tool too.
This was the case in R3.2 too.
While adding this special case, skip cloning private volume, to preserve
behaviour of TemplateBaseVMs which do not inherit private volume either.
FixesQubesOS/qubes-issues#3793
