Dave Eckhardt's Seagate GoFlex Home Arch Linux page

Warning

These directions worked well for a family with Macs running 10.6 ("Snow Leopard"). Then we "upgraded" to 10.9 ("Mavericks") and since then Time Machine has been EXTREMELY slow backing up to netatalk. Apple's official position is that they support backing up only to Apple devices, which is all very well, but if a disk blows up in a Time Capsule I can't fix it myself, so the current situation is annoying. So maybe these directions are of merely historical interest.

Background

I was doing off-site backups for my family's MacBooks using a Seagate "GoFlex Desk" USB/FireWire disk. I would occasionally bring it home, plug it into each machine for a Time Machine backup, and then store the disk off-site again. Because it was tough to stick to a regular schedule, I wanted to complement the occasional off-site snapshots with a more vulnerable but more automatic network-attached solution. I was interested in Seagate's "GoFlex Home" NASD docking base for the GoFlex Desk drives, but unfortunately the software Seagate ships it with is the opposite of what I want: its Time Machine support is lukewarm, and meanwhile it thoroughly supports access from outside my firewall via some Seagate centralized cloud service--no thanks!

Luckily it is fairly easy to replace Seagate's software (written by PogoPlug) with a standard Linux distribution, in particular Arch Linux. Here's what I did.

NOTE! THESE INSTRUCTIONS WERE WRITTEN BY SOMEBODY WHO HAS BEEN INSTALLING OPERATING SYSTEMS SINCE BEFORE LINUS TORVALDS WENT UP INTO HIS ATTIC TO START WRITING LINUX. THESE INSTRUCTIONS ARE TARGETED AT SOMEBODY WHO HAS EXTENSIVE EXPERIENCE WITH INSTALLING UNIX-LIKE OPERATING SYSTEMS. THESE INSTRUCTIONS ARE NOT SUITABLE FOR NOVICES. Seriously, it is unwise for you to try this unless you have installed some version of Unix at least once on an "easy" machine, i.e., one with a keyboard and a display.

Installing Arch Linux

I followed the Arch Linux installation instructions for the Seagate GoFlex Home. Well, mostly.

I was unable to follow the directions for setting the Ethernet MAC address to the value on the sticker on the bottom of the device. The "UBIT environment" mumbled some warning about needing to reboot before something could happen, and I spent many hours trying to figure out how to make it work, but eventually gave up. Luckily the machine booted anyway, albeit with a bogus MAC address. I found it because when it DHCP'd it identified itself as being named "alarm".
When you reboot into Arch Linux, your /etc/fw_env.config file will probably be wrong, with the result that fw_printenv and fw_setenv won't work. "Luckily" all you need to do is run hexdump -C /dev/mtd0 | less and search for plausible environment blocks. Note that you will see several, and all but one are decoys. The one you are looking for will probably contain the string "ubi_boot=", and you will probably see one that contains the string "explrpk=" which is not what you want (that belongs to Seagate's firmware). In my case, the right one started at 0x60000 and the right thing to put in /etc/fw_env.config was
```
/dev/mtd0               0x60000         0x20000         0x20000
```
In theory once /etc/fw_env.config is correct you can set the machine back to its factory-issued MAC address by running fw_setenv ethaddr 00:10:75:xx:yy:zz. However, when I did this in June 2013, fw_setenv contained a "helpful" "safety check" which disallows setting ethaddr if it's already been set once. If you read around online people will advise you to solve this by setting up a serial console or a network console, booting the machine into U-Boot, and fixing the MAC address using U-Boot's built-in commands. Because I wanted to avoid fussing to set up and learn yet another environment, instead I solved the problem using the following unsafe hack which is not suitable for everybody.
```
$ cp /usr/bin/fw_setenv /tmp/fw_setenv
$ hexdump -C /tmp/fw_setenv | less
...find the address of the string "ethaddr", which is used by the "safety" check...
$ dd if=/tmp/fw_setenv skip=NNNNN bs=1 count=10 # will print "ethaddr" if NNNNN is correct
$ echo -n XXX | dd of=/tmp/fw_setenv seek=NNNNN bs=1 count=3 conv=notrunc
```
If you are careful and did this right, now /tmp/fw_setenv is a version of fw_setenv with the safety check disabled. If you did it wrong you have a dangerous version of fw_setenv that could brick your device. So unless you understand exactly how that hack is supposed to work, you should probably slog through booting into U-Boot and fixing the MAC address that way. Or maybe by the time you try this UBIT will be in a better mood.

Configuring Arch Linux as an AFP server for Time Machine

