I have a brand new one with 266MHz factory settings. It has a sticker "Manufactured 07/2007".

I've also got one of the newer ones (I'll check the manufacturing date when I get home) and I floated this idea when I spoke to jake1981 but I wonder if something has changed between the pre-266MHz versions and the newer ones?

Although this still doesn't explain how OpenSLUG gets around this problem...

I thought of adding some debug parameters to the module loading but our problem seems to be even before the module gets loaded.

I thought of adding some debug parameters to the module loading but our problem seems to be even before the module gets loaded.

Why do you think so? nslu2init loads the ixp400 module first, then it tries to do the firmware stuff (AFAIR), and only after that it loads ixp400_eth module. None of the loads seems to produce traceable errors on my machine. In fact the module loading done later by /etc/init.d/modules should not matter with this nslu2init.

* Booted into OpenSLUG-3.10-beta without my external HDD connected
* Connected my external HDD and mounted the necessary partitions (/dev proc) and chrooted into the Gentoo/SLUG environment
* Edited /etc/conf.d/net and replicated the config for eth0, but changed the device to eth2
* Symlinked /etc/init.d/net.eth2 to /etc/init.d/net.lo
* Added net.eth2 to the default runlevel
* Unmounted everything, rebooted and prayed (I'm working remotely from the NSLU2

To my amazement after a while the NSLU2 came up with an IP address via DHCP and I SSHed into the box....having added "log_level=2" to the ixp400_eth module seems to make no difference at all but for some reason it seems to create an eth2 device and not an eth0!

When I get home I'm going to tinker around with it a bit more....maybe try removing the "alias ath0" stuff and see if ixp400_eth defaults to eth0 and not eth2._________________"Expect nothing. That way you will be ready for anything - Virginia Viadura"

* Booted into OpenSLUG-3.10-beta without my external HDD connected
* Connected my external HDD and mounted the necessary partitions (/dev proc) and chrooted into the Gentoo/SLUG environment
* Edited /etc/conf.d/net and replicated the config for eth0, but changed the device to eth2
* Symlinked /etc/init.d/net.eth2 to /etc/init.d/net.lo
* Added net.eth2 to the default runlevel
* Unmounted everything, rebooted and prayed (I'm working remotely from the NSLU2

To my amazement after a while the NSLU2 came up with an IP address via DHCP and I SSHed into the box....having added "log_level=2" to the ixp400_eth module seems to make no difference at all but for some reason it seems to create an eth2 device and not an eth0!

This is roughly what I have done above, but in my case this was insufficient to get an shh service. I guess the debug flag has nothing to do this (I was not touching this yet). My slug also goes on the nete with a DHCP address. But still dropbear would not start, claiming that net.eth0 has failed (sure, I want it to use eth2). Could it be because eth2 is actually started with some delay?

At the moment something bad happened to my openslug. Even this guy is refusing to go on the net now...

Things look a bit different than I expected. I am now sure that /etc/init.d/nslu2init was *not* loading the modules on my machine. At this point the modules are already loaded on my slug (I dumped the output of lsmod from within /etc/init.d/nslu2init, just before the first modprobe). It seems that the modules are loaded before this init is run (contrary to what I assumed). So the contents of my /etc/modules.autoload.d/kernel-2.6 takes precendence.

I believe this file was empty on the initial image, but I might have added the ixp modules to it following howto's on wikis. Normally adding modules twice does not hurt, so I though I can do it without testing (at least I guess I could have thought that). Obviously this is bad if we need to load firmware before the ixp400_eth modules is load (do we?).

I removed the two modules from autoload and I think this should solve the problem of error message in line 27. Jackal, can you check what is in your /etc/modules.autoload.d/kernel-2.6 file, remove ixp modules if found, and report whether the error in firmware uploading has disappeared (using your serial console)?

However this still does not help with getting eth0 to work on my slug. Still eth2 is the only interface that shows up in ifconfig.

I'm having the same problem as above....seems eth0 isn't brought up as it should be because the ixp400 device (in /dev) can't be found after its been created. This is a shame because I've just bought an NSLU2 with Gentoo/SLUG in mind...

Also, where is the "openslug-3.1-beta.bin" on jake1981's website that he mentions?

It's the same binary which is on nslu2-linux's download site. I had to remove it due to licensing issues, or put a same license which is for gentooslug image for there. Thought that I'd rather remove it, as that file also can be download from slug-firmwares..

Hi,
thanks for debugging so far. I tried the eth2 thing and it works!! Thanks!

wazow wrote:

Another anomaly, which is definitely less annoying than lack of the network connection, is that disk leds on my slug are interchanged. Turning on disk-1 actually turns on the led labeled "disk 2".

This happens obviously with OpenSlug, and to the extent I can guess also with gentoslug (after boot "disk 2" is on, while my rootfs is in disk1 slot). Is anybody else seeing this?

EDIT: This eth2 thing and swapped leds make me think more and more that newer slugs are differ from the normal ones slightly.

I have the same "problem" with the leds. I had to deunderclock my slug (Manufactured 10/2005), so it should be an old one.

red-nammoc

Hmm.. You could check if this is the issue for you, switch your harddisk to another usb slot on behind. I noticed this behaviour when I made my nslu2events ebuild, when I want it to turn on led for disk-1, it turns on led for disk-2. Order of leds has changed for newer full speed versions of slug (I'm running original one, expect that I turbo slugged it)..

But to change this behaviour, there's a file for configuring nslu2events in config folder in etc.. And to lid light for disk-1 is in local.start or something like that in init.d.. Can't check right now since I'm @ my gf's apartment and she's not gonna be happy if I turn her laptop into a board of development

Things look a bit different than I expected. I am now sure that /etc/init.d/nslu2init was *not* loading the modules on my machine. At this point the modules are already loaded on my slug (I dumped the output of lsmod from within /etc/init.d/nslu2init, just before the first modprobe). It seems that the modules are loaded before this init is run (contrary to what I assumed). So the contents of my /etc/modules.autoload.d/kernel-2.6 takes precendence.

I believe this file was empty on the initial image, but I might have added the ixp modules to it following howto's on wikis. Normally adding modules twice does not hurt, so I though I can do it without testing (at least I guess I could have thought that). Obviously this is bad if we need to load firmware before the ixp400_eth modules is load (do we?).

I removed the two modules from autoload and I think this should solve the problem of error message in line 27. Jackal, can you check what is in your /etc/modules.autoload.d/kernel-2.6 file, remove ixp modules if found, and report whether the error in firmware uploading has disappeared (using your serial console)?

However this still does not help with getting eth0 to work on my slug. Still eth2 is the only interface that shows up in ifconfig.

How about you try to remove references to eth0 completely and swap it to eth2?
You know it ain't requirement to call it eth0, on my slug, it originally is called ixp4xx_eth0, so that's why I aliased it as eth0, I could had aliased it eth2 or eth99 But for clarity I named it eth0.. But as you know, name doesn't blame man..

But dropbear, and other servers might be failing as there are references to eth0 and it has failed to start. I am pretty sure, that if you check dropbear file under /etc/init.d, you WILL notice that it says that it's dependant of /etc/init.d/net.eth0, change that in there to eth2 too... Actually, don't change first anything else expect requirement for dropbear. Keep your SYSTEM files as they are if they load up eth2 and it gets ip from dhcp..

Then if this lets you get in with ssh, check your other files under /etc/init.d and check if these files REQUIRE net.eth0 and change this.. once again to net.eth2, do NOT change everything too fast, I know it's pain in the ass to boot it again and again, but to take gentooslug working on these older slugs.. It took almost year for me to success this far and it's been a huge project.. But speeding up things in this phase isn't a good thing as human mind propably won't remember all changes it wanted to made.. Baby steps.. One step takes you closer to success on every boot. Good luck..

How about you try to remove references to eth0 completely and swap it to eth2?
You know it ain't requirement to call it eth0, on my slug, it originally is called ixp4xx_eth0, so that's why I aliased it as eth0, I could had aliased it eth2 or eth99 But for clarity I named it eth0.. But as you know, name doesn't blame man..

I kind of know that and exactly this makes me worried about this eth2 business. Aliases and all references are to eth0 as in your image (this is your image!). No single mention of eth2 anywhere and still it shows up, while eth0 does not. I can't sleep if I see things like that

But dropbear, and other servers might be failing as there are references to eth0 and it has failed to start. I am pretty sure, that if you check dropbear file under /etc/init.d, you WILL notice that it says that it's dependant of /etc/init.d/net.eth0, change that in there to eth2 too... Actually, don't change first anything else expect requirement for dropbear. Keep your SYSTEM files as they are if they load up eth2 and it gets ip from dhcp..

Actually dropbear has no references to net.eth0. It has "need net" instead...

Jackal, can you check what is in your /etc/modules.autoload.d/kernel-2.6 file, remove ixp modules if found, and report whether the error in firmware uploading has disappeared (using your serial console)?

Unfortunately I haven't got a serial console on my NSLU2 but my /etc/modules.autoload.d/kernel-2.6 is empty (no modules being loaded)!

I'll have a go at removing "alias eth0" when I get the time, at the moment I'm sluggishly compiling things on my NSLU2..._________________"Expect nothing. That way you will be ready for anything - Virginia Viadura"

Hmm... just asking because something must rename it to eth2 and I can see enything like that in /etc/modules.d/aliases.
In fact I have removed contents of the whole directory, which should give me vanilla not renamed device names. Somehow it does not help. I still see eth2 instead of ixp0. Really puzzled.

Misteriously my slug has booted now with eth2 and the ssh server went up for the first time. I am afraid to reboot it though as I fear that the result is random. Probably it depends on whether dropbear is activated before eth2 finished initialization, or while it is still doing it. I am annoyed by so much nondeterminism.

I removed the alias of the module ixp400_eth to eth0 (in /etc/modules.d/eth0), rebooted and it made no difference at all. Somehow ixp400_eth maps itself to eth2 regardless of any options given to it when loading the modules. I did notice that when I had "alias eth0 ixp400_eth", dmesg output reported something along the lines of "ixp400_eth: Activating Interface (eth2)" (can't be sure now as it now doesn't show up).

I can also confirm that my NSLU2 hasn't got the LEDs for both disks switched, I've got my external HDD plugged into the lower USB port and the "Disk 2" LED lights up as it should.

Btw, my NSLU2 was manufactured 05/2006.

Is it just me or does the NSLU2 takge ages to boot?_________________"Expect nothing. That way you will be ready for anything - Virginia Viadura"

I removed the alias of the module ixp400_eth to eth0 (in /etc/modules.d/eth0), rebooted and it made no difference at all. Somehow ixp400_eth maps itself to eth2 regardless of any options given to it when loading the modules. I did notice that when I had "alias eth0 ixp400_eth", dmesg output reported something along the lines of "ixp400_eth: Activating Interface (eth2)" (can't be sure now as it now doesn't show up).

This is also my experience. It is weird though, as Jake seems to be using the very same module.

Quote:

I can also confirm that my NSLU2 hasn't got the LEDs for both disks switched, I've got my external HDD plugged into the lower USB port and the "Disk 2" LED lights up as it should.

Interesting: lower port on my slug is definitely labeled "Disk 1" . I also have my drive plugged into this lower port, and the disk-2 label is on, so may be labeling of ports has been messed up on my slug?

Quote:

Is it just me or does the NSLU2 takge ages to boot?

It does. However I have not looked into optimizing the boot process yet.

I removed the alias of the module ixp400_eth to eth0 (in /etc/modules.d/eth0), rebooted and it made no difference at all. Somehow ixp400_eth maps itself to eth2 regardless of any options given to it when loading the modules. I did notice that when I had "alias eth0 ixp400_eth", dmesg output reported something along the lines of "ixp400_eth: Activating Interface (eth2)" (can't be sure now as it now doesn't show up).

This is also my experience. It is weird though, as Jake seems to be using the very same module.

Quote:

I can also confirm that my NSLU2 hasn't got the LEDs for both disks switched, I've got my external HDD plugged into the lower USB port and the "Disk 2" LED lights up as it should.

Interesting: lower port on my slug is definitely labeled "Disk 1" . I also have my drive plugged into this lower port, and the disk-2 label is on, so may be labeling of ports has been messed up on my slug?

Quote:

Is it just me or does the NSLU2 takge ages to boot?

It does. However I have not looked into optimizing the boot process yet.

This led issue is actually a filed bug in kernel by nslu2-linux/slugos/openslug team. There's a lot of interested information in nslu2-linux yahoo groups, this will also be fixed to openslug4..

What about changing files to use eth2 instead of eth0 in init.d? (rename net.eth0 to net.eth2 and so on)
Is eth2 able to get ip from dhcp? Can dropbear use eth2 instead of eth0?

What about changing files to use eth2 instead of eth0 in init.d? (rename net.eth0 to net.eth2 and so on)
Is eth2 able to get ip from dhcp? Can dropbear use eth2 instead of eth0?

In fact I've just symlinked net.eth2 to net.lo and removed net.eth0 from the default runlevel! Dropbear uses net.eth2 without any problem whatsoever as dropbear requires "net" which net.eth2 provides as its a symlink to "net.lo"._________________"Expect nothing. That way you will be ready for anything - Virginia Viadura"

What about changing files to use eth2 instead of eth0 in init.d? (rename net.eth0 to net.eth2 and so on)
Is eth2 able to get ip from dhcp? Can dropbear use eth2 instead of eth0?

In fact I've just symlinked net.eth2 to net.lo and removed net.eth0 from the default runlevel! Dropbear uses net.eth2 without any problem whatsoever as dropbear requires "net" which net.eth2 provides as its a symlink to "net.lo".

This is only partly true. I did the same and the outcome is nondeterministic. Dropbear refuses to work when the net is not up at the point it is started. I do not understand why the rc system attempts this before the net script has completed. I checked that the parallel startup is off.

As for using this as a permanent solution: sorry, I am not satisfied. There is a bug somewhere in the image. Openslug has no problem with this interface, running the same kernel. I can't just ignore the fact that there is a bug that we cannot diagnose

One other thing, I frequently get I/O errors when attempting to write to my USB HDD, which means the root filesystem gets re-mounted as read-only....this usually means shutting down the NSLU2, running fsck on the affected partition (/dev/sda1) and then booting into Gentoo/SLUG again.

This only happens when compiling some packages, for example distcc, courier-authlib and iptables. Although, several frustated attempts at compiling indicate that this happens at random within a compile.

Would this indicate overheating of the USB enclosure's bridge, the HDD or would it be just the NSLU2 not being able to cope with the high stresses of compiling?_________________"Expect nothing. That way you will be ready for anything - Virginia Viadura"