[qam] [ppc64le] ltp_fs_readonly and ltp_fs_ext4
swapped system and test device causes breakage of this two ltp tests on ppc64le SLE12SP3
Welcome to SUSE Linux Enterprise Server 12 SP3 (ppc64le) - Kernel 4.4.103-6.38-default (hvc1). suse-test login: root Password: Last login: Fri Jan 26 06:33:49 on hvc1 [1msuse-test:~ #[m(B PS1="# " # export TERM=dumb; stty cols 2048 ; echo NtGTe-$?- NtGTe-0- # echo Logged into $(tty) ; echo dohaM-$?- Logged into /dev/hvc1 dohaM-0- # dmesg --console-level 7 ; echo ccNyO-$?- ccNyO-0- # export LTPROOT=/opt/ltp; export LTP_COLORIZE_OUTPUT=n TMPDIR=/tmp PATH=$LTPROOT/testcases/bin:$PATH ; echo v9535-$?- v9535-0- # export PASSWD='nots3cr3t' ; echo NJML2-$?- NJML2-0- # lsblk -la; export LTP_BIG_DEV=/dev/vdb ; echo UNCHa-$?- NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 3.4G 0 rom vda 254:0 0 6G 0 disk vdb 254:16 0 20G 0 disk vdb1 254:17 0 7M 0 part vdb2 254:18 0 2G 0 part [SWAP] vdb3 254:19 0 18G 0 part / UNCHa-0- # uname -v| grep '/kGraft-' ; echo WuZtU-$?- #1 SMP Mon Dec 25 20:44:33 UTC 2017 (e4b9067/kGraft-90f211a) WuZtU-0- # env ; echo Z285j-$?-
#1 Updated by rpalethorpe over 4 years ago
AFAICT OpenQA passes the devices on the QEMU command line in order, so either QEMU or the kernel (udev?) are doing something which creates a strange order. I don't think this is a product bug however we are just relying on behaviour which is not guaranteed. I think there are a few potential fixes:
1) Create a util function which uses some heuristics (e.g. unmounted, writable and larger than 1 GB) to select a suitable drive. This might be a problem on bare metal, but is quite safe in VMs.
2) Set and/or use the drive serial number to identify the drive. On bare metal this would require a worker specific variable.
3) Poke around in QEMU and the Kernel to find some other solution.