Re: Fedora 24 Beta 1.2 compose check report

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux