Otavio: When you send replies to the BTS, please take note of where these replies will
end up. In this report you have sent two replies that never ended up on the debian-boot
list, when they were clearly intended for that list.
Otavio wrote on Sat, 28 Jun 2008 15:14:06 -0300:
> Not really, looks like we're missing a moduels on d-i that's why
> installer and installed systems behaves differently.
> It looks we should include hostap module to allow those to behave the
> same way.
>
> Look bellow:
> > 31,32c43,44
> > < Kernel driver in use: orinoco_pci
> > < Kernel modules: orinoco_pci
> > ---
> >
> >> Kernel driver in use: hostap_pci
> >> Kernel modules: orinoco_pci, hostap_pci
Right. Classic example of two drivers fighting over the same resource. And
unless some preference is coded into the kernel, we don't know which is
going to win. So adding hostap is only likely too add to the same
confusion in D-I.
Otavio wrote on Sat, 28 Jun 2008 16:49:23 -0300:
> We should add hostap modules to the kernel udebs. Those should fix the
> issue providing the same modules that are going to be used on the
> installed system.
No, AFAICT it is only going to result in the same problem ALSO happening
in the installer. Please look at what is really happening here.
The udev rule is:
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:d0:59:bd:d5:c5", NAME="eth1"
That rule _only_ matches on the MAC address; it has absolutely _no_
matching on the original interface name or name of a driver.
The ifconfig output in message #20 is also clear. We have two interfaces:
eth1 Link encap:UNSPEC HWaddr 00-D0-59-BD-D5-C5-00-00-00-00-00-00-00-00-00-00
wlan0_rename Link encap:Ethernet HWaddr 00:d0:59:bd:d5:c5
Originally these were:
wifi0 Link encap:UNSPEC HWaddr 00-D0-59-BD-D5-C5-00-00-00-00-00-00-00-00-00-00
wlan0 Link encap:Ethernet HWaddr 00:d0:59:bd:d5:c5
Note that both essentially have the same MAC address (even if the notation
in the first case is completely weird).
So what happens is that wifi0 gets renamed to eth1, and then udev *also*
tries to rename wlan0 to eth1, which fails in some intermediate stage
because eth1 at that point already exists.
IMO this is clearly a udev problem and adding the hostap modules to D-I
is NOT going to solve that, but is only going to make things worse.
The only thing that I can see us doing in D-I to prevent this problem is to
*blacklist* the hostap modules for the installed system. Main disadvantage
of that is that it's going to be completely non-obvious to users who
actually want to use them...
Attachment:
signature.asc
Description: This is a digitally signed message part.