Since a few days the CI started to fail randomly when there were loop
devices used in the tests. The mount fails because some device is
reported to be missing:
$ losetup --show --find
/dev/loop3
...
$ mkfs ...
ERROR: device scan failed on '/dev/loop3': No such file or directory
...
$ mount
mount: /home/runner/work/btrfs-progs/btrfs-progs/tests/mnt: wrong fs
type, bad option, bad superblock on /dev/loop3, missing codepage or
helper program, or other error.
$ dmesg
...
BTRFS error (device loop0): devid 3 uuid 11d9c345-9527-433e-a024-7102659fa0ee is missing
BTRFS error (device loop0): failed to read the system array: -2
BTRFS error (device loop0): open_ctree failed
This was reproducible in the "cli" tests, but also happened on a local
machine.
To fix that wait for all loop devices before mount, the command
'btrfs device ready' should block until that. The convenience helper
does that, for any standalone 'mount' used with loop devices this must
be done manually.
Signed-off-by: David Sterba <dsterba@suse.com>
Executing the script inside the directories as './test.sh' is not
supposed to work but could happen accidentally. With an exit after
attempting to source the we can fix that.
Signed-off-by: David Sterba <dsterba@suse.com>
Add a test for a scenario that used to fail due to find_mount_root()
incorrectly determining the mount point for the receive path due to the
fact that a different mount point with a path that is a prefix of the
receive path exists.
This is fixed by a recent patch titled:
"Btrfs-progs: fix mount point detection due to partial prefix match"
Reported-by: David Disseldorp <ddiss@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
[ adjustments to make the test work when hosted on NFS ]
Signed-off-by: David Sterba <dsterba@suse.com>
David Sterba
Filipe Manana