All my geeky stuff ends up here. Mostly Unix-related

Posts Tagged ‘Debian

Seagate dockstar rescue tips

leave a comment »

Seagate dockstar freeagent

Seagate dockstar freeagent

My Seagate dockstar freeagent (shortnamed: dock) has recently received a brand new hard disk to cope with my large data needs. dock has been serving me so well over the past months that I decided to entrust the new disk with the complete operating system (Debian) and let it run from there. Little did I know that the brand new hard disk would fail miserably one week later, taking away my only copy of Debian for dockstar. Now I do you unbrick these things again? I spent a couple of nights hunting for information and performing experiments so will document that and leave it here in case it may be useful to someone else.

The boot system

Dockstar is an ARM-based micro-computer with a very interesting feature: the whole boot system resides in flash memory. No grub, no LILO, no messing around with the boot sector every time you upgrade the kernel. Only problem is: out of the box the default dockstar only tries to boot its own PogoPlug system and nothing else. First thing you want to do is replace your stock flash boot by his.

Update uBoot on your Dockstar

In my case I happened to have fried the default Pogoplug installation on dock. I believe this happened when I mounted the flash partition from Debian as jffs2 filesystems. For some reason this corrupted everything on partitions /dev/mtd[123] and I could not recover them from old backups. Fortunately I did not try to mount /dev/mtd0, which is probably what saved Jeff’s boot sequence.

Another excellent point for the dockstar boot sequence is the Marvell bootloader installed in ROM on the device (this one cannot be fried). This is by far the most powerful and user-friendly boot system I have ever seen. You can get the OS from any connected device, from the network, over tftp, you name it. Commands are nicely documented and it is a pleasure to navigate. The only point is: if you want to have a chance to catch the boot sequence while the machine is loading, you need to connect a JTAG cable as there is no video card onboard. Quite unfriendly. The other solution is to ask the boot software to communicate with another machine on the same network. This is achieved by setting a few configuration variables and is completely described here:

Use netconsole to troubleshoot uBoot without a serial cable

You will see incoming console text and will be able to take over the boot sequence from a simple netcat. I cannot recommend enough that you do this before anything bad happens; finding a JTAG cable in the middle of the night is not always easy. Once you have configured dock for netconsole and made sure you use Jeff’s boot system, you should be on the safe side.

Rescue systems

Just in case you end up with no bootable drive as I did, you may want to keep a couple of files handy. Johannes explained on Jeff’s forum how to boot from tftp in this post:

Rescue system for use with USB stick and tftp

I would also recommend to go one step beyond and replace your PogoPlug installation by a real rescue system. Jeff again offers a complete downloadable system that will make sure your dockstar always boots on something even with no network (and netconsole) or USB drives attached.

Recovery system ready for use

Installing Debian

The easiest way to prepare a hard disk for Debian on the ARM-based Dockstar is to boot from it into a minimal system, hook up the destination hard drive and bootstrap Debian from there using debootstrap. This is exactly what Jeff put together on this page:

Run Linux on your Dockstar

Theoretically you could prepare the same hard drive from a very standard PC but debootstrap unfortunately does not support (yet) cross-platform installation. The only way to do that from an x86 or x64 PC would be to run an ARM emulator and run debootstrap from there, using your hard drive as a target. I tried using qemu in ARM mode but got some weird errors and gave up after many tries. If you want to avoid having to become an expert about cross-compilation, better make sure you can boot your dockstar and run the install from there.

As a beautiful side-effect: if you ever decide to move the dockstar Debian to another disk, no need for dd and gparted magic. A simple ‘cp -ar’ can do the trick since you do not have to deal with boot software on the boot sector or such things.

Executive summary

  • Do not mount /dev/mtd* under a running Debian. This fscked my flash partitions and restoring with dd proved useless
  • Flash your /dev/mtd0 with Jeff’s replacement. Do it now!
  • Activate netconsole so you can take over from another PC on the same network
  • Replace your default PogoPlug with a real rescue system

Putting the boot loader/manager in flash is a brilliant idea, I wish standard PCs had moved to such an option earlier. The Marvell bootloader is especially versatile with a surprisingly rich online help and excellent capabilities. The booting part is often neglectd by hardware vendors but it proves to make the difference between an expensive plastic brick and usable hardware.

A million thanks to Jeff Doozan for making his knowledge available and accessible!

