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
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
If no updates are available, display some notification about that (when
GUI mode requested). Otherwise user has no idea what happened (update
failed? still doing something?).
FixesQubesOS/qubes-issues#3751
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
On LVM thin it is easy to fill the pool if fstrim (or 'discard' mount
option) isn't used from time to time. Enable fstrim.timer by default,
which will do fstrim once a week.
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
* qubesos/pr/38:
Bad spaces
Add -p to mkdir to skip error if dir already exists
Make dir dom0-updates if not exists on UpdateVM
FixesQubesOS/qubes-issues#3620
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.
Avoid passing special characters (like '$' or '@') to the service, even
if in environment variable. Use separate variable (and
qubes-rpc-multiplexer argument) to provide type of original target.
There are two:
- specific VM by name ("name")
- special name, like $adminvm, $dispvm etc ("keyword")
Then, use separate variables to provide actual value:
- QREXEC_REQUESTED_TARGET_KEYWORD (if _TYPE == "keyword")
- QREXEC_REQUESTED_TARGET (if _TYPE == "name")
The later one intentionally is the same as in previous implementation,
to preserve compatibility.
GUI updaters and Packagekit are confused by networkless dom0 and often
report that:
- cannot check for updates (because of no network connection)
- no updates are available, even if they are
The latter happen mostly because PackageKit does not load dnf.conf, so
try to use /etc/yum.repos.d (network repositories) instead of
/etc/yum.real.repos.d (local cache, downloaded by qubes-dom0-update).
Currently PackageKit does not support configuring it, the path is
hardcoded.
Until both of above issues get fixed, prefer console updater.
FixesQubesOS/qubes-issues#1378
It's necessary to add the break at the end of "case -1" statement else the compiler will treat it as fall through and GCC 7 will throw an error because of -Werror=implicit-fallthrough=.
PackageKit is used only by GUI updaters, refresh its cache only then.
Since PackageKit daemon do not read dnf.conf, it doesn't know the right
repository location, so try to access network, which results in
timeouts. But at the same time, it invalidate previous cache, which is
what we need.
Do not delay every qubes-dom0-update call by pkcon call.
- only have one button, because "yes/no" makes no sense in this context
- inform use to use "-t pv" for xl console, because otherwise it won't
work for HVM domains.
- use the actual VM name, not "vmname"
Perhaps the UpdateVM template should be temporarily switched to the
backup too. That would make it really failsafe. Currently it requires
manual recovery (by setting template of UpdateVM to the backup).
DM_UDEV_DISABLE_DISK_RULES_FLAG flag sometimes isn't properly
propagated, so just to be sure, add a flag file
/var/lib/qubes/.qubes-exclude-block-devices to exclude that directory.
Fixes 5c84a0b "udev: don't exclude loop devices pointing outside of
/var/lib/qubes"
QubesOS/qubes-issues#3084
