Frans Pop wrote:
The workaround is still, as I wrote earlier, to remove the existing rename
rule for the wifi interface in the z25 script and to let udev regenerate
it.
I understand the complexity of the argument.
I would just stress that from the "simple user" (including me) point of
view, the key things are that
(a) the installer installs a stock debian kernel and all packages
(including udev) as if taken by apt from the standard repositories
(b) after the reboot at the end of the install (and subsequently), with
the system as installed, the interface has been renamed to wlan0_rename
(c) (see also below) since DURING the install, the interface is called
eth1, things like /etc/network/interfaces are set up with THAT interface
name
(d) therefore, sailing through the install, there's a very ugly
occurrence, namely, on the first reboot, the installed system won't
bring up the wireless net connection.
Therefore, it seems to me that the installer and the stock system have
to be brought to the same state: if the standard (installed, lenny)
system continues to do the renaming, then the installer must, however
unfortunately, bend to concur, so that the newly installed system DOES
bring up the interface.
Barry: a few requests.
1) What was the wireless interface called in the installer?
You can probably tell from /var/log/installer/syslog.
eth1
You can check this from my original report (email of Fri, 27 Jun 2008
14:16:15 +0100 in bug 488267), and in the installer outputs I provided
in my email of Fri, 27 Jun 2008 18:15:56 +0100 (cat /proc/net/dev and
ifconfig while installer running)
2) Does the workaround described above work?
As I have mentioned, my own workaround, with the system exactly as
installed, is simply to edit /etc/network/interfaces with the global
replace of eth1 by wlan0_rename (or whatever the installed system calls
the interface). IMHO, this is much simpler than editing udev rules
(here be dragons!) and doesn't require a reboot.
However, I am much attracted by your workaround since it avoids the
vastly ugly interface name wlan0_rename (!), and I'm glad to report that
it did work - but see comment after next para.
In a little more detail,
* I edited /etc/udev/z25_persistent-net.rules to include the
ATTRS{type}=1 phrase
* I rebooted - could I have done less? certainly, unsurprisingly,
neither udevcontrol reload_rules nor /etc/init.d/udev restart had any
visible effect
* after reboot, the key lines of ifconfig -a read:
wifi0 Link encap:UNSPEC HWaddr 00-D0-59-BD-D5-C5-77-6C-00-00-00-00-00-00-00-00
wlan0 Link encap:Ethernet HWaddr 00:d0:59:bd:d5:c5
(no mention of eth1 in ifconfig nor in /proc/net/dev nor in
/sys/class/net/) and after an edit of /etc/network/interfaces, wlan0 was
successfully brought up.
Do let me know if you want any more diagnostic info.
PLEASE NOTE - sorry for stating the obvious - that this single change
will not solve the original problem, because the interface was called
eth1 by the installer, and /etc/network/interfaces was built
accordingly, with eth1 not wlan0. So the installer will need changing
to use the same interface name as used by the (lenny-release) standard
system.
3) Could you please provide the output of
$ udevinfo -a -p /sys/class/net/<interface>
where <interface> is both of the interfaces you have in that directory
for your wireless.
BEFORE doing the workaround as above in (2):
(for your convenience, diff given after both outputs below)
~$ udevinfo -a -p /sys/class/net/eth1
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/class/net/eth1':
KERNEL=="eth1"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_len}=="6"
ATTR{iflink}=="3"
ATTR{ifindex}=="3"
ATTR{features}=="0x0"
ATTR{type}=="801"
ATTR{link_mode}=="0"
ATTR{address}=="00:d0:59:bd:d5:c5"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="1"
ATTR{dormant}=="0"
ATTR{operstate}=="unknown"
ATTR{mtu}=="1500"
ATTR{flags}=="0x1003"
ATTR{tx_queue_len}=="1000"
looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:02:0b.0':
KERNELS=="0000:02:0b.0"
SUBSYSTEMS=="pci"
DRIVERS=="hostap_pci"
ATTRS{vendor}=="0x1260"
ATTRS{device}=="0x3873"
ATTRS{subsystem_vendor}=="0x1468"
ATTRS{subsystem_device}=="0x0201"
ATTRS{class}=="0x028000"
ATTRS{irq}=="9"
ATTRS{local_cpus}=="ff"
ATTRS{modalias}=="pci:v00001260d00003873sv00001468sd00000201bc02sc80i00"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci0000:00/0000:00:1e.0':
KERNELS=="0000:00:1e.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x2448"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{subsystem_device}=="0x0000"
ATTRS{class}=="0x060400"
ATTRS{irq}=="0"
ATTRS{local_cpus}=="ff"
ATTRS{modalias}=="pci:v00008086d00002448sv00000000sd00000000bc06sc04i00"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
****************** and ***************
~$ udevinfo -a -p /sys/class/net/wlan0_rename/
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/class/net/wlan0_rename':
KERNEL=="wlan0_rename"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_len}=="6"
ATTR{iflink}=="4"
ATTR{ifindex}=="4"
ATTR{features}=="0x0"
ATTR{type}=="1"
ATTR{link_mode}=="0"
ATTR{address}=="00:d0:59:bd:d5:c5"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="1"
ATTR{dormant}=="0"
ATTR{operstate}=="unknown"
ATTR{mtu}=="1500"
ATTR{flags}=="0x1003"
ATTR{tx_queue_len}=="0"
looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:02:0b.0':
KERNELS=="0000:02:0b.0"
SUBSYSTEMS=="pci"
DRIVERS=="hostap_pci"
ATTRS{vendor}=="0x1260"
ATTRS{device}=="0x3873"
ATTRS{subsystem_vendor}=="0x1468"
ATTRS{subsystem_device}=="0x0201"
ATTRS{class}=="0x028000"
ATTRS{irq}=="9"
ATTRS{local_cpus}=="ff"
ATTRS{modalias}=="pci:v00001260d00003873sv00001468sd00000201bc02sc80i00"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci0000:00/0000:00:1e.0':
KERNELS=="0000:00:1e.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x2448"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{subsystem_device}=="0x0000"
ATTRS{class}=="0x060400"
ATTRS{irq}=="0"
ATTRS{local_cpus}=="ff"
ATTRS{modalias}=="pci:v00008086d00002448sv00000000sd00000000bc06sc04i00"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
******************8
The diff between these two outputs is:
8,9c8,9
< looking at device '/class/net/eth1':
< KERNEL=="eth1"
---
> looking at device '/class/net/wlan0_rename':
> KERNEL=="wlan0_rename"
13,14c13,14
< ATTR{iflink}=="3"
< ATTR{ifindex}=="3"
---
> ATTR{iflink}=="4"
> ATTR{ifindex}=="4"
16c16
< ATTR{type}=="801"
---
> ATTR{type}=="1"
25c25
< ATTR{tx_queue_len}=="1000"
---
> ATTR{tx_queue_len}=="0"
AFTER the workaround in (2) above,
:~$ ls -l /sys/class/net/
total 0
drwxr-xr-x 4 root root 0 2008-06-30 15:19 eth0
drwxr-xr-x 4 root root 0 2008-06-30 15:19 lo
drwxr-xr-x 5 root root 0 2008-06-30 15:19 wifi0
drwxr-xr-x 5 root root 0 2008-06-30 15:19 wlan0
and
~$ udevinfo -a -p /sys/class/net/wlan0/
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/class/net/wlan0':
KERNEL=="wlan0"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_len}=="6"
ATTR{iflink}=="4"
ATTR{ifindex}=="4"
ATTR{features}=="0x0"
ATTR{type}=="1"
ATTR{link_mode}=="0"
ATTR{address}=="00:d0:59:bd:d5:c5"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="1"
ATTR{dormant}=="0"
ATTR{operstate}=="unknown"
ATTR{mtu}=="1500"
ATTR{flags}=="0x1003"
ATTR{tx_queue_len}=="0"
looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:02:0b.0':
KERNELS=="0000:02:0b.0"
SUBSYSTEMS=="pci"
DRIVERS=="hostap_pci"
ATTRS{vendor}=="0x1260"
ATTRS{device}=="0x3873"
ATTRS{subsystem_vendor}=="0x1468"
ATTRS{subsystem_device}=="0x0201"
ATTRS{class}=="0x028000"
ATTRS{irq}=="9"
ATTRS{local_cpus}=="ff"
ATTRS{modalias}=="pci:v00001260d00003873sv00001468sd00000201bc02sc80i00"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci0000:00/0000:00:1e.0':
KERNELS=="0000:00:1e.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x2448"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{subsystem_device}=="0x0000"
ATTRS{class}=="0x060400"
ATTRS{irq}=="0"
ATTRS{local_cpus}=="ff"
ATTRS{modalias}=="pci:v00008086d00002448sv00000000sd00000000bc06sc04i00"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
Do let me know if you'd like more info, or you'd like me to try anything
else.
Best wishes, and many thanks for all your (and Otavio's and all other
DDs') work on debian,
Barry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
