GenLink for ARM9

From NAS-Central Buffalo - The Linkstation Wiki
(Redirected from GenLink)
Jump to: navigation, search

There is a possibility that you could brick your NAS with these instructions. Please make sure that you read the entire page carefully. It is easy to recover your bricked LS-GL, but you have to disassemble it. Disassembling may void your warranty or cause severe damage of the hardware!

GenLink on the LS-GL or LS-CL (manual installation)

Nuvola apps important.png 

Please note that you will lose your warranty - don't blame me if anything goes wrong!

At the moment, to get Gentoo running on the Linkstation Pro your only choice is manually unpack the latest Genlink_arm9 rootfs image to your /dev/sda2. The rootfs image consists of a typical Gentoo stage3, with very few modifications, and pre-configured to give you the possibility to emerge several binary packages, without having to compile them yourself.
Don't be scared off by the rather long instructions, actually they were even longer in their first version :-). Please make sure to read them through and understand them before starting to install Gentoo!


Get needed packages

Download all the packages needed in the further process, because in EM mode you have no way to get them easily.

Boot into EM mode

There are two ways to boot into EM-mode:

  • The complex one uses several reboots according to EM-mode
  • The simple one needs the ACP Commander. It allows to switch to EM mode via:
java -jar acp_commander.jar -t <linkstation-ip> -emmode

and opens an telnet server via:

java -jar acp_commander.jar -t <linkstation-ip> -o

Correcting System Date/Time

Before installing any files, it is a good idea to make sure that the system date and time are correct. If you don't do this, the files you install will be dated in the past or future, which can cause confusion later on. To check the system date and time, run:


If the date or time is incorrect, you can set the correct time with a command like:

 date -s "Aug 11 16:12:34 2009"

Then, (try to) synchronize the hardware clock with the newly set system clock:

 hwclock --systohc

Install Modified Initrd/Kernel

To boot another firmware, you need a modified Initrd. One initrd that will work is lb_worm's 'Modified Initrd'. Alternatively, you may install the Genlink tarball, which you only have to unpack over /dev/sda1 in order to have a custom initrd, a modified stock kernel with NFS and usb-printer support pre-configured to boot an alternative distribution. Note: Unpacking the Genlink tarball will overwrite your existing initrd.buffalo (initrd) and uImage.buffalo (kernel) files. It is highly recommended that you save backups of the stock initrd and kernel in case the modified initrd or GenLink kernel fail to boot.

Of course, if your box was already setup to boot an alternative firmware, you won't need to replace the stock kernel and initrd. This is most likely the case if the contents of your /dev/sda1 looks similar to:

 drwxr-xr-x  3 root root    1024 Feb 21 07:29 .
 drwxr-xr-x 20 root root    4096 Feb 27 01:17 ..
 -rw-r--r--  1 root root     722 Feb 20 22:29 boot_options
 -rw-r--r--  1 root root       0 Feb 20 15:36 hddrootmode
 -rw-r--r--  1 root root 4563579 Dec 27 23:29 initrd.buffalo
 -rw-r--r--  1 root root      84 Dec 15 23:27 linkstation_release
 drwx------  2 root root   12288 Jan 21 10:19 lost+found
 -rw-r--r--  1 root root      29 Feb 21 07:29 rootfs_ok
 -rw-r--r--  1 root root 1942020 Dec  5 23:26 uImage.buffalo

The contents of the file boot_options should look similar to this:

 ## Correct MAC address
 setMAC -s 00:16:01:A4:E0:2A
 ## WOL port options in standby.  Remove if WOL not required.
 ## Set to YES if not a stock box, comment out if stock box
 ## Define root path, comment out if stock box
 ## Advanced use only, specify system area format
 SYSTEM_FORMAT="mkfs.xfs -d agcount=4 -l size=32m"
 ## Default is 509MB, set to size required and following update the disk
 ## will be re-sized.  WARNING: Is destructive.
 ## Set menu timeout (secs), default is 4.  Disable, set to 0 or OFF. For
 ## EM mode set to EM
 ## Set to YES to delete hdd image following update or NO to leave it
 ## Reset watchdog & fan as micocontroller does not do this after reboot
 micro_evtd -q -s 013501,013300

