Bug#537502: D-I incorrectly expects firmware requests on module load
Hi,
On 09/29/2009 02:58 PM, Sergio wrote:
> Of course, bug is still in place - problem with firmware is not caught
> properly by installer, installer continues trying to setup DHCP
> network using unusable NIC, wrong error report is displayed to user,
> [...]
Reopening, since Sergio's description still applies to SVN trunk D-I.
The problem is that e100 is first requesting firmware when the link is
brought up, and not when the module is loaded, as D-I expects.
The flow is as follows check-missing-firmware ignores the first request
to show the firmware dialog, so that it can try to find firmware on the
media and install it silently and enable non-free sources to be
installed as well, but it doesn't find any firmware, then reloads the
module, so that the module has a chance to find the new firmware that
might be available now, and waits for a new firmware request, which
won't come no mather how long it sleeps, then it gives up, thinks
everything is fine, and the network card selection interface brings the
interface up and generates the firmware request, while D-I tries to get
DHCP, and tells the user that the DHCP request failed and while on tty4
you can read about the firmware request, that D-I never told you about.
The upstream kernel history clearly shows that upstream doesn't want it
to happen at probe (module load), in order to support built-in drivers.
A quick search revealed these commits:
bnx2x: Load firmware in open() instead of probe()
6891dd25d3f82e50979b27fde1980aa96320b975
iwlwifi: delay firmware loading from pci_probe to network interface open
5a66926aa9230810704fd5a127966215fd58881e
netxen: Avoid firmware load in PCI probe
b3e2d8874e8ba92bfefede645b8be2ec6c956933
spidernet: load firmware when open
3cf761ddccb9332218973e17f9b987bb5cae7b69
So since the kernel policy is against D-I's approach I see 2 options for
fixing this for squeeze:
1) Disable first_try in check-missing-firmware
Cons:
Will disable silent load of non-free firmware if present on media
Require extra preseed variable for automated non-free installs
Pro:
Will avoid network firmware requests from being ignored
Will still allow silent non-free firmware usage via preseed
Small change
2) Monitor interfaces during the modprobes at the end of
check-missing-firmware and 1 second after and try to
take any new through an up and down cycle.
Cons:
Not an one-liner, but properly ~10 liner
Adds an additional second of sleep per firmware-requesting module
Pro
Doesn't break existing working functionality
No need for an extra preseed for automated non-free installs
I can write a patch for either, but I don't know which one is preferred.
For wheezy I think a larger rewrite is needed, way too much sleep for my
taste.
> In very short, to resolve this problem you need:
>>From installation guide:
> http://www.debian.org/releases/stable/i386/ch06s04.html.en you can get to:
> http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/squeeze/current/
> or
> http://packages.debian.org/search?keywords=firmware
> and there in packet firmware-linux you can find the needed bin-file (that
> d101m_ucode.bin you saw in installer's log).
> Now, all you need - extract it from tar or deb, write to floppy or
> flashcard, start installer (preferably in expert mode), and before the
> network confuguration step switch to another console (alt+F3), plug
> floppy/flashcard in, mount it with mount -t vfat /dev/..... /some/directory
> and copy bin-file to /lib/firmware/e100/ (you need mkdir before that).
> And after that you are able to switch back (alt+F1) and continue
> installation.
My fix was to make a script that make a new initrd which includes the
firmware packages in /firmware, where D-I automatically
looks for them, and will install them and enable non-free on the target
system. Script available on request.
Sadly, this Intel DFSG-violation have forced me to have a non-free D-I
netboot option on my network :(
--
Best reagards
Asbjørn Sloth Tønnesen
asbjorn.biz
Reply to: