QA » openQA Project » openQA Infrastructure

Guess that was me. A simple "chassis power cycle" did the trick.

Interesting. But do you know what caused the problem then?

but also ssh service failed

I've rejected the salt-key for now on OSD to prevent automatic startup of workers. What I found while booting is that the systems hangs for quite some time with the last message being printed: [ 1034.526144] kexec_file: kernel signature verification failed (-129). - which seems to fit with okurz suggestion that this is caused by kernel updates.

nicksinger wrote:

[…] seems to fit with okurz suggestion that this is caused by kernel updates.

but what I meant is only that some package upgrades, for example kernel updates, trigger a reboot which is all according to plan. Have you seen #78010#note-9 regarding the systemd services? I suspect that this is simply again or still a problem of systemd service dependencies and fully in our control.

please see #77011#note-18 for changes that fvogt has applied. We should crosscheck the changes he did, commit to salt and ensure this is applicable for all machines and then apply the same to all, o3 and osd.

So I diffed with what fvogt did:

diff --git a/openqa/nvme_store/openqa_nvme_create.service b/openqa/nvme_store/openqa_nvme_create.service
new file mode 100644
index 0000000..9e9b57b
--- /dev/null
+++ b/openqa/nvme_store/openqa_nvme_create.service
@@ -0,0 +1,20 @@
+[Unit]
+Description=Create array on NVMe if necessary
+# Let's hope this is close enough to "all nvmes present"
+Requires=dev-nvme0n1.device
+After=dev-nvme0n1.device
+DefaultDependencies=no
+
+[Service]
+Type=oneshot
+
+# It's not really possible to wait for that to happen, so do it here
+ExecStart=/bin/sh -c "if ! mdadm --detail --scan | grep -qi openqa; then mdadm --assemble --scan || true; fi"
+# Create striped storage for openQA from all NVMe devices when / resides on
+# another device or from a potential third NVMe partition when there is only a
+# single NVMe device for the complete storage
+# For some reason mdadm --create doesn't send an udev event, so do it manually.
+ExecStart=/bin/sh -c -e 'if lsblk -n | grep -q "raid"; then exit 0; fi; if lsblk -n | grep -v nvme | grep -q "/$"; then mdadm --create /dev/md/openqa --level=0 --force --raid-devices=$(ls /dev/nvme?n1 | wc -l) --run /dev/nvme?n1; else mdadm --create /dev/md/openqa --level=0 --force --raid-devices=1 --run /dev/nvme0n1p3; fi; udevadm trigger -c add /dev/md/openqa'
+
+[Install]
+WantedBy=multi-user.target
diff --git a/openqa/nvme_store/openqa_nvme_format.service b/openqa/nvme_store/openqa_nvme_format.service
index f6f1c16..8e9d97c 100644
--- a/openqa/nvme_store/openqa_nvme_format.service
+++ b/openqa/nvme_store/openqa_nvme_format.service
@@ -1,19 +1,12 @@
 [Unit]
-Description=Setup NVMe before mounting it
+Description=Create Ext2 FS on /dev/md/openqa
 Before=var-lib-openqa.mount
+Requires=dev-md-openqa.device
+After=dev-md-openqa.device
 DefaultDependencies=no

 [Service]
 Type=oneshot
-
-# Create striped storage for openQA from all NVMe devices when / resides on
-# another device or from a potential third NVMe partition when there is only a
-# single NVMe device for the complete storage
-ExecStart=/bin/sh -c 'lsblk -n | grep -q "raid" || lsblk -n | grep -v nvme | grep "/$" && (mdadm --stop /dev/md/openqa >/dev/null 2>&1; mdadm --create /dev/md/openqa --level=0 --force --raid-devices=$(ls /dev/nvme?n1 | wc -l) --run /dev/nvme?n1) || mdadm --create /dev/md/openqa --level=0 --force --raid-devices=1 --run /dev/nvme0n1p3'
-# Ensure device is correctly initialized but also spend a little time before
-# trying to create a filesystem to prevent a "busy" error
-ExecStart=/bin/sh -c 'grep nvme /proc/mdstat'
-ExecStart=/bin/sh -c 'mdadm --detail --scan | grep openqa'
 ExecStart=/sbin/mkfs.ext2 -F /dev/md/openqa

 [Install]

I'm not convinced yet that this will resolve our problem. I'd rather like to look into why our array-devices are busy in the first place.
I suspect that something assembles our array before we format and therefore assume we have a dependency problem.

