The original (old hardware) model LinkStation PRO and LIVE appear to share the same hardware, but came with different firmware. Recently, a new model (new hardware) has appeared: again, the new versions of the PRO and LIVE appear identical, but differ from the older versions. The Freelink installation procedures for old and new hardware are different.
There are now four variations: old/new and PRO/LIVE.

WARNING!

IMPORTANT! Identify your hardware version from the picture below! New PRO and LIVE LinkStations have a modified hardware (v2), and will be bricked if the U-Boot bootloader (BOOT) is replaced by using the procedure designed for the older (v1) hardware.

USE THE RIGHT PROCEDURE FOR YOUR HARDWARE!

To determine whether you have the OLD (v1) or NEW (v2) hardware, compare the following rear-view images (of LS LIVE, but valid also for LS PRO) - note the position of the power cable socket (at top in new hardware, at side in old):

Download

How to use the Buffalo updater LSUpdater.exe

You will have to use the Buffalo-supplied windows program LSUpdater.exe, running on Windows (or maybe WINE under Linux). This comes in separate versions for the LS PRO and LS LIVE. The Freelink package contains an older LS PRO version not suitable for new hardware. Unless you are installing Freelink on an old-hardware (v1) LS PRO, you will need to use LSUpdater.exe from a buffalo firmware package for your type of ARM-9-based Linkstation (PRO or LIVE). You will also need its files lsupdater.ini and linkstation_version.txt .(You may need to edit linkstation_version.txt to increase the version numbers of the various components listed, so they are higher than the actual Buffalo versions installed on the LinkStation; this is just to fool LSUpdater that the update really is an update, otherwise it won't get applied).

To Access the Debug Menu

Start lsupdater.exe, then

Right-click the "Buffalo Updater Icon" on the Windows context-bar (the bar at the bottom of the screen that spans between the start menu and the clock).

Select "Debug(D)..." and the Debug Mode menu will pop up.

If you are using the lsupdater as supplied in Buffalo's own firmware packages (e.g., if you are installing FreeLink firmware on the LS LIVE, as described below), you will not see the Debug(D) option until you have modified the file lsupdater.ini (found in the same directory as lsupdater.exe): open lsupdater.ini with a text editor, and add the following lines:

[SpecialFlags]
Debug = 1

You should also change

[Flags]
VersionCheck = 1

to

[Flags]
VersionCheck = 0

Normally lsupdater does not detect a LinkStation which already running the firmware revision that came with the updater (this is specified in the file linkstation_version.txt); setting the flag VersionCheck=0 disables this behavior.

How to use the Firmware Updater with Wine

Linux users can also use the lsupdater.exe with wine: just make sure you have the Graphics setting for the Wine windows manager to control the window unchecked "Allow the window manager to control the windows" so you will be able to enter debug mode.

Installation on V1 (OLD hardware) LS PRO using LSUpdater

Initrd-Only Installation:

(This step is NOT for NEW-version hardware, ONLY for OLD-version hardware.)

Important:
Users that have not installed a lb_worm's custom initrd or firmwares containing lb_worm's custom initrd must install the "initrd-only" package before installing FreeLink. Failure to do so may result in a failed install or a bricked old-hardware-version box. The initrd-only package is included in the FreeLink package. Use the updater found in the initrd-only folder to install the initrd-only package (for Live, use Live version of LSUpdater.exe and LSUpdater.ini, see below).

Warning Notices:
When installing the initrd-only package, there will be an error saying "hddrootfs.img not found", "uImage.buffalo not found". That is expected as we are only updating initrd. The errors can be overridden by using the "Debug Mode" for the Buffalo Updater.

Right click on the Buffalo Updater icon in the Windows takbar. If lsupdater.ini has been edited as described above to allow Debug mode to be activated, you will see a choice Debug(D): select it.

In the upper left-hand corner of the menu is an "Update" section. Deselect everything in that section except "Update initrd" and hit "ok".

Then update as usual.

FreeLink Installation

Update BOOT skipped

Users may install FreeLink by using the buffalo updater supplied with the FreeLink package. The FreeLink firmware will be installed in the same manner as the stock firmware except you will skip installing boot (u-boot bootloader) as there is different versions of u-boot.

Please use a wired-ethernet connection to install FreeLink. Wireless-ethernet connections are known to cause problems.

Follow instructions above to use Debug mode. In Debug mode, uncheck Update BOOT as one of the Update options.

Ignore the "Waited for 240[s] seconds but couldn't confirm..." message at the end of the update and click "No" when the updater asks whether it should wait again for a response.

Also ignore any error messages afterwards. The error messages are cause by the fact that FreeLink does not contain the Buffalo Updater Daemon.

ACP_STATE_FAILURE error??:

If you receive the ACP_STATE_FAILURE error message, that means that the /boot partition of the hard drive is filled to capacity. The easiest way to resolve this is with Georg's ACP Commander:

Get console access, dos, terminal, shell it doesn't really matter as long as you can execute the java command.

cd to the directory where you saved acp_commander.jar

Disable your firewall temporarily. (If applicable)

Enter the following (Replacing <IP ADDRESS> with the IP Address of your Linkstation)

java -jar acp_commander.jar -t <IP ADDRESS> -cb

This will clear the boot partition, and now you can retry the firmware update, hopefully with success.

Installation on V1 (OLD hardware) LS LIVE using LSUpdater

(old v1 hardware) LS Live (HS-DHGL):
Please follow the same procedure as for old hardware LS PRO, except that you must first replace the LS PRO version of the LSUpdater that is supplied with the FreeLink distribution with the LS LIVE version of LSUpdater.exe and LSUpdater.ini, These are in the firmware for the LS LIVE which can be downloaded from Buffalo site (it's inside 1.03 or 2.03 firmware for LinkStation Live).
http://www.buffalo-technology.com/support/downloads/linkstation-live/

You will have to modify the LSUpdater.ini file as described above to allow Debug mode to be activated, and to suppress firmware version checking.

(There is no "1.06" firmware for the PRO that resembles the 2.06 firmware for the LS LIVE).

According to a procedure reported in the forum by LS Pro user ado, for 1.10 or 1.11 LSPRO firmware on new hardware,
(and confirmed to work by others) what you must do is:

1. Download FreeLink_arm9-1.0rev2
2. Use LSUpdater.exe (any version, within stock firmware 1.10 or 1.11, or within FreeLink_arm9-1.0rev2) (in Debug mode)
Flash the Linkstation with FreeLink firmware as follows:
Start LSUpdater, and enter Debug mode, as described above:
On the left Debug panel of the Debug mode window, select the boxes for KERNEL,initrd and rootfs
(all of these will be taken from FreeLink_arm9-1.0rev2) ,
but DO NOT SELECT BOOT .
On the right panel, check "Do not check version", and "force update".
(Important: make sure the checkbox for BOOT is NOT checked: leaving "update BOOT" checked when flashing WILL brick your new-hardware LinkStation by replacing the U-Boot loader!)

3. The initial reboot of the Linkstation will fail.
To fix this, you now need to get into EM mode, which will happen after three failed attempts to boot.
Each time the LinkStation boots, it will check 3 things to decide whether to boot into EM mode:
(i) Does a file /etc/hddrootmode exist?
(ii) Does a file /etc/rootfs_ok exist?
(iii) Is the version information in the file /boot/linkstation_release too old?
After you have installed FreeLink and the LinkStation has failed to boot 3 times, since the LinkStation has not found a file /etc/rootfs_ok,
and three failed boot attempts are recorded in /etc/rootfs_booting, the next boot will boot the LinkStation into EM mode.
When your LinkStation is running in EM mode, you can use acp_commander ("java -jar acp_commander.jar -t <IP ADDRESS> -cb") to remove the
root password and start the telnet service. Then telnet to the LinkStation and login as root (no password).
Once you are logged in as root in EM mode, modify the script in /etc/init.d/miconapl from
hdd()
{
## Use same files as linuxrc
ROOTFS_OK=/boot/rootfs_ok
ROOTFS_BOOTING=/boot/rootfs_booting
INITRDMODE=/boot/initrdmode
## Update the filesystem okay flag
date > $ROOTFS_OK
## delete booting file
rm -f $ROOTFS_BOOTING
rm -f $INITRDMODE
}
to:
hdd()
{
## Use same files as linuxrc
ROOTFS_OK=/boot/rootfs_ok
ROOTFS_BOOTING=/boot/rootfs_booting
INITRDMODE=/boot/initrdmode
## Update the filesystem okay flag
date > $ROOTFS_OK
## delete booting file
rm -f $ROOTFS_BOOTING
rm -f $INITRDMODE
##modified to resolve initial freelink boot into EM mode (v2 hardware)
ETC_ROOTFS_OK=/etc/rootfs_ok
ETC_ROOTFS_BOOTING=/etc/rootfs_booting
ETC_INITRDMODE=/etc/initrdmode
date > $ETC_ROOTFS_OK
rm -f $ETC_ROOTFS_BOOTING
rm -f $ETC_INITRDMODE
}
(The modifications above are shown in red).
Now reboot again, the modifications you made will get you out of EM mode.
After this final boot, you should have a working LinkStation PRO running FreeLink.

This procedure is reported to work starting with both 1.10 and 1.11 LSPRO firmware on the new hardware LS PRO.

DO NOT TRY TO FLASH BACK TO 1.03 FIRMWARE, this will brick the (new hardware) LS PRO.

Check the discussion in the forum about LS PRO new hardware.
Successful FreeLink installations of new hardware LS PRO have been reported.

If you have already updated the LS LIVE Buffalo firmware to v2.10 firmware (uses 2.6.16 Linux kernel) I suggest you first flash back to 2.06 (which the new hardware initially came with). This is still available on the Buffalo UK site http://www.buffalo-technology.com/support/downloads/linkstation-live/ . The file is called HS-DHGL_206_013_us.zip.
You will have to edit the file linkstation_version.txt to increase all the listed file dates and versions to be more
recent than the dates of the 2.10 firmware your are downgrading, to trick LSUpdater.exe intp replacing newer firmware with
older firmware. You may also need to activate Debug mode and uncheck "Version Check"

3. Edit linkstation_version.txt to increase the date ROOTFS=2007/06/12 17:54:57 to (say) ROOTFS=2007/06/13 17:54:57
(it just needs to be a later time, as LSUpdater will only replace the Root File System if it thinks the updated
ROOTFS is more recent than the 2.06 one installed on the LinkStation.

4. Rename the file hdrootfs_img to something else (like hdrootfs_img_orig). You will replace this file
with one taken from the FreeLink distribution.

5. Download the FreeLink rev2 distribution. FreeLink_arm9-1.0rev2.zip
Unzip it. Copy (only) its file hdrootfs_img to the Buffalo 2.06 firware update
directory which you have just prepared.

6. Now start LSUpdater, which should find your LinkStation on the network.
I successfully flashed it through a router, but it is highly recomended that you connect
the LinkStation directly to your PC with a crossover ethernet cable.
ALL WINDOWS FIREWALLS SHOULD BE DISABLED. etc.;
Never use a wireless connection for flashing.

7. Once your LSUpdater has found the LinkStation, right click on the Buffalo Update icon in the Windows taskbar
(usually at the bottom of the screen) and activate Debug(D) mode.
In the left panel of the Debug menu, uncheck the first three items
("update BOOT", "update KERNEL" and "update initrd"), and check the box for "update rootfs".
It is very important to NOT to "update BOOT" (to avoid bricking your new-hardware version LinkStation).
In this flash we will also NOT update KERNEL or initrd,
Click OK to exit the Debug menu, and click on "Update" in the LSUpdate menu.

Whatever else you do, NEVER flash a new-hardware Linkstation with LSUpdater.exe unless Debug mode with "update BOOT" UNCHECKED is used:
(You WILL brick a new-hardware LinkStation if you replace its U-boot bootloader with an incompatible one designed for the old hardware.)

When the LinkStation reboots, it will be running Freelink, and the LSUpdater will no longer find it.

Do not be alarmed when the Linkstation eventually reboots (and makes the rebooting chime noises), but LSUpdater reports
that it is still waiting for it to respond.
(You can ping your Linkstation at the IP address shown in the LSUpdater panel to verify that it is alive, and booted).
Ignore the "Waited for 240[s] seconds but couldn't confirm..." message at the end of the update and click "No"
when the updater asks whether it should wait again for a response.

What to do after FreeLink is installed

Now that your LinkStation has successfully rebooted, there are some further tasks to do.

Login

Find your LinkStation on the network and open up an SSH session to it. In windows PuTTY is a good client

login:root

password: lspro

or

login:admin

password: admin

Please NOTE that if the linkstation re-starts itself 3 times then it goes into EM mode

and therefore you will need to re-start it again before
you can proceed. otherwise you may think that the process hasnt worked.

Emergency backdoor

For safety and also to provide a 'back-door' entry in the event of a problem, edit the file /usr/local/bin/initsw.sh and add the following lines to the file:

rm -f /etc/hddrootmode
rm -f /boot/hddrootmode
reboot

Fix hostname and /etc/hosts (mandatory)

Edit /etc/hostname to set your LinkStation Hostname, and make sure /etc/hosts is correct.
The default Buffalo hostnames are LS-GLXXX (Pro) or HS-DHGLXXX (Live) where XXX are the last
three characters of the MAC address (LS-GL7D6 is the default hostname of the system the FreeLink
distribution was developed on). You will find the MAC address on a label on the bottom of
the LinkStation.

You must also make sure that /etc/hosts contains the alias "localhost" for 127.0.0.1, i.e.,
a line:

127.0.0.1 localhost.localdomain localhost

or

127.0.0.1 localhost.localdomain localhost $HOSTNAME

where $HOSTNAME is what you put in /etc/hostname
(if the alias localhost is missing, the scripts /etc/init.d/kernel-server-nfs
and /etc/init.d/openbsd-inetd will not work properly, because they call
rpcinfo -u localhost .... . A consequence is that nfs v3 gets disabled, and you unexpectedly
only get nfs v2 which has limits on file sizes when files are transferred.)

See the Debian Manual for more details about /etc/hostname (e.g. domain is set via /etc/resolv.conf).

Activating your changed hostname without rebooting:

hostname --file /etc/hostname

Allow root login on serial console (if you use it)

root login on console is blocked if /etc/securetty is world-writable

chmod 0744 /etc/securetty

Fix kernelmon script (mandatory check)

There can be an issue with the kernelmon script, that may cause a significant amount of system resources being used and/or having a non-working shutdown button.
This issue mostly occurs when using a newer Linux kernel from Buffalo (e.g from 2.10 Stock FW).

To find out if the kernelmon script is eating up your NAS performance, call "top" and check if the kernelmon script is always at the top of the list with a high CPU load.
Normally the script has a CPU usage of 0%.

To determine whether you can fix it, compare the output of "ls /proc/buffalo" and "ls /proc/driver".
If the subdirectory kernevnt is in /proc/buffalo, make this change; if it is in /proc/driver, do not.
(Without it, things like the shutdown button might not work.)
This is to ensure that the micon interrupt device is pointing to the correct location in the /proc virtual filesystem that is created by the kernel when it is running.

To fix the script do the following:

look in the file /usr/local/sbin/kernelmon script: find a line containing "cat /proc/driver/kernevnt", and change it to "cat /proc/buffalo/kernevnt".

if you needed to make this change, reboot your NAS for the change to take effect

Setting timezone (mandatory check)

To get the correct times for your files and schedules you have to set the correct timezone for the system and the users.

a) for the system in general

dpkg-reconfigure tzdata # otherwise use tzconfig, which is deprecated

b) for the user (e.g. root, admin, etc.)

tzselect
# then copy/add the given line to the user's .profile in his home directory (e.g. TZ='Europe/Berlin'; export TZ)
# if .profile is not available for the user, then just create it (check permissions afterwards)

c) UTC check