The bold and italic lines should be exactly as shown in order to boot an alternative firmware (distribution). The file rootfs_ok should also contain a fresh date, but you needn't worry about the contents of rootfs_ok right now. We'll come back to it later in these instructions, right before booting into the newly installed system.

Important Note For LS-CL Installs:

If you're installing GenLink to a LS-CL (the black LinkStation EZ), the kernel supplied in the Genlink tarball above will not boot. If you use the kernel in this GenLink tarball, the LS-CL will spin down the hard drive, the amber light will come on and stay on, and you will not be able to access the LinkStation. EM Mode isn't even accessible in this state, and you will have to remove the hard drive in order to replace the kernel with one that works. Using the stock kernel that came with the LS-CL, with the initrd.buffalo from the Genlink tarball, however should boot just fine on a LS-CL.

Re-partitioning (if you haven't previously)

While booted into EM-mode, if your /dev/sda2 partition wasn't already enlarged to at least 3-4GB, please do it now (check the respective wiki article about custom partitions on the LS-Pro if necessary, and format it to ext3 (or xfs, jfs if you know there are no more issues on arm9 with these filesystems)

Optional partitions (if not created previously)

While you're at resizing the big data partition anyway, create another logical partition behind it, of approx. 3-4GB for gentoo portage (if you won't, you still can make a symlink /mnt/xtra to point to some directory on the big partition. If you added that xtra partition, you might also want to add one for mounting later in /home to use it also for your workstations in the LAN if you make your LSpro a server. Format these partitions as ext3, too.

Installation, while still in EM boot

Actuially, this is where you can directly start in case you already did the previous steps some other time.

Mounting needed partitions

Mount the needed partitions (create mount points yourself, as necessary):

mount -t ext3 /dev/sda1 /boot
mount -t xfs /dev/sda2 /mnt/sda2

Optional quick backup of old system on the same partition

If your system partition mounted under /mnt/sda2 still contains an old system at this point (simply because you didn't have to resize it just now, since you already did it in the past, or this is a re-installation, if you want to keep that old system at least until the new one boots, you can quickly backup that system to a 00_backup directory on the same partition:

 mkdir -p /mnt/sda2/00_backup
 mv -r /mnt/sda2/* /mnt/sda2/00_backup

Ignore the error message about 00_backup, it's normal. Now your /mnt/sda2 should contain that backup directory, at most, your system partition is now ready for installation.

Downloading the latest rootfs image

If your initrd can't resolve names, put the download address in your /etc/hosts, it's only in RAM anyway. If you don't, your wget will be in trouble with the path on the virtual http server on Linkstationwiki:

 echo '' >> /etc/hosts

Just paste the link from the internet browser from your desktop:

 cd /mnt/sda2

Note: The stage 3 tarball listed above is based on an older (as of Aug 2009) version of Gentoo. If you want to use this stage 3 tarball with a current portage tree, some workarounds will be necessary. These workarounds are described in the appropriate sections below.

Note: You could also have downloaded the rootfs image to your data partition, maybe before booting into EM-mode or if you had the HDD mounted in your desktop, and now before unpacking you should then have made a symlink to the actual archive, on /mnt/sda2 to unpack it to the right place.

Unpacking the rootfs image

Make sure you execute the following command while your current directory is cd /mnt/sda2, regardless if the rootfs archive is a real file or a symlink pointing to another partition:

 tar xvjpf ./GenLink-stage3.1_arm9-1.1_rc3-20080923.tar.bz2

Important: Adjusting the network setup before rebooting

If you can't use DHCP, or want to adjust the fallback IP in case DHCP does not work, edit network configuration in /mnt/sda2/etc/conf.d/net (in EM mode, your only choice is vi), either leave the DHCP configuration active, as it is, and only edit the fallbacks, or comment the DHCP section and uncomment the static configuration and edit it according to your LAN. The DNS entry at the end of the file is common for both scenarios, it will automatically overwrite /etc/resolv.conf, please adjust that, too.

If you want to change the hostname from the default GenLSPro, edit /mnt/sda2/etc/conf.d/hostname.

Important: Configuring the initrd to boot the HDD

Depending on the initrd used, you may have to adjust/touch the respective tracer files on your /dev/sda1 partition:

 touch /boot/hddrootmode
 date > /boot/rootfs_ok

Important: Adjusting /mnt/sda2/etc/fstab according to your partition scheme

Regardless if you created the optional partition(s) above, edit /mnt/sda2/etc/fstab and uncomment/adapt the respective line(s) to mount /mnt/xtra, but most important adapt the filesystem types to those you've chosen for your partitions.

Important: If you're installing on a Linkstation Mini - micro_evtd & microapl do not work

At least for now, you can disable the micro_evtd service and any other call to microapl, as these are not needed on the Linkstation Mini to keep it alive. They are useless on LS Mini. Therefore, remove the micro_evtd service from the boot runlevel:

rm /mnt/sda2/etc/runlevels/boot/micro_evtd

and also comment the line in /mnt/sda2/etc/conf.d/local where microapl is called:

sed -i "s#/usr/sbin/microapl#\#/usr/sbin/microapl#" etc/conf.d/local


At this point, you may also edit the keymap in /mnt/sda2/etc/conf.d/keymaps if you want to use non-US when Gentoo boots.

Time to flush all buffers and reboot!!


First boot of the new Genlink rootfs - password "lspro"

While rebooting, after some while the power-LED will stop blinking and stay solid green, the boot process will last a bit longer for the first time, because SSHD will create new RSA keys, and finally you'll hear the I'm here sound signalizing that you're ready to ssh to your box. If you succeed to get a login prompt, log in as root with the password lspro, then you should see this:
GenLSPro login greeting.png

Confirm System Date/Time

The first thing you should do after logging into GenLink is confirm that, after rebooting, the system still has the correct date and time, as described above. If the time or date shown is incorrect, set it to the current date and time.

Set Root Password

The second thing you should do after logging into GenLink is set a password for root:


As always, make sure to use a password that can be remembered reliably, but is hard to guess.

Symlinking /mnt/xtra if not created as separate partition

If you did not create /mnt/xtra while editing /etc/fstab before first booting the new Genlink, then just make a symlink /mnt/xtra point to some directory on your big partition;

Initializing Portage

If this is your first Genlink installation on this Linkstation, or you didn't keep the optional gentoo partition from a previous Genlink installation, you have to initialize portage by running


otherwise just go on to the next step. If you had to start the script, you can take a 20 minutes brake now, after that you may continue with the next step. If you see some errors/warnings like these when the script says Populating portage for the first time..., just ignore them, they're normal given the fact that there is no portage tree yet:

 !!! Unable to parse profile: '/etc/make.profile'
 !!! ParseError: Parent '/usr/portage/profiles/default/linux/arm/2008.0/server' not found: '/mnt/xtra/gentoo/portage_overlays/layman/orion5x/profiles/orion5x/parent'
 WARNING: repository at /mnt/xtra/gentoo/portage is missing a repo_name entry

Finishing basic system (stage3) installation

If you're using the stage 3 tarball listed above, you'll have to downgrade portage to version before you'll be able to emerge updated packages. The version of portage in the tarball (version 2.2_pre-something) doesn't support EAPI 2, but version does. As many of the packages in the current portage tree are only offered under EAPI 2, you first need to emerge portage from source. Fortunately, this is quick and easy:

 emerge --oneshot portage

Due to a problem with the way portage handles dependencies, additional workarounds may be necessary. For example, I had to mask sys-fs/e2fsprogs-1.41.8 (which depends on a masked package) and sys-devel/gcc-4.2.4-r1 (which segfaults during compilation):

 echo =sys-fs/e2fsprogs-1.41.8 >> /etc/portage/package.mask/common
 echo =sys-devel/gcc-4.2.4-r1 >> /etc/portage/package.mask/common

Check the output from emerge to see if it complains about anything else in the portage tree. (It likes to do that.) While this step may require some patience (and coffee), resolving these dependencies generally isn't too hard.

Now, you may emerge the basic system from a combination of pre-built packages (hosted at linkstationwiki), or from source (for those packages which haven't yet been prebuilt). You tell portage to use binary packages with the --getbinpkg and --usepkg. (See emerge --help for details.) The --getbinpkgonly and --usepkgonly tell portage to use binary packages only. However, as of Aug 2009, a binary-only install with this stage 3 tarball is no longer possible. Because of issues in the current portage tree, some of the packages will have to be built from source. So, we'll be using --getbinpkg and --usepkg, and not --getbinpkgonly/--usepkgonly.

Finally, if you add the --pretend switch to your portage command, portage will not actually install any software, but will just show you what packages and dependencies it would emerge:

 emerge --getbinpkg --usepkg --update --pretend --verbose system

Note that, when using portage, the final argument to the portage command is system. If you're still using portage 2.2, the final argument should be @system instead. system and @system are not package themselves, but rather define a whole set of the basic packages required to boot and run a linux system.

If you omit --pretend and --verbose, portage will really start merging all those packages:

 emerge --getbinpkgonly --usepkgonly --update system

If you're lucky enough to be able to do a binary-only install, this should take maybe 5 to 10 minutes. If you're using a combination of prebuilt and source packages, it will take 5 or 6 hours. If you're building from source only, it will take even longer. Go play with the kids. Say hi to your wife. Go for a bicycle ride.

After merging the system packages, timezone-data will have been installed. Now, you can set your timezone by replacing the file /etc/localtime with a symlink to the proper timezone. Mine looks like this:

 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin

Setting up layman, the portage overlay manager

In order to get the buffalo-patched linux headers and other packages which had to be adjusted for usage and compilation on the Linkstation Pro from our overlay later, we want to get the overlay manager layman:

 emerge --getbinpkgonly --usepkgonly layman --pretend --verbose
 emerge --getbinpkgonly --usepkgonly layman

Note: In order to merge layman with a current (Aug 2009) portage tree, you need to merge it without the subversion, git, or test USE flags:

 USE="-subversion -git -test" emerge app-portage/layman

After emerging Layman you will get a notification that a config file in etc needs updating. Run etc-update and discard the updated config file, to keep the original as the original file has been edited for the linkstation overlay already. More on this...

After binary emerging layman, you can check what remote overlays (alternative portage repositories) are currently known to layman:

 layman -L

You can also verify if our overlay is already configured (should be):

 layman -l

should see something like

 * orion5x      [Subversion] (source: http://linkstationwiki.svn...)

which you also should have seen on top of the output of layman -L. You can also try to sync the orion5x overlay to the latest version, by issuing

 layman -S

which would sync all overlays configured locally (at this time, we only have one, if there where more, you can specify which one to sync with lowercase -s, please check layman --help.

Before emerging further pacakges, a note about configuration files

You'll be emerging (installing) packages now, please remember as a rule of thumb, that portage will inform you sometimes after emerging about configuration files in /etc that need updating, and that you should run etc-update to update them. Running this script is convenient, and also recommended, as sometimes configuration files really need to be upgraded to newer versions (some packages might even work badly or not at all if you won't update the configuration files). etc-update will notice if a configuration file has too complex changes compared to the previous version and can't just be overwritten, and will prompt you to decide what to do about those files. Therefore, it is good practice to:

  • try to postpone customizations to configuration files or scripts you intend to do yourself, after upgrading them;
  • in case of being prompted with files you know they have been customized (for those you know they where left as they originally came and you are sure you never customized them, just overwrite them), cancel etc-update, go and edit the new replacement files (they start with ._cfg0000_...) to manually migrate your old settings in the new files, run etc-update again and now you can safely overwrite them all.

These being said, please also consider as customized, the following files, take care when updating them, either keep their old versions (only recommended between minor updates), or manually migrate their settings, paying very special attention to the indicated lines, they have to remain like this:

  • /etc/layman/layman.cfg:
   storage   : file://%(storage)s/overlay_orion5x.xml
   overlays  :
  • /etc/conf.d/local:

There we have some very important calls to prevent the failed hddmode-boots counter in the /boot partition reach 3 and have the LSpro boot into EM mode, and also deleting the udev rule file which might at some point rename the eth0 network interface to eth1 and leave the box unreachable in the LAN...

   local_start() {
       # This is a good place to load any misc programs
       # on startup (use &>/dev/null to hide output)
       # want some kernel debugging over serial console (BREAK)?
       echo 1 > /proc/sys/kernel/sysrq
       echo 9 > /proc/sys/kernel/printk
       # signalize we're up & running
       /usr/sbin/microapl -a bz_imhere 120 am4 d4 f4 am4 d4 f4 dm4 dm4 f4 a4 am4 &>/dev/null
       # Update the filesystem okay flag and delete boot mode trace files
       # on /boot to prevent the boot failure counter reach 3 when we
       # in fact booted Gentoo ok
       date > /boot/rootfs_ok
       rm -f /boot/rootfs_booting
       rm -f /boot/initrdmode
       rm -f /boot/boot.log
       touch /boot/hddrootmode
       # avoid udev renaming 'eth0' bug by deleting this file:
       rm -f /etc/udev/rules.d/70-persistent-net.rules
       # We should always return 0
       return 0
   local_stop() {
       # This is a good place to unload any misc.
       # programs you started above.
       # avoid udev renaming 'eth0' bug by deleting this file:
       rm -f /etc/udev/rules.d/70-persistent-net.rules
       # We should always return 0
       return 0

Therefore, just delete the new proposed ._cfg0000_local file to keep ours. Of course, you can comment out other things like the I'm here melody...

Emerging further useful binary packages

Continue emerging further packages now. Since I want to use postfix as my SMTP agent later, I'd emerge postfix now, otherwise simple smtp would be pulled and compiled due to dependencies of other packages. Well, it's up to you if you emerge postfix now or skip to MC:

 emerge --getbinpkgonly --usepkgonly postfix --pretend --verbose
 emerge --getbinpkgonly --usepkgonly postfix

Midnight Commander and all its dependencies (including really large packages, like samba, cups, ghostscript, php5, apache), plus lots of other useful programs (more to follow) are just waiting at linkstationwiki to be binary emerged:

 emerge --getbinpkgonly --usepkgonly \
 mc pkgconfig nfs-utils ntp cvs proftpd webmin dos2unix unix2dos screen \
 ufed vixie-cron metalog jfsutils gentoolkit genlop phpldapadmin \
 --pretend --verbose

They're many, huh? Now get them:

 emerge --getbinpkgonly --usepkgonly \
 mc pkgconfig nfs-utils ntp cvs proftpd webmin dos2unix unix2dos screen \
 ufed vixie-cron metalog jfsutils gentoolkit genlop phpldapadmin \

And there are still other binary packages, like

 sqlite (3)
 amule (daemon & webui only)
 sys-apps/ksysguard (not kde-base/ksysguard, see  KDE ksysguardd daemon only on the Linkstation)

and the list may continue, please check the contents of the remote binpkg directory (BINHOST, in terms of Using PORTAGE BINHOST)

Monitoring Hard Drive Temperature

If your LS-GL/LS-CL contains a SATA hard drive that supports S.M.A.R.T, you may want to emerge sys-apps/smartmontools. Note: in order for smartctl to recognize a drive attached to the Marvell SATA controller in NAS, you need to pass it the -d marvell option. For example, if you want to see the SMART attributes and values for /dev/sda, you would run:

 smartctl -a -d marvell /dev/sda

One (rather important) SMART attribute you may want to keep an eye on is the one for hard drive temperature. On many drives, the value of attribute 194 is the temperature of the drive in Celsius degrees. If you prefer Fahrenheit, you can convert to Fahrenheit degrees using the formula: F = (C * 9)/5 + 32.

Important Security Note for NFS Users

The the stage 3 tarball from above contains an /etc/exports file with insecure defaults. If you're going to merge net-fs/nfs-utils, make sure to delete, edit, or otherwise fix /etc/exports before you start your NFS server.

Create whatis Database

The whatis and apropos commands provide a useful, searchable index to the man pages on your system. However, to use them, you must first generate an index of the man pages on your system:

 makewhatis -w

Now, typing whatis keyword or apropos keyword should return a list of matching man pages.

Start & configure automatic start for cron and logger

As on any GNU/Linux, service scripts are in /etc/init.d and you can look what's already there, the Gentoo runlevels you should be interested in are /etc/runlevels/boot and /etc/runlevels/default. Add the cron and logger services to the default runlevel:

 rc-update add vixie-cron default
 rc-update add metalog default

Start them in this uptime, too (cron will also pull the logger):

 /etc/init.d/vixie-cron start

Final words

  • Please test how packages actually run and report problems.
  • Don't forget to secure your system (especially if using it as a server).
  • If you want to share your emerged packages because you consider them useful and compilation took a long time (you can always check with genlop -t package-name) , and feel you might want to change USE flags, try to get away with changing them only in /etc/portage/package.use for that specific package and contact someone with developer access to upload the binpkg to the repository.
  • Add services, emerge normally (with compiling) new packages, play with other things, read some Gentoo docs if you're new to Gentoo and have fun with it!

--Zoolook & various contributors (check history)--