From a first, quick look I think it could be related to mdmonitor.service. From https://linux.die.net/man/8/mdadm:

[…] all arrays listed in the configuration file will be monitored. Further, if --scan is given, then any other md devices that appear in /proc/mdstat will also be monitored. 

Which would explain why the device is busy. I will experiment with some dependencies for our service to run before mdmonitor

well, seems like this custom image was (blindly? Or was I pressing Enter where no console showed up?) reinstalling the worker. At least this is how it looks to me:

0:openqaworker3:~ # lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0         7:0    0  89.1M  1 loop  /parts/mp_0000
loop1         7:1    0  12.7M  1 loop  /parts/mp_0001
loop2         7:2    0  58.3M  1 loop  /mounts/mp_0000
loop3         7:3    0  72.6M  1 loop  /mounts/mp_0001
loop4         7:4    0   4.1M  1 loop  /mounts/mp_0002
loop5         7:5    0   1.8M  1 loop  /mounts/mp_0003
sda           8:0    0 931.5G  0 disk
├─sda1        8:1    0   9.8G  0 part
│ └─md4       9:4    0   9.8G  0 raid1 /mnt
├─sda2        8:2    0 995.6M  0 part
└─sda3        8:3    0 920.8G  0 part
  └─md0       9:0    0 920.8G  0 raid1
sdb           8:16   0 931.5G  0 disk
├─sdb1        8:17   0   9.8G  0 part
│ └─md4       9:4    0   9.8G  0 raid1 /mnt
├─sdb2        8:18   0 995.6M  0 part
└─sdb3        8:19   0 920.8G  0 part
  └─md0       9:0    0 920.8G  0 raid1
nvme0n1     259:0    0 372.6G  0 disk
└─nvme0n1p1 259:1    0 372.6G  0 part
nvme1n1     259:2    0 372.6G  0 disk
0:openqaworker3:~ # ls -lah /mnt/
total 132K
drwxr-xr-x 27 root root 4.0K Dec 11 12:15 .
drwxr-xr-x 23 root root  820 Dec 14 13:34 ..
drwxr-xr-x  2 root root 4.0K Apr 13  2018 bin
drwxr-xr-x  3 root root 4.0K Dec 11 12:15 boot
-rw-r--r--  1 root root  893 Apr 13  2018 bootincluded_archives.filelist
-rw-r--r--  1 root root  816 May 24  2013 build-custom
drwxr-xr-x  3 root root 4.0K Apr 13  2018 config
drwxr-xr-x  3 root root 4.0K Apr 13  2018 dev
drwxr-xr-x 90 root root 4.0K Dec 14 11:34 etc
drwxr-xr-x  2 root root 4.0K Jun 27  2017 home
drwxr-xr-x  2 root root 4.0K Dec 11 12:14 kiwi-hooks
drwxr-xr-x  2 root root 4.0K Apr 13  2018 kvm
drwxr-xr-x  2 root root 4.0K Apr 13  2018 kvm_lock_sync
drwxr-xr-x 10 root root 4.0K Apr 13  2018 lib
drwxr-xr-x  7 root root 4.0K Apr 13  2018 lib64
drwx------  2 root root  16K Apr 13  2018 lost+found
drwxr-xr-x  2 root root 4.0K Jun 27  2017 mnt
drwxr-xr-x  2 root root 4.0K Jun 27  2017 opt
drwxr-xr-x  2 root root 4.0K Apr 13  2018 proc
drwx------  4 root root 4.0K Apr 13  2018 root
drwxr-xr-x 16 root root 4.0K Apr 13  2018 run
drwxr-xr-x  2 root root  12K Dec 11 12:14 sbin
drwxr-xr-x  2 root root 4.0K Jun 27  2017 selinux
drwxr-xr-x  5 root root 4.0K Apr 13  2018 srv
drwxr-xr-x  3 root root 4.0K May 24  2013 studio
dr-xr-xr-x  2 root root 4.0K Jun 27  2017 sys
drwxrwxrwt  9 root root 4.0K Dec 14 11:34 tmp
drwxr-xr-x 13 root root 4.0K Apr 13  2018 usr
drwxr-xr-x 11 root root 4.0K Dec 11 12:15 var

Guess it's time for a reinstall…

On 2021-1-25 morning, openqawokrer3 failed to start. I log in to this machine use ipmitool and press Control-D, and it showed:

[SOL Session operational.  Use ~? for help]

