GenLink for ARM9

From NAS-Central Buffalo - The Linkstation Wiki
Revision as of 01:54, 16 September 2008 by Laitr Keiows (Talk | contribs)

Jump to: navigation, search
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. 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!



Contents

GenLink on the LS-GL (manual install)

Nuvola apps important.png 
WARNING!

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

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


Modify Initrd

To boot another firmware you need an modified Initrd. You can use for example lb_worm's 'Modified Initrd' or 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.


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

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

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.

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

NOTE: At this time the IP address of the server is 89.149.216.143, that will change and this will need updating after the beginning of September. Post a reminder if you get a 404 error.

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 '140.211.169.172 downloads.nas-central.org' >> /etc/hosts

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

 cd /mnt/sda2
 wget http://buffalo.nas-central.org/download/LSPro_ARM9/Distributions/Genlink/Rootfs/GenLink-stage3.1_arm9-1.1_rc1-20080910.tar.bz2

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_rc1-20080910.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 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, and also do not work (Laitr Keiows reported in the 'Genlink broken?' thread) that micro_evtd causes the root partition to be mounted read-only. 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

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

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:

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

Emerge the basic system just from already built packages hosted at 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).

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

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

 emerge system --getbinpkgonly --usepkgonly

This will take some time at first run (maybe 5 to 10 minutes), as a cache is calculated for the binary packages repository. 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 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 timezone. Mine looks like this:

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

emerge net-misc/openssh

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.

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:

 emerge --getbinpkgonly --usepkgonly layman --pretend --verbose
 emerge --getbinpkgonly --usepkgonly 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):

 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  : http://www.gentoo.org/proj/en/overlays/layman-global.txt
               file://%(storage)s/overlay_orion5x.xml
  • /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

 ddclient
 hplip
 sqlite (3)
 mt-daapd
 mldonkey
 squirrelmail
 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)

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.
  • 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 12 September 2008 (EST)--