Contents

Brick

In the context of LinkStation hacking to brick a LinkStation means to render the LinkStation unusable. A bricked LinkStation does not boot any more, does not respond to requests (e.g. for serving data via Samba), enters EM Mode, and/or does cyclic reboots.

Effectively, the LinkStation is just a brick, which can only be used as a door stopper unless one can fix it. It is broken, kaputt, finished, done. You get the idea.

When people say that a particular activity can brick a LinkStation, or when an article is marked as such, people mean it! It is not a joke. If you can't afford to lose a LinkStation or if you don't posses the necessary mental strenghts to deal with the loss of a LinkStation, don't hack it! There are many ways to brick a LinkStation, and not every bricked LinkStation can be recovered. Some recovery procedures are so complicated that they are practically impossible to perform by the unskilled.

Causes

Improper Flash

There have been cases of users writing uploading an incompatible flash image. Please be sure of what you are doing, and be very careful when attempting to modify the contents of the flash memory.

It regularly happens that an LS is diagnosed as bricked, when it isn't. The most common error is to not follow the flashing or installation instructions and still leave some software firewall in place during install.

Failure to reset watchdog timer

A LS has a watchdog timer, which needs to be reset in regular intervals. If this resetting is not done, a system crash is assumed, and the LS reboots. Now, if one somehow manages to permanently disable this watchdog resetting, the LS reboots cyclically.

There are a number of more or less "clever" ways to disable the resetting of the watchdog timer. Most of them center around accidentally or intentionally removing the daemon which is responsible for sending the watchdog resets in regular intervals (mc_ctld, ppc_uartd, avr_evtd).

A more obscure way to hinder the watchdog timer happens as it follows: The start of the daemon happens relatively late in the LS' boot procedure. Now, if someone added a time-consuming boot task (e.g. some long taking service startup) before the start of the daemon, the watchdog timer is not properly reset, and the LS cyclic reboots while still in the boot procedure.

Other Causes

There are many more causes, including hardware failures, broken operating system updates, broken configurations, etc. As a general rule of thumb, don't attempt to hack a LinkStation if you can't afford to lose it.

NOTE: with 2.30 firmware (LS2), haven't verified elsewhere, once a flash upgrade fails the update util fails continually. running the exe with the /force flag seems to fix _most_ of the partial installs I've seen. in any case if the upgrade fails the /force flag can't really hurt and seems to do the manual flash steps below in most cases.

Watchdog timer triggers during boot

If this happens because there is a service which takes to long to start up, this can be fixed by opening the LS, connecting the hard drive to some Linux machine, mounting the drive and removing the offending service startup script from the rc boot sequence. The service startup script can than be placed after the daemon start. Since the daemon start is typically at sequence number 95, this leaves 96, 97, 98 and 99 for additional startup activities. Activities can share the same startup sequence number, so these few available numbers don't pose a limit to the number of startup activities. However, it could also be considered to move the watchdog daemon startup to an earlier sequence.

Fixing a Bad Flash

Linkstations/Kuroboxes that have been bricked due to bad flash memory contents can be restored by rewriting the flash memory with the correct contents. However, since the device can not be booted, this requires the use of JTAG.