Bug 2401745

Summary:	/usr/lib/firmware/vpu_p.bin.xz: broken symbolic link to mediatek/mt8173/vpu_p.bin.xz
Product:	[Fedora] Fedora	Reporter:	John Dodson <jwadodson>
Component:	linux-firmware	Assignee:	David Woodhouse <dwmw2>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	dwmw2, jforbes, jwboyer, kernel-maint, pbrobinson
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	linux-firmware-20260519-1.fc44	Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-05-21 23:20:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description John Dodson 2025-10-06 03:48:57 UTC

I am sad to report that,

/usr/lib/firmware/vpu_p.bin.xz: broken symbolic link to mediatek/mt8173/vpu_p.bin.xz

it is claimed to be owned by,

linux-firmware-20250917-2.fc42.noarch

Obviously I do not have the package that I expect contains the target installed.
(mediatek-firmware.noarch 20250917-2.fc42?)



Reproducible: Always

Steps to Reproduce:
1. Wait for linux-firmware-20250917-2.fc42.noarch to be installed.
2. file /usr/lib/firmware/vpu_d.bin.xz
3.
Actual Results:
file /usr/lib/firmware/vpu_d.bin.xz
/usr/lib/firmware/vpu_p.bin.xz: broken symbolic link to mediatek/mt8173/vpu_p.bin.xz


Expected Results:
No broken symlink, where the package that controls the target maintains
the symlink.

Comment 1 John Dodson 2025-12-02 12:04:56 UTC

upped to fc43

Comment 2 John Dodson 2026-04-12 05:46:01 UTC

Can we perhaps add aome kind of procedural advice for all such packaging/symlink creation?

ie. that the package that controls the target ALWAYS maintains the symlink?

Comment 3 John Dodson 2026-04-24 03:07:07 UTC

Still broken in linux-firmware-20260410-1.fc43.noarch

Comment 4 John Dodson 2026-05-13 12:03:12 UTC

Still broken in FC44

Comment 5 Peter Robinson 2026-05-13 12:14:13 UTC

Correct, which is why this bug is still open, no need to comment. It will be fixed in the May release.

Comment 6 Fedora Update System 2026-05-19 20:08:00 UTC

FEDORA-2026-2b07c67f06 (linux-firmware-20260519-1.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-2b07c67f06

Comment 7 Fedora Update System 2026-05-19 20:08:10 UTC

FEDORA-2026-16c8693020 (linux-firmware-20260519-1.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-16c8693020

Comment 8 Fedora Update System 2026-05-20 01:23:01 UTC

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

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

Comment 9 Fedora Update System 2026-05-20 01:39:59 UTC

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

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

Comment 10 Fedora Update System 2026-05-21 23:20:43 UTC

FEDORA-2026-2b07c67f06 (linux-firmware-20260519-1.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.