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