Bug 2042877

still see this crash on newly installed system with Fedora-Workstation-Live-x86_64-Rawhide-20220127.n.0.iso.

Proposed as a Blocker for 36-final by Fedora user lnie using the blocker tracking app because:

 This is a violation of the criteria:
There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop.

Discussed during the 2022-02-07 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as other testers have not immediately been able to reproduce this. We will ask lnie for more details on the scenario and try again to reproduce.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-07/f36-blocker-review.2022-02-07-17.00.txt

This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

just installed the Fedora-Workstation-Live-x86_64-36-20220209.n.0.iso on a VM (kvm/qemu/virt-manager at UEFI)and its running well, no crashes at startup here.

I'm able to reproduce this bug all the time(just do a default installation with Fedora-Workstation-Live-x86_64-Rawhide-20220205.n.1.iso and boot the newly installed system,you will see the crash and#2020759 ),in case I miss anything,I'm gonna to upload the screencast.
But,due to the abrt bug#2052872,I'm not able to report the crash with gnome-abrt,may be that's one reason why we don't see other reports.

Created attachment 1860306 [details]
screencast

I also see this crash after I switch to a newly created user,actually,that's how I get the coredump with the help of abrt-2.14.6-9.fc36

(In reply to lnie from comment #6)
> I'm able to reproduce this bug all the time(just do a default installation
> with Fedora-Workstation-Live-x86_64-Rawhide-20220205.n.1.iso and boot the
> newly installed system,you will see the crash and#2020759 ),in case I miss
> anything,I'm gonna to upload the screencast.
> But,due to the abrt bug#2052872,I'm not able to report the crash with
> gnome-abrt,may be that's one reason why we don't see other reports.

I see your point, but it seems this is not replicable anymore at the branched F36 build. Must see if its at Fedora-Rawhide-20220127.n.0 too, if so, it is a Rawhide only bug, and not a F36.

I tested the Fedora-Rawhide-20220127.n.0 and it behaves just like you described. So I turned back again to the Fedora-Workstation-Live-x86_64-36-20220209.n.0.iso VM wo was succesfully installed to search for a coredump manually (since I do not have the ABRT warning the firs time I installed the system, and I FOUND A COREDUMP FROM THE SAME COMPONENT. I'll attach it to this ticket. Strangely, I installed and runned the first time without any crash warnings, the coredump still there, but the system is running fine.

Created attachment 1860506 [details]
Coredumpctl info at Fedora-Workstation-Live-x86_64-36-20220209.n.0.iso

Just tested the Fedora-Workstation-Live-x86_64-36-20220210.n.0.iso build and it doesnt show any warnings at start, it worked just as expected, but if I go to ABRT I can see at system tab that spyce-vdagent have crashed.

I checked with Fedora-Workstation-Live-x86_64-36-20220210.n.0,and yes,it dose not show any warnings at start any more.

spice-vdagent agent crashes most of the time(I run 12 rounds,there are no crash in 2 rounds),some times in gnome-initial-setup session,some times in the default user(lnie) session,and if you switch to the new added user,spice-vdagent will crash all the time and the warnings will show up.

Created attachment 1860565 [details]
screencast

I can reproduce the crash.

It looks like a race between vdagent_init_async_cb() and vdagent_display_send_daemon_guest_res() which relies on x11->vdagent_display being initialized to dispatch randr events. This seems enough to solve the crash:

Δ src/vdagent/vdagent.c
-    g_timeout_add(0, vdagent_init_async_cb, agent);
+    vdagent_init_async_cb(agent);

I also think we should remove: /etc/xdg/autostart/spice-vdagent.desktop, as it duplicates /usr/lib/systemd/user/spice-vdagent.service on systemd. Or pick one of the two at least on Fedora.

@

Posted a fix https://gitlab.freedesktop.org/spice/linux/vd_agent/-/merge_requests/42.

It was easy to reproduce:
- used a live distro DVD and a VM;
- installed openssh-server and connected to it;
- logout from graphical;
- kill spice-vdagent;
- login again with live user;
- wait some seconds for the crash;
- check coredumpctl.

(In reply to Frediano Ziglio from comment #22)
> It was easy to reproduce:

Lucky you! I tried a few times with 20220213 iso [0] without luck. I had a rawhide qcow2 image around and I used that to hit the bug and review [1]

[0] https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/
[1] https://gitlab.freedesktop.org/spice/linux/vd_agent/-/merge_requests/42

I think we are close to a fix, I tested the fix below and couldn't hit any regression so far

[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=82785651

--

(In reply to Marc-Andre Lureau from comment #19)
> I also think we should remove: /etc/xdg/autostart/spice-vdagent.desktop, as
> it duplicates /usr/lib/systemd/user/spice-vdagent.service on systemd. Or
> pick one of the two at least on Fedora.

I like that! Moving spice-vdagent to use user service by default would be better imho.
The 'only' problem is going through the process of having it added as enable by default exception by FESCo [3]
I'll try to submit MR improving the services and filing a bug for exception later this week.

[3] https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/

> (In reply to Marc-Andre Lureau from comment #19)
> > I also think we should remove: /etc/xdg/autostart/spice-vdagent.desktop, as
> > it duplicates /usr/lib/systemd/user/spice-vdagent.service on systemd. Or
> > pick one of the two at least on Fedora.
> 
> I like that! Moving spice-vdagent to use user service by default would be
> better imho.
> The 'only' problem is going through the process of having it added as enable
> by default exception by FESCo [3]
> I'll try to submit MR improving the services and filing a bug for exception
> later this week.
> 
> [3]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/

Actually, I wonder, the .desktop should be more versatile and adapted than the user service (which isn't really tight to a desktop lifecycle afaik)

FEDORA-2022-f666b4aeb8 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f666b4aeb8

https://bodhi.fedoraproject.org/updates/FEDORA-2022-788408f6db should have fixed this for F36, can folks confirm? Thanks.

Discussed during the 2022-02-14 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop". 

It's not entirely clear whether this crash always triggers a notification but it seems to happen often enough to accept this.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-14/f36-blocker-review.2022-02-14-17.01.txt

FEDORA-2022-f666b4aeb8 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-f666b4aeb8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f666b4aeb8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Checked with spice-vdagent-0.22.1-1.fc36,the crash seems gone.

Thanks, in that case we can close as the F36 update is stable already.

Confirmed that Fedora 36 Branched 20220215.n.0 ISO have spice-vdagent-0.22.1-1.fc36 and no crash at all. Bug really gone.

FEDORA-2022-f666b4aeb8 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.