No green light at all

[kpaluch]

I have installed the appropriate archlinux arm software, along with LAMP and webmin and the ssl option for that.
Next I wget the pogoplug pro software, so I would be able to use the original services along with all the linux goodness. I followed the guide to the letter and everything seems fine. This morning I look at it and there is no external green light. I opened the case and I can see the ethernet lights up and there is a little blue light on the board itself that it solid on.

I've since realized that it's probably very important to mention I connected a sata drive to the pogo plug. It looks like that's the important detail. I will try hooking it up again and see if I can get the green light back on.

I don't know where to start troubleshooting this as I can't ssh into it. Is this bricked or is there something more I can do?

I will deeply appreciate any help any of you could give me.

Thanks!

[WarheadsSE]

Most likely, using the pogoplug software caused the glitch I warned about. Grab a copy of the 2012.05 rootfs (link in my upgrade notice) and put that on a usb stick with root privleges, and try booting again. The recent update nukes the first kernel image, and thus falls back to slot B, which is the old kernel as a backup

[kpaluch]

I tried doing exactly that. I took the USB memory stick out, put it in my SuSE machine, followed the fdisk instructions you provide in the guide, used mke2fs -t ext3 to make the file system, mounted it, cp the tarball to the USB stick, untarred and zipped it right on the root of the stick. umounted the usb stick, then powered off the Pogoplug, put the stick in the same USB slot as where it was when it stopped working after the cloudengines update posted elsewhere on this forum, and now there is no green light, the Pogo isn't pulling an address from my router and the only sign of life is the blink of the ethernet interface.

What could I try now? Did I follow the procedure properly? It seems simple enough, I did everything with the tarball as root on the SuSE machine. Any help would be much appreciated Warheads SE, since you are the resident Pogo Ninja. I thank you in advance.

[WarheadsSE]

Well... that is not good.

Serial console & SATA will win, but sounds like there is something bad in your NAND.

[kpaluch]

Actually I've been a bonehead that didn't learn my lesson. Ignore that first post. I got that working again. Then I wanted a fresh install because I didn't keep track of what I was doing and it got too complicated. So I popped the tarball on there and it worked fine... until I ran the cloudengines script, when it went down for reboot, it never came back up. Is this still a NAND issue, or is there something I can still do to get her up and running again?

I may have the option of exchanging this for another one since I've had it less than 30 days. I just hate giving up on the problem if I have the opportunity to learn something new. Thanks for all the help so far, you've been excellent. I will definitely donate as soon as I get a check.

Again, I don't know what I'd do without you.

Thanks,
Ken

[Geoff]

If you (still) have a non-bootable SATA HD attached, you won't be able to boot up from USB. You could just unplug the HD as a test of the bootable USB stick. Otherwise, you could make the first partition of the SATA HD bootable, just as you did with the USB flash drive. Better yet, you could bypass the NAND completely by installing the bootloader, kernel and rootfs all on the SATA HD, as explained here: viewtopic.php?f=29&t=2146

[kpaluch]

$this->bbcode_second_pass_quote('Geoff', 'I')f you (still) have a non-bootable SATA HD attached, you won't be able to boot up from USB. You could just unplug the HD as a test of the bootable USB stick. Otherwise, you could make the first partition of the SATA HD bootable, just as you did with the USB flash drive. Better yet, you could bypass the NAND completely by installing the bootloader, kernel and rootfs all on the SATA HD, as explained here: viewtopic.php?f=29&t=2146

[WarheadsSE]

The cloud engines stuff didn't do this, directly. An update routine in those scripts did that. Why it is failing without ever getting a light I cannot tell you.