|
Bugzilla – Full Text Bug Listing |
| Summary: | sof-firmware not present after clean installing tumbleweed (no sound) | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | David Liu <davidliu8023> |
| Component: | Other | Assignee: | Takashi Iwai <tiwai> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | davidliu8023, fvogt, tamara.schmitz |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE Tumbleweed | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
David Liu
2021-12-06 01:25:19 UTC
This could be a package dependency problem in the kernel packages, a patterns problem or maybe a deprecated firmware package; but it's for sure not a problem of the installer. Reassigning. The package is provided via Supplements in the spec file so that it'll be installed via zypper install-recommends automatically when the corresponding chip is present. Please check PCI IDs of your sound devices (of the onboard audio) check whether those match with the output of rpm -q sof-firmware --supplements Alternatively, you can check by uninstalling sof-firmware package once, then run like zypper install-recommends If sof-firmware is proposed, it should have been installed by the installer. If it doesn't show up, the PCI ID is likely missing in the Supplements list. In the latter case, please alsa-info.sh output. Run the script with --no-upload option and attach to Bugzilla. I recently did a MicroOS Desktop Gnome installation on my personal laptop. Since MicroOS to my knowledge does not install recommends packages, the sof-firmware package was not installed after setup. I had to install the package manually. My device is listed as a sof-firmware supplement in the RPM package. My laptop's audio device ID is 8086:9DC8. bug 1207211 is about the same issue, let's unify them. (In reply to Tamara Schmitz from comment #3) > I recently did a MicroOS Desktop Gnome installation on my personal laptop. > > Since MicroOS to my knowledge does not install recommends packages, the > sof-firmware package was not installed after setup. I had to install the > package manually. Hardware supplements are nevertheless honoured. > My device is listed as a sof-firmware supplement in the RPM package. > My laptop's audio device ID is 8086:9DC8. *** This bug has been marked as a duplicate of bug 1207211 *** (In reply to Takashi Iwai from comment #2) > Alternatively, you can check by uninstalling sof-firmware package once, then > run like > > zypper install-recommends Please: zypper install-recommends --no-recommends Looks strange, but INR re-evaluates _all_ recommends, i.e. also ordinary package recommends. --no-recommends will restrict INR to ter namespace recommends (hardware,language,filesystem). (In reply to Takashi Iwai from comment #2) > Please check PCI IDs of your sound devices (of the onboard audio) check > whether those match with the output of > rpm -q sof-firmware --supplements Providing a solver tetscase is IMO an easy way to spot the reason why: zypper up --debug-solver (the actual command in/up/dup does not matter) (packed and attached to the bugreport) - In the testcase directory is a zypp-modalias.yaml showig all modaliases zypp spotted in the system. - Packages like sof-firmware are listed in the *.repo.gz files, so you can check their supplements - In case of doubt we can even replay the result of an install/inr command to check why the package was not installed. If modaliases matches and the package is nevertheless not installed, it's usually due to some dependency conflict the package is involved in. (In reply to Michael Andres from comment #5) > (In reply to Takashi Iwai from comment #2) > > Alternatively, you can check by uninstalling sof-firmware package once, then > > run like > > > > zypper install-recommends > > Please: > zypper install-recommends --no-recommends > > Looks strange, but INR re-evaluates _all_ recommends, i.e. also ordinary > package recommends. --no-recommends will restrict INR to ter namespace > recommends (hardware,language,filesystem). How about introducing subcommand with a bit more intuitive name for doing the above? |