I installed SVN+SSH; it worked right out of the apt-get box as far as I can remember. The default repository location is under /var/local/svn/... in the root filesystem (an 8G Flash SDHC 6 card on mine). Of course, imagining I'm going to pound my CF with my svn activity (hah) I HAD to move it to a huge spinning disk.

I set up a mount point to an external HDD, and created a "var/local" path under the drive's mount point (imitating the default path mostly to avoid getting confused later). Then I prepended the mount point path to the default "var/local/svn/..." path specified in  /etc/xinetd.d/svn, rebooted, and it was ready to go.

I moved the lighthttp and mysql data directories over to that drive's var/local also; mysql was a PITA because you also have to edit apparmor files.

This will sound idiotic but you might try using another USB cable or at least verify that the cable you're using works with other things.

I managed to bring a USB drive back to life recently that had been "dead" for years. It was the stupid cable the whole time. And it did work initially, long enough for me to back everything up onto the drive before it went limp.

Now Marvell, OTOH, seems to have shipped me an OK USB cord. But my plug only worked for a little while, before it just died. That drove me nuts for a few minutes until I realized it powered up when plugged directly into an oulet. The AC cord they gave me for this thing failed after several hours of use!

Oh well, it looks sexier plugged into the wall anyway- otherwise what's the point! 

Hmmm... it seems I hit Ctrl instead of Shift while typing and all that crap got posted before I finished.

I was going to say you could do all this stuff with no SD cards, just a single USB drive (or SD)- loosely following the first half of the FAQ, the second half, then the first half again only backwards. Copy the NAND onto the USB drive. Take the drive to the second plug, move USB ahead of NAND in boot order there, boot up into your USB drive, mount the NAND from its /dev handle to some mount point in your filesystem, then blow everything away on the NAND before copying the whole USB root folder and its /dev back into the NAND. If you aren't going to have bootable USB drives attached to your cloned plug, you can unplug the USB at this point and you're finished, otherwise go to uboot again and undo what you did before so that the NAND is prioritized.

Maybe the installer's really nice and it's easier just to repeat what you did in the UI each time, who knows.

I haven't used the installer, so I'm not sure what's going on with your current configuration. But nobody's answered you yet so here's a low quality response on how to .tar.gz a root folder.

In general if you're trying to archive a filesystem with tar, what you want to do is something like

tar -cX my_rootfs.tar.gz / | gzip -c > ./my_rootfs.tar.gz

The "X my_rootfs.tar.gz" part is an exclude filter to avoid trouble when tar encounters the ultimate my_rootfs.tar.gz file that gzip is streaming to the disk within the same process. It's just to be safe; I'm not sure if that's an issue or not.

Keep in mind tar isn't really good for this because it doesn't include the /dev directory. I don't know if that's a problem for what you're trying to do. Maybe you haven't messed with it at this point.

If you're into cloning plugs and don't mind spending a few bucks extra per plug (plus having something sticking out of it), a better approach is probably just to buy an SD card for each plug, copy your root folder from the NAND into each SD card, and then have all of them boot from the SD. You'd basically be following the first half of the instructions in this FAQ:

http://www.openplug.org/plugwiki/index.php/SD_Card_As_Root_File_System#Create_a_bootable_file_system_on_the_SD_card

On the source plug (after messing around in the NAND filesystem as needed) you would mount the SD as /dev/sda1 and copy your root filesystem recursively starting with / from the NAND into the mount point, using cp -ax. Then copy the /dev folder (without the -x argument) to the mount point. Unplug, pop out the SD card, put a new one back in, plug, fdisk (using ext2), mkdir, mkfs, mount, cp -ax, cp -a, repeat. Pump out as many SD cards as you need for all your plugs.

Now you've got to have them all boot off the SD cards, maybe including your source plug if you have an SD for it, so follow the second batch of instructions:

http://www.openplug.org/plugwiki/index.php/SD_Card_As_Root_File_System#Booting_from_the_SD_Card

You have to screw with uboot on each plug to prioritize the SD card over the NAND when booting. Plug your USB into the little slave USB port, run whatever unpleasant USB-serial drivers / terminal stuff you need to on the host system, reboot the card from SSH using shutdown -r now, hit ENTER like it says, and get to the Marvell>> prompt. (Make sure you can do this before buying 10 SD cards off Amazon.) Edit the bootargs variable as described, on each plug, then plug them all in and you've got cloned plugs with filesystems on SD instead of NAND.

Lots of people have trouble with certain cards. I used a Kingston 8GB SDHC

I searched around to figure out how to tune Linux networking parameters. Every HOWTO I find says you shouldn't mess with anything if TCP autotuning is set, which it is for kernels past 2.6.7, because then it's working perfectly:

root@debian:~# cat /proc/sys/net/ipv4/tcp_moderate_rcvbuf
1
root@debian:~# uname -a
Linux debian 2.6.22.18 #1 Thu Mar 19 14:46:22 IST 2009 armv5tejl GNU/Linux

So this is apparently as fast as it will go. No problems with any other machine on this LAN, just the plug. Is it a limitation of the harware? Are these plugs seriously going to run at 400 kb/sec with a 7 ms latency even on a 54Mbps LAN? I wish knew that when I bought one.

This web server was set up this weekend so the image URL might break.

This is booting off the SDIO card sticking out at the right and the USB is heading off to an external drive. The ethernet port is bright as hell, isn't it?

I plugged it into a power meter and got readings of 3-4 watts, usually 3. I thought they were lying when they said roughly five.

I bought a Kingston 8 GB SDHC Class 6 Flash Memory Card and moved my root filesystem onto it; no problems. 

The router is an old Netgear FWG114P 802.11g I've had for five years; it doesn't support QOS.

It resides at 192.168.0.1 and hands out DHCP addresses starting at 192.168.0.2 (to two laptops). The plug is at 192.168.0.8 which the router reserves for the plug's MAC. The plug is responding to pings with a latency between 1 and 8 ms. This is the routing table on the plug:

Kernel IP routing table
Destination      Gateway         Genmask            Flags Metric Ref    Use Iface
192.168.0.0     *                     255.255.255.0   U        0        0        0 eth0
default             192.168.0.1    0.0.0.0               UG     100     0        0 eth0


Meanwhile this is what the Netgear is reporting:
Destination            Mask                      Gateway               Metric  Active
default                   ---                          24.130.23.218      1          yes
24.130.20.0           255.255.252.0       24.130.23.218      1          yes
192.168.0.0           255.255.255.0       192.168.0.1          1          yes
192.168.0.1           255.255.255.255   192.168.0.1          1          yes
24.130.23.218       255.255.255.255   24.130.23.218      1          yes

And running tracepath locally on this laptop:

user@t60:~$  tracepath 192.168.0.8
  1:  t60.local            (192.168.232.135)  1.375ms pmtu 1500
  1:  192.168.232.2  (192.168.232.2)      0.280ms
  1:  192.168.232.2  (192.168.232.2)      0.252ms
  2:  192.168.0.8      (192.168.0.8 )         7.207ms reached
       Resume: pmtu 1500 hops 2 back 128

I have a brand new SheevaPlug running the default Ubuntu install (with root filesystem transferred to SDIO), plugged directly into a Netgear 802.11g router.

Network transfers to the plug from any machine on the local network are really slow, usually less than 1 MB/s. Everything is slow- FTP, HTTP, Samba, etc. Other machines on the network appear to be going at normal 802.11g speeds. Anyone have any ideas?

Everything works, and is still usable, just really slow.

Yep Sheeva Christmas is here.    Ordered May 3, received June 5.

Since we all received the same shipment of these things we should probably try to remember each others' names.