Bug 1184403

Did you install kernel-firmware-iwlwifi package?

I didn't install anything yet as I don't have any internet connectivity right after installation.

Do you mean that the installer itself has no WiFi support?  Or do you mean about the installed system?

In the former case, it's likely a missing MODULE_FIRMWARE() entry that points to this firmware file.  For the latter case, it's the selection of a package; kernel-firmware-iwlwifi should be picked up by zypper install-recommends with the package supplement information.

I think it is both. In any case, neither during installation I was prompted to connect to the internet nor was there any possibility to connect after installation of MicroOS.

Please try installing kernel-firmware-iwlwifi (if not installed yet) and check whether the wireless works as expected after that.  Once after confirming it working, give the output from hwinfo command (attach to Bugzilla).

(In reply to Takashi Iwai from comment #3)
> Do you mean that the installer itself has no WiFi support?  Or do you mean
> about the installed system?
> 
Yeah, both (we have reports of other users too).

> In the former case, it's likely a missing MODULE_FIRMWARE() entry that
> points to this firmware file.  
>
Forgive my ignorance, we're missing a MODULE_FIRMWARE, where?

> For the latter case, it's the selection of a
> package; kernel-firmware-iwlwifi should be picked up by zypper
> install-recommends with the package supplement information.
>
Oh, that might be due to the fact that in MicroOS we have no-recommends, then?

I couldn't get the kernel-firmware-iwlwifi installed.

(In reply to Dario Faggioli from comment #6)
> (In reply to Takashi Iwai from comment #3)
> > Do you mean that the installer itself has no WiFi support?  Or do you mean
> > about the installed system?
> > 
> Yeah, both (we have reports of other users too).
> 
> > In the former case, it's likely a missing MODULE_FIRMWARE() entry that
> > points to this firmware file.  
> >
> Forgive my ignorance, we're missing a MODULE_FIRMWARE, where?

See an example in bug 1183860.  The firmware files included in the installation image are determined from the information of modinfo for each included module.  Each driver module is supposed to declare the relevant firmware names via MODULE_FIRMWARE() macro in the code.  In the case of the bugzilla entry above (SLE15-SP3), iwlwifi declared the non-existing firmware version via MODULE_FIRMWARE(), hence the installation image missed a few of them.

However, looking at the TW iwlwifi 5.11.x module, all MODULE_FIRMWARE() look correct; and above all, iwlwifi-6000g2a-* has been always correct in the older kernels, so my early guess was incorrect.  It must be something else, if the installer really can't provide the WiFi access.

> > For the latter case, it's the selection of a
> > package; kernel-firmware-iwlwifi should be picked up by zypper
> > install-recommends with the package supplement information.
> >
> Oh, that might be due to the fact that in MicroOS we have no-recommends,
> then?

Yes, likely.  In the normal installation, kernel-firmware-all package is usually installed via recommends.  Also, some other firmware like CPU microcode is installed in a similar way, IIRC.

So, without recommends installation, many such bits would be missing, and some can be serious problems; e.g. AMD GPU require the firmware files mandatory, and it'll lead to a blank screen without it.  Or, the lack of CPU microcode results in the security hole.

In anyway, if the WiFi works after installing the kernel-firmware-* package, that's the case.  And it's a different problem from the lack of WiFi in the installer; if so, we need to open a separate bug report for it, too.

(In reply to Martin Rohde from comment #7)
> I couldn't get the kernel-firmware-iwlwifi installed.

Did you install via transaction-update command?  e.g.
  % transactional-update pkg install kernel-firmware-iwlwifi-*.rpm

(In reply to Takashi Iwai from comment #9)
> (In reply to Martin Rohde from comment #7)
> > I couldn't get the kernel-firmware-iwlwifi installed.
> 
> Did you install via transaction-update command?  e.g.
>   % transactional-update pkg install kernel-firmware-iwlwifi-*.rpm

Yes, I did. Dario helped me walk through it. I will try again soon to narrow down the issue. Most likely just myself not getting it installed properly.

(In reply to Takashi Iwai from comment #9)
> (In reply to Martin Rohde from comment #7)
> > I couldn't get the kernel-firmware-iwlwifi installed.
> 
> Did you install via transaction-update command?  e.g.
>   % transactional-update pkg install kernel-firmware-iwlwifi-*.rpm
>
There's no `transactional-update` in the image that Martin is used. This is expected as that is only a wrapper around `tukit`, and the path for MicroOS desktop is to move away from both for package management.

Anyway, the following command should work (for now):

$ sudo tukit execute zypper in /root/kernel-firmware-iwlwifi-*.rpm

As well as entering a shell with `sudo tukit execute bash` and installing the package with zypper, from inside it.

In fact, it worked in my system but it apparently didn't in Martin's... And I do not really know why.

In any case, I think we want the installer of MicroOS desktop to include wireless firmware (as it used to be just a couple of months ago, as confirmed by other reports), because we want people having only WiFi on their laptop to be able to install and use it. So that's IMO the issue that we should try to fix

(In reply to Takashi Iwai from comment #8)
> (In reply to Dario Faggioli from comment #6)
> > Oh, that might be due to the fact that in MicroOS we have no-recommends,
> > then?
> 
> Yes, likely.  In the normal installation, kernel-firmware-all package is
> usually installed via recommends.  Also, some other firmware like CPU
> microcode is installed in a similar way, IIRC.
> 
Ok, great... Thanks for the info!

> So, without recommends installation, many such bits would be missing, and
> some can be serious problems; e.g. AMD GPU require the firmware files
> mandatory, and it'll lead to a blank screen without it.  Or, the lack of CPU
> microcode results in the security hole.
> 
Totally agree. What I still don't know (and am trying to figure out) is where it is decided what will end up in the install media.

Like, using this issue as an example, why isn't the firmware package there? If it's due to the no-recommends thing... Where is it that we set "no-recommends" in such a way that is has this effect?

Is it, perhaps, here: https://github.com/yast/skelcd-control-MicroOS/blob/master/control/control.MicroOS.xml#L100 ?

(In reply to Dario Faggioli from comment #12)
> Totally agree. What I still don't know (and am trying to figure out) is
> where it is decided what will end up in the install media.
> 
> Like, using this issue as an example, why isn't the firmware package there?
> If it's due to the no-recommends thing... Where is it that we set
> "no-recommends" in such a way that is has this effect?
> 
> Is it, perhaps, here:
> https://github.com/yast/skelcd-control-MicroOS/blob/master/control/control.
> MicroOS.xml#L100 ?

Hm, patterns-microos-onlyDVD seems containing kernel-firmware.  It looks specific to MicroOS, so I don't know what's the purpose, though...

In the normal installation, kernel-firmware is chosen either via the recommends from kernel-default (or equivalent), or from patterns-media, as far as I look though the packages  So, install-recommends is mandatory in that case.

(In reply to Takashi Iwai from comment #13)
> (In reply to Dario Faggioli from comment #12)
> > Totally agree. What I still don't know (and am trying to figure out) is
> > where it is decided what will end up in the install media.
> > 
> > Like, using this issue as an example, why isn't the firmware package there?
> > If it's due to the no-recommends thing... Where is it that we set
> > "no-recommends" in such a way that is has this effect?
> > 
> > Is it, perhaps, here:
> > https://github.com/yast/skelcd-control-MicroOS/blob/master/control/control.
> > MicroOS.xml#L100 ?
> 
> Hm, patterns-microos-onlyDVD seems containing kernel-firmware.  It looks
> specific to MicroOS, so I don't know what's the purpose, though...
> 
Yeah, it really is.

> In the normal installation, kernel-firmware is chosen either via the
> recommends from kernel-default (or equivalent), or from patterns-media, as
> far as I look though the packages  So, install-recommends is mandatory in
> that case.
>
We've been discussing (on MicroOS Desktop chat channels) how to deal with this. Enabling soft dependencies is apparently a no go, nor we want firmware-all in there.

So I'll probably add the most obvious network firmware packages to the onlyDVD pattern (which definitely includes iwlwifi) and see if this fixes this issue.

The soft-dependency installation only for the hardware (but no Recommends) can be achieved via
  zypper inr --no-recommends

And I'm sure that you'd need more and more different firmware files as long as you run on various machines.  e.g. AMD GPU mandates the firmware (otherwise you'll get only blank screen) and CPU microcode is a must for the security mitigations.  Lost of BT devices need the firmware files, etc, etc.

(In reply to Takashi Iwai from comment #15)
> And I'm sure that you'd need more and more different firmware files as long
> as you run on various machines.  
>
I know and I agree, but approaches like enabling recommends, or including firmware-all in the media have been rejected, so we'll deal with this on a case by case basis.

> e.g. AMD GPU mandates the firmware
> (otherwise you'll get only blank screen) 
>
Ok, good to know... is that this one kernel-firmware-amdgpu ?

> and CPU microcode is a must for the
> security mitigations.  Lost of BT devices need the firmware files, etc, etc.
>
Yes, and luckily those seem to be there already (at least in DVD):

%package onlyDVD
Summary:        Packages only for the DVD of openSUSE MicroOS
[...]
%ifarch %ix86 x86_64
Requires:       ucode-amd
Requires:       ucode-intel
%endif

Hm, onlyDVD has already Requires: kernel-firmware.  So the firmware packages are already on the media, at least.
(Though, I'm not sure whether kernel-firmware-all or kernel-firmware is put in the end; those both conflict with each other, and the former is preferred for the kernel >= 5.3.  kernel-firmware-all is a meta package to include all other kernel-firmware-* subpackage, while kernel-firmware is an all-in-one package containing the uncompressed firmware files, just for compatibility with older distros.)

I still don't get how you'd make those firmware packages installed without the help of hardware supplements.  Certainly we don't want to install them unconditionally, right?

(In reply to Takashi Iwai from comment #17)
> Hm, onlyDVD has already Requires: kernel-firmware.  So the firmware packages
> are already on the media, at least.
>
Yes, I was puzzled about this as well.

And in fact, if I try to configure my wireless network card during installation, it works.

However, when booting into a freshly installed system, the `kernel-firmware` package *is not* installed, and hence no network. :-(

Now, can this be due to the fact that, if we check here: https://build.opensuse.org/package/view_file/Kernel:HEAD/kernel-firmware/kernel-firmware.spec?expand=1

we see that the kernel-fimrware (sub)package does not have any "Supplements:" ?

> I still don't get how you'd make those firmware packages installed without
> the help of hardware supplements.  Certainly we don't want to install them
> unconditionally, right?
>
What do you mean with "without the need of hardware supplements" ?

My current line of thinking is that, e.g., on this laptop, we would need the firmware that are in the kernel-firmware-iwlwifi package. On the media, there's no package that provides the proper "Supplements:". In fact, there is kernel-firmware there, but it does not come with any "Supplements:" at all, so it's not installed.

The package that has the proper "Supplements" is indeed kernel-firmware-iwlwifi, but it's not present on the media, so it's not installed. But if I put it there, it will be installed, thanks to the fact that it has the proper "Supplements:" for this hardware.

Or do I have a bug in my reasoning?

(In reply to Dario Faggioli from comment #18)
> My current line of thinking is that, e.g., on this laptop, we would need the
> firmware that are in the kernel-firmware-iwlwifi package. On the media,
> there's no package that provides the proper "Supplements:". In fact, there
> is kernel-firmware there, but it does not come with any "Supplements:" at
> all, so it's not installed.
> 
> The package that has the proper "Supplements" is indeed
> kernel-firmware-iwlwifi, but it's not present on the media, so it's not
> installed. But if I put it there, it will be installed, thanks to the fact
> that it has the proper "Supplements:" for this hardware.
> 
> Or do I have a bug in my reasoning?
>
As an example that, IMO, this should work, the media seems to have both ucode-intel and ucode-amd, right? Well, I just checked and on my Intel laptop, ucode-intel and *only* ucode-intel has been installed.

That seems to me like it could confirm the theory that "Supplements:" work fine (as ucode-intel was installed while ucode-amd wasn't), but only if the package with the proper "Supplements:" is available (which in this case means it should be present in the DVD).

Does this make sense?

If that's the case, the fix would be to simply replace
  Requires: kernel-firmware
with
  Requires: kernel-firmware-all
in the patterns.

Then all kernel-firmware-* subpackages will be on the media.

(In reply to Takashi Iwai from comment #20)
> If that's the case, the fix would be to simply replace
>   Requires: kernel-firmware
> with
>   Requires: kernel-firmware-all
> in the patterns.
> 
> Then all kernel-firmware-* subpackages will be on the media.
>
Yes, honestly, I think that too (and see also 1184767).

However, as Richard advised against that (Cc-ing him), I've for now put together SR https://build.opensuse.org/request/show/885499 .

This pulls in the media only a few specific firmware packages. If accepted, we can further test this theory and at that point, I will try again to push for kernel-firmware-all.

Well, this doesn't sound right.  First off, if you want to have the split kernel-firmware-* packages on the media, keeping Requires:kernel-firmware makes no sense.  kernel-firmware is an all-in-one package containing the *all* raw uncompressed firmware files.  You have to drop it from patterns at first.

After that, you can put individual kernel-firmware-* packages -- but only if you really want to manage that.  For example, with this SR, you still don't put the kernel-firmware-amdgpu; hence the installation on AMD graphics chip would lead to a blank screen.  Similarly, the lack of kernel-firmware-bluetooth leads to the lack of BT, the lack of kernel-firmware-ath11k would miss the recent Atheros chip, etc, etc.

And, the fact that you have had already kernel-firmware on the media indicate that the media size won't change so much even if you replace it with kernel-firmware-all.  kernel-firmware-all is just a meta package of kernel-firmware-* subpackages, and again, kernel-firmware already contains all of those files in it without split.  (There is slight difference due to the compression over compressed files, and of course some overhead due to metadata amount, but that's all.)

So, my recommendation is to replace Requires:kernel-firmware with Requires:kernel-firmware-all.  Or if we want to reduce some firmware files, maybe it's better to create a new pattern-firmware-desktop or such and specify the needed ones there.  It'll be useful for the normal installation, not only on MicroOS Desktop, too.

(In reply to Takashi Iwai from comment #22)
> Well, this doesn't sound right.  First off, if you want to have the split
> kernel-firmware-* packages on the media, keeping Requires:kernel-firmware
> makes no sense.  kernel-firmware is an all-in-one package containing the
> *all* raw uncompressed firmware files.  You have to drop it from patterns at
> first.
> 
I completely agree. kernel-firmware was put there as a consequence of 1174521 , which is marked as fixed, so maybe it worked back then? If yes, how so? Maybe the kernel-firmware package had some "Supplements:", and they've been dropped now?

The problem here is that I still don't fully understand how this works. I mean:
- it was working at some point (i.e, firmware were being installed)
- it stopped working, and that's why 1174521 exists, I guess
- did 1174521 actually fixed it? If yes, I don't understand how
- currently, even with the fix from 1174521 in place, it's not working

In particular, Supplements is a weak dependency AFAIUI. And MicroOS should not honor weak dependencies, so why it seems like it does, e.g., for ucode-intel? Is it really (i.e., MicroOs honoring Supplements) what is happening there? And is it intentional or is it basically a bug (although in this case, it has a good side effect)?

I personally don't yet know for sure the answers to the above question. Once I'll know them, I'm ready to push for firmware-all, which also seems the proper solution to me, basing on what I've understood so far.

But I'l like for it to be the real and proper solution. If anyone is able to help me understand better what's going on, I'm all ears. So far, everything that I've been able to find and read has not really shed much light on the issue...

> So, my recommendation is to replace Requires:kernel-firmware with
> Requires:kernel-firmware-all.  Or if we want to reduce some firmware files,
> maybe it's better to create a new pattern-firmware-desktop or such and
> specify the needed ones there.  It'll be useful for the normal installation,
> not only on MicroOS Desktop, too.
>
Creating a firmware-desktop pattern is IMO an interesting idea. At the same time, it's only necessary if firmware-all does not work, and it's only going to work if we confirm that MicroOS still honor Supplements (and that the fact that it does that is a feature and not a bug). Or we risk being back in this same situation again in the future.

Well, the question is which real package was put in DVD.  If it's kernel-firmware, it was just a wrong fix.  OTOH, if it's been resolved to kernel-firmware-all in the end (as kernel-firmware-all itself provides kernel-firmware), it's fine, but I guess this wasn't the case.

I also have no idea whether the installer really deals with the hardware supplements or not.  You'd better ask YaST people about that.  But, I believe that the installation via hardware supplements is a must for the deployment on bare metal.  You cannot pre-select the all hardware-dependent packages after all.

This is fixed for me. If there is nothing further to adjust, feel free to close this bug. Thanks a lot!

OK, let's close now.