Login incorrect

Give root password for maintenance
(or press Control-D to continue): 
Starting default target
[86888.689121] openvswitch: Open vSwitch switching datapath
[86890.320765] No iBFT detected.

Welcome to openSUSE Leap 15.2 - Kernel 5.3.18-lp152.60-default (ttyS1).

openqaworker3 login: [86891.801204] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[86891.825522] device ovs-system entered promiscuous mode
[86891.831409] Timeout policy base is empty
[86891.835347] Failed to associated timeout policy `ovs_test_tp'
[86892.109539] device br1 entered promiscuous mode
[86892.235381] tun: Universal TUN/TAP device driver, 1.6
[86892.798181] gre: GRE over IPv4 demultiplexor driver
[86892.855322] ip_gre: GRE over IPv4 tunneling driver
[86892.861814] device gre_sys entered promiscuous mode
[86895.245432] bpfilter: Loaded bpfilter_umh pid 2680
[86895.245646] Started bpfilter
[86903.635371] BTRFS info (device sda3): balance: start -dusage=0
[86903.641304] BTRFS info (device sda3): balance: ended with status: 0
[86906.584005] BTRFS info (device sda3): balance: start -dusage=5
[86906.590673] BTRFS info (device sda3): balance: ended with status: 0
...

• Observed a "host up alert" today, ssh would time out, hit ^D via ipmi
• ssh claims it's not the expected host anymore and my key is denied... apparently I hit another corner case, which I worked around by explicitly specifying the key... 🙄
• systemctl list-units --failed w/ no obvious way to fix i.e. restarting the service won't work

On 2021-02-22, openqaworker3 failed to reboots (was: [Alerting] openqaworker3: host up alert). just like https://progress.opensuse.org/issues/78010#note-20 said.

openqa_nvme_format.service failed on openqaworker3 after it rebooted success. (was: [Alerting] Failed systemd services alert (except openqa.suse.de)),
Checking in: https://stats.openqa-monitor.qa.suse.de/d/KToPYLEWz/failed-systemd-services?orgId=1

The result in openqaworker3 is:

xiaojing@openqaworker3:~> sudo systemctl --failed
  UNIT                       LOAD   ACTIVE SUB    DESCRIPTION                  
● openqa_nvme_format.service loaded failed failed Setup NVMe before mounting it

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

openqaworker3 not ready today, blocking osd-deployment. Manually continued boot process with ^D

Mentioned MR: https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/474

Looks like it succeeded 10 reboots. I've just started another round of reboots.

openqaworker8 is fully online again. Unpaused the corresponding host-up alert in grafana. Next candidate for testing could be again openqaworker3 as for this ticket. On openqaworker3 did systemctl mask --now telegraf salt-minion openqa-worker-cacheservice && systemctl mask --now openqa-worker-auto-restart@{1..13}

checked stability in a loop with

for run in {01..30}; do for host in openqaworker3; do echo -n "run: $run, $host: ping .. " && timeout -k 5 600 sh -c "until ping -c30 $host >/dev/null; do :; done" && echo -n "ok, ssh .. " && timeout -k 5 600 sh -c "until nc -z -w 1 $host 22; do :; done" && echo -n "ok, uptime/reboot: " && ssh $host "uptime && sudo reboot" && sleep 120 || break; done || break; done

and all 30 reboots were successful.

In the journal we can check if the retry was triggered:

# journalctl --since=today -u openqa_nvme_format.service | grep 'Trying RAID0 creation again'
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: Trying RAID0 creation again after timeout (attempt 2 of 10)
Apr 08 11:43:03 openqaworker3 openqa-establish-nvme-setup[920]: Trying RAID0 creation again after timeout (attempt 2 of 10)
Apr 08 13:33:37 openqaworker3 openqa-establish-nvme-setup[904]: Trying RAID0 creation again after timeout (attempt 2 of 10)
Apr 08 13:39:54 openqaworker3 openqa-establish-nvme-setup[903]: Trying RAID0 creation again after timeout (attempt 2 of 10)
Apr 08 14:16:00 openqaworker3 openqa-establish-nvme-setup[901]: Trying RAID0 creation again after timeout (attempt 2 of 10)

with full logs from the first entry:

Apr 08 11:03:12 openqaworker3 systemd[1]: Starting Setup NVMe before mounting it...
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: Current mount points (printed for debugging purposes):
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: devtmpfs on /dev type devtmpfs (rw,nosuid,size=131889732k,nr_inodes=32972433,mode=755)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=sys>
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_c>
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacc>
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on / type btrfs (rw,relatime,space_cache,subvolid=268,subvol=/@/.snapshots/1/snaps>
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pgrp=1,timeout=0,minpro>
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: debugfs on /sys/kernel/debug type debugfs (rw,relatime)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: mqueue on /dev/mqueue type mqueue (rw,relatime)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /.snapshots type btrfs (rw,relatime,space_cache,subvolid=267,subvol=/@/.snapsho>
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,space_cache,subvolid=265,subvol=>
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /boot/grub2/i386-pc type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/@/>
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /tmp type btrfs (rw,relatime,space_cache,subvolid=260,subvol=/@/tmp)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /root type btrfs (rw,relatime,space_cache,subvolid=262,subvol=/@/root)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /usr/local type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/usr/local)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /opt type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@/opt)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /home type btrfs (rw,relatime,space_cache,subvolid=264,subvol=/@/home)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /srv type btrfs (rw,relatime,space_cache,subvolid=261,subvol=/@/srv)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: /dev/sda3 on /var type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@/var)
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: Present block devices (printed for debugging purposes):
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: sda         8:0    0 931.5G  0 disk
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: ├─sda1      8:1    0   9.8G  0 part
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: │ └─md126   9:126  0   9.8G  0 raid1
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: ├─sda2      8:2    0 995.6M  0 part
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: │ └─md125   9:125  0 995.5M  0 raid1
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: └─sda3      8:3    0 920.8G  0 part  /
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: sdb         8:16   0 931.5G  0 disk
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: ├─sdb1      8:17   0   9.8G  0 part
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: │ └─md126   9:126  0   9.8G  0 raid1
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: ├─sdb2      8:18   0 995.6M  0 part
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: │ └─md125   9:125  0 995.5M  0 raid1
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: └─sdb3      8:19   0 920.8G  0 part
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: nvme1n1   259:0    0 372.6G  0 disk
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: └─md127     9:127  0   745G  0 raid0
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: nvme0n1   259:1    0 372.6G  0 disk
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: └─md127     9:127  0   745G  0 raid0
Apr 08 11:03:12 openqaworker3 openqa-establish-nvme-setup[901]: Creating RAID0 "/dev/md/openqa" on: /dev/nvme0n1 /dev/nvme1n1
Apr 08 11:03:15 openqaworker3 openqa-establish-nvme-setup[901]: mdadm: cannot open /dev/nvme0n1: Device or resource busy
Apr 08 11:03:15 openqaworker3 openqa-establish-nvme-setup[901]: Waiting 10 seconds before trying again after failing due to busy device.
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: Trying RAID0 creation again after timeout (attempt 2 of 10)
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: Stopping current RAID "/dev/md/openqa"
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: mdadm: stopped /dev/md/openqa
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: mdadm: /dev/nvme0n1 appears to be part of a raid array:
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]:        level=raid0 devices=2 ctime=Thu Apr  8 10:57:02 2021
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: mdadm: partition table exists on /dev/nvme0n1 but will be lost or
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]:        meaningless after creating array
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: mdadm: /dev/nvme1n1 appears to be part of a raid array:
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]:        level=raid0 devices=2 ctime=Thu Apr  8 10:57:02 2021
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: mdadm: partition table exists on /dev/nvme1n1 but will be lost or
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]:        meaningless after creating array
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: mdadm: Defaulting to version 1.2 metadata
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: mdadm: array /dev/md/openqa started.
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: Status for RAID0 "/dev/md/openqa"
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: md127 : active raid0 nvme1n1[1] nvme0n1[0]
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: ARRAY /dev/md/openqa metadata=1.2 name=openqaworker3:openqa UUID=4984c770:c8a94fd6:488f2ccc:>
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: Creating ext2 filesystem on RAID0 "/dev/md/openqa"
Apr 08 11:03:23 openqaworker3 openqa-establish-nvme-setup[901]: mke2fs 1.43.8 (1-Jan-2018)
Apr 08 11:03:25 openqaworker3 openqa-establish-nvme-setup[901]: [182B blob data]
Apr 08 11:03:25 openqaworker3 openqa-establish-nvme-setup[901]: Creating filesystem with 195289600 4k blocks and 48824320 inodes

so this works but I wonder if we can find out what blocks the device. This is something I could check later again, maybe on the same machine. But as I enabled the services again let's give them a chance to finish :)