Anyone who wants to try out a development/alpha version of a possible Rescue System V3.0 is welcome to, and certainly anyone who wants to contribute to the effort, try to solve problems, etc. is encouraged to do so.

Jeff's original V1 & V2 have served us well... recently I put out a V2.8.1 which should run on over a dozen different Kirkwood boxes... but all of these are still based on 2010.08 Buildroot sources...

I've recently worked w/ Buildroot 2012.02 and 2012.05** to try to truly bring this up-to-date - current _everything_, and so it will boot on a wide variety of Kirkwood boards (see README for the list) .

Some new features that were truly needed, IMHO, and are now in Buildroot's package inventory, have been added.

• parted : the GNU command-line-interface Partition Editor (handy for resizing partitions on drives)
• sdparm : a utility for setting parameters in SATA drives (perhaps more useful than hdparm)
• gdisk : utility for creating EFI/GPT partitions (enables us to use drives larger than 2.1 TB)

A USB-based tarball for trial is available here : http://dl.dropbox.com/u/1015928/Kirkwood/rescue/USB-Rescue-tarballs/rootfs-br2012.02_06082012.tar
This image will boot without _any_ changes to the default U-Boot env variables. Simply follow the directions on the README-USB-Rescue-tarballs document.

Ideas for a few more key/crucial utilities?

Maybe you want to help getting systemd/sysvinit or udev working on it? Currently none of them are included... maybe they should be left out, to keep it as truly a "Rescue" system, and not really a applications-oriented system.

It just takes a few minor modifications to turn it into a UBIFS image. Size is a concern, though, and maybe some of the extra apps that had been included could be removed, to save space under the hood.


** I tried to use the 2012.05 BR source, but something in it seems to disagree w/ kernel patches. Until this is solved, I'll be sticking w/ 2012.02. It has all the infrastructure that is necessary, and any "new" packages we need to add in to it can be back-ported.

=====================================================

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 06/09/2012 08:47AM by davygravy.

hi davy,

for me it would be nice, if there is the inadyn package and ftp in the rescue system.
because when there is a power failure, the dockstar with an usb-drive wont boot,
but the rescue system always boots.
so my plan was to run the openvpn server on the rescue system.

thx
major

Hi major-tom007, openvpn is just a click to turn on, but inadyn doesn't look like it is in their package repository. It will take a day or so til I get it built in, but I can see that _yes_ inadyn is a good candidate for an additional package. [Frankly I'm astounded that it isn't in there already.] It isn't a lot of work, just adding the package makefile & Config.in changes & rebuild.

TBH, it seems strange that inadyn hasn't been updated in a while. ddclient seems to be more recently updated, but it requires python and perl... and we are trying to keep this from bloating up.

I'll build it as a USB image first, so you can test it. Once you tell me the USB image works as you want it to, I'll do the changeover to UBIFS.

=====================================================

• davy's Github Repo's rescue-dg

hi,

that sounds good ;-)
hope you'll have success...

cya
major

@ major-tom007 : From what I can see, the original inadyn has ceased development and is now stalled...
1. http://www.inatech.eu/inadyn/readme.html (last update seems to be 2007)

2. There is an updated fork... http://freecode.com/projects/inadyn

and yet another fork ... inadyn-mt
3. http://sourceforge.net/projects/inadyn-mt/

#1 seems to be too outdated to take seriously (as a first choice) - though it is still available in Debian, Ubuntu
#3 looks good as far as future-proofing (IPV6 support)
#2 appears to be the least deviated from the original

Major-Tom007, would you be able to do a bit of research & find out if #2 supports IPV6 ? Which fork are most distros using nowadays? Maybe a peek at the forums of dyndns.com and a couple of other such providers would show a tilt in preferences, and reasons why... ?


I've already got the original (#1) included and in a tarball... but it makes sense for us to put in the _best_ version/fork, rather than just an arbitrary.

