So far when prompting for the LUKS passphrase the dialog always looks
like this:
+------------------------------------------------+
| LUKS Passphrase /dev/sdb1 |
+------------------------------------------------+
| Enter LUKS passphrase to open /dev/sdb1 |
| Passphrase: [ ] |
| |
| |
| [ Cancel ] [ Unlock ] |
+------------------------------------------------+
Specifically the first line of the dialog says the reason to provide the
passphrase is to open the encryption mapping. Now the passphrase may
also be requested when resizing the encryption mapping, as part of a
resize of check operation, show the appropriate reason in the password
dialog.
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
A check operation involves (1) checking the file system, (2) growing the
encryption volume and (3) growing the file system. Therefore prompt for
the LUKS passphrase as required when composing a check operation too.
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
This is the final piece which enables GParted to pass the LUKS
passphrase when resizing an open LUKS encryption mapping when
'cryptsetup resize' will prompt for it.
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
This is the equivalent to what was previously done when adding opening
of LUKS mappings. Namely to add a way to pass the LUKS passphrase to
'cryptsetup luksOpen' via standard input. Previously the functionality
was added to Utils::execute_command() [1]. Now it is also needed to
pass the LUKS passphrase to 'cryptsetup resize', which is executed as
part of applying resize and check operations to an encrypted file
system. So add this functionality to FileSystem::execute_command().
For now writing to stdin is only needed for the one variant of
FileSystem::execute_command() which doesn't have progress tracking
callbacks. Writing to stdin can easily be added to the other progress
tracking callback variants of execute_command() when needed.
[1] 8dff80edc6
Add ability for small writes to stdin of child processes (#795617)
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
When composing a resize operation on an open encryption mapping, use the
existing LUKS password dialog to prompt for the passphrase, if and only
if 'cryptsetup resize' will prompt and GParted doesn't already have a
password. 'cryptsetup resize' will prompt for a LUKS passphrase when
the passphrase was stored in the kernel keyring service,
key_loc == KEYLOC_KeyRing. See the previous commit "Capture LUKS
mapping master encryption key location (#59)" for more details.
As commented in the code GParted specifically doesn't support the case
where the LUKS passphrase is changed while GParted is running and it
knew the old passphrase. When resizing an open encryption mapping
GParted will just pass the old out of date passphrase it knows and the
resize will fail like this:
# cryptsetup status sdb2_crypt | egrep 'type|key location'
type: LUKS2
key location: keyring
# dmsetup table --target crypt
sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768
# echo -n oldpassword | cryptsetup -v --size 491520 resize sdb2_crypt
No key available with this passphrase.
Command failed with code -2 (no permission or bad passphrase).
# echo $?
2
To work around this either close and restart GParted or close and reopen
the encryption mapping. The former because GParted doesn't save
passwords across a restart so will prompt and the latter because GParted
will use the wrong old passphrase to try to open the mapping and then
prompt for the correct passphrase until successfully opened.
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
ISSUE OVERVIEW
When GParted tries to resize an open LUKS encryption mapping and the
volume (master) key was stored in the kernel keyring service [1] it
fails like this:
Check and repair file system ([Encrypted] ext4) on /dev/...(ERROR)
+ calibrate /dev/sdd1 (SUCCESS)
+ check file system on /dev/mapper/sdd1_crypt for errors...(SUCCESS)
+ grow encryption volume to fill the partition (ERROR)
+ cryptsetup -v resize 'sdd1_crypt' (ERROR)
Command failed with code -1 (wrong or missing parameters).
Nothing to read on input.
This error occurs with cryptsetup >= 2.0, kernel >= 4.10 and LUKS2
format because the crypt Device-Mapper target no longer has the volume
key so cryptsetup resize prompts for a passphrase, but GParted doesn't
provide it.
THIS COMMIT
Additionally capture the location of the volume (master) key location
for active encryption mappings. Do this the using the same method that
cryptsetup uses [2][3]. Namely if the first character of the KEY is a
":" then the key *was* stored in the kernel keyring service, otherwise
it *is* store in the Device-Mapper crypt target as previously.
# echo -n badpassword | cryptsetup luksFormat --type luks1 /dev/sdb1 -
# echo -n badpassword | cryptsetup luksOpen /dev/sdb1 sdb1_crypt
# cryptsetup status sdb1_crypt | egrep 'type|key location'
type: LUKS1
key location: dm-crypt
# echo -n badpassword | cryptsetup luksFormat --type luks2 /dev/sdb2 -
# echo -n badpassword | cryptsetup luksOpen /dev/sdb2 sdb2_crypt
# cryptsetup status sdb2_crypt | egrep 'type|key location'
type: LUKS2
key location: keyring
# dmsetup table --target crypt
sdb1_crypt: 0 520192 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:17 4096
sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768
^
First character of the KEY field --------------'
[1] Integration with the kernel keyring service
https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/Keyring.txt
"
Starting with cryptsetup 2.0 we load [Volume Key] VK in kernel
keyring by default for LUKSv2 devices ...
In summary, the key description visible in dm-crypt table line is a
reference to VK that usually no longer exists in kernel keyring
service if you used cryptsetup to for device activation.
"
[2] cryptsetup/v2.3.5/lib/libdevmapper.c:_dm_target_query_crypt()
https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/lib/libdevmapper.c#L2031
if (key_[0] == ':')
*act_flags |= CRYPT_ACTIVATE_KEYRING_KEY;
[3] cryptsetup/v2.3.5/src/cryptsetup.c:action_status()
https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/src/cryptsetup.c#L839
log_std(" key location: %s\n", (cad.flags & CRYPT_ACTIVATE_KEYRING_KEY) ? "keyring" : "dm-crypt");
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
When GParted probes an open encryption mapping which is either blank or
contains a file system which libparted doesn't recognise, such as:
exfat, f2fs, lvm2 pv, minix or reiser4, then the partition also gets
this warning message:
/dev/mapper/sdb11_crypt: unrecognised disk label
Clear the message so that it isn't shown in the GUI.
Note that the message is still written to stderr by GParted, like all
libparted exceptions are. This is done by GParted's libparted exception
handler:
GParted_Core::ped_exception_handler()
_ped_exception_handler()
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
The previous commit "Resolve empty drive displayed as blank minor logic
issue (#152)" left the code in set_device_and_disk() some what
unsightly.
Refactor the whole function. Use if fail return early pattern for
failure of the get_device() call at the start of the function. Reorder
the 4 cases into a single depth if then else if chain. Hopefully this
is a little easier to follow.
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
The previous commit "Remove coding landmine in get_disk() (#152)" made
an empty drive without a disk label (partition table) display as
nothing, instead of the normal single unallocated partition with warning
"unrecognised disk label".
The previous commit said:
3. The two remaining direct calls to get_disk() where the strict
parameter is explicitly set to false, from set_device_from_disk()
and detect_filesystem_in_encryption_mapping(), are when scanning.
As the pass strict=false they don't allow the PedDevice deletion
to occur if no recognised disk label is found.
This is true, but get_disk(..., strict=false) additionally returned true
even if there was no disk label. And in set_device_from_disk() the
empty drive case is inside the if branch of the get_disk() call
returning true.
Simply fix this by calling get_disk(), ignoring the return value.
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
get_disk() is the wrapper around libparted's ped_disk_new() which reads
a disk label from the specified device and if successful creates the in
memory PedDisk object to represent it. In the case that libparted
doesn't recognise a disk label or a file system, having get_disk() go
and destroy the passed in PedDevice object via parameter lp_device is
very unexpected behaviour hence describing it as a coding landmine.
BACKGROUND
1. Early on GParted only worked with devices with valid disk labels.
FileSystem.h:open_device_and_disk() required both ped_device_get()
and ped_disk_new() to succeed or neither to succeed.
2. Commit [1] added support for devices which didn't yet have a disk
label. open_device_and_disk() had default parameter strict=true
added. While scanning strict=false was passed which allowed
open_device_and_disk() to return success if only ped_device_get()
succeeded and ped_disk_new() failed when the disk was empty. All
other times open_device_and_disk() was called with default
strict=true, still requiring both or neither to succeed.
3. Commit [2] added support for whole disk file systems. The now named
get_device_and_disk() had it's functionality split between
get_device() and get_disk(). This result in the code landmine being
left behind: get_disk() destroying the passed device object if
default parameter strict=true and no disk label or file system was
detected.
ANALYSIS
1. Since support for whole disk file systems [2] all current calls to
get_device_and_disk() let the strict parameter default to true and
are only called on known partitions within disk labels when applying
a change to that partition. Therefore they don't care about the
behaviour of get_disk(), just that get_device_and_disk() maintains
that both ped_device_get() and ped_disk_new() succeed or neither
succeed.
2. Two direct calls to get_disk() where the strict parameter defaults to
true, from calibrate_partition() and erase_filesystem_signatures(),
only do so on known partitions within disk labels as part of applying
a change to that partition. Therefore ped_disk_new() will succeed
and so PedDevice isn't deleted when not wanted.
3. The two remaining direct calls to get_disk() where the strict
parameter is explicitly set to false, from set_device_from_disk() and
detect_filesystem_in_encryption_mapping(), are when scanning. As the
pass strict=false they don't allow the PedDevice deletion to occur if
no recognised disk label is found.
FIX
Remove the strict parameter from get_disk() and get_device_and_disk() as
it's no longer needed. Remove the code landmine by removing the side
affect of destroying the PedDevice object if a disk label isn't found.
Make sure get_device_and_disk() maintains the all or nothing behaviour.
Also don't pass lp_device by reference to a pointer to get_disk() so the
code can't change where lp_device points.
[1] 038c5c5d99
P (special thanks to mantiena-baltix for bringing this issue to my
[2] 51ac4d5648
Split get_device_and_disk() into two (#743181)
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
As discussed in the previous commit "Don't crash probing libparted
unrecognised encrypted file system (#152)", detect_filesystem() accepted
a NULL lp_device pointer and dereferenced it leading to the crash.
Document the requirement for lp_device parameter to be non-NULL via an
assert and also correctly const the parameters.
This forces needing to const the lp_partition parameter to
get_partition_path() too. Also assert it's non-NULL requirement.
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
Create a LUKS encrypted partition and open it. Then either leave the
contents blank or create a file system which libparted doesn't
recognise, such as: exfat, f2fs, lvm2 pv, minix or reiser4. When
GParted probes the disk device it crashes.
# echo -n badpassword | cryptsetup luksFormat /dev/sdb11
# echo -n badpassword | cryptsetup luksOpen /dev/sdb11 sdb11_crypt
# ./gpartedbin /dev/sdb
GParted 1.2.0-git
configuration (none)
libparted 3.1
/dev/mapper/sdb11_crypt: unrecognised disk label
Segmentation fault (core dumped)
Backtrace:
#0 0x0000000000460f68 in GParted::GParted_Core::detect_filesystem(_PedDevice*, _PedPartition*, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&)
(lp_device=0x0, lp_partition=0x0, messages=std::vector of length 0, capacity 0)
at GParted_Core.cc:1235
#1 0x00000000004615a6 in GParted::GParted_Core::detect_filesystem_in_encryption_mapping(Glib::ustring const&, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&)
(path=..., messages=std::vector of length 0, capacity 0)
at GParted_Core.cc:1096
#2 0x00000000004647c8 in GParted::GParted_Core::set_luks_partition(GParted::PartitionLUKS&)
(this=this@entry=0x7fff43f974e0, partition=...)
at GParted_Core.cc:1011
#3 0x000000000046511b in GParted::GParted_Core::set_device_partitions(GParted::Device&, _PedDevice*, _PedDisk*)
(this=this@entry=0x7fff43f974e0, device=..., lp_device=0x7efc780008c0, lp_disk=0x7efc78000d10)
at GParted_Core.cc:883
#4 0x00000000004658e3 in GParted::GParted_Core::set_device_from_disk(GParted::Device&, Glib::ustring const&)
(this=this@entry=0x7fff43f974e0, device=..., device_path=...)
at GParted_Core.cc:704
#5 0x0000000000465fff in GParted::GParted_Core::set_devices_thread(std::vector<GParted::Device, std::allocator<GParted::Device> >*)
(this=0x7fff43f974e0, pdevices=0x7fff43f96bc8)
at GParted_Core.cc:266
#6 0x00007efc99ba413d in call_thread_entry_slot ()
at /lib64/libglibmm-2.4.so.1
#7 0x00007efc97dc8555 in g_thread_proxy ()
at /lib64/libglib-2.0.so.0
#8 0x00007efc96ab4ea5 in start_thread () at /lib64/libpthread.so.0
#9 0x00007efc967dd9fd in clone () at /lib64/libc.so.6
The relevant sequence of events goes like this:
detect_filesystem_in_encryption_mapping(path, ...)
lp_device = NULL
get_device(path, lp_device)
lp_device = ped_device_get(path.c_str())
return true
lp_disk = NULL
lp_partition = NULL
get_disk(lp_device, lp_disk) // + default parameter strict=true
lp_disk = ped_disk_new(lp_device)
// No libparted recognised disk label or file system found, so
// NULL returned.
destroy_device_and_disk(lp_device, lp_disk)
ped_device_destroy(lp_device)
lp_device = NULL
return false
detect_filesystem(lp_device, lp_partition, ...)
path = lp_device->path
The key points are:
1. get_device() created a PedDevice object pointed to by lp_device;
2. get_disk() didn't find a libparted recognised disk label or file
system but also unexpectedly destroyed the PedDevice object and
assigned NULL to lp_device;
3. detect_filesystem() dereferenced lp_device assuming it was still
valid.
Implement the simplest possible fix by telling get_disk() to not
destroy the needed PedDevice object when there's no recognised content.
This is the same as how get_disk() is called in set_device_from_disk().
Closes#152 - GParted crashed when trying to probe an encrypted
partition containing content that libparted doesn't
recognise
Even though blkid is considered mandatory [1] GParted should still
perform reasonably when blkid is not available, provided that is not too
onerous a task. Also use libparted file system identification inside
encryption mappings.
[1] 749a249571
Document blkid command as a mandatory requirement (#753436)
Closes 148 - Encrypted file systems are no longer recognised
GParted no longer recognises file systems inside LUKS encryption, apart
from the few recognised by GParted's internal detection. Bisected to
this commit:
8b35892ea5
Pass device and partition names to blkid (#131)
Prior to this commit blkid was run querying all known block devices
including active encryption mappings, hence prior recognition. With
this commit blkid was run only for named or found disk devices and
associated found partitions from /proc/partitions, so no more
recognition of encrypted file systems.
Fix by running blkid on the encryption mapping just before querying for
the file system. This restores the level of functionality that existed
before.
Closes 148 - Encrypted file systems are no longer recognised
To avoid making set_luks_partition() more complicated extract the file
system detection portion into a new function.
Closes 148 - Encrypted file systems are no longer recognised
Since changes for issue #131 "GParted hangs when non-named device is
hung" FS_Info cache is initialised, cleared and loaded via one call to
load_cache_for_paths(). It runs blkid for named or found disk devices
and associated found partitions from /proc/partitions, rather than
running blkid and letting it report for all block devices.
To avoid the possibility of using blkid on an encryption mapping on a
non-specified and possibly hung block device GParted can't just specify
all encryption mappings. Instead only encryption mappings which belong
to the above identified block devices should be probed. That requires
identifying LUKS encryption data in the block devices first so will
require subsequently loading additional data into the FS_Info cache and
running blkid again.
To accommodate this make the FS_Info cache incrementally loadable,
rather than doing everything in a single call to load_cache_for_paths().
Have a separate clear_cache() call which initialises and clears the
cache and make load_cache_for_paths() just run blkid and insert data for
the named paths.
Closes 148 - Encrypted file systems are no longer recognised
Reiser4 has introduced new disk format which includes support for
spanning the file system over multiple block devices (subvolumes)
[1][2]. As such the output of the debugfs.reiser4 for the UUID has
changed slightly. So far the new reiser4progs package (version 2.0.x)
is only available as a Debian experimental package.
Using reiser4progs 1.2.1 the old output was like this:
$ debugfs.reiser4 test.img
debugfs.reiser4 1.2.1
Format release: 4.0.2
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.
Master super block (16):
magic: ReIsEr4
blksize: 4096
format: 0x0 (format40)
uuid: 1116afce-99fd-4a6e-94cb-2d9f19c91d67
label: <none>
...
With reiser4progs 2.0.4 the new output is like this:
$ debugfs.reiser4 test.img
debugfs.reiser4
Package Version: 2.0.4
Software Framework Release: 5.1.3
Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.
Master super block (16):
magic: ReIsEr4
blksize: 4096
volume: 0x1 (asym)
distrib: 0x1 (fsx32m)
format: 0x1 (format41)
description: Standard layout for logical volumes.
stripe bits: 14
mirror id: 0
replicas: 0
volume uuid: 9538bfa3-5694-4abe-864c-edc288a9d801
subvol uuid: d841c692-2042-49e6-ac55-57e454691782
label: <none>
...
GParted happens to read the correct UUID just because the first matching
"uuid" string in the output is the volume UUID. Make the code more
robust by explicitly reading the volume uuid when labelled as such.
[1] Logical Volumes Howto
https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Howto
[2] Logical Volumes Background
https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Background
The GitLab CI ubuntu_test job has occasionally been failing like this,
perhaps once every few weeks or so.
[ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4
test_SupportedFileSystems.cc:569: Failure
Expected: (m_partition.uuid.size()) >= (9U), actual: 0 vs 9
[ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4, where GetParam() = 24 (17 ms)
[----------] 1 test from My/SupportedFileSystemsTest (17 ms total)
Turns out there are 2 bugs in resier4progs. One causes debugfs.reiser4
to report a null UUID if the first byte of the UUID happens to be zero
[1], and the other cases mkfs.resier4 to write a corrupted UUID,
sometimes a null (all zeros) UUID [2].
There is a 1 in 256 chance of getting a null UUID [2] when creating and
reading a reiser4 file system, hence the occasional failure of the CI
job. The centos_test job isn't affected because CentOS doesn't have the
reiser4progs package.
Fix this by detecting when reiser4 reports a null UUID and assign a
dummy UUID to make the test pass. This does mean that there is a 1 in
256 chance of not detecting a true failure. However that still means
there is a 255 in 256 chance of detecting a true failure. That's good
odds. When a null UUID is detected for a reiser4 file system the test
output looks like this:
[ RUN ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4
test_SupportedFileSystems.cc:580: Ignore test failure of a null UUID.
[ OK ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4 (46 ms)
[1] 4802cdb18a
Fix up repair_master_print()
[2] 44cc024f39
Stop occasionally making file systems with null UUIDs
Closes#145 - Sporadic failure of test case
My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4
Print the kernel version and supported file systems inside the GNOME
GitLab CI jobs as a debugging aid. Kernel version helps identify the
CI job runner's distribution to identify kernel features. Supported
file systems identifies which ones can be mounted, should that be
possible in future. Print supported file systems before and after the
tests because checking for support may load additional modules. See
calls to Utils::kernel_supports_fs() for: btrfs, jfs, nilfs2 and xfs.
Closes#147 - GitLab CI test failure from *.CreateAndGrow/jfs
For the first time ever the ubuntu_test GitLab CI job failed running the
JFS grow test like this. Fragment from tests/test-suite.log:
[ RUN ] My/SupportedFileSystemsTest.CreateAndGrow/jfs
test_SupportedFileSystems.cc:387: Failure
Failed
create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img'
losetup: cannot find an unused loop device
create_loopdev(): Losetup failed with exit status 1
create_loopdev(): Failed to create required loop device
Error: Could not stat device - No such file or directory.
test_SupportedFileSystems.cc:446: Failure
Value of: lp_device != NULL
Actual: false
Expected: true
test_SupportedFileSystems.cc:649: Failure
Value of: m_fs_object->create(m_partition, m_operation_detail)
Actual: false
Expected: true
Operation details:
mkfs.jfs -q -L '' '' 00:00:00 (ERROR)
mkfs.jfs version 1.1.15, 04-Mar-2011
The system cannot find the specified device.
detach_loopdev(): Execute: losetup --detach ''
losetup: : failed to use device: No such device
detach_loopdev(): Losetup failed with exit status 1
detach_loopdev(): Failed to detach loop device. Test NOT affected
[ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/jfs, where GetParam() = 17 (24 ms)
JFS can only be grown when mounted by the kernel and GParted only
enables JFS grow support when, among other things, kernel support is
detected.
Unknowingly the JFS grow test had always previously been skipped, even
in the ubuntu_test CI job which installs jfsutils, because the kernel
didn't support JFS. Capture of this test from another run of the
ubuntu_test CI job:
[ RUN ] My/SupportedFileSystemsTest.CreateAndGrow/jfs
test_SupportedFileSystems.cc:641: Skip test. grow not supported or support not found
[ OK ] My/SupportedFileSystemsTest.CreateAndGrow/jfs (0 ms)
Plus additional debug added into the job based on what
Utils::kernel_supports_fs() does to identify kernel support:
$ fgrep jfs /proc/filesystems || true
$ modprobe jfs || true
modprobe: FATAL: Module jfs not found in directory /lib/modules/3.10.0-1160.11.1.el7.x86_64
$ fgrep jfs /proc/filesystems || true
Therefore until now every GitLab job runner machine kernel didn't
support JFS, but for the first time ever this ubuntu_test job ran on a
runner machine where the kernel did support JFS, hence the attempt to
use losetup.
Examining test_SupportFileSystems.cc there are 24 file system tests
which specify SKIP_IF_NOT_ROOT_FOR_REQUIRED_LOOPDEV_FOR_FS(), but only
17 exclusions in .gitlab-ci.yaml [1]. The 7 tests without exclusions
are:
*.CreateAndReadLabel/lvm2pv
*.CreateAndReadUUID/lvm2pv
*.CreateAndWriteLabel/lvm2pv
*.CreateAndWriteUUID/lvm2pv
*.CreateAndGrow/jfs
*.CreateAndGrow/nilfs2
*.CreateAndShrink/nilfs2
For LVM2 PVs reading and writing of labels and UUIDs aren't implemented
(only reading of UUIDs could be supported as the others are impossible)
so those tests are always skipped. Add unit test exclusions just for
completeness.
JFS grow is this case. NILFS2 grow and shrink are more cases where
kernel support is needed. Add unit test exclusions to stop attempting
to run JFS and NILFS2 resizing tests, which don't currently work because
losetup doesn't work in the GitLab CI docker images [1].
[1] 39fdfe51da
Exclude unit tests needing losetup in Docker CI image (!59)
Closes#147 - GitLab CI job failure from *.CreateAndGrow/jfs
Hugo Carvalho