I opened up the serial console (while the plug was still in the messed-up state) and got this:

[2061996.143493] EXT3-fs error (device sda2): ext3_find_entry: reading directory #1183320 offset 0
[2061996.152312] EXT3-fs error (device sda2): ext3_find_entry: reading directory #1183225 offset 0
[2061996.162646] Read-error on swap-device (8:0:44040)                                     
[2061996.177952] Kernel panic - not syncing: Attempted to kill init!
[2061996.184174] [<c002d0b8>] (unwind_backtrace+0x0/0xdc) from [<c02b3f20>] (panic+0x34/0x128)
[2061996.192571] [<c02b3f20>] (panic+0x34/0x128) from [<c004777c>] (do_exit+0x6c/0x64c)
[2061996.200372] [<c004777c>] (do_exit+0x6c/0x64c) from [<c0047de4>] (do_group_exit+0x88/0xbc)
[2061996.208788] [<c0047de4>] (do_group_exit+0x88/0xbc) from [<c0054d7c>] (get_signal_to_deliver+0x2f4/0x330)
[2061996.218508] [<c0054d7c>] (get_signal_to_deliver+0x2f4/0x330) from [<c0029590>] (do_notify_resume+0x70/0x604)
[2061996.228578] [<c0029590>] (do_notify_resume+0x70/0x604) from [<c0026ee8>] (work_pending+0x1c/0x20)

The system logs didn't look to have anything relevant once I rebooted the plug.

I've got my plug booting completely off an external USB drive (both root directory and kernel) running Debian Squeeze.  The problem is that occasionally, maybe once every two weeks, the USB mount seems to fail out of nowhere.  When this happens, the plug still respond to pings normally, but I can no longer SSH into it (I just get ssh_exchange_identification: Connection closed by remote host), and while Apache remains active, every request returns a 403 Forbidden, presumably because the plug can't access anything on the filesystem.  Whenever this happens, I reboot the plug by hand and everything comes back up (until the next time it happens).

This is annoying for two primary reasons: one, I have no idea why it's happening, and two, when it happens, I have no way to remotely reboot, since I can't get a shell.  Anyone have any ideas as to why it might be happening or what I could try to deal with it?