(ddclient doesn't look like a great choice, as it requires both perl and python - both are available in Buildroot, but would balloon the size beyond the limit for mtd2)

------------------------------------------------

Later comment: I noticed that on the dyndns.com pages for update clients, it mentions the 2007 version (original) as the only version that they have "vetted". With this in hand, it seems smart to stay w/ it.

I found this : http://www.linuxquestions.org/questions/linux-software-2/how-do-i-execute-inadyn-automatically-during-boot-541367/#post4518378 : which may be useful for getting it started correctly...

=====================================================

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 06/12/2012 10:50AM by davygravy.

@ Major-Tom007: If you follow my sig links: Kirkwood>Rescue>V3pre1-forMT007, you'll find a tarball that you can simply put on a ext3 sda1 , swap sda2 formatted USB flash drive...

You can test out the functionality of inadyn. It compiled, it runs, and it has a pre-slugged conf file at /etc/inadyn.conf The pre slugged config file will have to be altered to match your situation - and I can't say that I've tested it myself, so feedback from you would really be appreciated.

You can stop/start it with

/etc/init.d/S70inadyn  stop/start

It will be running by default, so you'll have to stop it, set up the config, and then start it.

Let me know how it works for you... this is the minor fork off of the old/stalled inadyn, seems best for embedded systems like our Kirkwoods.

It also has openvpn, iftop and a few more networky things.
====================

tested it out a bit for myself...

rescue:/var/log# cat messages | grep inadyn
Jun 12 22:35:50 rescue user.info inadyn[140]: Inadyn version 1.98.1 -- Dynamic DNS update client.
Jun 12 22:35:50 rescue user.info inadyn[140]: Resolving hostname test.homeip.net => IP# 31.60.248.2
Jun 12 22:35:51 rescue user.info inadyn[140]: Checking for IP# change, connecting to checkip.dyndns.org(216.146.38.70)
Jun 12 22:35:51 rescue user.warn inadyn[140]: Update needed for alias test.homeip.net, new IP# 184.60.70.80
Jun 12 22:35:51 rescue user.info inadyn[140]: Sending IP# update to DDNS server, connecting to members.dyndns.org(204.13.248.111)
Jun 12 22:35:51 rescue user.info inadyn[140]: Successful alias table update for test.homeip.net => new IP# 184.60.70.80
Jun 12 22:45:52 rescue user.info inadyn[140]: Checking for IP# change, connecting to checkip.dyndns.org(216.146.39.70)
Jun 12 22:45:52 rescue user.info inadyn[140]: No IP# change detected, still at 184.60.70.80
Jun 12 22:55:53 rescue user.info inadyn[140]: Checking for IP# change, connecting to checkip.dyndns.org(216.146.38.70)
Jun 12 22:55:53 rescue user.info inadyn[140]: No IP# change detected, still at 184.60.70.80
Jun 12 23:05:53 rescue user.info inadyn[140]: Checking for IP# change, connecting to checkip.dyndns.org(91.198.22.70)
Jun 12 23:05:53 rescue user.info inadyn[140]: No IP# change detected, still at 184.60.70.80
...
Jun 13 04:16:03 rescue user.info inadyn[140]: Checking for IP# change, connecting to checkip.dyndns.org(216.146.39.70)
Jun 13 04:16:04 rescue user.info inadyn[140]: No IP# change detected, still at 184.60.70.80
Jun 13 04:26:04 rescue user.info inadyn[140]: Checking for IP# change, connecting to checkip.dyndns.org(216.146.38.70)
Jun 13 04:26:04 rescue user.info inadyn[140]: No IP# change detected, still at 184.60.70.80
Jun 13 04:36:04 rescue user.info inadyn[140]: Checking for IP# change, connecting to checkip.dyndns.org(216.146.38.70)
Jun 13 04:36:04 rescue user.info inadyn[140]: No IP# change detected, still at 184.60.70.80

...seems to work OK... but this is with a dummy/test account...

=====================================================

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 06/12/2012 11:39PM by davygravy.

hi,
you are faster than i can check the topic :-))
I'll try the tarball and give you feedback,

cu
major

@ major-tom007 : I found a minor omission in the bare-bones initscript for inadyn... one line really needs to be added in the stop section ... the pid file needs to be deleted upon exit.

#!/bin/sh
#
# Start the inadyn client
#

case "$1" in
  start)
        echo "Starting inadyn."
        start-stop-daemon -S -x /usr/sbin/inadyn
        ;;
  stop)
        echo  "Stopping inadyn."
        start-stop-daemon -K  -x /usr/sbin/inadyn                         
        rm -f /tmp/inadyn/inadyn.pid             ####  <<<<<--------add this line-----<<<<
        ;;
  restart|reload)
        "$0" stop
        "$0" start
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart}"
        exit 1
esac

exit $?

=====================================================

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 06/13/2012 02:21PM by davygravy.

so,
fired up your rootfs and configured inadyn.
for now it looks quite good.
but i've to wait for an ip change....
but in think (and hope) that there is no problem with the update...

cya
major

hi,

inadyn works perfekt, i don't see any problems here.

cu
major

I have rescued My Goflex Home with a serial cable so I can now help ^^

I have an old 256 MB USB Key so it should be perfect !

Hi davy,

can u build the PreV3 for the nand?
I've the usbimage about 10 days on,
and there a absolutly no problems...

cya
major

@ major Tom

I'm in the Bighorns backpacking w onlymy iPhone til July 10