grep -e 'UTC' /etc/default/rcS

It should say "UTC=yes" which is the default for Linux/Unix.

Only reason to set it to "UTC=no" is if your machine is running Linux/Unix and a non-UTC-based system (non-UTC-based = local time based).
For instance Windows defaults to local time rather than UTC.
So if you either use these systems separately side-by-side or via a virtual machine (e.g. Debian on Windows), then "UTC=no" will help having the correct time in both systems.

Update of the Debian repository and packages

You can update your system with APT.

It is recommended, even by the Debian maintainers, to use APTITUDE instead of APT-GET, as it keeps track of automatically installed packages and does smarter and safer decisions when upgrading to a new release.
Keep in mind that whenever you are told to use apt-get for maintaining packages, that you replace it with aptitude.

Note as the current UDEV package requires a higher kernel than the 2.6.12.6 kernel of Freelink ARM9 1.0rev2, the UDEV package should not be updated.
Therefore hold the current UDEV package back, to avoid upgrades of it.

To get the latest versions of your installed software, first update the package list and then upgrade the packages.

As there are some scripts as left overs from the hotplug package inside the Freelink image, just purge the hotplug package before upgrading. (Maybe when the Freelink image was build the hotplug package was only removed and not purged.)

To speed up the process of checking for updated packages, you can easily update apt's repository list with a cron job, which is already prepared by Debian.
Just add the following lines to /etc/apt/apt.conf, then your NAS will update the list every morning and you can directly use the upgrade command.

