Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On 2/25/07, Gordon Farquharson [EMAIL PROTECTED] wrote: How about the following idea for a quick and simple workaround to this problem (it is based on something Steve suggested earlier in the thread). Include the ixp4xx NPE driver modules in both the official and unofficial installer images and modify oldsys-preseed with the patch below. I have tested the installer (revision 45431) both with and without the NPE-B microcode and everything worked fine on my setup. I also tested the case where the user may have both a USB to Ethernet adapter and the NPE-B microcode, and everything worked. For these tests, I told the installer to use packages from unstable to work around #412572 because the fix hadn't hit testing by the time I started yesterday and I was too lazy to recompile apex with a different kernel command line. All my tests have been using a static IP address which is configured in the NSLU2 flash. I should probably try a DHCP served address just to make sure that it doesn't change anything. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Gordon Farquharson [EMAIL PROTECTED] [2007-02-26 23:10]: 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. Need to get 932kB of archives. After unpacking 2541kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! libvolume-id0 udev busybox libklibc klibc-utils initramfs-tools Install these packages without verification [y/N]? n E: Some packages could not be authenticated Looks like a problem with the signatures for these packages. Is this problem just on ARM or installer-wide, or does the problem lie somewhere else ? I saw Frans discussing some kind of key archive problems with Joey on IRC yesterday, so hopefully it's this problem. I don't know for sure though. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Gordon Farquharson wrote: I tried a build of the installer from trunk (revision 45431) and nearly fell of my chair: Known problem at the top of DebianInstaller/Today in the wiki. -- see shy jo signature.asc Description: Digital signature
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Gordon Farquharson [EMAIL PROTECTED] [2007-02-25 23:19]: + if [ -h /lib/firmware/NPE-B ]; then + INTERFACE=eth0 + else + INTERFACE=eth1 + fi I'm happy to make this change if Frans thinks that it's not too late to do it. (FWIW, I can guarantee that changes proposed by Gordon are fully tested.) I think -e is better than -h since (afaik) it follows symlinks. BTW, if we adopt this workaround, we will need to change /usr/share/initramfs-tools/hooks/nslu2 which complains about the missing NPE-B microcode if the NPE driver Well, yeah, that would be nice but imho not strictly necessary because it's only a warning. It might confuse some users but to be honest the majority of users will run the unofficial image that has the microcode included anyway. The assumption (and therefore the possible problem) with this workaround is that the built-in interface will always be named eth0. I have found this to be the case with an asix based USB to Ethernet adapter. It would be reassuring to test this assumption with an different adapter. I'm pretty sure I saw the same with pegasus, but I'm away from my box right now. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Martin I tried a build of the installer from trunk (revision 45431) and nearly fell of my chair: --- [!!] Install the base system Unable to install initramfs-tools An error was returned while trying to install the initramfs-tools package onto the target system. Check /var/log/syslog or see virtual console 4 for the details. --- Needless to say that this problem did not occur when I tested my changes to oldsys-preseed on Sunday night. The notable difference in the build since Sunday night is the new kernel 2.6.18.dfsg.1-11 and associated udebs. However, the problem does not seem to be due to apt seg faulting. ~ # chroot /target sh-3.1# apt-get -f install Reading package lists... Done Building dependency tree... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Here is the relevant output from syslog: Feb 27 05:47:18 base-installer: info: Using kernel 'linux-image-2.6-ixp4xx' Feb 27 05:47:19 base-installer: info: Setting do_initrd='yes'. Feb 27 05:47:19 base-installer: info: Setting link_in_boot='yes'. Feb 27 05:47:20 base-installer: info: Available initramfs generator(s): 'initramfs-tools yaird' Feb 27 05:47:21 apt-install: Reading package lists... Feb 27 05:47:21 apt-install: Feb 27 05:47:21 apt-install: Building dependency tree... Feb 27 05:47:27 apt-install: Feb 27 05:47:28 apt-install: The following extra packages will be installed: Feb 27 05:47:28 apt-install: busybox klibc-utils libklibc libvolume-id0 udev Feb 27 05:47:28 apt-install: The following NEW packages will be installed: Feb 27 05:47:28 apt-install: busybox initramfs-tools klibc-utils libklibc libvolume-id0 udev Feb 27 05:47:29 apt-install: 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. Feb 27 05:47:29 apt-install: Need to get 932kB of archives. Feb 27 05:47:29 apt-install: After unpacking 2541kB of additional disk space will be used. Feb 27 05:47:29 apt-install: WARNING: The following packages cannot be authenticated! Feb 27 05:47:29 apt-install: libvolume-id0 udev busybox libklibc klibc-utils initramfs-tools Feb 27 05:47:29 apt-install: E: Feb 27 05:47:29 apt-install: There are problems and -y was used without --force-yes Feb 27 05:47:29 apt-install: Feb 27 05:47:29 base-installer: error: exiting on error base-installer/kernel/failed-package-install In the chroot: sh-3.1# apt-get install libvolume-id0 udev busybox libklibc klibc-utils initramfs-tools Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: busybox initramfs-tools klibc-utils libklibc libvolume-id0 udev 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. Need to get 932kB of archives. After unpacking 2541kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! libvolume-id0 udev busybox libklibc klibc-utils initramfs-tools Install these packages without verification [y/N]? n E: Some packages could not be authenticated Looks like a problem with the signatures for these packages. Is this problem just on ARM or installer-wide, or does the problem lie somewhere else ? Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Martin I'm CC'ing this message to debian-boot because we may like to get this fix into RC2. On 2/13/07, Martin Michlmayr [EMAIL PROTECTED] wrote: Anyway, I'm away from my slug for the next 3 weeks, but maybe someone can try adding such a udev rule and the nic-modules udeb and see whether it works. How about the following idea for a quick and simple workaround to this problem (it is based on something Steve suggested earlier in the thread). Include the ixp4xx NPE driver modules in both the official and unofficial installer images and modify oldsys-preseed with the patch below. Index: oldsys-preseed === --- oldsys-preseed (revision 45326) +++ oldsys-preseed (working copy) @@ -37,7 +37,15 @@ parse_sysconf /dev/$sysconf # The original NSLU2 uses a different name for the network interface if [ $INTERFACE = ixp0 ]; then - INTERFACE=eth0 + # IXP4xx NPE ethernet interface seems to come + # up as eth0 (#407460) therefore only use eth0 + # for the installer if the NPE microcode is + # present + if [ -h /lib/firmware/NPE-B ]; then + INTERFACE=eth0 + else + INTERFACE=eth1 + fi fi # Use DHCP if the original IP from the firmware has never been changed if [ $IPADDRESS = 192.168.1.77 ]; then Both the official and unofficial installer images work on my setup with this patch applied. The rational behind this workaround is that I have found that with the NPE driver modules included in the image, the built-in Ethernet interface comes up as eth0, regardless of whether the NPE microcode is present. So it makes sense to use eth0 as the default installer interface if the NPE microcode is included in the installer image, or eth1 (the alternate Ethernet adapter) if the NPE microcode is not included. What is nice is that the post-installation configuration is correct (/etc/network/interfaces and udev; see the output at the end of this email) which means that the system is accessible post-installation. The assumption (and therefore the possible problem) with this workaround is that the built-in interface will always be named eth0. I have found this to be the case with an asix based USB to Ethernet adapter. It would be reassuring to test this assumption with an different adapter. In the future, maybe Marco could add a udev rules file (e.g. z30_persistent-embedded-devices or something) in the udev deb and udeb that would have persistent device names for embedded devices supported by Debian, e.g. for ixp4xx it could have the rule # IXP4xx built-in Ethernet adapter SUBSYSTEM==net, DRIVERS==ixp4xx_mac, NAME=eth0 which would then guarantee that the built-in ethernet adapter would always be named eth0 on ixp4xx platforms. BTW, if we adopt this workaround, we will need to change /usr/share/initramfs-tools/hooks/nslu2 which complains about the missing NPE-B microcode if the NPE driver modules are present. For example, during the installation using the official image (with the NPE driver modules) I see Feb 26 04:31:13 apt-install: Warning: ixp4xx_npe ethernet driver firmware file /lib/firmware/NPE-B not found Feb 26 04:31:13 apt-install: Warning: This system has an ethernet module loaded; it's not safe to Feb 26 04:31:13 apt-install: create an initramfs image for the new kernel without the firmware file. Feb 26 04:31:13 apt-install: Feb 26 04:31:13 apt-install: Unable to abort; system will probably be broken! Let me know what you think. Gordon Additional output: * Official (with NPE driver modules but no NPE microcode): $ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth1 iface eth1 inet static address 192.168.1.67 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 205.171.3.65 205.171.2.65 dns-search example.org $ cat /etc/udev/rules.d/z25_persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # MAC addresses must be written in lowercase. # USB device 13b1:0018 (asix) SUBSYSTEM==net, DRIVERS==?*,
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Gordon Farquharson wrote: On 2/12/07, Steve Langasek [EMAIL PROTECTED] wrote: The problem seems as simple as that the ipx4xx driver is *not* included in d-i, but is included in the installed kernel; so in the installer, the module is never loaded resulting in the USB adapter getting the eth0 name, but after a reboot the ipx4xx driver is found first, breaking the handling of persistent device names. Yup. The original reason it wasn't included in the installer is because including it without the NPE-B microcode causes the NLSU2 built-in ethernet adapter to be named eth0, and the installer, by default, uses eth0 to provide the installation interface. This situation makes the installer inaccessible to users without a serial console attached to the NSLU2. Er, it is included in d-i: [EMAIL PROTECTED]:~/src/d-i/packages/kernel/linux-kernel-di-arm-2.6/modules/arm-ixp4xxgrep ixp4xx nic-modules ixp4xx_mac ixp4xx_npe ixp4xx_qmgr -- see shy jo signature.asc Description: Digital signature
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Steve Langasek wrote: severity 407460 important reassign 407460 nic-usb-modules-2.6.18-4-ixp4xx-di thanks What does nic-usb-modules-2.6.18-4-ixp4xx-di have to do with this? -- see shy jo signature.asc Description: Digital signature
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Joey Hess [EMAIL PROTECTED] [2007-02-13 15:24]: Er, it is included in d-i: No, nic-modules is not included on the ixp4xx image. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Martin Michlmayr wrote: * Joey Hess [EMAIL PROTECTED] [2007-02-13 15:24]: Er, it is included in d-i: No, nic-modules is not included on the ixp4xx image. So the right package is debian-installer and the bug can be fixed by adding nic-modules? -- see shy jo
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On Tue, Feb 13, 2007 at 03:27:36PM -0500, Joey Hess wrote: Steve Langasek wrote: severity 407460 important reassign 407460 nic-usb-modules-2.6.18-4-ixp4xx-di thanks What does nic-usb-modules-2.6.18-4-ixp4xx-di have to do with this? Is ixp4xx the flavor used for installs on NSLU2? In testing there was an nslu2 flavor, but that's no longer present in unstable. I understood that ixp4xx is the flavor being used. It made sense to me that this would be the package to provide the workaround of adding an extra udev rule. If you think the workaround belongs somewhere else (e.g., in the debian-installer package itself because nslu2 installs now share a kernel flavor with other types of hardware), by all means feel free. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Joey Hess [EMAIL PROTECTED] [2007-02-13 15:38]: No, nic-modules is not included on the ixp4xx image. So the right package is debian-installer and the bug can be fixed by adding nic-modules? No. If nic-modules is included (and hence the ixp4xx ethernet driver), USB will get eth1 and the installer won't work at all because it will use eth0, which is the ixp4xx device that doesn't work because of the missing microcode. One solution would be to include nic-modules and have a udev rule file to make sure that the USB ethernet is eth0. Unfortunately, I've no idea how to easily add such a udev file to the image. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Steve Langasek [EMAIL PROTECTED] [2007-02-13 12:54]: Is ixp4xx the flavor used for installs on NSLU2? In testing there was an nslu2 flavor, but that's no longer present in unstable. I understood that ixp4xx is the flavor being used. ixp4xx is the platform and NSLU2 is one ixp4xx device. We got rid of the specific nslu2 flavour when we changed nslu2 support so it could use the generic ixp4xx kernel. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Martin Michlmayr wrote: No. If nic-modules is included (and hence the ixp4xx ethernet driver), USB will get eth1 and the installer won't work at all because it will use eth0, which is the ixp4xx device that doesn't work because of the missing microcode. I take it that netcfg's use of link detection doesn't make it default to eth1 in this case? One solution would be to include nic-modules and have a udev rule file to make sure that the USB ethernet is eth0. Unfortunately, I've no idea how to easily add such a udev file to the image. The rule could go in rootskel for arm only, but it would need to be one that only affected the nslu2 and not other arms. If that is not possible in a udev rule, we would have to make rootskel move the rule into place during early boot if it detected an nslu2. -- see shy jo signature.asc Description: Digital signature
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Joey Hess [EMAIL PROTECTED] [2007-02-13 16:27]: I take it that netcfg's use of link detection doesn't make it default to eth1 in this case? No, oldsys-preseed always sets netcfg/choose_interface. Although now I'm starting to wonder whether this is a good idea... The rule could go in rootskel for arm only, but it would need to be one that only affected the nslu2 and not other arms. If that is not possible in a udev rule, we would have to make rootskel move the rule into place during early boot if it detected an nslu2. The rule Gordon suggested could be included on all arm machines since it mentions the ixp4xx driver: # Built-in Ethernet Adapter (NPE-B microcode not present) SUBSYSTEM==net, DRIVERS==ixp4xx_mac, NAME=eth1 And then the unofficial ixp4xx image which contains the microcode would simply need to remove that file from the initramfs. Anyway, I'm away from my slug for the next 3 weeks, but maybe someone can try adding such a udev rule and the nic-modules udeb and see whether it works. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Joey Hess [EMAIL PROTECTED] [2007-02-13 18:15]: And then the unofficial ixp4xx image which contains the microcode would simply need to remove that file from the initramfs. There are other arm machines that use ixp4xx ethernet though. So? None of them will work without the proprietary microcode that cannot be included in Debian. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Martin Michlmayr [EMAIL PROTECTED] [2007-02-13 23:18]: So? None of them will work without the proprietary microcode that cannot be included in Debian. (In theory, there could be a IXP4xx based device that contains the microcode in flash; but the ixp4xx driver in Debian doesn't allow loading the microcode from flash and while I believe the nslu2 people have a patch for this upstream has rejected it because it can be done in user space...) -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Martin Michlmayr wrote: The rule Gordon suggested could be included on all arm machines since it mentions the ixp4xx driver: # Built-in Ethernet Adapter (NPE-B microcode not present) SUBSYSTEM==net, DRIVERS==ixp4xx_mac, NAME=eth1 And then the unofficial ixp4xx image which contains the microcode would simply need to remove that file from the initramfs. There are other arm machines that use ixp4xx ethernet though. -- see shy jo signature.asc Description: Digital signature
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On Tue, Feb 13, 2007 at 06:15:47PM -0500, Joey Hess wrote: The rule Gordon suggested could be included on all arm machines since it mentions the ixp4xx driver: # Built-in Ethernet Adapter (NPE-B microcode not present) SUBSYSTEM==net, DRIVERS==ixp4xx_mac, NAME=eth1 And then the unofficial ixp4xx image which contains the microcode would simply need to remove that file from the initramfs. There are other arm machines that use ixp4xx ethernet though. Do the other machines have the same problem of not giving the user the opportunity to interactively select a network interface in the installer? The issue of device names seems to be a problem mainly for those systems with neither a VGA nor a serial console by default. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On Sun, Feb 11, 2007 at 10:06:41PM -0700, Gordon Farquharson wrote: On 2/10/07, Gordon Farquharson [EMAIL PROTECTED] wrote: On 1/18/07, Martin Michlmayr [EMAIL PROTECTED] wrote: Well, I still believe this is a problem with udev. CCing Marco. I just tested a patch [1,2] that was applied to udev to fix the network interface renaming code to see if it would solve this bug, but no luck. The USB ethernet adapter is still (most often) renamed eth1_rename despite the rule to name it eth0 in /etc/udev/rules.d/z25_persistent-net.rules. AIUI this basically comes down to a conflict over the use of the name 'eth0'; there's a udev rule asking for the USB ethernet adapter to be named eth0, but the ixp4xx driver is found first, and loaded under this name by default, with no further rules to rename it to e.g. eth1. The problem seems as simple as that the ipx4xx driver is *not* included in d-i, but is included in the installed kernel; so in the installer, the module is never loaded resulting in the USB adapter getting the eth0 name, but after a reboot the ipx4xx driver is found first, breaking the handling of persistent device names. Which means in turn that a simple fix would be to make ixp4xx available in the installer so that it can be detected; it certainly makes sense to me that the onboard ethernet ought to be eth0, even if it needs extra firmare to be usable. Adding the hard-coded rule to rename ixp4xx_mac devices to eth1 would also seem to be a pretty reliable workaround, as long as it was limited to only be activated on NSLU2 systems. (You wouldn't want this confusing rule being added to systems without this hardware!) Finally, as popular as NSLU2 is, this is still a hardware-specific bug, and as such I'm inclined to downgrade this bug report. I'm happy for us to have a well-supported NSLU2 installer in etch, but I don't see that this should be a blocker for the release if it's not addressed in a timely manner. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On Feb 12, Steve Langasek [EMAIL PROTECTED] wrote: The problem seems as simple as that the ipx4xx driver is *not* included in d-i, but is included in the installed kernel; so in the installer, the module is never loaded resulting in the USB adapter getting the eth0 name, but after a reboot the ipx4xx driver is found first, breaking the handling of persistent device names. No, wait... When a new network interface is added it will get the next available name, this is a supported configuration. The problem is that for some reason udev believes that both devices should get the same name. I had no time to properly review this bug, but my bet is that udev thinks that one of the devices (eth0) should not be renamed, so trying to rename the other one to eth0 too will fail. Maybe DRIVERS==?* (which is needed to ignore stuff like VLAN subinterfaces) is not matching. Adding the hard-coded rule to rename ixp4xx_mac devices to eth1 would also seem to be a pretty reliable workaround, as long as it was limited to only be activated on NSLU2 systems. (You wouldn't want this confusing rule being added to systems without this hardware!) Yes, this would work. -- ciao, Marco signature.asc Description: Digital signature
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On Mon, Feb 12, 2007 at 10:40:39AM +0100, Marco d'Itri wrote: On Feb 12, Steve Langasek [EMAIL PROTECTED] wrote: The problem seems as simple as that the ipx4xx driver is *not* included in d-i, but is included in the installed kernel; so in the installer, the module is never loaded resulting in the USB adapter getting the eth0 name, but after a reboot the ipx4xx driver is found first, breaking the handling of persistent device names. No, wait... When a new network interface is added it will get the next available name, this is a supported configuration. Ok, so this is true when the built-in device is loaded first at boot time and is initially assigned eth0, there is no rule saying to rename it, and there is a rule saying to rename another interface to eth0? The problem is that for some reason udev believes that both devices should get the same name. I had no time to properly review this bug, but my bet is that udev thinks that one of the devices (eth0) should not be renamed, so trying to rename the other one to eth0 too will fail. Maybe DRIVERS==?* (which is needed to ignore stuff like VLAN subinterfaces) is not matching. Ok, thanks for the info. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On Feb 12, Steve Langasek [EMAIL PROTECTED] wrote: No, wait... When a new network interface is added it will get the next available name, this is a supported configuration. Ok, so this is true when the built-in device is loaded first at boot time and is initially assigned eth0, there is no rule saying to rename it, and there is a rule saying to rename another interface to eth0? If there is already a rule to rename some other device to eth0 then the current eth0 will be renamed to the first free name and a new rule will be created for it. -- ciao, Marco signature.asc Description: Digital signature
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Steve On 2/12/07, Steve Langasek [EMAIL PROTECTED] wrote: The problem seems as simple as that the ipx4xx driver is *not* included in d-i, but is included in the installed kernel; so in the installer, the module is never loaded resulting in the USB adapter getting the eth0 name, but after a reboot the ipx4xx driver is found first, breaking the handling of persistent device names. Yup. The original reason it wasn't included in the installer is because including it without the NPE-B microcode causes the NLSU2 built-in ethernet adapter to be named eth0, and the installer, by default, uses eth0 to provide the installation interface. This situation makes the installer inaccessible to users without a serial console attached to the NSLU2. Which means in turn that a simple fix would be to make ixp4xx available in the installer so that it can be detected; it certainly makes sense to me that the onboard ethernet ought to be eth0, even if it needs extra firmare to be usable. Currently, if we include the ixp4xx NPE driver, and tell the installer to use eth1 (the USB to ethernet adapter) by default, we would prevent people that do not have a USB to ethernet adapter from using the unofficial Debian installer image that includes the NPE-B microcode and which is made available through http://www.slug-firmware.net/. We would have to change the installer default interface based on whether or not we had the NPE-B microcode present in the image. This solution will only work if interfaces are always detected in the same order, which may not be reliable. Adding an extra naming rule should never fail, so, although I dislike this solution, it seems more reliable. It does mean that the interface name for the built-in ethernet will depend how you installed Debian on the NSLU2, and this could cause headaches down the line in terms of support (maybe). Finally, as popular as NSLU2 is, this is still a hardware-specific bug, and as such I'm inclined to downgrade this bug report. I'm happy for us to have a well-supported NSLU2 installer in etch, but I don't see that this should be a blocker for the release if it's not addressed in a timely manner. I was hesitant with deciding on the severity of the bug, because 99% will use the unofficial installer image which works great. This bug only affect the probably less than 1% that use a DFSG installation. However, it looks like we should be able to find a solution that works for etch. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On Feb 12, Gordon Farquharson [EMAIL PROTECTED] wrote: Will udev add this new rule to /etc/udev/rules.d/z25_persistent-net.rules ? Since no new rules are Yes, this is the whole point. being added on my test system, does this tells whether something like DRIVERS==?* is matching or not ? Apparently not. I see that I already suggested this in my first reply on december 14. It seems that the real question is what sequence of events causes an interface to be named eth1_rename, as opposed to the next available interface name (e.g. eth1). I'll see if I can figure this out from the I explained this today. I do not think I can help you further if you ignore what I write. -- ciao, Marco signature.asc Description: Digital signature
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Marco On 2/12/07, Marco d'Itri [EMAIL PROTECTED] wrote: On Feb 12, Steve Langasek [EMAIL PROTECTED] wrote: No, wait... When a new network interface is added it will get the next available name, this is a supported configuration. Ok, so this is true when the built-in device is loaded first at boot time and is initially assigned eth0, there is no rule saying to rename it, and there is a rule saying to rename another interface to eth0? If there is already a rule to rename some other device to eth0 then the current eth0 will be renamed to the first free name and a new rule will be created for it. Will udev add this new rule to /etc/udev/rules.d/z25_persistent-net.rules ? Since no new rules are being added on my test system, does this tells whether something like DRIVERS==?* is matching or not ? It seems that the real question is what sequence of events causes an interface to be named eth1_rename, as opposed to the next available interface name (e.g. eth1). I'll see if I can figure this out from the code. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Marco On 2/12/07, Marco d'Itri [EMAIL PROTECTED] wrote: being added on my test system, does this tells whether something like DRIVERS==?* is matching or not ? Apparently not. I see that I already suggested this in my first reply on december 14. Yeah, your comment in your previous email is what prompted me to ask the question :-) It seems that the real question is what sequence of events causes an interface to be named eth1_rename, as opposed to the next available interface name (e.g. eth1). I'll see if I can figure this out from the I explained this today. Ok, I thought that you meant that the interface would be renamed to the next available interface name e.g. 'eth0' would become 'eth1', not 'eth1_rename'. Sorry for the misunderstanding. I do not think I can help you further if you ignore what I write. Ok. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
severity 407460 important reassign 407460 nic-usb-modules-2.6.18-4-ixp4xx-di thanks On Mon, Feb 12, 2007 at 11:56:06AM -0700, Gordon Farquharson wrote: The problem seems as simple as that the ipx4xx driver is *not* included in d-i, but is included in the installed kernel; so in the installer, the module is never loaded resulting in the USB adapter getting the eth0 name, but after a reboot the ipx4xx driver is found first, breaking the handling of persistent device names. Yup. The original reason it wasn't included in the installer is because including it without the NPE-B microcode causes the NLSU2 built-in ethernet adapter to be named eth0, and the installer, by default, uses eth0 to provide the installation interface. This situation makes the installer inaccessible to users without a serial console attached to the NSLU2. Oh, if eth0 needs to be pointed at the USB interface during install as well, then yes, I guess including the ipx4xx driver in the installer would be a wrong solution. Which means in turn that a simple fix would be to make ixp4xx available in the installer so that it can be detected; it certainly makes sense to me that the onboard ethernet ought to be eth0, even if it needs extra firmare to be usable. Currently, if we include the ixp4xx NPE driver, and tell the installer to use eth1 (the USB to ethernet adapter) by default, we would prevent people that do not have a USB to ethernet adapter from using the unofficial Debian installer image that includes the NPE-B microcode and which is made available through http://www.slug-firmware.net/. We would have to change the installer default interface based on whether or not we had the NPE-B microcode present in the image. This solution will only work if interfaces are always detected in the same order, which may not be reliable. It's possible to make it reliable by controlling the order in which the drivers become available to the installer, I think. But I also think this is something of a non-issue; if the user has the unofficial image that includes the firmware, they can simply control the order themselves by not having a USB ethernet device plugged in at install time, no? So giving precedence to the USB interface as eth0 would work for both installer versions. Adding an extra naming rule should never fail, so, although I dislike this solution, it seems more reliable. It does mean that the interface name for the built-in ethernet will depend how you installed Debian on the NSLU2, and this could cause headaches down the line in terms of support (maybe). Hmm, I hope it wouldn't cause support issues. At least, no other Debian support isn't going to assume anything about which device has which interface name. I was hesitant with deciding on the severity of the bug, because 99% will use the unofficial installer image which works great. This bug only affect the probably less than 1% that use a DFSG installation. However, it looks like we should be able to find a solution that works for etch. Well, on those grounds alone then I'm going to downgrade the report now. I'm also reassigning the bug to nic-usb-modules-2.6.18-4-ixp4xx-di, since that seems to be the package that needs to take care of fixing this if I understand correctly. On Mon, Feb 12, 2007 at 12:05:16PM -0700, Gordon Farquharson wrote: It seems that the real question is what sequence of events causes an interface to be named eth1_rename, as opposed to the next available interface name (e.g. eth1). I'll see if I can figure this out from the code. AIUI the sequence is: - the NPE interface is brought up as eth0 - the USB interface is brought up, and is initally assigned to eth1 - the udev rule is processed that says to name the USB interface to eth0, which is currently occupied, so the USB interface is first renamed to eth1_rename to allow the swap - udev goes to rename the NPE interface to eth1, and this operation fails, so processing stops here -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Marco On 2/10/07, Gordon Farquharson [EMAIL PROTECTED] wrote: On 1/18/07, Martin Michlmayr [EMAIL PROTECTED] wrote: Well, I still believe this is a problem with udev. CCing Marco. I just tested a patch [1,2] that was applied to udev to fix the network interface renaming code to see if it would solve this bug, but no luck. The USB ethernet adapter is still (most often) renamed eth1_rename despite the rule to name it eth0 in /etc/udev/rules.d/z25_persistent-net.rules. Gordon [1] http://git.kernel.org/git/?p=linux/hotplug/udev.git;a=commitdiff;h=ca714ef70e549aad486a62f4d6ef849572e3a7f1 [2] http://marc.theaimsgroup.com/?l=linux-hotplug-develm=116956926523008w=2 -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On 1/18/07, Martin Michlmayr [EMAIL PROTECTED] wrote: Well, I still believe this is a problem with udev. CCing Marco. Marco, a while ago, you suggested that the problem could be due to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389250 but I still see the problem with 2.6.20 which includes the patch that apparently fixes 389250. Do you any further ideas ? Martin, in the meantime, what do you think about adding a script to the installer to add the following rule to /etc/udev/rules.d/z25_persistent-net.rules: # Built-in Ethernet Adapter (NPE-B microcode not present) SUBSYSTEM==net, DRIVERS==ixp4xx_mac, NAME=eth1 It is a hack, but adding this rule causes the USB Ethernet adapter to be named eth0 as opposed to eth1_rename. The system would therefore be accessible after an installation without the NPE-B microcode, which means that we could downgrade the severity of the bug. I'm not sure where to put such a script in the installer though. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
However, when booting after the installation, the NPE driver seems to assume control of the interface name eth0, which causes something to rename the interface of the USB to ethernet adapter to eth1_rename. it sounds to me like the built in nic is getting detected first before the USB to ethernet adaptor, udev should then swap the names back to those used at install time. It looks like it is renaming the usb to ethernet to a temporary name (nessacery for a swap operation) but failing to rename the built in nic for some reason.
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Package: debian-installer
Version: 20061102
Severity: serious
I'm not sure which package to assign this bug to, but since it causes
the system to be inaccessible after an install, debian-installer seems
like a good place to start.
Summary of the problem:
After an installation of Debian on the Linksys NSLU2, the system is
inaccessible because the USB ethernet interface is renamed
eth1_rename.
Background:
The NSLU2 is an ARM based network available storage device. Support
for installing Debian on this system has been added to etch. The NSLU2
has a single built-in ethernet adapter for which a driver has been
written and included in the Debian 2.6.18 kernel. However, Debian
installer images cannot use this driver, because the network processor
engine (NPE) in the IXP4xx CPU requires non-free microcode. Therefore,
a USB to ethernet adapter is required to install Debian.
Problem description:
Debian installs without problems using the USB to ethernet adapter.
During the installation, a udev rule is written which names the USB to
ethernet adapter to eth0:
# cat /etc/udev/rules.d/z25_persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.
# USB device 13b1:0018 (asix)
SUBSYSTEM==net, DRIVERS==?*, ATTRS{address}==00:14:bf:fe:2a:4e,
NAME=eth0
However, when booting after the installation, the NPE driver seems to
assume control of the interface name eth0, which causes something to
rename the interface of the USB to ethernet adapter to eth1_rename.
From the boot log:
IXP4XX NPE driver Version 0.2.0 initialized
input: ixp4xx beeper as /class/input/input0
IXP4XX Q Manager 0.2.0 initialized.
ixp4xx_mac driver 0.2.1: eth0 on NPE-B with PHY[1] initialized
eth1: register 'asix' at usb-:00:01.2-2, ASIX AX88772 USB 2.0
Ethernet, 00:14:bf:fe:2a:4e
usbcore: registered new driver asix
the output of ifconfig -a:
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.1.67 Bcast:192.168.1.255 Mask:255.255.255.0
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth1_rena Link encap:Ethernet HWaddr 00:14:BF:FE:2A:4E
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
and the /etc/network/interfaces created by the installer
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.67
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 205.171.3.65 205.171.2.65
dns-search example.org
This configuration causes the system to be inaccessible unless the
user has added a connector for a serial port to the NSLU2. This
procedure requires soldering; something most users are not going to
do.
Here is the relevant output from /dev/hotplug.log with hotplug logging enabled:
HOTPLUG_TIME='Thu Jan 18 08:08:22 MST 2007'
PHYSDEVPATH=/devices/platform/ixp4xx_mac.0
SUBSYSTEM=net
OLDPWD=/
DEVPATH=/class/net/eth0
ACTION=add
UDEV_LOG=3
COMMENT=Unknown net device (/class/net/eth0) (ixp4xx_mac)
UDEVD_EVENT=1
PHYSDEVDRIVER=ixp4xx_mac
INTERFACE=eth0
PHYSDEVBUS=platform
SEQNUM=684
Note that eth1 or eth1_rename does not appear in the log.
I have tried the latest version of the NPE driver (0.3.1) that has
been checked into the Debian kernel repository, but there is no change
in the behaviour.
IXP4XX NPE driver Version 0.3.0 initialized
IXP4XX Q Manager 0.2.1 initialized.
ixp4xx_mac driver 0.3.1: eth0 on NPE-B with PHY[1] initialized
eth1: register 'asix' at usb-:00:01.2-2, ASIX AX88772 USB 2.0
Ethernet, 00:14:bf:fe:2a:4e
I am using the version of debian-installer in trunk, and linux-2.6
2.6.18.dfsg.1-9 (linux-image-2.6.18-4-ixp4xx).
I'm still looking for a solution to the problem. Any suggestions would
be helpful.
Other bugs that may be related: #405845, #406948, and #389250
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389250
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405845
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406948
Gordon
--
Gordon Farquharson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
* Gordon Farquharson [EMAIL PROTECTED] [2007-01-18 08:57]:
I'm not sure which package to assign this bug to, but since it causes
the system to be inaccessible after an install, debian-installer seems
like a good place to start.
Well, I still believe this is a problem with udev. CCing Marco.
Summary of the problem:
After an installation of Debian on the Linksys NSLU2, the system is
inaccessible because the USB ethernet interface is renamed
eth1_rename.
Background:
The NSLU2 is an ARM based network available storage device. Support
for installing Debian on this system has been added to etch. The NSLU2
has a single built-in ethernet adapter for which a driver has been
written and included in the Debian 2.6.18 kernel. However, Debian
installer images cannot use this driver, because the network processor
engine (NPE) in the IXP4xx CPU requires non-free microcode. Therefore,
a USB to ethernet adapter is required to install Debian.
Problem description:
Debian installs without problems using the USB to ethernet adapter.
During the installation, a udev rule is written which names the USB to
ethernet adapter to eth0:
# cat /etc/udev/rules.d/z25_persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.
# USB device 13b1:0018 (asix)
SUBSYSTEM==net, DRIVERS==?*, ATTRS{address}==00:14:bf:fe:2a:4e,
NAME=eth0
However, when booting after the installation, the NPE driver seems to
assume control of the interface name eth0, which causes something to
rename the interface of the USB to ethernet adapter to eth1_rename.
From the boot log:
IXP4XX NPE driver Version 0.2.0 initialized
input: ixp4xx beeper as /class/input/input0
IXP4XX Q Manager 0.2.0 initialized.
ixp4xx_mac driver 0.2.1: eth0 on NPE-B with PHY[1] initialized
eth1: register 'asix' at usb-:00:01.2-2, ASIX AX88772 USB 2.0
Ethernet, 00:14:bf:fe:2a:4e
usbcore: registered new driver asix
the output of ifconfig -a:
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.1.67 Bcast:192.168.1.255 Mask:255.255.255.0
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth1_rena Link encap:Ethernet HWaddr 00:14:BF:FE:2A:4E
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
and the /etc/network/interfaces created by the installer
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.67
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if
installed
dns-nameservers 205.171.3.65 205.171.2.65
dns-search example.org
This configuration causes the system to be inaccessible unless the
user has added a connector for a serial port to the NSLU2. This
procedure requires soldering; something most users are not going to
do.
Here is the relevant output from /dev/hotplug.log with hotplug logging
enabled:
HOTPLUG_TIME='Thu Jan 18 08:08:22 MST 2007'
PHYSDEVPATH=/devices/platform/ixp4xx_mac.0
SUBSYSTEM=net
OLDPWD=/
DEVPATH=/class/net/eth0
ACTION=add
UDEV_LOG=3
COMMENT=Unknown net device (/class/net/eth0) (ixp4xx_mac)
UDEVD_EVENT=1
PHYSDEVDRIVER=ixp4xx_mac
INTERFACE=eth0
PHYSDEVBUS=platform
SEQNUM=684
Note that eth1 or eth1_rename does not appear in the log.
I have tried the latest version of the NPE driver (0.3.1) that has
been checked into the Debian kernel repository, but there is no change
in the behaviour.
IXP4XX NPE driver Version 0.3.0 initialized
IXP4XX Q Manager 0.2.1 initialized.
ixp4xx_mac driver 0.3.1: eth0 on NPE-B with PHY[1] initialized
eth1: register 'asix' at usb-:00:01.2-2, ASIX AX88772 USB 2.0
Ethernet, 00:14:bf:fe:2a:4e
I am using the version of debian-installer in trunk, and linux-2.6
2.6.18.dfsg.1-9 (linux-image-2.6.18-4-ixp4xx).
I'm still looking for a solution to the problem. Any suggestions would
be helpful.
Other bugs that may be related: #405845, #406948, and #389250
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389250
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405845
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406948
Gordon
--
Gordon Farquharson
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to
