POGO-P21 install worked; green light on reboot but no IP

[linuxizer]

I just received a POGO-P21 and followed the archlinux installation instructions. Got to step 12 without any trouble or error message. Rebooted the device, and now it won't come up.

Good news:

- When I power cycle the Pogoplug, the light stays off, then blinks green, then goes to steady green.
- If I clear ip dhcp binding 192.168.1.121 (the old IP), it immediately grabs a new IP from the router's DHCP server.

Bad news:

- I can't ping or ssh in to the Pogoplug.

~~~~~~~~~~~~~~~~~~~~~~~~~~

After that, I confirmed that the filesystem looked OK on the USB drive. Stumped, I used the "Help it stopped working!" instructions to format the drive as ext3 and uncompressed the tarball as root. I entered the MAC address into the appropriate file, cleanly umounted the USB drive, started up the Pogoplug, and....

Same thing. Turns on, network light blinks. Green light on the front flashes wildly, then goes steady green. But no SSH or pinging that IP address. This time it doesn't even request an IP from the DHCP server.

~~~~~~~~~~~~~~~~~~~~~~~~~~

Anyone have any hints for diagnosing this thing? The install guide troubleshooting section mentions it could just be mounting the drives in the wrong order, but I've left my data drive quite unplugged throughout this all, lest I risk wiping it by accident....

[WarheadsSE]

Sounds like a problem with the network, otherwise the device is coming up. The question is what.

