[RESOLVED] ddclient @ pogoplug or force reboot to Arch Linux ARM?

[donv]

I have Arch Linux ARM installed on a remotely situated DockStar. While booted under Arch Linux ARM, ddclient keeps DynDNS informed of the site's IP address so it can be accessed remotely. This site has a dsl connection which times out and the IP is changed if/when there is no activity.

I've had an issue with the DockStar not always coming up into Arch Linux ARM in case of a power cycle (there is another thread on this here). However, if I reboot the machine it then does load Arch Linux ARM.

The problem is, if the power goes out and the machine comes back up under the pogoplug OS, I don't currently have ddclient working to update DynDNS and therefore can't ssh in to reboot the machine if it gets a new IP. In a few hours, the site will be unmanned for several months so I can't power cycle the machine manually.

Is it possible to add ddclient within the existing pogoplug OS? Or is there another solution to ensure the DockStar automatically reboots if it is running the pogoplug OS (and the USB drive is present with Arch Linux ARM on it)?

[kmihelich]

The actual solution you want is to find out what is needed to get your dockstar coming back up properly after power failure. If it's not coming up into PA every time it starts, you might need to increase the rootdelay in uboot, the drive you're using might not be coming up in time. By default it's set at 10 seconds, people have seen better success with issues like this by using 15 or even 20. If you've run install_uboot_mtd0.sh in PA, you should have fw_setenv available from within PA. Otherwise, you can run it to get the utility, or just go into stock firmware.

Code: Select all

fw_setenv rootdelay 15

The value is saved after issuing that command. You can verify with fw_printenv.

[donv]

Thanks for the help, and I fully agree on the desired solution!

• I've tried jacking rootdelay up to 20 (and to be clear, this was rootdelay, not usb_rootdelay, right?). No change.
• I've also now tried increasing bootdelay from 3 to 10. No change.

What is frustrating about this is, with default settings, I see the activity light on the USB key flash almost immediately after power on (I presume this is the USB bus finding the disk). On alternating power cycle 1 (corresponding to when it boots Arch Linux ARM), there is about a 3 second delay (matching bootdelay?) and then there is a flurry of additional USB key activity until Arch Linux ARM comes up (front led flashing green, then solid green). On the other power cycle, there is just the initial activity and then nothing for a long delay while pogoplug is booted and comes up (front led flashing yellow, then green, then yellow).

And just to reaffirm how 100% reproducible this is, I'm now working locally with a second Dockstar with the same exact behavior. Power cycle a=pogoplug, b=Arch Linux ARM, c=pogoplug, d=Arch Linux ARM, etc. They both have the exact same HW attached (same model USB key, USB to Serial 1-wire adapter).

Were it more random then I'd be more likely to accept marginal drive timing. It just feels too deterministic for that? I do have another brand of USB key here that I will try in the next day or so just to try to rule that out.

Thanks again!

[pepedog]

Maybe you could put a shutdown (in minutes) in rc.local of native pogoplug software
http://linux.die.net/man/8/shutdown
shutdown can also reboot
I remember in the early days when uBoot was alternatively booting between the OS's someone did this.
Remember it needs full path, ie
/sbin/shutdown blahetc
Test first, and with minutes to shutdown you could kill the shutdown before it happens.

[kmihelich]

My bad, I believe the correct uboot variable is usb_rootdelay. You can double check with fw_printenv | grep rootdelay just to be sure, though you'll likely now see just a rootdelay variable as well.

You also might want to run the instal_uboot_mtd0.sh script from http://jeff.doozan.com/debian/uboot/ to be sure you're on the latest uboot. Old versions from last year would cycle between usb and stock firmware.

[donv]

My bad, I believe the correct uboot variable is usb_rootdelay. You can double check with fw_printenv | grep rootdelay just to be sure, though you'll likely now see just a rootdelay variable as well.

You also might want to run the instal_uboot_mtd0.sh script from http://jeff.doozan.com/debian/uboot/ to be sure you're on the latest uboot. Old versions from last year would cycle between usb and stock firmware.

OK, I'll give that a go, thanks! I'd tried to find info on both variables in the uboot documentation but got nothing definitive re: usb_rootdelay vs. rootdelay.

Yep, both times I used the latest uboot script from Jeff per the installation process laid out at Arch Linux ARM.

Maybe you could put a shutdown (in minutes) in rc.local of native pogoplug software
http://linux.die.net/man/8/shutdown
shutdown can also reboot
.
.
.
Test first, and with minutes to shutdown you could kill the shutdown before it happens.

Thanks. This is a great suggestion and I may come back to it after trying usb_rootdelay now. BTW, in reading the man page, it appears that shutdown prevents further logins while in the period up to shutdown. I've tried googling but could not come up with an answer to this: do you know if that includes root (if so, how can I stop the shutdown remotely)? If it does, I guess I could have a script that calls shutdown with the -k option just to issue the warning message (as a reminder), wait period x (during which I could kill the job), then issue the real

Code: Select all

shutdown -r

command if not killed before.

Thanks again for the help.

[donv]

Sorry to report no joy with usb_rootdelay set as high as 25 (tried 15 & 20 as well). Did a comparison of the Arch Linux ARM wiki uboot installation script download URL vs. Jeff's - they match. Tried reinstalling uboot and resetting uboot environment (confirmed via fw_printenv) and then setting usb_rootdelay to 25. Same behavior - alternating pogoplug and Arch Linux ARM boots.

Before trying other disks I'm going to try moving the existing one to a different USB port (internet readings seem to indicate that the side port is a lower port number than the back ports). Probably won't matter, but at this point even making burnt offerings to lower gods are worth considering.

[pepedog]

Perhaps you could get something like a ping or call to a known port to your location to let you know ip address where it is?

[donv]

Well, I think it has been solved!

In googling using other terms, I found an obscure reference to someone else having difficulty with booting a usb disk on the doozan forum: http://forum.doozan.com/read.php?3,2075,2339 . Their solution was to stop and restart the USB bus additional times in the bootcmd. I came really close to screwing things up when attempting their solution but luckily realized that in order to change the default

Code: Select all

bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset

to get an end result of

Code: Select all

bootcmd=usb start; usb stop; usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset

that I needed to actually enter

Code: Select all

fw_setenv bootcmd 'usb start; usb stop; usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset'

(notice the single quotes). I did it without the quotes the first time, which of course got interpreted as separate commands. I was really concerned something got borked by that, so another re-installation of uboot and resetting of its environment got me back to a suitable state to enter the fw_setenv command again with the quotes.

I've since done several power cycles (still with the overlong usb_rootdelay, and the extra usb stop and start, so sloooow) and the unit has come up into Arch Linux ARM every time since. Next I'll try cutting that variable back to the default value of 10 to see if it still works.

Just FYI, the disks I've been using are the 2GB Patriot X-Porter mini.

I'll post a cross-reference from my other related thread to here to close that one out too.

Thanks.

[donv]

Just an update: this bootcmd change has been 100% effective over many power cycles now, even with the usb_rootdelay set back to 10. The impact is a slightly longer cold boot. Warm reboots take just over 1 minute. Now I can just play with the applications.