If the file /etc/apt/apt.conf does not exist, then just create it via the following command and add the lines from above.

touch /etc/apt/apt.conf

To undo the holding of UDEV use

aptitude unhold udev

or for dpkg's dselect

echo -e "udev install" | dpkg --set-selections

Set your Locale

You may notice when installing from apt or in other situations that there are some errors about not having the correct locale.

You can fix this with

aptitude install locales

This will give you a few choices on what to set for your default locale.

Static IP address

You can set up a static IP address instead of DHCP.
This is done by editing /etc/network/interfaces.

If you also want to state your local DNS server (e.g. your router) and local domain, then you can not directly modify /etc/resolv.conf, as Freelink 1.0rev2 comes with the resolvconf package installed.
Instead you have to define all DNS data in /etc/network/interfaces for each interface.

NOTE: Do not blindly copy these lines into your file, rather choose the correct IP address and additional information based on your local network settings.
If you don't know what these are, then don't modify this file.

To activate your changes without rebooting:

invoke-rc.d networking restart

To see that the change of the domain has occured:

hostname -f

For more information about DNS settings via resolvconf see the README file:

zcat /usr/share/doc/resolvconf/README.gz

Customized Partitions

You may not have enough space to install all the Applications you want to. If you have customised partitions, you will have enough space to install other applications (like webmin)
Here you can see, how to do this:

