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.

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.

<br>

<br>

−

Don't be scared off by the rather long instructions, actually they where even longer in their first version :-). '''Please make sure to read them through and understand them before starting to install Gentoo!'''

+

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!'''

== Preliminary ==

== Preliminary ==

Line 26:

Line 26:

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

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:

+

date

+

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

−

=== Modify Initrd ===

+

=== Install Modified Initrd/Kernel ===

−

To boot another firmware you need an modified Initrd. You can use for example [http://forum.nas-central.org/viewtopic.php?f=19&t=1771 lb_worm's 'Modified Initrd'] or install the [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/boot(sda1)/GenLink-bootSDA1_arm9-20080910.tar.bz2 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.

+

To boot another firmware, you need a modified Initrd. One initrd that will work is [http://forum.buffalo.nas-central.org/viewtopic.php?f=19&t=1771 lb_worm's 'Modified Initrd']. Alternatively, you may install the [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/boot(sda1)/GenLink-bootSDA1_arm9-20080910.tar.bz2 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:

−

Of course, if your box was already setup to boot an alternative firmware previously, you don't need to replace the kernel and the 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 3 root root 1024 Feb 21 07:29 .

drwxr-xr-x 20 root root 4096 Feb 27 01:17 ..

drwxr-xr-x 20 root root 4096 Feb 27 01:17 ..

Line 42:

Line 48:

-rw-r--r-- 1 root root 29 Feb 21 07:29 '''rootfs_ok'''

-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

-rw-r--r-- 1 root root 1942020 Dec 5 23:26 uImage.buffalo

−

The contents of the file '''boot_options''':

+

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

## Correct MAC address

## Correct MAC address

setMAC -s 00:16:01:A4:E0:2A

setMAC -s 00:16:01:A4:E0:2A

Line 63:

Line 69:

## Reset watchdog & fan as micocontroller does not do this after reboot

## Reset watchdog & fan as micocontroller does not do this after reboot

micro_evtd -q -s 013501,013300

micro_evtd -q -s 013501,013300

−

while the '''''bold and italic lines''''' should be exactly as shown, in order to boot an alternative firmware (distribution). Also, '''rootfs_ok''' should contain a fresh date, but more about this in the last section before booting into the newly installed system.

+

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 [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/boot(sda1)/GenLink-bootSDA1_arm9-20080910.tar.bz2 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.

'''''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.''

'''''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.''

Line 108:

Line 120:

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:

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_rc2-20080916.tar.bz2

+

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

=== Important: Adjusting the network setup before rebooting ===

=== Important: Adjusting the network setup before rebooting ===

Line 129:

Line 141:

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

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

−

At least for now, you '''must''' 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:

+

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

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

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

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

Line 142:

Line 154:

reboot

reboot

−

== First boot of the new Genlink rootfs ==

+

== 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:

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:

Line 149:

Line 161:

<br>

<br>

<br>

<br>

+

+

=== 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:

+

passwd

+

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 ===

=== Symlinking '''/mnt/xtra''' if not created as separate partition ===

Line 166:

Line 186:

=== Finishing basic system (stage3) installation ===

=== Finishing basic system (stage3) installation ===

−

Emerge the basic system just from already built packages hosted at [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/Binaries/ linkstationwiki] by issuing the emerge commands with '''--getbinpkgonly''' and '''--usepkgonly''' (PLEASE see '''emerge --help''' and note that the '''--getbinpkg[only]''' switches will download binary packages to '''/var/tmp/binpkgs/All''' and the '''--usebinpkg[only]''' will do the actual binary installation from there, so if you do this later you might skip downloading if you have the binaries ). If you don't use those switches, portage will start to compile packages from the sources it will download (which is most likely what you want if you want even newer packages than those pre-compiled binaries). For now it's more efficient to use the already compiled packages which didn't fit on the initial rootfs image. If you add the '''--pretend''' switch, portage will just show you what packages it would emerge (with respect to required dependencies).

+

If you're using the [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/Rootfs/GenLink-stage3.1_arm9-1.1_rc3-20080923.tar.bz2|20080923 stage 3 tarball] listed above, you'll have to '''''downgrade''''' portage to version 2.1.6.13 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 2.1.6.13 does. As many of the packages in the current portage tree are only offered under EAPI 2, you first need to emerge portage 2.1.6.13 from source. Fortunately, this is quick and easy:

−

emerge system --getbinpkgonly --usepkgonly --pretend --verbose

+

emerge --oneshot portage

−

If you omit '''--pretend --verbose''', emerging all those packages will really start.

+

Due to a problem with the way portage 2.1.6.13 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):

−

emerge system --getbinpkgonly --usepkgonly

+

echo =sys-fs/e2fsprogs-1.41.8 >> /etc/portage/package.mask/common

−

This will take some time at first run (maybe 5 to 10 minutes), as a cache is calculated for the binary packages repository.

+

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

−

'''Note:''' ''system'' is not a package itself, but rather defines a whole set of the basic packages required to boot and run a linux system. Another example is ''world'', which will contain almost all packages you installed, it's useful when you generally

+

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.

−

update packages later.

+

−

Now that the zoneinfo has been installed (as part of the emerge system you just completed), you can replace the file /etc/localtime with a symlink according to your

+

Now, you may emerge the basic system from a combination of pre-built packages (hosted at [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/Binaries/ linkstationwiki]), or from source (for those packages which haven't yet been prebuilt).

−

'''''timezone'''''. Mine looks like this:

+

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'''.

−

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

+

−

Of course, you can also do this later, after you have MC for example, if you're more comfortable.

+

−

'''''After following these instructions and rebooting, the Pro retected ssh connections. Emerge OpenSSH from source to avoid this problem.

+

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 2.1.6.13, 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.

−

emerge net-misc/openssh'''''

+

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

−

Is this actually still needed? Please someone check this with this new Genlink image and update this part in the wiki if it's no longer a problem.

+

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 ===

=== Setting up '''layman''', the portage overlay manager ===

Line 189:

Line 214:

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

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

emerge --getbinpkgonly --usepkgonly layman

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. [[GenLink for ARM9#Before_emerging_further_pacakges.2C_a_note_about_configuration_files| More on this...]]

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. [[GenLink for ARM9#Before_emerging_further_pacakges.2C_a_note_about_configuration_files| More on this...]]

Line 279:

Line 306:

amule (daemon & webui only)

amule (daemon & webui only)

sys-apps/ksysguard (not kde-base/ksysguard, see [[KDE_ksysguardd_on_the_Linkstation| KDE ksysguardd daemon only on the Linkstation]])

sys-apps/ksysguard (not kde-base/ksysguard, see [[KDE_ksysguardd_on_the_Linkstation| KDE ksysguardd daemon only on the Linkstation]])

−

and the list may continue, please check the contents of the [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/Binaries/ remote binpkg directory] (''BINHOST'', in terms of [http://gentoo-wiki.com/TIP_Using_PORTAGE_BINHOST Using PORTAGE BINHOST])

+

and the list may continue, please check the contents of the [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/Binaries/ remote binpkg directory] (''BINHOST'', in terms of [http://en.gentoo-wiki.com/wiki/TIP_Using_PORTAGE_BINHOST 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. hard drive monitoring| 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 [http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/Rootfs/GenLink-stage3.1_arm9-1.1_rc3-20080923.tar.bz2 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:

* 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.

* 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!

* 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!

Latest revision as of 20:29, 22 March 2011

WARNING!

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)

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!

Preliminary

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

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:

date

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:

## Correct MAC address
setMAC -s 00:16:01:A4:E0:2A
## WOL port options in standby. Remove if WOL not required.
WOL=7
## Set to YES if not a stock box, comment out if stock box
OTHER_DISTRIBUTION=YES
## Define root path, comment out if stock box
ROOTPATH=/boot
## 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.
SDA2=909MB
## Set menu timeout (secs), default is 4. Disable, set to 0 or OFF. For
## EM mode set to EM
MENU_TIMEOUT=0
## Set to YES to delete hdd image following update or NO to leave it
REMOVE_HDDROOTFS=YES
## 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

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:

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:

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

Reboot

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!!

sync
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:

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:

passwd

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

/00-post_1st_boot/init_portage.sh

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:

Finishing basic system (stage3) installation

If you're using the stage 3 tarball listed above, you'll have to downgrade portage to version 2.1.6.13 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 2.1.6.13 does. As many of the packages in the current portage tree are only offered under EAPI 2, you first need to emerge portage 2.1.6.13 from source. Fortunately, this is quick and easy:

emerge --oneshot portage

Due to a problem with the way portage 2.1.6.13 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):

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 2.1.6.13, 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 SF.net overlay later, we want to get the overlay manager 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 SF.net overlay is already configured (should be):

which you also should have seen on top of the output of layman -L.
You can also try to sync the orion5xoverlay 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:

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...

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:

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:

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:

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!