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 <vorlon@debian.org> 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
Reply to: