Brick

From NAS-Central Buffalo - The Linkstation Wiki
Revision as of 10:49, 28 January 2007 by 77.128.168.240 (Talk)

Jump to: navigation, search

Some of this information from kuroboxwiki:Brick

Wiki articles which might result in bricking an LS are often, but not always marked with this ugly badge:
Kurobrick.png
WARNING!

There is a possibility that you could brick your NAS with these instructions. Please make sure that you read the entire page carefully.


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

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

There are a number of more or less "clever" ways to disable the reseting 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 thump, don't attempt to hack a LinkStation if you can't afford to lose it.


Fixing a Bricked LS

Reflashing or Reinstalling Firmware

Re-animating a bricked LS depends on what went wrong or what was done wrong. Sometimes re-flashing the original or a hacked firmware & OS can help (see The LinkStation firmware flasher, Manually flash the LinkStation's firmware. Sometimes it is necessary to Disassemble the LinkStation, connect the disk to a PC and re-image the drive. See Recover a non working "bricked" Linkstation for instructions.

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.