On Sun, 2018-01-14 at 16:54 +0000, Fedora compose checker wrote: > No missing expected images. > > Failed openQA tests: 16/129 (x86_64), 6/24 (i386), 1/2 (arm) > > New failures (same test did not fail in Rawhide-20180111.n.0): > > ID: 185786 Test: x86_64 universal install_software_raid > URL: https://openqa.fedoraproject.org/tests/185786 > ID: 185809 Test: x86_64 universal install_software_raid@uefi > URL: https://openqa.fedoraproject.org/tests/185809 This is actually a funny knock-on effect of what looks like quite a significant change in anaconda behaviour. It seems to have changed how it names some things by default: in this case, volume groups, but the change also seems to affect other things, like the default system hostname. All of these seem to be derived from some property of the system itself, now. Prior to this compose, the volume group name anaconda decided to use in openQA tests was 'fedora', and the hostname it decided to use for the installed system (unless the test explicitly set one) was 'localhost'. As of this compose, though, it seems to generate a value based on some property of the system, and use that value in the names. The volume group in this test was called 'fedora_ibm-p8-kvm-03-guest-01', and the hostname of an installed system winds up being 'ibm-p8-kvm-03-guest-01' (or similar). The strange thing is, anaconda does not actually seem to have changed between 20180111.n.0 and this compose, nor has any obvious other culprit for a change like this. Lots of things did change, but none of them quite jumps out at me as the cause of this. It'd be good to know what did change, and if this is quite intentional. Anyhow, this winds up causing an openQA needle to fail to match simply because the longer volume group names change the layout of the custom partitioning screen. I've made the needle match area narrower to account for this. > ID: 185823 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit > URL: https://openqa.fedoraproject.org/tests/185823 > ID: 185825 Test: x86_64 universal install_european_language > URL: https://openqa.fedoraproject.org/tests/185825 These two I *think* may just be quasi-random test failure, I've restarted them. > ID: 185852 Test: i386 universal install_software_raid > URL: https://openqa.fedoraproject.org/tests/185852 This is the same as the long explanation above. > ID: 185859 Test: x86_64 universal upgrade_realmd_client > URL: https://openqa.fedoraproject.org/tests/185859 This one actually usually fails, but it usually shows up as 'parallel_failed', which the script doesn't count as a failure state, because the related server upgrade test fails. This time it actually failed earlier, in its own right, in what looks like the same way as the desktop_encrypted upgrade test above. Looking into it in more detail, it looks like there's kind of a timing issue which can cause a false failure for upgrade tests if the bootloader screen goes by very fast and the test doesn't manage to spot it; I'll try and fix this. > New soft failures (same test did not soft fail in Rawhide-20180111.n.0): > > ID: 185783 Test: x86_64 universal install_simple_encrypted > URL: https://openqa.fedoraproject.org/tests/185783 > ID: 185789 Test: x86_64 universal install_ext3 > URL: https://openqa.fedoraproject.org/tests/185789 > ID: 185790 Test: x86_64 universal install_xfs > URL: https://openqa.fedoraproject.org/tests/185790 > ID: 185795 Test: x86_64 universal install_blivet_btrfs > URL: https://openqa.fedoraproject.org/tests/185795 > ID: 185798 Test: x86_64 universal install_blivet_software_raid > URL: https://openqa.fedoraproject.org/tests/185798 These all just hit the same journald SELinux denials which cause almost all the soft fails in current testing: https://bugzilla.redhat.com/show_bug.cgi?id=1527684 It looks like occasionally these don't show up, for some reason, so when that happens for one test for one compose, then on the next compose they *do* show up for the same test, it'll show up in this category ('new soft failures'). But the bug isn't really new. > Installed system changes in test x86_64 Server-dvd-iso install_default_upload: > Filesystem for mount / changed from /dev/mapper/fedora_ibm--p8--kvm--03--guest--01-root to /dev/mapper/fedora-root <snip> looks like I might have this check's output wired up the wrong way around...see above. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
