Prior to this commit, if the Linux kernel's Xen-related components were
built into the kernel (as opposed to the use of kernel modules), then
the dracut module initialization would fail during the generation of the
initial ramdisk image.
This commit corrects this issue by using an if/then block.
Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
There was a logic error in pending requests cleanup code, causing
policy_pending_max being set to 0, even if there were more pending
requests. This effectively limited maximum pending requests to 1, after
some system uptime, because policy_pending_max set to 0 makes the code
looks only at the first pending request slot.
While at it, remove outdated FIXME comment, actually this bug is in the
code implementing this FIXME.
FixesQubesOS/qubes-issues#2699
There was a logic error in pending requests cleanup code, causing
policy_pending_max being set to 0, even if there were more pending
requests. This effectively limited maximum pending requests to 1, after
some system uptime, because policy_pending_max set to 0 makes the code
looks only at the first pending request slot.
While at it, remove outdated FIXME comment, actually this bug is in the
code implementing this FIXME.
FixesQubesOS/qubes-issues#2699
Can close windows of a VM while it's paused, and can not accidentally
harm dom0 by errant clicking.
Discussion in https://github.com/QubesOS/qubes-issues/issues/881
Thanks to rustybird for suggested implementation.
Design documentation says:
'note string dom0 does not match the $anyvm pattern; all other names do'
This behaviour was broken, because 'is not' in python isn't the same as
string comparison. In theory this could result in some service
erroneously allowed to execute in dom0, but in practice such services are
not installed in dom0 at all, so the only impact was misleading error
message.
FixesQubesOS/qubes-issues#2031
Reported by @Jeeppler
I need to set some flags in order to boot as described here:
https://www.qubes-os.org/doc/uefi-troubleshooting/
My settings look like this:
$ efibootmgr -v
BootCurrent: 0000
Boot0000* Qubes HD(...)/File(\EFI\qubes\xen.efi)p.l.a.c.e.h.o...
which causes awk to get confused and think my $EFI_DIR should be:
/EFI/qubesp.l.a.c.e.h.o.l.d.e.r. ./.m.a.p.b.s. ./.n.o.e.x.i.t.b.o.o.t.
This causes the script to later bail:
if [ ! -d "$EFI_DIR" ]; then
# non-EFI system
exit 0;
fi
So my xen.cfg did not get new entries when installing dom0 kernel packages.
Add support for `$dispvm:DISP_VM` syntax in target specification. At the
same time update the code for core3 API for handling DispVMs.
QubesOS/qubes-issues#2253
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").
Normally when qrexec-client setup VM-VM connection it exits
immediatelly. But it may be useful to wait for the connection to
terminate - for example to cleanup DispVM.
qrexec-daemon (the one that allocated vchan port) do receive such
notification, so expose such option to qrexec-client.
QubesOS/qubes-issues#2253
It is critical to call rename-related events in the right order related
to those in QubesVM, because handler at QubesVM renames VM directory.
After "qubes/events: fix event handlers ordering" in qubes-core-admin it
is (again) possible to deterministically order event handler from
extension in relation to those from the class itself. But since ordering
on object class have higher priority (first from base class), those
handlers needs to be attached to the same class.