Written by nicolas314

Monday 7 March 2011 at 12:32 am

Posted in Debian, dockstar, Unix

Tagged with , , , , ,

DNS-323 fun

leave a comment »

Got a new toy: a NAS device (Network Attached Storage) from D-Link called DNS-323. This little piece is just a little bit bigger than two 3.5 hard drives stuck together. It is basically sold as a mass storage with a network plug but under the hood is a tiny Linux 2.6 running Samba and an ftp server to share files. D-Link played the game and released the sources for all software running on the box, which allowed me to discover my name in the credits. It is not the first time I buy a piece of hardware running my own code but it is always a nice surprise!



Several links of interest:

The obligatory Wiki summarizes everything you always wanted to know about the DNS-323:

The Linux image you get in the firmware is very limited. To enhance it to support e.g. telnet or ssh login, you need to install more software.  Fortunately the guys at D-Link made it quite easy by adding a hook at the end of the boot process to run your own scripts, so it all boils down to installing a couple of files through Samba and rebooting the machine a couple of times. No risk of bricking the beast since you always keep clear of the firmware itself, though it is possible to build your own firmware if you really want to.

The two packages I settled upon are:

Fonz Fun Plug (ffp)

This one comes with a fairly limited number of pre-built packages but is nonetheless useful to enhance the box. Since it runs as root in the same Linux instance as the firmware, you can access all parts of the machine through your usual Linux commands.


This HOWTO explains how to run a full-fledged Debian distribution inside a chroot jail on your DNS-323. It is absolutely incredible to see a Debian install come to life on such a small machine! I did not even know Debian had been ported to so many different platforms. Since the whole distribution runs inside a chroot jail it does not mix too well with the original Linux firmware though. As long as you stay in userspace you should be Ok but anything related to machine administration is better served with FFP.

Other guys have replaced the original firmware with a true Debian image but that is going a little too far for me. Bricking the box requires some soldering on the mainboard to get access, and I am not going to do that.
All in all a very happy surprise and yet another headless box on my home network!

Written by nicolas314

Sunday 1 March 2009 at 2:00 am

Posted in dns323

Tagged with , , ,

Debian upgrades on Junior

leave a comment »

Junior runs Debian. Debian gets upgraded, so Junior gets upgraded.

Unfortunately this upgrade comes with a kernel upgrade, requiring re-compilation of all specific drivers: sis7019 for sound, ndiswrapper for WiFi and the webcam-specific drivers. I tried to install Debian packages from testing but could not get anything so I tried manual re-compilation. This failed miserably because the kernel headers have changed in some incompatible way. Time for me to Google my way out of this and I could finally get anything back to a usable state.

I am getting quite annoyed by the regular changes in kernel interfaces. There must be other ways of maintaining a kernel without requiring every driver writer to maintain their code for each new release, especially for a piece of software that is 15 years old now.

Written by nicolas314

Tuesday 29 January 2008 at 10:56 pm

Posted in junior

Tagged with , ,

Junior webcam support

leave a comment »

Just for fun: I have added a webcam to Junior. A USB webcam, the kind you can find for 20€ in any computer store out there. I bought one without checking for Linux support beforehand and was lucky enough to get one that is supported. For what it’s worth: the webcam is sold as Hercules Delux webcam. The package said it supports 1.3 Mpix images but that is a lie: the captor is 640×480, that is 300 kpix and they have software to interpolate (extrapolate) to larger images under Windows. Oh well… Next time I will check before going to the store.

Anyway: I needed to compile and install an extra driver to support this camera. The driver is called ov51x-jpeg and it can be found here:

Once the driver is loaded into the kernel, you get new devices corresponding to video and audio inputs (this webcam comes equipped with a microphone): /dev/video0 and /dev/dsp1. To check everything is working smoothly, I started up VLC (VideoLAN Client), chose “Open Capture Device” and provided these device names. Video is really smooth on this webcam and sound is working as expected.

Now I have video and sound acquisition capabilities on Junior, which finally enables me to implement a simple but powerful alarm system in my house. What I want is:

– A system running full-time when I am not home
– Keep acquiring images from the cam until some movement is detected
– As soon as something is detected, send the images to me by e-mail and send me an alert by SMS

I should also be able to log into Junior and listen to the audio flux remotely, and why not get the video flux too. I did not get to this last part yet but the rest is pretty easy.