Updating your kernel (not always necessary)

Securing Your Linkstation

Limit and/or remove the "guest" account

Note that the Guest account is a common attack point. This account can be used for system testing, but can be compromised due to default password in a Debian install. Further the Guest account by default in Debian 2.6 is capable of executing BASH scripts allowing system reconfiguration.

You can simply lock the Guest account ...

passwd guest -l

Change and protect your passwords

Anyone who can see your NAS on the network can of-course log into it as the root user (=full control!) with the default password, and make it their own.

Therefore change the passwords for the users root and admin using (as root):

passwd
passwd admin

Please do not use the same password for both accounts.

As /etc/passwd and /etc/group must be world-readable the passwords in them can be read and cracked. Therefore it is recommended to turn on shadow passwords, so only user root can see the encrypted passwords.

pwconv (for user passwords)
grpconv (for group passwords)

You should avoid group passwords, as those shared passwords are a typical security breach.

It is just as important to change the ssh server keys (see section below).

Limit which users and IPs can have access to SSH and su/sudo

If you don't want the trouble of using a ssh key pair (see below) then limit the range of IP and users that can have ssh access vis the sshd configuration file /etc/ssh/sshd_config.

Before your box has an active ssh port open to the internet, initially it is recommended that you basically shut off root access and only allow access via su or sudo for given users. This makes access to the box narrow and root execution via two passwords, via ssh and then su/sudo.

You can add the following line to /etc/ssh/sshd_config to disable root ssh access.

Create Unique SSH server keys for your machine

Due to the way that Freelink is currently installed, you will be using the ssh server keys that are distributed with the freelink archive. As these are publicly available, unless you change these, then your Linkstation will be vulnerable to both "Man-In-The-Middle" attacks - whereby someone impersonates your machine, and passes data along to the real machine (recording, and potentially altering data as they do so), and eaves-dropping (whereby they can decode the encrypted ssh data, as long as they can read the data that is being exchanged between the linkstation, and the machine which they are logging in from).

rm /etc/ssh/*host*key*
dpkg-reconfigure openssh-server

Whereupon you should see:

Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Restarting OpenBSD Secure Shell server: sshd.

After this is finished, you can log out, and log back in again. When you try to, you will see a message like:

$ ssh root@linkstation
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
e2:74:96:43:fd:21:57:9e:94:ca:fa:8b:64:05:0c:23.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:56
RSA host key for linkstation has changed and you have requested strict checking.
Host key verification failed.

You are seeing this message because you have changed the host key (if someone really was doing a man-in-the-middle attack with the old key, you wouldn't see this message, as they would have the correct key to not-trigger the error report). Remove the old key from your ssh known_hosts file (in this case line 56 of /home/user/.ssh/known_hosts), and log in again... This time it should proceed as normal.

Your Linkstation is now secure - ideally, you should not have placed the Linkstation on an untrusted network before you reach this stage.