* 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
