When -f/--force is used, wipefs does not call ioctl(BLKRRPART), hence
the partitions will remain in sysfs. Let's not use the option.
This also makes it use 'udevadm lock' for safety.
When the test VM is accidentally rebooted, there exists the previously
created volume, and the command fails with the following:
```
TEST-64-UDEV-STORAGE.sh[282]: + lvm pvcreate -y /dev/md/mdlvm
TEST-64-UDEV-STORAGE.sh[442]: Can't initialize physical volume "/dev/md127" of volume group "mdlvm_vg" without -ff
TEST-64-UDEV-STORAGE.sh[442]: /dev/md127: physical volume not initialized.
[FAILED] Failed to start TEST-64-UDEV-STORAGE-mdadm_lvm.service.
```
Let's ignore the existence of previous volume and forcibly create new one.
Workaround for issue #38240.
- drop unused variables,
- adjust number of partitions, interations, and timeout,
- clear partitions on each test case finished,
- check if unnecessary devlinks are removed,
- several coding style cleanups.
To suppress the following warnings in case check_device_unit() failed e.g.
when the device is already removed:
```
sed: couldn't write 130 items to stdout: Broken pipe
awk: write failure (Broken pipe)
awk: close failed on file "/dev/stdout" (Broken pipe)
```
For some reasons, kernel or sfdisk once remove the created partitions
and recreated them. And if 'udevadm trigger' triggers devices currently
being removed, the udevd does not receive the triggered events, and the
command stuck.
```
[ 33.150452] TEST-64-UDEV-STORAGE.sh[546]: + sfdisk --wipe=always /dev/md/mdmirpar
[ 33.478336] systemd-udevd[442]: md127: Device is queued (SEQNUM=2163, ACTION=change)
[ 33.480153] kernel: md127: p1 p2 p3
[ 33.483772] systemd-udevd[442]: md127p1: Device is queued (SEQNUM=2164, ACTION=add)
[ 33.483914] systemd-udevd[442]: md127p2: Device is queued (SEQNUM=2165, ACTION=add)
[ 33.484999] systemd-udevd[442]: md127p3: Device is queued (SEQNUM=2166, ACTION=add)
[ 33.485564] systemd-udevd[442]: md127: Received inotify event of watch handle 164.
[ 33.503016] TEST-64-UDEV-STORAGE.sh[546]: + SYSTEMD_LOG_LEVEL=debug
[ 33.503016] TEST-64-UDEV-STORAGE.sh[546]: + timeout 30 udevadm trigger --settle --parent-match /dev/md/mdmirpar
[ 33.485905] systemd-udevd[442]: Successfully forked off '(udev-synth)' as PID 3208.
[ 33.486067] systemd-udevd[442]: md127: Removing watch handle 164.
[ 33.489035] systemd-udevd[442]: md127p1: Device is queued (SEQNUM=2167, ACTION=remove)
[ 33.489048] systemd-udevd[442]: Received inotify event about removal of watch handle 164.
[ 33.489507] systemd-udevd[442]: md127p2: Device is queued (SEQNUM=2168, ACTION=remove)
[ 33.496298] systemd-udevd[442]: md127p3: Device is queued (SEQNUM=2169, ACTION=remove)
[ 33.500628] systemd-udevd[442]: md127: Device is queued (SEQNUM=2170, ACTION=change)
[ 33.502355] systemd-udevd[442]: md127p1: Device is queued (SEQNUM=2171, ACTION=add)
[ 33.509371] TEST-64-UDEV-STORAGE.sh[3211]: md127: Triggered device with action 'change'.
[ 33.509371] TEST-64-UDEV-STORAGE.sh[3211]: md127p1: Triggered device with action 'change'.
[ 33.509371] TEST-64-UDEV-STORAGE.sh[3211]: md127p2: Triggered device with action 'change'.
[ 33.512532] systemd-udevd[442]: md127: Device is queued (SEQNUM=2172, ACTION=change, UUID=a0b75692-08ad-428a-859b-9ef8772874d7)
[ 33.512666] systemd-udevd[442]: md127p1: Device is queued (SEQNUM=2173, ACTION=change, UUID=4cd75a91-aa5b-4678-878c-0420b6c2e1e9)
[ 33.512796] systemd-udevd[442]: md127p2: Device is queued (SEQNUM=2174, ACTION=add)
[ 33.512910] systemd-udevd[442]: md127p3: Device is queued (SEQNUM=2175, ACTION=add)
[ 33.531834] TEST-64-UDEV-STORAGE.sh[3211]: md127: Got uevent without UUID, ignoring: No such file or directory
[ 33.553563] TEST-64-UDEV-STORAGE.sh[3211]: md127p1: Got uevent without UUID, ignoring: No such file or directory
[ 33.561262] TEST-64-UDEV-STORAGE.sh[3211]: md127p2: Got uevent without UUID, ignoring: No such file or directory
[ 33.562468] TEST-64-UDEV-STORAGE.sh[3211]: md127p2: Got uevent without UUID, ignoring: No such file or directory
[ 33.563143] TEST-64-UDEV-STORAGE.sh[3211]: md127p3: Got uevent without UUID, ignoring: No such file or directory
[ 33.564174] TEST-64-UDEV-STORAGE.sh[3211]: md127p1: Got uevent without UUID, ignoring: No such file or directory
[ 33.567614] TEST-64-UDEV-STORAGE.sh[3211]: md127p3: Got uevent without UUID, ignoring: No such file or directory
[ 33.597750] TEST-64-UDEV-STORAGE.sh[3211]: md127: Got uevent without UUID, ignoring: No such file or directory
[ 33.623522] TEST-64-UDEV-STORAGE.sh[3211]: md127p1: Got uevent without UUID, ignoring: No such file or directory
[ 33.676268] TEST-64-UDEV-STORAGE.sh[3211]: md127p3: Got uevent without UUID, ignoring: No such file or directory
[ 33.686088] TEST-64-UDEV-STORAGE.sh[3211]: md127p2: Got uevent without UUID, ignoring: No such file or directory
```
Let's wait for partition devices being actually created, and wait for
all queued events being processed. Then, call 'udevadm trigger'.
Otherwise, if a test in a spurious state, it consumes quite long time.
Let's fail earlier in such case.
This also drops an unnecessary calls of 'udevadm settle' in
testcase_nvme_basic() of TEST-64-UDEV-STORAGE.
New version of mdadm now asks a second question, so send 'y' twice
to it in the test scripts
[ 5.253483] TEST-64-UDEV-STORAGE.sh[684]: + echo y
[ 5.254412] TEST-64-UDEV-STORAGE.sh[685]: + mdadm --create /dev/md/mdmirror --name mdmirror --uuid aaaaaaaa:bbbbbbbb:cccccccc:00000001 /dev/disk/by-id/scsi-0systemd_foobar_deadbeefmdadm0 /dev/disk/by-id/scsi-0systemd_foobar_deadbeefmdadm1 -v -f --level=1 --raid-devices=2
[ 5.254759] TEST-64-UDEV-STORAGE.sh[685]: To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? mdadm: Note: this array has metadata at the start and
[ 5.255085] TEST-64-UDEV-STORAGE.sh[685]: may not be suitable as a boot device. If you plan to
[ 5.255418] TEST-64-UDEV-STORAGE.sh[685]: store '/boot' on this device please ensure that
[ 5.255745] TEST-64-UDEV-STORAGE.sh[685]: your boot-loader understands md/v1.x metadata, or use
[ 5.256285] TEST-64-UDEV-STORAGE.sh[685]: --metadata=0.90
[ 5.256672] TEST-64-UDEV-STORAGE.sh[685]: mdadm: size set to 64512K
[ 5.257063] TEST-64-UDEV-STORAGE.sh[685]: Continue creating array [y/N]? mdadm: create aborted.
This is backward compatible with the older version that asks just one
question
In the nvme_subsystem test, there are only namespace IDs 16 and 17,
so there would no longer be an "obsolete" symlink created, since this
test scenaro does not create a namespace with ID 1.
Signed-off-by: Bryan Gurney <bgurney@redhat.com>
When running the test on aarch64 the symlinks look as follows:
"""
[root@H ~]# ls /dev/disk/by-path
platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0 platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part1 platform-4010000000.pcie-pci-0000:00:05.0-nvme-16
platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part2 platform-4010000000.pcie-pci-0000:00:05.0-nvme-17
"""
So let's make the PCI patterns a little more generic so they match
both the x86 and the aarch64 paths.
The virtio-scsi driver is available in the KVM/cloud kernel
packages provided by distributions whereas the megasas2 driver is
not. Let's switch to virtio-scsi so we can switch back to the KVM/cloud
kernel packages.
On running cryptsetup, udevd detects two inotify events for the
underlying device. Running the test on enough fast host, the expected
symlinks based on UUID and disk label are created by the second event.
During processing a uevent for a device, udevd disables the inotify
watch for the device. If the test runs on slow system, the second
inotify event may comes during a udev worker processing the synthesized
uevent triggered by the first inotify event. Hence, no synthesized
uevent for the second inotify event will be generated, and the expected
symlinks will be never created.
To prevent the issue, we need to lock the device during cryptsetup
command is running.
Fixes#32913.
On Debian/Ubuntu, the unit is named tgt.service instead of tgtd.service,
so let's make sure we take that into account.
On CentOS, tgtd.service is not available, so let's skip the test if we
can't find the service.
Having these named differently than the test itself mostly creates
unecessary confusion and makes writing logic against the tests harder
so let's rename the testsuite-xx units and scripts to just use the
test name itself.