You want to have a look at Motion, a pure command-line motion detector. This utility can be configured to take any kind of action upon detecting movement in a video feed, which is exactly what I want, and it is available from the Debian repositories. It took me a while to understand the configuration file and get it right but once put together it works really nice.

The last part I needed to solve was sending an alert over SMS. Un-surprisingly, there are still no SMS-brokers out there offering SMS sending services for free. You need to register and pay for these, and this is not cheap. I guess this is a good thing in the end to avoid spam on mobile phones in general. I checked out my phone subscription and found out that my provider also offers a Webmail that can be connected to my mobile phone: whenever I receive an e-mail at that address, they send an alert by SMS to my mobile phone containing the e-mail Subject line, and this is free of charge. There we are! The final algorithm can be summarized as:

– Run motion on Junior
– Whenever movement is detected, send the images by e-mail to me, and send an SMS alert to the e-mail account associated to my mobile subscription.

Since I do not want to be flooded with false SMS alarms, I limited the system to sending only one per day. This should be enough. Now I need to find a way to deactivate the alarm system when I come home, otherwise the alarm will trigger every day.

Yet another simple but nice project. Not sure it will ever be useful, I just wanted to know if it could be done!

Written by nicolas314

Sunday 12 August 2007 at 1:17 pm

Posted in junior

Tagged with , , ,

Junior as syslog archiver

with 2 comments


You have a Junior box or equivalent sitting at the heart of your home network and want to use it as a network syslog archiver for all of your machines.


All Unix machines on your network store their syslog messages locally and also send them to Junior through UDP packets, where they are stored in separate files for each machine.


install syslog-ng

The default Debian syslog has the capability to log network-based syslog messages coming from other machines on the same subnet (-r option). Unfortunately, syslog cannot be easily configured to store logs separately
for each machine, so everything ends up in the same files, mixing information from all hosts as well as local messages. This can get quite confusing.

Enters syslog-ng: this new generation brings a lot of useful features, among which the capability to do much better filtering on incoming messages and how to store them. The procedure to install it is as follows:

apt-get install syslog-ng

This will install syslog-ng and remove syslog.

For this example I assume we have a machine on the local network called ‘billy’ at address Modify your /etc/syslog-ng/syslog-ng.conf configuration file as follows:

Add a UDP listener by un-commenting udp() in the source list:

source s_all {
# message generated by Syslog-NG
# standard Linux log source (this is the default place for the syslog()
# function to send logs to)
# messages from the kernel
file("/proc/kmsg" log_prefix("kernel: "));
# use the following line if you want to receive remote UDP logging messages
# (this is equivalent to the "-r" syslogd flag)

Add another destination for log files generated by billy:

destination df_billy { file("/var/log/billy/messages.log"); };

Add a filter based on IP:

# all messages from billy
filter f_billy { netmask(""); };

There are probably better ways to do filtering than providing a static IP address. Bear with me, I did not want to get any deeper into syslog-ng documentation since this fits the bill.

Add a rule to combine filter and output directory:

# Billy logs
log {

On billy, make sure syslogd is started with option -R x.x.x.x where the latter is the IP address of your syslog archive box.

You should now get messages logged in /var/log/billy/messages.log.

Written by nicolas314

Tuesday 31 July 2007 at 1:31 pm

Posted in Uncategorized

Tagged with , , ,


with 5 comments

Looking through the BIOS for Junior, I could find no option to activate Wake-on-LAN. The way to achieve that is actually to configure the Ethernet chip directly. Under Debian, this is done with:
# ethtool -s eth0 wol g

The ‘g’ option for wake-on-lan (wol) actually specifies that you want to wake up on magic packets, but there are other interesting options if you want to wake up on other network events. Read the documentation for ethtool.

One important point: this setting only survives until the next boot. If you want to make it persistent, create a file called e.g. wol in /etc/network/if-up.d with the following contents:

if [ "$IFACE" == "eth0" ]; then
ethtool -s eth0 wol g

Make the file executable by chmod +x wol

I can now wake Junior from another Linux machine on the same subnet using tools like wakeonlan or etherwake. The former does not need root privileges to perform, which is safer.

Written by nicolas314

Sunday 1 July 2007 at 11:30 pm

Posted in junior

Tagged with , , , ,