On Thu, 2016-04-28 at 20:49 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Apr 28, 2016 at 12:27:40PM -0700, Adam Williamson wrote: > > On Thu, 2016-04-28 at 18:44 +0000, Fedora compose checker wrote: > > > Missing expected images: > > > > > > Cloud_base raw-xz i386 > > > Atomic raw-xz x86_64 > > > > > > Failed openQA tests: 5/67 (x86_64), 3/17 (i386) > > > > > > ID: 14899 Test: x86_64 Workstation-live-iso base_selinux > > > URL: https://openqa.fedoraproject.org/tests/14899 > > > > Probably not worth worrying about. > > Actually that's a major screw up, and it affects all systems where > hypervvssd, hypervfcopyd, or hypervkvpd are installed. The reason that > it's only always visible that systemd cuts of the output to the > console when starting getty. So depending on the ordering of things, this > error will not be visible on the console, but it's still there in the logs: > > $ systemctl status hypervvssd > ● hypervvssd.service - Hyper-V VSS daemon > Loaded: loaded (/usr/lib/systemd/system/hypervvssd.service; enabled; vendor preset: enabled) > Active: inactive (dead) > > Apr 28 16:09:35 rawhide systemd[1]: Dependency failed for Hyper-V VSS daemon. > Apr 28 16:09:35 rawhide systemd[1]: hypervvssd.service: Job hypervvssd.service/start failed... > > $ uname -p > x86_64 > hypervvssd.service and friends are enabled by default in presets > [https://bugzilla.redhat.com/show_bug.cgi?id=1279322], and pulled in by > default in comps (in @guest-desktop-agents, which is in all desktops). > > > This is a weird one: systemd decided we were Hyper-V for some reason? > Not really. hypervvssd.service has > ConditionVirtualization=microsoft > BindsTo=sys-devices-virtual-misc-vmbus\x21hv_vss.device > After=sys-devices-virtual-misc-vmbus\x21hv_vss.device > but Condition* is checked just before the unit is started, so a timeout > occurs and a notice is logged. So everything happens according to the plan, > but it's the plan that is wrong, so to speak. > > I filed https://bugzilla.redhat.com/show_bug.cgi?id=1331577 to > start a discussion about the solution. Ah, thanks. The funny thing is that there are two other base_foo tests that run in exactly the same way, and neither of them had the problem: https://openqa.fedoraproject.org/tests/14901 https://openqa.fedoraproject.org/tests/14900 all three of those tests start with the same image of an installed system, boot it up, do a few things and finish. The base image is not modified. So the issue clearly isn't 100% reproducible... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