You can either: check the logs safely by adding to /etc/rc.local $this->bbcode_second_pass_code('', 'sleep 20
poweroff')
or get a serial cable and see what is really misbehaving.

[linuxizer]

$this->bbcode_second_pass_quote('WarheadsSE', 'S')ounds like a problem with the network, otherwise the device is coming up. The question is what.

You can either: check the logs safely by adding to /etc/rc.local $this->bbcode_second_pass_code('', 'sleep 20
poweroff')
or get a serial cable and see what is really misbehaving.

[WarheadsSE]

It has to be a 3.3v TTL/RS232 cable, and there is a header, for which there is a pin map.

[linuxizer]

Here's daemon.log.1:

$this->bbcode_second_pass_code('', 'Dec 31 18:00:23 alarm dhcpcd[759]: version 5.6.3 starting
Dec 31 18:00:23 alarm dhcpcd[759]: eth0: sending IPv6 Router Solicitation
Dec 31 18:00:23 alarm dhcpcd[759]: eth0: broadcasting for a lease
Dec 31 18:00:27 alarm dhcpcd[759]: eth0: sending IPv6 Router Solicitation
Dec 31 18:00:31 alarm dhcpcd[759]: eth0: sending IPv6 Router Solicitation
Dec 31 18:00:35 alarm dhcpcd[759]: eth0: sending IPv6 Router Solicitation
Dec 31 18:00:35 alarm dhcpcd[759]: eth0: no IPv6 Routers available
Dec 31 18:00:53 alarm dhcpcd[759]: eth0: offered 192.168.1.126 from 192.168.1.1
Dec 31 18:00:53 alarm dhcpcd[759]: eth0: acknowledged 192.168.1.126 from 192.16\
8.1.1
Dec 31 18:00:53 alarm dhcpcd[759]: eth0: checking for 192.168.1.126
Dec 31 18:00:53 alarm dhcpcd[759]: timed out
Dec 31 18:00:27 alarm dhcpcd[761]: version 5.6.3 starting
Dec 31 18:00:27 alarm dhcpcd[761]: eth0: sending IPv6 Router Solicitation
Dec 31 18:00:27 alarm dhcpcd[761]: eth0: broadcasting for a lease
Dec 31 18:00:31 alarm dhcpcd[761]: eth0: sending IPv6 Router Solicitation
Dec 31 18:00:35 alarm dhcpcd[761]: eth0: sending IPv6 Router Solicitation
Dec 31 18:00:39 alarm dhcpcd[761]: eth0: sending IPv6 Router Solicitation
Dec 31 18:00:39 alarm dhcpcd[761]: eth0: no IPv6 Routers available
Dec 31 18:00:57 alarm dhcpcd[761]: timed out
')

And here are the only things I noticed in kernel.log.1:

$this->bbcode_second_pass_code('', '
Dec 31 18:00:14 alarm-oxnas kernel: [ 5.740000] Bad eraseblock 63 at 0x0000007e0000
Dec 31 18:00:14 alarm-oxnas kernel: [ 5.770000] Bad eraseblock 462 at 0x0000039c0000
')

$this->bbcode_second_pass_code('', 'Dec 31 18:00:14 alarm-oxnas kernel: [ 7.970000] Probing for Synopsis GMAC, unit 0
Dec 31 18:00:14 alarm-oxnas kernel: [ 7.980000] eth0: Tuning GMAC 0 RGMII timings
Dec 31 18:00:14 alarm-oxnas kernel: [ 7.980000] eth0: PHY is Realtek RTL8211D, type 0x001cc914
Dec 31 18:00:14 alarm-oxnas kernel: [ 7.990000] eth0: GMAC ver = 53, vendor ver = 18 at 0xed400000, IRQ 40
Dec 31 18:00:14 alarm-oxnas kernel: [ 8.000000] eth0: Found PHY at address 3, type 0x001cc914 -> 10/100/1000
Dec 31 18:00:14 alarm-oxnas kernel: [ 8.000000] eth0: Ethernet addr: 00:30:e0:00:00:00
Dec 31 18:00:14 alarm-oxnas kernel: [ 8.010000] probe() eth0: Leon x2 clock
Dec 31 18:00:14 alarm-oxnas kernel: [ 8.870000] EXT3 FS on sda2, internal journal
Dec 31 18:00:14 alarm-oxnas kernel: [ 10.870000] eth0: PHY is Realtek RTL8211D, type 0x001cc914
Dec 31 18:00:14 alarm-oxnas kernel: [ 10.880000] CoPro offload is active on eth0
Dec 31 18:00:14 alarm-oxnas kernel: [ 10.880000] Alloc'ing ARM descs 8192 bytes
Dec 31 18:00:14 alarm-oxnas kernel: [ 10.890000] Alloc'ing CoPro parameters 36 bytes
Dec 31 18:00:14 alarm-oxnas kernel: [ 10.890000] gmac gmac.0: firmware: requesting gmac_copro_firmware
Dec 31 18:00:14 alarm-oxnas kernel: [ 10.930000] CoPro: Programming start address as 0xd000e000
Dec 31 18:00:14 alarm-oxnas kernel: [ 11.040000] eth0: Resetting GMAC
Dec 31 18:00:14 alarm-oxnas kernel: [ 11.040000] eth0: GMAC reset complete
Dec 31 18:00:14 alarm-oxnas kernel: [ 11.040000] eth0: Setting Rx flow control thresholds for LAN port
Dec 31 18:00:14 alarm-oxnas kernel: [ 11.600000] eth0: PHY is Realtek RTL8211D, type 0x001cc914
Dec 31 18:00:14 alarm-oxnas kernel: [ 12.100000] eth0: link down
Dec 31 18:00:14 alarm-oxnas kernel: [ 14.060000] ADDRCONF(NETDEV_UP): eth0: link is not ready
Dec 31 18:00:15 alarm-oxnas kernel: [ 15.600000] eth0: link up, 1000Mbps, full-duplex, not using pause, lpa 0xC1E1
Dec 31 18:00:15 alarm-oxnas kernel: [ 15.600000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Dec 31 18:00:26 alarm-oxnas kernel: [ 26.020000] eth0: no IPv6 routers present
')

Could a lack of IPv6 routing possibly be causing this? If so, why and how do I fix it?

Thanks, and happy new year everyone!

[WarheadsSE]

You'll want to add some options to dhcp call:
-A --noarp

[linuxizer]

$this->bbcode_second_pass_quote('WarheadsSE', 'Y')ou'll want to add some options to dhcp call:
-A --noarp

$this->bbcode_second_pass_quote('linuxizer', '')$this->bbcode_second_pass_quote('WarheadsSE', 'Y')ou'll want to add some options to dhcp call:
-A --noarp

[WarheadsSE]

I've seen similar issue a few times with oddball networks that don't respond in a quite "fast enough" manner. Thankfully, it's a rather simple fix.