Hi!

Check whether this command


yields 0 or 1. It should be 1.

Do this:


to enable ip forwarding.

This setting won't survive across reboots; for that, edit /etc/sysctl.conf, like this:


(See http://www.cyberciti.biz/tips/linux-as-router-for-dsl-t1-line-etc.html for reference).


Hope that it helps.

Cheers!


BTW, are you in Quito?

Hi.

Congrats!

To be sure about which Debian version is installed, simply do

$ cat /etc/debian_version

In order to backup the internal SD, I would remove it and read it in another computer (with GNU/Linux).

$ dd if=/dev/mmcblk0 of=dreamplug-rootfs.img bs=4M

should do the trick.  Note that the actual device name may vary.


Cheers,

pancho.

Hi!

Sounds like a case of stale proxy cache to me.

Try to determine if your ISP is forcing you through a web proxy.


Cheers,

Hi there.

It seems that the binary ‘mkimage’ is missing.


Try installing it:


Hope that it helps.

Happy hacking!

Hi there.

Try posting here the output of this command
$ dmesg

Maybe the kernel is not recognizing the ethernet card, or udev is renaming it
to another name (eth1?).

Cheers,

Hi there!


Try this:

$locate libftdi.so.1
/usr/lib/libftdi.so.1
/usr/lib/libftdi.so.1.17.0
$ ldd uboot/openocd/openocd
   linux-gate.so.1 =>  (0xf771b000)
   libdl.so.2 => /lib32/libdl.so.2 (0xf7700000)
   libftdi.so.1 => not found
   libusb-0.1.so.4 => /lib32/libusb-0.1.so.4 (0xf76f7000)
   libc.so.6 => /lib32/libc.so.6 (0xf75b3000)
   /lib/ld-linux.so.2 (0xf771c000)

The problem is that you (and me, and lots of users) are using an amd64 flavor of debian, and the opencd that is bundled with sheevaplug-installer-1.0 is built and linked against the i386 version.

For that to work you could edit 'runme.php' and change the path to use the debian-provided openocd, which you can install with:

To edit runme.php:


I know that since your SheevaPlug is in critical condition (won't say dead... yet) this is a bit pointless right now.  But let's hope for the best (or a replacement GuruPlug, at least).

Best of luck.

Cheers,

@tbm
Hi!

If I recall correctly, this issue is related to the crosscompiler toolchain.  For some reason, the one that pingtoo uses does the trick (in Gentoo, /methinks), but the one used by rooster does not.

Cheers,

pancho.

I don't know.  But the rootfs.tar.gz image that comes with SheevaPlug installer 1.0 has the setting OK.  Maybe it was wrong in the original image and then fixed it afterwards :-?

Hi, recursix.

The line:
openocd/openocd: error while loading shared libraries: libftdi.so.1: cannot open shared object file: No such file or directory

suggest that you have to install the missing library:
$ sudo aptitude install libftdi1

Hope that it helps.

Good luck with the PSU!

Happy hacking,

pancho.

Hi, recursix.

Have you tried to press the reset button?  I am not sure if it has any effect different from unplugging and replugging the whole SheevaPlug.  Can't hurt, though.

Regarding the USB port, what does the kernel say when you plug in the connector?  (the output of 'dmesg').

You could try also booting a debian-live system, to see if that one catches the usb connection right.
(http://debian-live.alioth.debian.org), to discard that ubuntu is somehow failing to detect it.

We understand your pain, buddy.

Best of luck,

pancho.

And not only compress them; it will remove old ones, too, preventing infinite growth.

Hi again, odoll.

I just noticed that your /etc/network/interfaces does not conform to current spec ($ man interfaces), around the 'iface lo inet loopback' line.
It seems that the lines:

address 127.0.0.1
netmask 255.0.0.0

are no longer necessary, and I wonder if that could cause the weird double route... It is a long shot, but maybe worth a try.

Good luck!

Hi, odoll.

If you had issues with the mac address, maybe udev messed things up with the ethernet interfaces.

Check the file /etc/udev/rules.d/70-persistent-net.rules and verify that no spurious mac addresses appear there.
[that is the path in debian, I don't have an ubuntu available but I think that they haven't changed it]

Hope that it helps this time too.

Cheers,

pancho.

Hi, fellas.

This is a common pitfall, that happens when we update u-boot on the sheevaplug.
The reason is that the u-boot binary has a built-in ethaddr variable.  If we use other people's builds of u-boot, and answer 'yes' to the question 'Override Env parameters? (y/n), we must subsequently update the ethaddr variable on the environment to reflect the actual MAC address of our SheevaPlug.

Marvell>> set ethaddr 00:00:DE:AD:BE:EF      # check the label on the back of your SheevaPlug for the actual value
Marvell>> saveenv

Hope that it helps.

Try the wiki.