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!
I just installed the IOMEGA StorCenter ix2-200 Cloud Edition but it is telling me that it cannot locate a storage device. Please tell me how this should be done. It seems silly it cannot locate its ow read more. Hi everybody, I have an iomega ix2-200 cloud edition that is connected to my network via an Ethernet cable coming out of my Cisco router using a static IP address. I have a mixed environment of laptop read more.
Systems might not be bootable when updated due to this issue. The remediation requires changes to the memory addresses in which the kernel and initramfs are loaded. 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
)`:
An already updated and broken system can be fixed through a serial connection by running in U-Boot:
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 iomega StorCenter ix2-200 Cloud Edition specs are located.HERE. so there is little point in me detailing all of the items. Personally I've found the iomega StorCenter ix-200 Cloud Edition very easy to configure and very easy to use. The ix2-200 CE didn't have any hardware changes, so we didn't review it. But we took at look at the CE features when Craig reviewed the single-drive Home Media Network Hard Drive - Cloud Edition over on SmallCloudBuilder. This latest change drops both the 'Cloud Edition' and '-200' from the ix2's moniker, leaving it as just the plain ol. Dec 10, 2011 Introducing the Iomega® StorCenter™ ix2-200 Network Storage, Cloud Edition. Iomega Personal Cloud is a new technology that creates your own Internet connected 'cloud' network of StorCenter storage devices, personal computers and handheld mobile devices, which allows you to connect, share, copy and protect your files within your network.
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
.
If it is not possible to stop and remove some of the superblocks, run:
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:
- Use
o
to create a clean DOS partition table. - Use
n
to create a new partition, type:p
rimary, number:1
, first sector: default, last sector:+256M
. - Use
n
to create a new partition, type:p
rimary, 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 be83
.
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.
Now a U-Boot image of the initramfs has to be created. This makes it readable by the boot loader of the ix2-200.
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.
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:
Preparation of the installation medium is now complete. Run the following commands to dismount the installation medium safely:
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.htmlFor 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:
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.
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:
Iomega Ix2 Software
- Remove the 4 large screws from both HDD bays on the bottom.
- Remove the HDD bays.
- Remove the 4 small screws on the rear.
- Remove the plastic bracket from the rear.
- Remove the 2 small screws under the front side of the two front rubber feet.
- 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:
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.
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:
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):
Now install the required packages by running:
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:
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:
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):
Use o
to create a clean GPT partition tableUse 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):
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
:
Add the following new lines to the bottom of /etc/fstab
:
Add mdadm
to HOOKS in /etc/mkinitcpio.conf. An example of the modified line:
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:
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:
Copy all data from the installation medium to the single RAID1 disk. Run the following commands:
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.
Edit /etc/fstab
. Add the following new line to the end of the file:
Create a mount point for the large data partition and mount it.
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:
Create the file /usr/local/sbin/generate-ubootfiles
in a text editor with the following contents:
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:
Now edit /etc/ssmtp/ssmtp.conf
. An example configuration:
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:
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:
Now test whether the RAID configuration can send email by running:
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:
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:
Create /etc/samba/smb.conf
. A minimalistic example with ACL support:
See /etc/samba/smb.conf.default
for more configuration options.
Enable and start the file server by running the following commands:
To add an SMB user account named ‘user’, run the following commands:
To create a directory to share with ‘user’, run the following commands:
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:
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:
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:
Verify that rebuild of the RAID1 array has started by running:
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:
To see the supported algorithms, run:
To run some benchmarks:
To enable support for the crypto accelerator in OpenVPN, add the following line to the OpenVPN configuration file on the ix2-200:
To run OpenVPN automatically at startup with access to the crypto accelerator, run:
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:
Now run:
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:
Alternatively, run the following commands in U-Boot using a USB to TTL serial adapter:
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.
I’m posting this basically because I know others are out there on your own. Cold and wandering through the internets looking for something about how to mod and update this device. I’m talking about the (EMC) Iomega Storecenter ix2. I picked up this little guy a little more then a year ago for some cheap money. Then I found out that they were discontinuing the model because of some pretty obvious problems.
Pretty obvious problem #1. The fan is horrible and you probably have already done something about it. Along with the fan the airflow through the device is just as bad. You can see that Iomega took a complete 180 when they came out with “the new model“** What I suggest is you get out your Dremel and cut a nice hole in the back panel. I put an over-sized ultra quiet fan with a dust filter on it. It’s already back in the closet, so I’m not getting a picture of it… Hell, you don’t want to see a picture of it. It’s a 80mm PC fan bolted to the back of a $200 NAS drive. It’s goofy looking utilitarian hardware that needs to be in the closet. Let the sexy laptops and iPods take the credit while the hacked Linux device with wires and fans all over it gets the job done. *cough **For reasons of ‘search’ the next model up is the ‘eye ex two hundred’
Problemo #2. I have been looking for a USB aware UPS (Uninterruptible Power Supply) for this device from day one. Having a ‘self aware’ storage device is pretty cool. Enable write caching and don’t worry when the power goes out when your in Tahiti. I finally obtained a Tripp Lite UPS and replaced the battery on it. Fresh USB cable plugged in and – nothing. Then it gets worse. I restart the device and it just hangs. So – Are you having a problem where your Storcenter ix2 won’t recognize your Uninterruptible Power Supply?
Final Problem #3. Every time you try to search for Iomega Storcenter ix2 (or maybe storecenter?) you get a thousand ‘re-view’s’ of how awesome it is and nothing about helping you solve issues or fix problems. Even after you use a crazy Google search like this…
I’m here to help!
Not with the fan though – you’re clever, you’ll come up with something.
Good news / Bad news. You hit ‘update’ and your device tells you that you have the latest firmware! You don’t. The latest firmware would be 2.0.15.43099 or higher. The good news is that along with potentially fixing the UPS not recognized problem, you will get the torrent downloader. This means that while your desktop is off and not using 500watts an hour your little ix2 can stay busy getting ‘the latest release of Fedora’***.
***or movies and pr0n.
Other bad news is you’re going to have to sign up to the Iomega site with an email. It’s not nearly as bad as Cisco is – but you have to get a valid email. Or an alias that forwards to your real email that you can shut down after you hit accept.
Ix2-200 Cloud Edition
While your doing that – Might as well sign up for the Iomega Support Forums Lots of moderated fun in there…
Iomega Ix2 200 Software
Backup your data. Hack the fan. Load the firmware file and hit update. Wait a while in a panic. Login. Connect your UPS. Hopefully it now recognizes it! Torrent movies and pr0n. Set quotas. Oh – and because it can’t possibly all be good. You will lose the ability to get email updates from the unit… This is a gem – exhange??
Update – I got SSH access! Easy as HTML. Here’s how you get SSH access to your ix2. Now to FIX the email notification port and configuration… Initial look tells me that it doesn’t use sendmail