Main qubes-core-dom0 should not be installed as part of installer image,
but os-prober dependency pulls that in. So move it into
qubes-core-dom0-kernel-install subpackage. After all this is where grub
config regeneration code is placed, so it is more logical place.
(cherry picked from commit e062c431dd)
Split kernel-install hook into separate package, as only this part is
needed by the installer. This will prevent installing all the Qubes/Xen
staff in the installer, especially udev scripts and xenstored, which
doesn't play well with anaconda.
(cherry picked from commit 5e6d3a273d)
Conflicts:
rpm_spec/core-dom0-linux.spec
The default one generates initramfs in location expected by Boot Loader
Specification, which as noted before, isn't useful for Qubes.
(cherry picked from commit fddeb4a23c)
Since we now allow using Fedora kernel, add a script to generate proper
bootloader configuration then. Standard Fedora mechanism relies on
Boot Loader Specification support in grub2, which sadly does not support
Xen, so it is useless in Qubes.
(cherry picked from commit 2a14ae9c0b)
Conflicts:
rpm_spec/core-dom0-linux.spec
Apparently when package is signed with DSA key, rpm -K output is totally
different. This is the case for bumblebee package on rpmfusion.
Fixesqubesos/qubes-issues#988
(cherry picked from commit a5650d3251)
Otherwise if some package download fails once - further tries will also
report errors.
Fixesqubesos/qubes-issues#987
(cherry picked from commit f2b5cf1cc0)
This would override user changes to the template. Previous method
(Obsoletes: rpm header) doesn't work now, so add explicit exclude list
as yum option
Fixesqubesos/qubes-issues#996
(cherry picked from commit 4cab815317)
Conflicts:
dom0-updates/qubes-dom0-update
This will prevent passing an option instead of command (qvm-run) /
domain name (qrexec-policy). In both cases when VM tries to pass some
option it would fail because missing argument then - VM can not pass
additional arguments, so if one act as an option, one argument will be
missing).
(cherry picked from commit d031126737)
Conflicts:
qrexec/qrexec-daemon.c
When VM-VM qrexec service is called, two qrexec-clients are connected in
dom0. If both VMs are sending data simultaneously it can happen that
both qrexec-client processes will call write(2) and none of them will be
reading -> deadlock.
Solve it by handling I/O in two separate threads (one for reading from
VM, another for writing), at any time qrexec-client is ready to accept
data from either direction.
Marek Marczykowski-Górecki