I'm currently running an NFS server on my SheevaPlug to several Mac OS X clients.  I've set it up so that everything maps to a single user on the plug (so basically world-writable by everybody, which is okay since it's just my LAN) -- if you think this setup would work for you I can give you the details on getting Mac OS X to cooperate.

This is what I'm running right now:


So assuming the 2nd partition is the root partition on your SD card, you can run:

Yes, I thought that looked suspicious too.  I installed via the Debian installer, exactly following the online instructions, and had no problems with the installation whatsoever.

EDIT: Okay, that was the problem.  I added root=/dev/mmcblk0p2 to the bootcmd and everything is working now.  Thanks!

Perhaps I wasn't clear in my earlier post -- I have TWO plugs, the first of which I set up awhile ago booting off USB and is completely fine.  I just got my second plug and have been trying to set it up using an SD card, during which I've run into this problem.  I've never booted this second plug off USB.  Do I need to explicitly set root= in uboot?  I got the plug from someone else, so it's possible there are leftover values in uboot.  Below is my env:

Sorry to resurrect an old topic, but I'm having this same problem and can't for the life of me get past it.  I've tripled checked my commands, run the installer multiple times, and everything always goes smoothly until I try to boot, at which point I get


I've installed everything onto a 4 gig SD card.  Any ideas?

EDIT: I'm running u-boot 3.4.27 pingtoo patch.01, which I've been running without issue on my other plug off a USB drive, but this is my first time trying to boot off an SD card.

EDIT 2: Here's what I get from fdisk when I plug the SD card into my desktop (the partitions mount normally and I can see the Debian installation just fine):

Stable as in working 100% of the time?  I don't think it exists.  I'm booting from a usb HD and I'm currently using 3.4.27 with pingtoo's patch (the latest version that I'm aware of) and was previously using 3.4.19.  I still have to muck around with running reset in u-boot and possibly plugging and unplugging my hard drive to get the thing to boot whenever my plug needs a reboot.  It's a pain in the neck, but since I rarely have to reboot the plug it hasn't stopped me from booting off my HD.  As far as booting from a USB HD is concerned, I haven't noticed much difference between 3.4.19 and 3.4.27.

I ended up not finding any 'nice' solution, but was able to manually compile the library by hand-editing the generated config file and cutting out configure and make entirely.  Forked-daapd is now running nicely on my plug.  In case anyone else runs into this issue, I wrote up all the gory details on fixing this at http://blog.zortrium.net/archives/7.

I think the problem may actually be related to the weird configure line I noted in my first post.  In the configure script, that line is just which expands to a bunch of standard #include lines.  In the configure script, that variable is just executed as a bash command, which obviously does nothing because #include isn't a bash command.  The next thing the configure script does is check for some other standard header files -- it claims they aren't there, but it's wrong because they're all sitting in /usr/include right where they should be. Notably, every one of the header file checks BEFORE the failing $ac_includes_default succeed, and every one after fails.  The configure script is incredibly obtuse, so I'm not sure what to do with it.  I tried compiling on my laptop, and I also got the '#include: command not found' output from configure, but it still managed to find the header files directly afterwards and the make subsequently succeeded.

Here's lines 210 to 214:

Hi all,

I set up mt-daapd on my plug (running Debian Lenny) without any problems, but I was annoyed by its lack of updates and functionality for streaming video.  It looked like forked-daapd (http://blog.technologeek.org/2009/06/12/217) would fix some of these problems, so I tried following the instructions at http://ubuntuforums.org/showthread.php?t=1354196 to compile it.

The problem is compiling the C bindings for ANTLR.  These don't seem to be packaged anywhere for Debian, so I grabbed the sources and tried compiling.  The ./configure ran without complaining, but the first problem I ran into was the compiler flags generated:


Trying a make quickly resulted in a 'cc1: error: unrecognized command line option "-m32"' error.  From what I've read, this flag is irrelevant and useless on ARM (since it's all 32 bit anyways), so I hand-edited the makefile generated by configure and removed -m32 from the flags.  I then tried compiling again and got the following error, which I can't make heads or tails of:


At this point I'm pretty much stuck.  The only other suspicious-looking output from configure was './configure: line 19707: #include: command not found', which appeared in the middle of the checks and didn't seem to cause anything else to complain.

Any advice would be appreciated.  Documentation both on forked-daapd and libantlr3c seems to be quite sparse, so I'm not sure what to try.

The patches seem to be mostly related to SD card issues -- do they do anything else?  I'm presently using a custom 2.6.32.3 kernel I compiled from the unmodified kernel.org sources and wanted to make sure I'm not missing anything important (I'm booting off USB rather than SD, so I don't need those tweaks).

I rebuilt my kernel and made sure all modules were compiled directly in, then changed my rootdelay=10 to rootwait.  Not sure exactly what the previous issue was, but it worked on the first try and booted my new kernel just fine.  Thanks again pingtoo.

Marvell>> version

U-Boot 1.1.4 (Jul 19 2009 - 16:03:28) Marvell version: 3.4.19
Marvell>> printenv
baudrate=115200
loads_echo=0
rootpath=/mnt/ARM_FS/
netmask=255.255.0.0
console=a0000
e=ttyS0,115200
CASset=min
MALLOC_len=1
ethprime=egiga0
ethmtu=1500
usb0Mode=host
nandEcc=1bit
ethact=egiga0
serverip=10.10.0.2
ipaddr=10.10.0.1
cesvcid=ULULULULULULPPULULULULULDA
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); boot;
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
yuk_ethaddr=00:00:00:EE:51:81
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
run_diag=no
bootargs=console=ttyS0,115200 mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/mtdblock1 rw ip=10.4.50.4:10.4.50.5:10.e
ethaddr=00:50:43:01:40:AA
arcNumber=2097
bootargs_nand=console=ttyS0,115200 mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/mtdblock1 rw ip=10.4.50.4:10.4.50.e
bootcmd_nand=nand read.e 0x800000 0x100000 0x400000; bootm 0x800000
bootargs_console=console=ttyS0,115200
bootargs_root=root=/dev/sda2 rootdelay=10
bootcmd_usb=usb start; ext2load usb 0:1 0x0800000 /uImage
bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_usb; bootm 0x0800000; reset
stdin=serial
stdout=serial
stderr=serial
nandEnvBase=a0000
mainlineLinux=yes
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootdelay=3
disaMvPnp=no
enaAutoRecovery=yes
pcieTune=no

Environment size: 1758/131068 bytes