Will build and test a NAND image for you once i return

Thnx again for your help w testing

Regrds

Davy the Trout Slayer

=====================================================

• davy's Github Repo's rescue-dg

hi Davy!

I wish u a very nice weather and much fun and time for relaxing.....
Enjoy your holiday!!!
cu
major

Hi there ... Great rescue System... I would prefer for Remote troubleshooting also "ddclient" so we are able also to troubleshoot the devices with the Rescue System remotely!

This would be really awesome...

@BigRon inadyn is like ddclient

DavyGravy
I'm impressed. This is the way I would expect things to work. I prepped a usb-drive, popped it into a pogoplug running the original V2 kernel and software and some newer uBoot and rebooted.

Your system works! No need for a serial cable, no jtag, just ssh.

One issue that did show up... an attempt to simply ssh root@rescue.local did not find the machine... Fortunately it had the same ip assignment as it has been getting all along.

A second, not so great thing was that when I plugged in a wireless usb device, it was recognized, but the kernel did not autoload any modules. I chose one to load with modprobe and the rest loaded. That could be a problem rescuing a remote device.

I guess my question is why call it a rescue? Because it can? But if you included a package manger in the system, then it would be the perfect place for someone to start putting togther the pieces they need for their particular purposes.

It could even include a short set of stage 2 installs using the package manager that put together the required packages for say a weather station, a webcam, or a tvcontroller.
Really simple apt-get "list of packages for purpose"

That would provide the best of both worlds. A full fledged debian system without bloat from including everything "just in case."

Overall, a much easier to deal with system than a script that has to be debugged and restarted. I'm not a fan of debootstrap.
Does it work on a virgin pogplug? or is a modified uBoot required?
TJ

Quote
TJ
Your system works! No need for a serial cable, no jtag, just ssh.

Just one problem - I'm getting

$ ssh root@rescue.local
ssh: connect to host rescue.local port 22: Connection refused

so I edited /etc/sshd_config to allow root login
next, the password is unknown
so I blank out the root password and try again
back to "connection refused" as sshd won't allow a passwordless root login

i tried copying the hash of a known password into /etc/shadow
but the hash algorithm must be different as that failed

any ideas on how to pass this point
"root" as the password did not work

Liz, that form of connection refused usually happens when you forget to take the ip address line out of the ~root/.ssh/known_hosts file. One reason to use Putty as the ssh client is that it checks whether you expected the change.

Quote

i tried copying the hash of a known password into /etc/shadow

I just copied the whole shadow file from another system and added the passwd lines that were missing. That worked.



But, I may have been overzealous in my enthusiasm. I have not gotten it to boot again!

Did everything over, starting from partitioning the usb sd card and behold it boots again. This time I forgot to copy over
the shadow files, but the boot password worked fine.

DavyGravy,

Hmmmm, from another pogoplug on the same network, running Jeff's new wheezy distribution, I tried:

# ssh root@rescue.local
ssh: Could not resolve hostname rescue.local: Name or service not known

On the other hand, Putty from a windows box on the same network finds rescue.local just fine.

The router doesn't pick up the name rescue on the attached device list. It is blank for Device Name. The wheezy pogoplug shows up with the hostname that I assigned in /etc/hostname.

I don't understand what this means, exactly, but I thought you should know. It isn't what I expected, but it may be what you expect. :-)

I also have to say that this is not a rescue disk unless it allows idiots like me to get the tools we already know how to use installed. (especially man)

Three questions: 1) Should ipkg from optware run on this rescue system?
2) Is there something that defines a "rescue image"?
3) Could I expect it to boot to a wireless network?

Thanks again.

TJ

I found a clue, but I don't know what it means.

Quote
You'd need something uclibc-based feed .

This was in response to ipkg not working.
What does uclibc-based mean and what is the alternative?
It seems angstrom was uclibc-based but is now all eglibc .. whatever that means?

Bottom line: Is there a feed that can feed to the rescue 3.0 system?

TJ

Hi Major_Tom,

I'm taking a look at that right now... do you know the "date modified" stamp on that tarball for the USB image I made for you? I thought I'd kept good notes, but I need to be sure I have the right components built in for you. Inadyn was the key component?

=====================================================

• davy's Github Repo's rescue-dg

Short answer to your question TJ: Unfortunately, no. There is no suitable ipkg feed for this rescue system, as far as I am aware of. Personally, though the idea of adding in a package seems nice, it may not play so well with a space-limited-by-NAND-flash-size that we have in this case. If you want the capability to add packages, Debian or some other full-fledged distro is the best choice.

TJ Wrote:
-------------------------------------------------------
> I found a clue, but I don't know what it means.
>
>

