Two New Dockstars Non-Responsive

I had just recently provisioned a Dockstar using Jeff's script and then after it failed for the debootstrap problem, using shyd's script referenced here. Was very happy with the results, and needing several more low-power platforms, bought several more new Dockstars. I used the same approach as the first one and after the script finished successfully and rebooted, it was unresponsive. It appears to boot from the USB disk (FreeAgent GO drive like the first successful install) as the LED stops blinking and it accesses the drive during boot, but my DHCP server never displays an IP address for it. Further, it momentarily obtains the original IP of the Pogoplug kernel, yet if I ping it or try to ssh into it, the host is not reachable (ARP not responsive). I then mounted the Go drive on my linux desktop and changed the network setup to a static IP address to remove that variable. Still no dice. If I boot the Dockstar without the Go drive it alternates green and yellow blinking forever.

I then decided that Dockstar had corrupted uboot environment or kernel image so I ordered a CA-42 cable on ebay and set about trying the second new Dockstar. Same story.

I know it will be obvious once I have a serial console for uboot, but I'm beginning to wonder if there is a problem with the kirkwood kernel image being downloaded by the script. Has anyone else seen this behavior or have any insight as to what is going on? It's going to take a week to get that darn cable and I am impatient!

Thanks in advance.

I second this. I'm having the same issue.

Yes. I had the same problem. Fortunately, I backed up my previous installations. When use the ones backed up a few months ago, every thing were just fine. However, if I do a upgrade or dist-upgrade, it became unresponsive. I have not used the serial cable to check what's wrong yet.



Edited 2 time(s). Last edit at 07/02/2011 07:43PM by twinclouds.

You mean a back up of the /dev/sda1 disk image or of the uboot image and/or environment? I have tried my working disk image from the first dockstar on the second dockstar but it behaves in the same way. That's what led me to believe it was an issue with something in flash (uboot or environment).



Edited 1 time(s). Last edit at 07/02/2011 07:45PM by mteel.

I only used /dev/sda1 disk image on my Dockstars, which have been working fine before. I don't see any issues. If you can still boot into the Pugoplug, you can try to install the Lenny first to see if it works. I never have problem with the Lenny installation. If Lenny works but stop working after upgrade, then it is the Squeeze problem. Otherwise, it might be the uboot problem.

Some little notes from my debian squeeze install docs:
-------------- snip -------------
Do check the contents of /boot. Do it after every apt-get update; apt-get upgrade. Have the timestamps changed? Any file new? Maybe the directory? Did the update process spout lines about initramfs or the kernel? Yes? Then look closely: /boot/uImage and /boot/uInitrd must be in sync with the other files. Sometimes they are, sometimes they are not. If not, the system will not boot. If you want to be or just make sure, run the following lines:

/usr/bin/mkimage -A arm -O linux -T kernel  -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-5 -d /boot/vmlinuz-2.6.32-5-kirkwood /boot/uImage
/usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/initrd.img-2.6.32-5-kirkwood /boot/uInitrd

-------------- snip -------------

Moving the usb stick from dockstar to dockstar will not work (network wise,) unless you add the following line to rc.local

ifconfig eth0 > /dev/null
if [ $? != 0 -a -f /etc/udev/rules.d/70-persistent-net.rules ]; then
    rm /etc/udev/rules.d/70-persistent-net.rules
    reboot;
    exit 1
fi

Without this debian will create a eth1 device instead of a eth0 since the mac address changed, and everything will go bonkers, more or less.

bastel:
Thanks.
I have already removed two files:

/etc/udev/rules.d/70-persistent-net.rules
/lib/udev/rules.d/75-persistent-net-generator.rules

in my previous backed up USB images so they will work on any Dockstar. After upgrade, these files were reinstalled. The easiest way is to remove or rename them to something else. I don't know if there will be any problem without these two files.

I was able to resolve my problem by removing the entries in 70-persistent-net.rules file. I don't know why I didn't think of that before. Works for me now. Thanks!

Hey bastel, thanks. I like your rc.local script. I'm definitely going to use it. I worked around this by modifying 75-persistent-net-generator.rules, commenting out the line that executes write_net_rules. But I prefer to leave the base debian installation as un-altered as possible.

I tried your script as-is but it didn't work. It wouldn't capture ifconfig's exit status of 1. I don't know why. I could clearly see the exit status was 1 when testing it in my bash shell. I experimented with a few variations and wound up rewriting the test a bit differently, but it works. Here's my rc.local:

echo none > /sys/class/leds/dockstar\:orange\:misc/trigger
echo default-on > /sys/class/leds/dockstar\:green\:health/trigger

# if eth0 doesn't exist,
# its likely because of a stale persistent network rule
if [ x"$(ifconfig | grep eth0)" = x"" ]
then
  # use orange led as a visual indicator
  echo timer > /sys/class/leds/dockstar\:orange\:misc/trigger
  echo 100 > /sys/class/leds/dockstar\:orange\:misc/delay_on
  echo 200 > /sys/class/leds/dockstar\:orange\:misc/delay_off
  rm -f /etc/udev/rules.d/70-persistent-net.rules
  sleep 30
  reboot
  exit 1
fi

exit 0

I tested this a few times, moving it between two different dockstars, and it worked every time. When it can't find eth0, the orange led blinks over the green as a visual indicator of the problem and it reboots 30 seconds later.

It didn't work for me either. I simply deleted:

/etc/udev/rules.d/70-persistent-net.rules
/lib/udev/rules.d/75-persistent-net-generator.rules

and everything is fine then.

There's a few ways to skin this cat. I've honestly never had to swap my usb boot stick between my devices but its nice to have the option if something happens.

I did run into the issue though. I cloned my original stick to hack a second device. It's much faster. But when it wouldn't come up on the network, I remembered this. My fix was to modify /lib/udev/rules.d/75-persistent-net-generator.rules to prevent it from adding entries to /etc/udev/rules.d/70-persistent-net.rules. You're fix was to delete them entirely, but you found an update restored them.

I liked the intention of bastel's script as it would keep debian stock. It just needed a minor rewrite to accomplish the same thing. What I posted works. You just need the correct arcNumber to make the leds blink.

Strange that it didn't work. I am pretty sure it did work at my place.
Maybe the test should use -ne instead of != or "$?" != "0" ... dunno

Thanks for the tips on sharing disk images between dockstars.

After receiving the CA-42 cable and much consternation determining the RX, TX and GND wires on it (non-standard colors), I was able to communicate with the dockstar via serial. The output will stop if you don't periodically hit a key (as described in a different post) but otherwise it worked fine. The interesting thing is that with the serial cable attached the pogoplug kernel would boot up and obtain a DHCP address as expected. No serial, no DHCP. Of course I can't tell why that is when the serial cable is not attached...

The failure to boot from the USB Go drive was caused by a mismatch of reported superblocks on the drive's first partition. Again, not sure why that was, but once I had a pogoplug kernel running with an IP address I could reformat the boot partition of the Go drive and proceed as normal. Thus, I don't have an answer for why the process was failing for a few days there but it appears to be in good shape again now.

Aside: I also just received an RMA unit from Seagate that had the newer hbplug utility installed, the one that disables ssh if you kill it. To get around this I remounted the rootfs rw and moved the old hbplug (thankfully Seagate left it there) into place. It won't start dropbear at boot but it will not disable it when killed. I just started dropbear manually after the pogoplug kernel booted (all from the serial port of course) then ran the modified install script from an ssh session as usual. If you don't jump through these hoops, the install script will kill hbplug and you will lose ssh access to the dockstar shortly thereafter.