Fix current EFI boot dir discovery script.
Also, adjust scripts order:
50-dracut generates initramfs in /boot/(efi/)?/$MACHINE_ID/.../initrd
80-grub2 copies it to /boot/initramfs-....img
90-xen-efi copies it to /boot/efi/EFI/qubes/initramfs-....img
Make the above order explicit, rather than relying on xen sorted later
than grub2.
QubesOS/qubes-issues#3234
(cherry picked from commit 9eefe23f4c)
Remove also EFI version of BootLoader Specification dirs. This will:
- really force to re-generate initramfs during installation, after all
relevant configs are updated; previously, dracut (called by anaconda
through kernel-install) refuse to update already existing
/boot/efi/.../initrd file.
- save some precious space in /boot/efi
FixesQubesOS/qubes-issues#3234
(cherry picked from commit 53730c4ba2)
During installation, /usr/lib/kernel/install.d/50-dracut.install
generate initramfs in $BOOT_DIR_ABS. It is important to use that one,
even if there is one in /boot/initramfs-*.img already, because it was
generated later and contains all required config files (including
keyboard layout for entering LUKS passphrase).
This fixes d1f3be0eed "kernel-install:
avoid creating initramfs multiple times".
FixesQubesOS/qubes-issues#3234
(cherry picked from commit bcf7c9e978)
There are multiple places where initramfs can be created:
- /boot/iniramfs-*.img
- /boot/$MACHINE_ID/.../initrd (unused on Qubes, but created by Fedora
scripts)
- /boot/efi/EFI/.../initramfs-*.img
Do not generate all of those from scratch, but try to reuse existing
image (if exists). Since one dracut call may last even 5 minutes, this
change should greatly reduce installation time.
FixesQubesOS/qubes-issues#3637
(cherry picked from commit d1f3be0eed)
Rely on qrexec-client resolving QUBESRPC keyword, same as in case of VM
call. This will allow applying special treatment to such calls, like
calling qubes-rpc-multiplexer directly (avoiding shell), because we have
defined protocol what can be used here.
Using '$' is easy to misuse in shell scripts, shell commands etc. After
all this years, lets abandon this dangerous character and move to
something safer: '@'. The choice was made after reviewing specifications
of various shells on different operating systems and this is the
character that have no special meaning in none of them.
To preserve compatibility, automatically translate '$' to '@' when
loading policy files.
After the change of target keywords, apply transparen translation from
old names. This will avoid breaking calls from not updated VMs. Apply
this change only in stable branch.
Those parameters eventually may eventually be passed to a shell script
(at least /usr/lib/qubes/qubes-rpc-multiplexer). While it is possible to
properly escape shell special characters, lets do safer and less fragile
thing: forbid such characters entirely.
In case of target name, qrexec policy keywords are allowed, and after
recent change, those contains '@', so allow this char.
(cherry picked from commit cf28dad1943bd424b2ed23000cdcfd32d8e3190c)
This avoids duplicating service call parsing in multiple places. For
dom0 part it was in qrexec-policy tool.
Also, add execl() error handling.
(cherry picked from commit 32b0c659a1)
When policy specify 'target=' option, update 'vm' variable too (used to
start appropriate domain), not only 'target' variable (used to
make the actual call. Otherwise wrong domain is started (original one,
not the one overriden by target= option), and the call fails - since
the right domain is not running.
There was a second place with exactly the same bug. See
dad208a "qrexec: fix pending requests cleanup code" for details.
FixesQubesOS/qubes-issues#2699
(cherry picked from commit 8719e5d74c)
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
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.