Quote
You'd need something uclibc-based feed
> .
>

>
> This was in response to ipkg not working.
> What does uclibc-based mean and what is the
> alternative?
> It seems angstrom was uclibc-based but is now all
> eglibc .. whatever that means?
>
> Bottom line: Is there a feed that can feed to the
> rescue 3.0 system?
>
> TJ

=====================================================

• davy's Github Repo's rescue-dg

Major_Tom:

I built and tested it... below is how I flashed it into NAND. https://dl.dropbox.com/u/1015928/Kirkwood/rescue/RescueV3-for-Major_Tom.tar.gz It is uploading now, and should be available by around 5:30 UTC on August 23.

You ***cannot*** be booted into any NAND system while you are flashing it... For instance, I was booted into the USB-rescue image that I'd built for you back in June when I flashed it. Note that if you have a different version of mtd-utils, the commands might differ a bit.

Note: there are three files: uImage-mtd1.img rootfs-mtd2.img and rootfs.tar . The two img files are for NAND. The third one is basically the tarball that you already tested, suitable for USB drive booting.

usb-rescue:/# flash_erase /dev/mtd1 0 0
Erasing 128 Kibyte @ 3e0000 -- 100 % complete 
usb-rescue:/# nandwrite /dev/mtd1 uImage-mtd1.img
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
...
Writing data to block 25 at offset 0x320000
Writing data to block 26 at offset 0x340000
Writing data to block 27 at offset 0x360000
usb-rescue:/# flash_erase /dev/mtd2 0 0
Erasing 128 Kibyte @ 1fe0000 -- 100 % complete 
usb-rescue:/# ubiformat /dev/mtd2 -s 512 -f rootfs-mtd2.img -y
ubiformat: mtd2 (nand), size 33554432 bytes (32.0 MiB), 256 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 255 -- 100 % complete  
ubiformat: 256 eraseblocks are supposedly empty
ubiformat: flashing eraseblock 226 -- 100 % complete  
ubiformat: formatting eraseblock 255 -- 100 % complete

reboot and then make fix the inadyn.conf file ... and restart it inadyn.

mount -o remount,rw /
#  make whatever changes you want to inadyn.conf

mount -o remount,ro /
/etc/init.d/S70inadyn start  #start it up

The success or failure of inadyn in setting/renewing the IP address should be visible in /var/log/messages. It should start properly at boot.

=====================================================

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 08/22/2012 11:43PM by davygravy.

Hi davygravy!

Big Thx for your work and sorry for late response.
but it's so hot at my location, so i had no drive to look
into a pc or so ;-)
but i will flash asap.

cya
mt

Major_Tom: I got your message. I've just rerolled it w/ the mangle modules (and a lot of other netfilter stuff). As far as I could tell, I got them all included - but if not, just let me know.

openvpn --version
OpenVPN 2.2.2 arm-linux [SSL] [LZO2] [EPOLL] built on Aug 24 2012
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>

http://www.linuxintro.org/wiki/Openvpn

I've no great experience setting up openvpn, so you are on your own for that... :)

New tarball is uploading... https://dl.dropbox.com/u/1015928/Kirkwood/rescue/RescueV3pre2-for-MajorTom-w-netfiltermangles.tar.gz

Note that you might have to modify /etc/init.d/openvpn or whatver openvpn conf file there is.

Please keep a record of such changes so we can share them here w/ other users.

=====================================================

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 08/24/2012 12:06PM by davygravy.

Hi Davy,

After a weekend with hours of testing, i had no luck with openvpn.
I always got the message: "Starting openvpn: FAILED-> client1ifconfig: SIOCSIFADDR: No such device
FAILED-> tun0."

At the moment I have no Idea...
I configured openvpn like here: Openvpn

Maybe you have an idea?

cya
mt

If tun0 is an interface (ie. a device, in /dev/) then you may have to create it first.

mknod /dev/net/tun c 10 200

or something similar... perhaps it would be /dev/tun instead of /dev/net/tun, or /dev/net/tun0, or /dev/tun0 ?
I don't have mdev or udev included to create them dynamically, since it won't fit ...

This link has a lot of the details, including the command above a few others that may be needed... including adding an alias tun0 for it... or perhaps just a symlink will do?
http://openvpn.net/index.php/open-source/documentation/install.html

Your link from shyd is a good one, but that is in Debian ... this is a tiny miniaturized version of that basically, without all the bells, whistles, etc.

Thank you for your work and testing...

=====================================================

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 08/27/2012 08:24AM by davygravy.

Hi,

After a hard weekend, where i found some time to test,
I can say that openvpn starts.
But i couldn't connect.
so there is something to find out....

I'll try to find out, but i could take a while...

cya
major