Those devices are most likely attached using "PV USB" from another
domain, so it doesn't make sense to list them as available for further
passthrough.
QubesOS/qubes-issues#531
Even if particular PV USB implementation doesn't support it, still have
it included in QubesDB. It should be up to attaching code to decide.
Also, don't fail if xen-usbback module doesn't exist. This isn't the
only option (the other one is usbip over qrexec).
QubesOS/qubes-issues#531
During early dom0 boot, before xenstored is started any access to it
through /proc/xen/xenbus (or /dev/xen/xenbus) will wait until xenstored
is started. If that happens in script ordered to start before xenstored,
we have a deadlock. Prevent this by using `xenstore-ls -s` in dom0,
which will fail immediately when xenstored isn't running yet. This fail
isn't a problem, because when xenstored isn't running yet, surely device
isn't attached anywhere.
QubesOS/qubes-issues#1081
This prevents simultaneous attachment of the same device (in practice)
to multiple VMs.
This change to be effective requires udev action being called when such
device is attached/detached to some domain. Script
/etc/xen/scripts/block will take care of it.
FixesQubesOS/qubes-issues#1081
Exclude exclude device if mounted/part of other device, or any of its
partition is used (same definition). Update this state whenever device
or it's partition receives udev event.
FixesQubesOS/qubes-issues#1600
* origin/pr/4:
archlinux: fix syntax errors in install file
archlinux: add an install file specifically for vm-kernel-support
kernel-support: compile u2mfn from source even if it has been never built
archlinux: implement kernel-support
archlinux: ensure gcc, make and pkgconfig are makedependencies
When device becomes non-attachable (for example because it gets mounted,
or used as part of LVM/RAID/whatever), it should be removed from
advertised available devices. The code for removing QubesDB entry was
buggy - the device is actually a directory in QubesDB, not a single
entry.
QubesOS/qubes-issues#1600
There are already some other rules to ignore not interesting devices.
This includes device-mapper assembled in initramfs manually. 'dmroot'
isn't properly detected as mounted because /dev/mapper/dmroot isn't a
symlink to /dev/dm-0 and /proc/mounts contains the former name, while
udev event the later.
FixesQubesOS/qubes-issues#1586
Generally build env (rpmbuild, dpkg-buildpackage) provide sane and
useful defaults.
Fixes hardening-no-relro lintian warning.
QubesOS/qubes-issues#1416
By default dracut set 600 mode. While it isn't a problem for starting a
VM (which is done as root), it is a problem for creating standalone VM,
which has it's own copy of kernel directory.
New version of sfdisk have different syntax for other units (suffixes
beside the numbers, instead of global --unit). The only common unit is
sector, so use that.
FixesQubesOS/qubes-issues#1427
Commit https://github.com/QubesOS/qubes-linux-utils/commit/c1d42f1 --
"qfile-unpacker: do not call fdatasync() at each file" fixing
QubesOS/qubes-issues#1257 -- increased the chance of data loss with
qvm-move-to-vm: Say it nominally succeeds, and *deletes* the files from
the source VM. Soon after, the destination VM or the system could crash,
or an external drive hosting ~/QubesIncoming/srcVM could get unplugged
by accident, all before the data had really been persisted to disk.
But reverting the commit (ignoring the performance issue) wouldn't
completely solve this:
"Calling fsync() does not necessarily ensure that the entry in the
directory containing the file has also reached disk. For that an
explicit fsync() on a file descriptor for the directory is also
needed." - fsync(2)
It gets even worse for "slow symlinks" (whose target is too long to be
stored directly in the inode metadata), apparently they can't be synced
at all individually.
So instead, just call syncfs() once after everything has been unpacked:
+ Should prevent all data loss (if fs and disk are well behaved)
+ Allows caching and reordering -> no slowdown with many small files
- Blocks until any unrelated writes on the filesystem finish :\
The filesystem hosting ~/QubesIncoming/srcVM/ needs to support O_TMPFILE
too, in addition to the kernel. If it doesn't, take the use_tmpfile = 0
fallback.
Theoretically it shouldn't be a problem, because module isn't installed
in initramfs by default (in dom0), but since such error would be fatal
to dom0 (will prevent it from booting), add a safety check for it.
Probably it will be required when (if) we migrate dom0 to Debian
