Sven and the Art of Computer Maintenance

Sven and the Art of Computer Maintenance

15 Nov 2016

Installing Arch Linux ARM on an Iomega ix2-200

2021-04-22 update

This version of the guide is obsolete. Look here for the 2021 version, which contains some necessary fixes since this was published.

2020-02-11 update

Jens Rommel contacted me and notified me of an issue with recent larger Linux boot files, also referred to in this post on the Arch Linux ARM forum. Thanks!

Systems might not be bootable when updated due to this issue. The remediation requires changes to the load addresses and entry points of the kernel and initramfs images. These changes have been incorporated in this guide. Existing systems can run these commands to update the boot loader (make sure package uboot-tools is installed)`:

fw_setenv memoffset_kernel '0x02000000'
fw_setenv memoffset_initrd '0x08004000'

An already updated and broken system can be fixed through a serial connection by running in U-Boot:

setenv memoffset_kernel '0x02000000'
setenv memoffset_initrd '0x08004000'
saveenv

Do not forget to update /usr/local/sbin/generate-ubootfiles to the newer version in this guide, so the U-Boot headers of future kernel and initramfs images have the correct information. This might not be strictly needed, but it is a best practice for maximum compatibility.

Original post

In this post I explain how to modify an aging network attached storage device with a Linux distribution that will keep its software and functionality up-to-date for the foreseeable future.

The Iomega ix2-200 Network Storage (hereafter, “ix2-200”) is a two disk NAS that was introduced in October 2009 by Iomega, a subsidiary of EMC that later became a joint venture known as LenovoEMC. In 2011 a revised version of the ix2-200 was released, known as the ix2-200 Network Storage Cloud Edition. The revised version has the exact same hardware as the original. The only difference was a newer firmware which supported additional online services to cater to the ‘cloud’ hype. Officially it was not supported, but users were able to upgrade the original ix2-200 to the Cloud Edition.

As of October 15, 2015 all revisions of the ix2-200 have reached their End-of-Service-Life. They will no longer be supported or maintained by LenovoEMC. The last firmware version is 3.2.14.30167, released on August 13, 2015 and available here. It contained a relatively new version of a very old OpenSSL branch (0.9.8zf, released in March 2015) which fixed some vulnerabilities. Since it is such an old branch, recent TLS developments (such as TLS 1.2 and new cipher suites) are not supported. Furthermore, the Linux kernel is version 2.6.31.8, which is older than dirt and has quite a number of security vulnerabilities that will never be fixed.

The ix2-200 uses the Marvell Kirkwood 88F6281 System on Chip (SoC), which houses an ARM9E CPU (ARMv5TE architecture). The SoC is also used in the famous SheevaPlug platform of plug computers. The SheevaPlug and several other ‘pluggable computers’ based on the same SoC were made by Globalscale Technologies. These were quite popular as a hobbyist platform before the cheaper and generally more powerful Raspberry Pi was introduced in 2012. Due to its legacy, the Kirkwood SoC is well supported by many Linux distributions today.

Since the official software of the ix2-200 will only grow more out of date in the future while its hardware is still well supported by the open-source community, I decided to replace its original operating system with Arch Linux ARM. This was quite easy, since the implementation of the Kirkwood SoC in the ix2-200 is almost the same as that of Globalscale Technologies’ OpenRD reference design platform, which is fully supported by Arch Linux ARM.

This post contains instructions to install Arch Linux ARM on an ix2-200. Following these instructions could result in a fresh Arch Linux ARM installation on a set of two disks in RAID1. Note that this will not give you the sparkling web-interface and out-of-the-box experience of the ix2-200, which you will lose.

Step 1: Installation medium preparation

An Arch Linux ARM installation medium has to be prepared to install the operating system. The installation disk can be either a USB flash drive or a SATA disk. A USB flash drive has the advantage that it is easy to prepare, and is the recommended medium.

Requirements:

  • An Arch Linux, Debian Linux or Ubuntu installation. This can be a virtual machine that supports USB passthrough (e.g. using Oracle VirtualBox).
  • A USB thumb drive or SATA disk.

It is assumed that /dev/sdb is the device detected by your Linux installation to be prepared as an installation medium for the ix2-200. Make sure you verify whether this is the right device (e.g. by running dmesg after connecting a USB thumb drive).

SATA disks must be initialized before they are usable. Any existing RAID superblocks have to be removed. Only run the following commands on a Linux machine that does not utilize RAID. Otherwise, stop only the relevant /dev/md* devices by examining /proc/mdstat using cat /proc/mdstat.

ls -al /dev/md*
mdadm --stop /dev/md*
mdadm --zero-superblock /dev/sdb*

If it is not possible to stop and remove some of the superblocks, run:

dd if=/dev/zero of=/dev/sdb bs=1M count=16

Reboot the system used to prepare the installation disk and any old RAID arrays should not be detected anymore.

Use fdisk to partition the disk:

fdisk /dev/sdb
  • Use o to create a clean DOS partition table.
  • Use n to create a new partition, type: primary, number: 1, first sector: default, last sector: +256M.
  • Use n to create a new partition, type: primary, number: 2, first sector: default, last sector: +8G (or the rest of the remaining free disk space if smaller).
  • Use p to see the new partition table.
  • If ID and Type are not ‘83 Linux’ for both partitions: Use t to change a partition’s type. Type must be 83.

Use w to write the changes to disk.

Create and mount the file systems, and download and extract Arch Linux ARM using the following commands. If bsdtar is unavailable, tar can be used instead with the same parameters. Warnings about ignored unknown extended header keywords can be ignored.

mkfs.ext2 /dev/sdb1
mkfs.ext4 /dev/sdb2
e2label /dev/sdb1 BOOT
e2label /dev/sdb2 ROOT

mount /dev/sdb2 /mnt
mkdir /mnt/boot
mount /dev/sdb1 /mnt/boot

cd /mnt
wget http://os.archlinuxarm.org/os/ArchLinuxARM-kirkwood-latest.tar.gz
bsdtar -xpf ArchLinuxARM-kirkwood-latest.tar.gz
rm ArchLinuxARM-kirkwood-latest.tar.gz

Now a U-Boot image of the initramfs has to be created. This makes it readable by the boot loader of the ix2-200.

apt-get install u-boot-tools # If Debian or Ubuntu is used to create the installation medium
pacman -S uboot-tools # If Arch Linux is used to create the installation medium
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x08004000 -n "Arch Linux ARM initrd" -d /mnt/boot/initramfs-linux.img /mnt/boot/uInitrd

Network support has to be enabled on the installation medium. eth0 is an internal network card that is not used by the ix2-200. eth1 is the actual Gigabit Ethernet adapter wired to the network port on the rear of the unit. eth1 must be enabled and eth0 must be disabled.

sed 's/eth0/eth1/g' /mnt/etc/systemd/network/eth0.network > /mnt/etc/systemd/network/eth1.network
rm /mnt/etc/systemd/network/eth0.network

DHCP will be used to assign an IP address to eth1. /mnt/etc/systemd/network/eth1.network can be edited to assign a static IP address instead. An example configuration:

[Match]
Name=eth1

[Network]
DHCP=no
Address=192.168.1.2/24
Gateway=192.168.1.1
DNS=192.168.1.1

Preparation of the installation medium is now complete. Run the following commands to dismount the installation medium safely:

cd /
sync
umount -R /mnt

Disconnect the prepared installation medium.

Step 2: ix2-200 preparation

Before the installation medium can be booted it is required to configure the ix2-200. This can be done in two ways: the ‘headless’ preparation and the ‘console’ preparation.

The headless preparation can be done if a disk with the original ix2-200 software set is available. No additional hardware is required.

The console preparation can be done without any disks. For this, the ix2-200 has to be opened and a TTL serial interface has to be connected to the internal serial port.

The headless preparation method is recommended. If a disk with the original ix2-200 software set is not available, it can also be created. Follow the instructions in ‘Appendix B: Restore the original ix2-200 firmware’ to prepare such a disk.

Headless preparation

The requirements for this method are:

  • An ix2-200 with at least one disk running the original firmware.
  • A network connection to the ix2-200.
  • An SSH client. Tested clients include PuTTY and OpenSSH.

First, enable SSH access. Power up the ix2-200. For the non-Cloud Edition of the ix2-200, visit: http(s)://hostnameorip/support.html For the Cloud Edition of the ix2-200, visit: http(s)://hostnameorip/diagnostics.html

Now login using an SSH client (such as PuTTY). The SSH username is root. The SSH password is soho concatenated with the web-interface admin password. If the web-interface does not require a password, the SSH password will simply be soho. If the web-interface password would be password, the SSH password would be sohopassword. If the web-interface is configured with a password you do not have or the (static) IP address is not available, press and hold the reset button on the back of the ix2-200 for 15 seconds. The ix2-200 will reboot to factory defaults and use DHCP to request an IP address. Re-enable SSH (if required) and use soho as the SSH password.

Run the following command in an SSH session:

fw_printenv

Copy all output text to a file on the SSH client named “nandconfig.txt”. This is a backup of the ix2-200’s original NAND configuration. Keep it safe in case you ever need to recover it.

Now run the following commands to reconfigure U-Boot, the boot loader of the ix2-200. These commands will allow the ix2-200 to boot Arch Linux ARM from the installation medium and from the disks after it has been installed. It is possible to copy/paste all commands in one go.

fw_setenv ethaddr 'AA:00:00:00:00:01'
fw_setenv mainlineLinux 'yes'
fw_setenv arcNumber '1682'

fw_setenv bootargs_console 'console=ttyS0,115200'
fw_setenv bootargs_mtdparts 'mtdparts=orion_nand:640k(u-boot)ro,16k(u-boot-env),-(iomega-firmware)ro'
fw_setenv bootargs_root 'root=LABEL=ROOT rw'

fw_setenv memoffset_kernel '0x02000000'
fw_setenv memoffset_initrd '0x08004000'

fw_setenv bootargs_combine 'setenv bootargs ${bootargs_console} ${bootargs_mtdparts} ${bootargs_root}'
fw_setenv bootlinux 'bootm ${memoffset_kernel} ${memoffset_initrd}'

fw_setenv usb_load_firstdevice 'ext2load usb 0:1 ${memoffset_kernel} /uImage; ext2load usb 0:1 ${memoffset_initrd} /uInitrd'
fw_setenv usb_load 'run bootargs_combine; usb reset; run usb_load_firstdevice; run bootlinux'

fw_setenv sata_load_disk1 'ext2load ide 0:1 ${memoffset_kernel} /uImage; ext2load ide 0:1 ${memoffset_initrd} /uInitrd'
fw_setenv sata_load_disk2 'ext2load ide 1:1 ${memoffset_kernel} /uImage; ext2load ide 1:1 ${memoffset_initrd} /uInitrd'
fw_setenv sata_load 'run bootargs_combine; ide reset; run sata_load_disk1; run sata_load_disk2; run bootlinux'

fw_setenv bootcmd 'run usb_load; run sata_load'

Now power down the ix2-200 and continue with step 3.

Console preparation

The requirements for this method are:

  • A Philips M1 screwdriver.
  • A USB to TTL serial adapter with support for +3.3V. Recommended serial adapters include the CP2102 and any FTDI-based adapters. Avoid adapters made by Prolific, since their drivers are crippled on purpose. Expect BSODs with Prolific adapters when running certain terminal software (e.g. PuTTY) or when a counterfeit chip is used. Note that it is impossible for a consumer to know whether a chip is counterfeit or not. Tested software includes PuTTY and Tera Term.

Access to the main board of the ix2-200 is required. Follow this procedure to remove the main board:

  1. Remove the 4 large screws from both HDD bays on the bottom.
  2. Remove the HDD bays.
  3. Remove the 4 small screws on the rear.
  4. Remove the plastic bracket from the rear.
  5. Remove the 2 small screws under the front side of the two front rubber feet.
  6. Remove the main board by sliding it from the rear to the front.

Locate the serial interface on the mainboard. The interface has the label JP1. Connect the serial adapter to this interface using the following pinout (JP1 = pin 1):

  • Pin 1: Do NOT connect. This pin provides +3.3V and is not required for USB UART serial adapters.
  • Pin 2: TxD. Connect to RxD of the serial adapter.
  • Pin 3: GND. Connect to GND of the serial adapter.
  • Pin 4: RxD. Connect to TxD of the serial adapter.

Open in the terminal software the relevant serial port using the following parameters:

  • Baud rate / speed: 115200
  • Data bits: 8
  • Parity: None
  • Stop bits: 1
  • Flow control: XON/XOFF

Power on the ix2-200 (without any installed disks) by connecting the power adapter while monitoring the terminal software. Press enter at the autoboot prompt to abort the boot process and to remain in the boot loader.

In the shell of U-Boot, run:

printenv

Copy all output text to a file on the SSH client named “nandconfig.txt”. This is a backup of the ix2-200’s original NAND configuration. Keep it safe in case you ever need to recover it.

Now run the following commands to configure the ix2-200. These commands will allow the ix2-200 to boot Arch Linux ARM from the installation medium and from the disks after it has been installed. Do NOT copy/paste all commands since this will result in incomplete executed commands due to the lack of flow control on the serial interface in U-Boot. A copy/paste of each line separately should be OK. In Tera Term, it is also possible to copy/paste all commands if the paste delay per line is configured as 250 ms.

setenv ethaddr 'AA:00:00:00:00:01'
setenv mainlineLinux 'yes'
setenv arcNumber '1682'

setenv bootargs_console 'console=ttyS0,115200'
setenv bootargs_mtdparts 'mtdparts=orion_nand:640k(u-boot)ro,16k(u-boot-env),-(iomega-firmware)ro'
setenv bootargs_root 'root=LABEL=ROOT rw'

setenv memoffset_kernel '0x02000000'
setenv memoffset_initrd '0x08004000'

setenv bootargs_combine 'setenv bootargs ${bootargs_console} ${bootargs_mtdparts} ${bootargs_root}'
setenv bootlinux 'bootm ${memoffset_kernel} ${memoffset_initrd}'

setenv usb_load_firstdevice 'ext2load usb 0:1 ${memoffset_kernel} /uImage; ext2load usb 0:1 ${memoffset_initrd} /uInitrd'
setenv usb_load 'run bootargs_combine; usb reset; run usb_load_firstdevice; run bootlinux'

setenv sata_load_disk1 'ext2load ide 0:1 ${memoffset_kernel} /uImage; ext2load ide 0:1 ${memoffset_initrd} /uInitrd'
setenv sata_load_disk2 'ext2load ide 1:1 ${memoffset_kernel} /uImage; ext2load ide 1:1 ${memoffset_initrd} /uInitrd'
setenv sata_load 'run bootargs_combine; ide reset; run sata_load_disk1; run sata_load_disk2; run bootlinux'

setenv bootcmd 'run usb_load; run sata_load'
saveenv

Now power down and re-assemble the ix2-200. Continue with step 3.

Step 3: Install Arch Linux ARM using the prepared installation medium

If in step 1 a USB thumb drive was prepared, install two disks with similar capacities in the HDD bays (if not already installed) and connect the thumb drive to any of the USB ports of the ix2-200.

If in step 1 a SATA disk was prepared as an installation medium, place the installation medium in HDD bay 2. Place another SATA disk with a similar capacity in HDD bay 1.

Now power up the ix2-200. It should boot from the prepared installation medium. Monitor your DHCP server on any newly assigned leases if DHCP was configured, or monitor the static IP that you configured manually. Once it has booted up, establish an SSH connection. Use alarm as username and alarm as password. Once logged in, use su root to get root access using the password root.

Start by loading some kernel modules. These have to be loaded now to avoid any reboots during the installation process. Run the following command:

modprobe raid1

Note that by loading the ‘raid1’ module, other required modules will automatically be loaded.

Arch Linux ARM needs to be fully up-to-date before new packages can be installed. See the Arch Linux Wiki for more information. Run the following commands (where sdX is either sda when the system was booted using a USB thumb drive, or sdb when the system was booted using a SATA disk in HDD bay 2):

mount /dev/sdX1 /boot
pacman -Syu

Now install the required packages by running:

pacman -S gptfdisk rsync uboot-tools

It is required to switch to a kernel line that supports device trees to support the buttons and LEDs on the front of the ix2-200, and to be able to power down the system in a safe manner. A warning will be shown about that the system will not be able to boot without user intervention when the pacman command is executed. This warning can be ignored, since the required user intervention is in the commands that follow. Run the following commands:

pacman -S linux-kirkwood-dt
cp /boot/zImage /boot/zImage-dtb
cat /boot/dtbs/kirkwood-iomega_ix2_200.dtb >> /boot/zImage-dtb
mkimage -A arm -O linux -T kernel -C none -a 0x02000000 -e 0x02000000 -n "Arch Linux ARM kernel" -d /boot/zImage-dtb /boot/uImage

Arch Linux ARM will be installed to the disk in HDD bay 1 (/dev/sda). After the installation a RAID1 array will be constructed. Start by destroying any old RAID superblocks if one or both of the disks were used previously. Run the following commands:

mdadm --stop /dev/md*
mdadm --zero-superblock /dev/sda*
mdadm --zero-superblock /dev/sdb*

Now partition the disk in HDD bay 1. Run the following command (where sdX is sdb if the system was booted using a USB thumb drive, or sda if the system was booted using a SATA disk in HDD bay 2):

gdisk /dev/sdX

Use o to create a clean GPT partition table Use n to add partition 1, default first sector, +256M size, type hex code FD00 (Linux RAID). Use n to add partition 2, default first sector, +8G size, type hex code FD00 (Linux RAID). Use p to see the current GPT partition table and the remaining free space. Use n to add partition 3, default first sector, the size slightly smaller than the remaining free space, type hex code FD00 (Linux RAID). Use r to enter recovery/transformation mode. Use p to see the current GPT partition table. Use h to create a hybrid MBR. Only add GPT partition 1 (which will be /boot, ext2) to the hybrid MBR. Do not allow the EFI GPT partition entry to be placed first in the MBR (n). Use MBR hex code 83 for the partition type in the MBR. Bootable flag does not have to be set (n). Do not use the unused partition space(s) to protect partitions (n). Use o at the recovery/transformation command prompt to see the new hybrid MBR. Use w and y to write all changes to disk.

Create and initialize an incomplete RAID1 array. You can ignore any warnings about that the array might not be suitable for boot. Run the following commands (where sdX is sdb if the system was booted using a USB thumb drive, or sda if the system was booted using a SATA disk in HDD bay 2):

mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90 /dev/sdX1 missing
mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdX2 missing
mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sdX3 missing

mkfs.ext2 /dev/md0
mkfs -t ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/md1
mkfs -t ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/md2

e2label /dev/md0 BOOT
e2label /dev/md1 ROOT
e2label /dev/md2 DATA

The way the ext4 partitions are formatted will take some time, but it will save disk I/O after the installation. See this page for more information.

Publish information about the RAID1 array for automated assembly at boot. Add the following new lines to the bottom of /etc/mdadm.conf:

ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md1 devices=/dev/sda2,/dev/sdb2
ARRAY /dev/md2 devices=/dev/sda3,/dev/sdb3

Add the following new lines to the bottom of /etc/fstab:

/dev/md0  /boot  ext2  defaults,noatime  0  0
/dev/md1  /      ext4  defaults,noatime,barrier=1  0  0

Add mdadm to HOOKS in /etc/mkinitcpio.conf. An example of the modified line:

HOOKS="base udev autodetect modconf block filesystems keyboard fsck mdadm"

Now it is time to create an initramfs, which is required to notify the kernel at boot that the system uses a RAID1 array. Run the following commands:

mkinitcpio -p linux-kirkwood-dt
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x08004000 -n "Arch Linux ARM initrd" -d /boot/initramfs-linux.img /boot/uInitrd

It is recommended to enable access to U-Boot’s configuration parameters in Linux in case changes are required at a later time. Edit /etc/fw_env.config. Add the following new line to the end of the file:

/dev/mtd1  0x0000  0x4000  0x4000

Copy all data from the installation medium to the single RAID1 disk. Run the following commands:

mount /dev/md1 /mnt
mkdir /mnt/boot
mount /dev/md0 /mnt/boot
rsync -aAXq --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/lost+found"} / /mnt
sync
umount -R /mnt

Now power down the ix2-200 by running shutdown now and by unplugging the power after the disks are switched off. The installation is complete. If you used a USB thumb drive, remove it now.

If you used a SATA disk as the installation medium, leave it connected to be used as a second disk for the RAID1 set after the next boot. Otherwise, this is the time to replace the disk. The ix2-200 is configured to boot from the disk in HDD bay 1 before trying the disk in HDD bay 2. This was the reason why the earlier instructions noted that the installation medium SATA disk should be in HDD bay 2 for this step.

Step 4: Make the RAID1 array complete

Power up the ix2-200 and establish an SSH connection. It will have the same IP that was used during the installation, unless you used DHCP and have a jumpy DHCP configuration. In that case, monitor the assigned leases on your DHCP server.

Make the RAID1 array complete by preparing and adding the second disk.

#Copy GPT partition layout from the first disk to the second disk
sgdisk -b /root/raid1.gpt /dev/sda
sgdisk --zap-all /dev/sdb
sgdisk -l /root/raid1.gpt /dev/sdb

#Add the second disk to the existing RAID1 array
mdadm /dev/md0 -a /dev/sdb1
mdadm /dev/md1 -a /dev/sdb2
mdadm /dev/md2 -a /dev/sdb3

#Verify that rebuild of the RAID1 array has started.
#Also see: https://raid.wiki.kernel.org/index.php/Mdstat
watch cat /proc/mdstat

Edit /etc/fstab. Add the following new line to the end of the file:

/dev/md2  /mnt/r1data  ext4  defaults,noatime,barrier=1  0  0

Create a mount point for the large data partition and mount it.

mkdir /mnt/r1data
mount /mnt/r1data

Further configuration of the system and reboots will not disrupt the rebuild process.

Step 5: Automate kernel and initramfs management

Arch Linux ARM can update the kernel when new software is installed through its package management system. Several actions must be performed every time this happens to allow the boot loader to load the new boot files:

  • The new kernel must be converted to uImage.
  • The newly generated initrd must be converted to uInitrd.

Start by creating the directory /etc/pacman.d/hooks by running mkdir /etc/pacman.d/hooks. Create the file /etc/pacman.d/hooks/generate-ubootfiles.hook in a text editor with the following contents:

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux-kirkwood-dt

[Action]
Description = Make the new kernel and initrd bootable by U-Boot
When = PostTransaction
Exec = /usr/local/sbin/generate-ubootfiles
Depends = uboot-tools

Create the file /usr/local/sbin/generate-ubootfiles in a text editor with the following contents:

#!/bin/sh
#Creates U-Boot images from the boot files

zImage=/boot/zImage
dtb=/boot/dtbs/kirkwood-iomega_ix2_200.dtb
zImagedtb=/boot/zImage-dtb
uImage=/boot/uImage
uImageAddr=0x02000000

initrd=/boot/initramfs-linux.img
uInitrd=/boot/uInitrd
uInitAddr=0x08004000

if [ ! -e $zImage -o ! -e $initrd ]; then 
  echo "distribute-bootfiles: Error! $zImage and/or $initrd is missing."
  echo "distribute-bootfiles: New U-Boot files will NOT be created!"
  exit 1
fi

#Create uImage
cp $zImage $zImagedtb
cat $dtb >> $zImagedtb
mkimage -A arm -O linux -T kernel -C none -a $uImageAddr -e $uImageAddr -n "Arch Linux ARM kernel" -d $zImagedtb $uImage > /dev/null

#Create uInitrd
mkimage -A arm -O linux -T ramdisk -C gzip -a $uInitAddr -n "Arch Linux ARM initrd" -d $initrd $uInitrd > /dev/null

Make the file executable by running chmod +x /usr/local/sbin/generate-ubootfiles. Test whether the script works by running /usr/local/sbin/generate-ubootfiles. Everything works OK if there is no output.

This concludes the ix2-200 specific installation steps. You can finalize the Arch Linux ARM installation (e.g. configuring the time zone) by consulting the Arch Linux Wiki.

Step 6 (OPTIONAL): Add support for email events in case of RAID failure

It is useful to know when a disk fails. For instructions on how to replace a disk, see ‘Appendix A: Replace a failed RAID disk’.

Requirements:

  • A mail account with (preferably secure) SMTP access.

Start by installing SSMTP. Run the following command:

pacman -S ssmtp

Now edit /etc/ssmtp/ssmtp.conf. An example configuration:

Mailhub=smtp.domain.ext:465
UseTLS=Yes
UseSTARTTLS=No
AuthUser=mailboxusername
AuthPass=mailboxpassword

Hostname=ix2-200.domain.ext

FromLineOverride=Yes

Mailhub is the hostname and TCP port used to reach the SMTP server. UseTLS determines if SMTPS will be used (commonly used with TCP port 465). UseSTARTTLS determines whether STARTTLS will be used (commonly used with TCP port 25 or 587). AuthUser and AuthPass must contain respectively the username and the password used to access the SMTP server. Hostname can override the internal value used to identify the machine to the SMTP server.

Test the email client by running:

echo test | mail -v -r addresstosendfrom@domain.ext -s "testing ssmtp setup" addresstosendto@domain.ext

addresstosendfrom@domain.ext must be the email address associated with the mailbox account. Make addresstosendto@domain.ext the email address on which RAID failure mails should be received.

Make the RAID configuration aware of the email server and the address to send email to. Edit /etc/mdadm.conf and add the following new lines to the bottom, above the ARRAY lines:

MAILFROM "My ix2-200 <addresstosendfrom@domain.ext>"
MAILADDR addresstosendto@domain.ext

Now test whether the RAID configuration can send email by running:

mdadm --monitor --scan --oneshot --test

If a disk fails in real life, it might be that three mails will be send: one for /dev/md0, one for /dev/md1 and one for /dev/md2. This is due to that each partition is in fact its own RAID1 array. To know which disk fails, look for the status block that is part of the output of /proc/mdstat (attached to each mail message originating from the RAID daemon). Normally, it will look like this:

[UU]

This means that two (=all) disks are up and running. If a ‘U’ is replaced with an ‘F’ (failed) or an underscore (disk is missing), a disk has failed. To see which disk has not failed, look at the line above the line showing the status block. It will show device names corresponding with the disk that is still working. E.g.: for md0, “active raid1 sda1[0]” would mean that the disk in bay 2 failed since sdb1 is missing from the line.

More information about mdstat can be found at the Linux Kernel Wiki.

Step 7 (OPTIONAL): Install Samba and add a share

This is a very brief example implementation.

Install Samba using the following command:

pacman -S samba

Create /etc/samba/smb.conf. A minimalistic example with ACL support:

[gobal]
   workgroup = WORKGROUP
   server string = ix2-200 Samba Server

   log file = /var/log/samba/%m.log
   max log size = 50

   security = user

   vfs objects = acl_xattr
   map acl inherit = yes
   store dos attributes = yes

See /etc/samba/smb.conf.default for more configuration options.

Enable and start the file server by running the following commands:

systemctl enable smbd
systemctl start smbd

To add an SMB user account named ‘user’, run the following commands:

useradd -c "Test User" -M -d / -s /usr/bin/nologin user
smbpasswd -a user

To create a directory to share with ‘user’, run the following commands:

mkdir /mnt/r1data/usershare$
chown -R user:user /mnt/r1data/usershare$

To share the created directory using SMB with ‘user’, edit /etc/samba/smb.conf. Add the following new lines to the bottom of the file:

[usershare$]
   comment = Some user's share
   path = /mnt/r1data/usershare$
   valid users = user
   writable = yes

Changes to /etc/samba/smb.conf should be processed automatically. systemctl reload smbd forces Samba to reload its configuration.

Appendix A: Replace a failed RAID disk

Remember that HDD bay 1 is /dev/sda and HDD bay 2 is /dev/sdb. ‘/dev/sdX’ is used as a placeholder in the commands for the disk that will be replaced.

If the disk is still accessible, it must be marked as faulty. This prevents data corruption at boot if the old disk is accidentally placed back after its removal. Run the following commands:

mdadm --fail /dev/md0 /dev/sdX1
mdadm --fail /dev/md1 /dev/sdX2
mdadm --fail /dev/md2 /dev/sdX3
mdadm --zero-superblock /dev/sdX*
sgdisk --zap-all /dev/sdX

Remove the faulty disk and add a new disk with a similar capacity. The ix2-200 supports hotswap, so it is not necessary to power down the system.

After swapping in a new disk, run:

sgdisk --zap-all /dev/sdX
sgdisk -l /root/raid1.gpt /dev/sdX
mdadm /dev/md0 -a /dev/sdX1
mdadm /dev/md1 -a /dev/sdX2
mdadm /dev/md2 -a /dev/sdX3

Verify that rebuild of the RAID1 array has started by running:

cat /proc/mdstat

Appendix B: Enable the crypto accelerator

The chipset of the ix2-200 contains a Marvell Cryptographic Engines And Security Accelerator (CESA), which is useful to offload the CPU when using a VPN.

To enable the crypto accelerator, run:

pacman -S linux-kirkwood-dt-headers cryptodev-dkms openssl-cryptodev
echo "cryptodev" > /etc/modules-load.d/cryptodev.conf
insmod /lib/modules/`uname -r`/extra/cryptodev.ko

To see the supported algorithms, run:

cat /proc/crypto|more # See entries for module 'marvell_cesa'
openssl engine cryptodev -t -c

To run some benchmarks:

cryptsetup benchmark
openssl speed -engine cryptodev -evp aes-256-cbc

To enable support for the crypto accelerator in OpenVPN, add the following line to the OpenVPN configuration file on the ix2-200:

engine cryptodev

To run OpenVPN automatically at startup with access to the crypto accelerator, run:

cp /usr/lib/systemd/system/openvpn-client\@.service /etc/systemd/system/
cp /usr/lib/systemd/system/openvpn-server\@.service /etc/systemd/system/

Now edit /etc/systemd/system/openvpn-client@.service and /etc/systemd/system/openvpn-server@.service. For each file, add to the [service] section the following line:

DeviceAllow=/dev/crypto rw

Now run:

systemctl daemon-reload

If the specific OpenVPN configuration was already enabled to start at boot, disable and re-enable it to use the new configuration.

Appendix C: Restore the original ix2-200 firmware

You will need this ix2-200 recovery image, which is based on the last official Iomega ix2-200 firmware. Place ‘ix2-boot.tgz’ on a FAT32 formatted USB thumb drive in these directories:

  • /emctools/ix2-200_images
  • /emctools/ix2-200d_images

Now run in Arch Linux ARM the following commands:

fw_setenv mainlineLinux
fw_setenv arcNumber
fw_setenv bootcmd 'run flash_load'

Alternatively, run the following commands in U-Boot using a USB to TTL serial adapter:

setenv mainlineLinux
setenv arcNumber
setenv bootcmd 'run flash_load'
saveenv

Power down the ix2-200. Place one or two (preferably clean) disks in its bays and connect the prepared USB flash drive to any of the USB ports.

Now press and hold the reset button on the back of the ix2-200. Power up the ix2-200 while keeping the reset button pressed. After ~90 seconds the USB thumb drive will be read intensively, which can be observed if the USB thumb drive has an activity LED. Release the reset button when this happens.

The ix2-200 will power itself down after the recovery is complete. Remove the USB flash drive and power the ix2-200 on. The original firmware will be restored. Check your DHCP server to see which IP address is assigned to the ix2-200. The default settings are as follows.

Web interface: http://hostnameorip/

No username and password will be set for web access.