The network-uplink-wait.sh script may be called before xen-netfront
module is even loaded (by udev). In that case, `get_qubes_managed_iface`
will fail to get the interface name and the wait will be skipped.
Fix this by loading xen-netfront module explicitly (do not try to
synchronize with udev, which is tricky not knowing the device
name).
... if it doesn't exist.
The /qubes-mac qubesdb entry is present on Qubes 4.1, but not 4.0. It is
ok to depend on it here, but keep safer fallback if this code would need
to be backported.
Check just 10 MiB of the private volume + blkid before considering it
empty and calling mkfs. Avoid reading 1GB of data at the VM boot -
which should speed up startup even further, especially for fresh
DispVMs.
QubesOS/qubes-issues#3758
The previous approach used `df` to get usable space and then added a
fixed size to that number in order to account for filesystem
overhead. However, at some point that stopped working for me. It
appears that ext4 filesystem overhead can vary over time or because of
other factors. (Certainly now that I think about it the old code would
only work well for people with the exact same filesystem size as me.)
So the new approach is to just completely ignore what `df` tells us
and instead go directly to the source: the filesystem's internal
notion of exactly how much space it takes up. We use `dumpe2fs` to
retrieve this information and calculate the on-disk size dynamically
from that. Then we add the space that boot data takes up (unchanged),
and we add 5MB padding because when I tested this it didn't quite add
up otherwise. https://unix.stackexchange.com/a/13551/29146 suggests
that this unaccounted-for data may be e.g. additional copies of the
superblock.
* origin/pr/141:
is_protected_file: if no config dir is present, assume the file is _not_ protected
/rw/config
Fix logic bug.
Allow per-VM protected file list
See
https://github.com/QubesOS/qubes-core-agent-linux/pull/146#discussion_r238080117
for details; but tl;dr:
* Journal size is 64M
* Inode table is 256 bytes * 643376 inodes allocated = ~157M
* Reserved GDT blocks take up 1024 blocks * 4096 byte block size = 4M
* Fixed-size parts of the filesystem probably take up another MB or
two
These actually adds up to more than the 222M number used in this
commit. But it seems _about_ right, so just Ship It(tm).
This reverts commit 8000e76d43, because
as @marmarek pointed out, the original was correct and I totally
misread. The check in question is checking whether to _abort_, not
whether to continue. So we want to check if the block device size is
_less_ than the filesystem + margin, not more.
ReopensQubesOS/qubes-issues#4553
If xvda is not partitioned, checking size of device mounted as root dev
doesn't detect xvda resize - it will have the new size, while the fs on
it not. Change to checking actual filesystem size.
Also, improve log message to include the size.
FixesQubesOS/qubes-issues#4274
As described in QubesOS/qubes-issues#3758, a VM may fail to start
if the volume is large. This because the whole volume is read to
ensure it's empty (=all zeros).
This changes limits the check to the first 1 GiB of the private
volume. As additional safety, a scan with blkid is done.
Fixes https://github.com/QubesOS/qubes-issues/issues/3758
On first VM's boot, setup-rwdev.sh script create filesystem on
/dev/xvdb. But it does so only after checking if /dev/xvdb is really
empty, by comparing it to /dev/zero. Speed up reads from /dev/zero bu
using larger blocks (default of head - 8k, instead of explicit 512).
This speed up the check over 5 times.
This looks like an overkill. And more importantly - required modules are
not installed by default, making it impossible to use in default minimal
template.
FixesQubesOS/qubes-issues#1610
When trying offline resize2fs, it require running fsck first, which
takes time, especially on large volumes. And in most cases, resize2fs
will notice that no action is needed - after wasting some time on fsck.
To remedy this, use resize2fs in online mode (on mounted filesystem).
And drop fsck call if it fails (filesystem is already mounted
read-write, running fsck isn't good idea).
But do not remove fsck call completely - still call it, but without '-f'
flag, so it run actual check only when really needed (unclean shutdown,
last check far in the past etc).
FixesQubesOS/qubes-issues#979FixesQubesOS/qubes-issues#2583