Make sure you've set a root password.
timedatectl set-timezone America/New_York
set up /root/.ssh/authorized_keys.
"Host name" configuration:
1. hostnamectl set-hostname SomeHostName
2. hostnamectl set-icon-name computer
3. hostnamectl set-chassis server
If you followed the Arch Linux directions for creating the second primary partition, you may have ended up with your large storage partition not being 4K-aligned (fdisk will complain when printing out the partition table). So I deleted the partition and re-created it with better alignment (I didn't worry about the root partition).
pacman -Sy netatalk avahi dbus
I decided to use LVM to make it possible to grow/shrink partitions and to some day make it easier to migrate the data onto a larger disk. So here's what I did. These directions create two Time Machine volumes, one large and one medium, each destined to support one MacBook.
1. pvcreate /dev/sda2
2. vgcreate SomeVGName /dev/sda2
3. lvcreate -L 1536G SomeVGName -n large
4. lvcreate -L 250G SomeVGName -n medium
5. lvcreate -L 10G SomeVGName -n swap
Then I initialized the file systems.
1. mkfs.ext3 /dev/mapper/SomeVGName-large
2. mkfs.ext3 /dev/mapper/SomeVGName-medium
3. mkswap /dev/mapper/SomeVGName-swap
Then I rebooted, because I had never set up LVM before and was worried by something I'd read about maybe needing to jump through hoops to get LVM running early in the boot process. I didn't think I needed to do that because I am using a non-LVM root partition, but I figured it would be better to fail early rather than after doing lots of work setting up AFP. The reboot took FOREVER (hours and hours!). I suspect that what happened is that on the way up the system saw a giant file system which had never been fsck'd and went to town. I also suspect/hope that this might not have happened if I had mounted and un-mounted each file system before the reboot, so you might want to try that. YMMV!

Time to permanently configure the file systems.

mkdir -m 755 /NASdata

Edit /etc/fstab:

/dev/mapper/SomeVGName-large   /NASdata/large   ext3  defaults  0  2
/dev/mapper/SomeVGName-medium  /NASdata/medium  ext3  defaults  0  2
/dev/mapper/SomeVGName-swap    none             swap  defaults  0  0

Un-comment-out "enable-dbus=yes" in /etc/avahi/avahi-daemon.conf, and start Avahi up.
1. systemctl enable avahi-daemon.service
2. systemctl start avahi-daemon.service
Now is probably a good time for a reboot. If the system doesn't seem to come up right away (~30 seconds), put your hand on the disk and see if you feel it seeking every minute or so. This might indicate you're in a multi-hour fsck run, in which case you should absolutely be patient and NOT power-cycle the device. I don't know how long it took for my system to do this, because once I figured out what was happening I went to sleep; that's the kind of patience you should be prepared to deploy.
Once you're back, in theory you have blank file systems all ready to be configured for Time Machine, so let's do that. We will create one account and one AFP volume for each client.
1. useradd -M -N -g nobody -s /sbin/nologin -u 1000 macbook1
2. useradd -M -N -g nobody -s /sbin/nologin -u 1001 macbook2
3. passwd macbook1
4. passwd macbook2
5. chown macbook1:nobody /NASdata/large
6. chown macbook2:nobody /NASdata/medium
Now we need the AFP-server configuration file, /etc/afp.conf. I deliberately used somewhat conservative settings since as I write this we are early in the netatalk-3 life cycle.
```
[Global]
uam list = uams_dhx.so,uams_dhx2.so
[presets]
cnid scheme = dbd
appledouble = v2
ea = ad
[User 1's Time Machine Backups]
time machine = yes
path = /NASdata/large
presets = presets
valid users = macbook1
[User 2's Time Machine Backups]
time machine = yes
path = /NASdata/medium
presets = presets
valid users = macbook2
```
Now we can start the AFP server up.
1. systemctl enable netatalk
2. systemctl start netatalk
Time Machine should "see" the volumes you created, and if you provide the correct username and password you should be able to start a backup right away.
You might want to install smartmontools to enable SMART monitoring of your disk hardware.

Finally, based on post-installation tweaking advice from Philipp Klaus, I wrote a systemd "unit" which turns the device's LED orange when it completes a halt or shutdown (so you know when it's safe to hit the power button). I put this in /etc/systemd/system/halt_orange.service.

[Unit]
Description=Orange LED alert on halt
DefaultDependencies=no
After=shutdown.target halt.target umount.target
Before=final.target
[Service]
Type=oneshot
ExecStart=/bin/sh -c "/bin/echo default-on > /sys/class/leds/status:orange:fault/trigger"
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
[Install]
WantedBy=shutdown.target halt.target

To "install" this, run systemctl enable halt_orange.service

Future Work

Since the device's power button is "hard" rather than "soft", you really shouldn't use the power button to shut the device down, which means you should do something else to shut it down so it's safe to remove power, which is troublesome since the power button is the only button. Thus it would be really nice to have a sleek way to ask the device to halt itself. The best thing I've thought of so far would be to launch shutdown if the status of the wired Ethernet goes from "carrier" to "no carrier" and stays that way for 60 seconds--that way you could walk up to the device and unplug the Ethernet cable to get it to shut down.

It would be nice if the green LED could blink in time with disk I/O. Oh, well.

It would also be nice if the device would warn AFP clients when it was planning to shut down.