The future of the NSLU2-Linux project - your input is required!
We find ourselves at a juncture where the project's core team needs to
decide where it is going to focus its developer resources going forward.
The core team is looking for your input (yes, all 5000 of you) to help
us make a decision about which firmware should continue to be officially
supported with binary images and pre-built package feeds, and which
should be only maintained at the source code level by interested
developers. Note that supporting a binary image and corresponding
package feeds is a large effort, both in developer time, and in hardware
and network resources. Please read this message carefully, and post
your feedback to the nslu2-linux mailing list. If necessary, we may set
up a poll to formally judge the response of the community.
Firstly, there is Unslung. It is not in danger of being replaced by
anything else, and will continue to remain and be updated as long as
there are Unslung firmware developers (such as mwester and marceln who
have recently stepped forward) and Optware/NSLU2 package maintainers (88
of them registered on sf.net/projects/nslu, and Josh Parsons doing a
great job of overseeing them) willing to support it. We have released 7
Unslung beta versions (with Unslung 6.x in alpha testing now), and there
have been over 15000 downloads of the latest Unslung-5.5-beta binary
image. There are over 400 Optware/NSLU2 packages available today (not
counting Unslung kernel module packages).
If you really only care about using the Unslung firmware, then you can
breathe a sigh of relief and stop reading here if you like :-)
Next there is UcSlugC, which is designed to be the basis of "turnkey"
flash-only NSLU2 applications (i.e. a dedicated pre-configured device
for a particular purpose, with no hard disk or flash disk attached).
John Bowler continues to develop this firmware variant, and I expect it
will continue for as long as he is willing to support it. As there is
no binary image available (it's meant to be the basis of such an image,
not an image in itself), it's hard to judge how widespread the use of
this variant is (as we can't just count downloads of the binary image).
Note that it is not possible to use UcSlugC to debootstrap into Debian.
Then we have the whole
OpenSlug/DebianSlug/OpenDebianSlug/LeSlug/LeDebianSlug melting pot.
This is the bit which we need to clean up and focus.
Historically, we had OpenSlug which was defined to be a combination of
the latest linux kernel, and the latest OpenEmbedded rootfs and
packages, compiled for big-endian arm. We have released 4 OpenSlug beta
versions (with OpenSlug 3.x in alpha testing now), and there have been
about 2000 downloads of the latest OpenSlug-2.7-beta binary image.
There are over 200 OpenSlug packages available today (there are actually
over 3000 ipks in the feed, but over 800 of these are Perl modules,
almost 300 of these are kernel modules, and locales form a large part of
the rest), and there are many other OpenEmbedded packages which are
candidate OpenSlug packages (they just have to be verified to build and
then added to the feed list).
Then Peter Korsgaard worked out how to get a slug to boot Debian in
little-endian mode (albeit requiring a serial port and an external USB
ethernet adapter). This technique could take advantage of the existing
Debian arm port (and its 14000+ packages). We have no way of knowing
how many people have gone down this path. The only problem was that we
could not build the drivers for the internal ethernet interface in
little-endian mode, which meant that you needed an external USB ethernet
adapter to use this method. There was no simple single binary image
released for this variant.
Then Lennert Buytenhek ported enough Debian sarge packages to big-endian
arm to enable "OpenDebianSlug" (which consists of installing the
standard OpenSlug binary image, and pivoting to an external Debian
rootfs). It is possible to boot OpenDebianSlug without a serial port
and with no additional hardware required. Lennert and Derek Young have
since built over 13000 packages from the Debian sarge (stable)
distribution for big-endian arm (available at
http://debian.nslu2-linux.org/sarge/debian). According to
http://www.debonaras.org/wiki/Info/OpenDebianSlugUsers we have at least
70 people using OpenDebianSlug.
Then a number of people working together solved the little-endian
internal ethernet driver problem, but nothing was done with that
achievement for a while (other than proving it could be done and that it
Around that same time, we convinced a couple of influential Debian
Developers to help us set up some machines to build the Debian sid
(unstable) set of packages. The project donated two slugs for this
purpose (Bob and Wendy) and those slugs have currently built just over
10% of Debian unstable. It is unknown whether two slugs are enough to
keep up with the continual changes in Debian unstable in the long run.
Those packages can be found at http://armeb.debian.net/debian-armeb/ and
can be used with OpenDebianSlug.
Just recently I added the "LeSlug" variant to the mix. This is a
little-endian version of OpenSlug (identical to OpenSlug in all other
respects) which can debootstrap Debian sarge or Debian sid onto an
external hard disk, and which can directly use the existing
little-endian arm port of Debian (including all 14000+ packages). It
does not require either a serial port or any additional hardware. If
there was sufficient demand, a binary image could be made available in
exactly the same way that the OpenSlug binary image is made available,
and a LeSlug package feed has already been populated with all OpenSlug
packages (and will continue to be automatically kept up to date with
OpenSlug and UcSlugC by our build host).
Thanks to a lot of work by John Bowler and Alessandro Zummo, we are
currently pushing patches upstream to support the NSLU2 in the standard
Linux kernel. We are also pushing patches for the Iomega NAS 100d
I have recently started to engage with the debian-kernel and
debian-installer teams, to work out how to incorporate NSLU2 support
into the Debian kernel and the Debian installer. This is at an early
stage, and we need to work out where we focus our efforts here too (i.e.
do we focus on getting the nslu2 into the existing little-endian arm
ixp4xx kernel, or do we try and get a new armeb architecture supported
in Debian, or do we do both?).
This email is long enough already, so please read and digest this, and I
will follow up with another email giving a set of options for the future
of NSLU2-Linux ...
(In the interim, please feel free to discuss this here in the
nslu2-linux mailing list)
-- Rod (NSLU2-Linux Project Lead)
On 1/31/06, John Bowler <jbowler@...> wrote:
> From: Adrian Day
> >Running 'ls -lR /' will lock a ssh session.
> Well, can you still ping the slug? (I.e. does it still
> respond to ping?)
> I've never managed to lock a system (i.e. a hard kernel lock
> or a crash) by doing that, or the pretty much identical
> command "find /", and I do it quite a lot (it's a quick and
> easy way of getting CPU load).
> What gets locked exactly? Assuming the ping doesn't respond,
> does the power button work? What if you run a shell script to
> toggle the disk 1 led on/off:
> while true; do echo -n 100 >/sys/class/leds/disk-1/brightness; sleep 1; echo -n 0 >/sys/class/leds/disk-1/brightness; sleep 1; done
> Does that keep going? (Running in another ssh session). What
> happens when the LED is being made to flash from the kernel:
> echo timer >/sys/class/leds/disk-1/trigger
> echo 1000 >/sys/class/leds/disk-1/frequency
> Does it lock up then? (That would indicate a kernel crash).
It's definitely not a kernel crash. It just kills the current ssh
session. I'm at work now but will attempt to delve a little deeper
into this when I get home. I'm not alone - Jean Fabrice has
experienced similar problems - I'd posted something about this a week
or so back.
Like I said, I'll spend some time looking into this in more detail.
It's the least I can do compared to the considerable effort you and
others have put into the slug.