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]
