First off, I will state how I understand the system operation after doing this yesterday and today:
The goflex home base unit has internal firmware (referred to as uboot) that is, for all intents, the bootloader and hardware manager portion of the environment. This system first starts (the blinking green light says that this is "currently" what is running the hardware), and then will, by default, attempt to scan for operating systems on the USB port (first) and the connected hard drive on the SATA interface (second). When it finds a bootable machine (with the proper OS bootable image), it loads that in to memory (the orange light appears to be this step) and then the new OS runs and operates the machine (the solid green).
Most likely, there is a problem here with either:
1) no OS found on the devices (should stay flashing green)
2) the OS loading has crashed/stuck (solid green)
3) the OS is running fine but no IP network available (also solid green)
I had an issue with #3... I was not aware this was the case until I used a USB serial connection (one I used for my raspberry pi) and connected to the serial console to see what was happening. This meant I had to take the unit apart carefully and connect the cable to the pin holes for the serial port... but that was not hard... just take your time if doing. Google for details - I wont go in to it from here.
My issue was that during the process to load Arch Linux the UBOOT system lost the MAC address of the network card, so it was showing up in the OS as all 0's. Again, google to see how to easily set the MAC at UBOOT console to fix this. Again, you will need the serial connection as this error prevents an IP stack on the card.
Once on the UBOOT console, I just did this:
setenv ethaddr XX:XX:XX:XX:XX:XX (the address is on the sticker on the device!)
saveenv
After fixing that, I also found another issue: the 3TB drive was reporting only 2TB available. It was originally formatted using "fdisk" but not one that could deal with large drives over 2TB in size... so I attempted to fix it and fouled it up, and stopped it from working. I ended up corrupting the MBR and GPT of the drive so it was not able to be read by UBOOT anymore.
While attempting to fix, I had used a USB to SATA adapter to connect the 3TB drive to my Laptop. I was going insane on this as the drive appeared corrupted and was reporting only 746GB available, lots of errors when using fdisk, gdisk, parted, etc to repartition. I even tried getting windows to re-partition it unsuccessfully. Using Seagate's own SEATOOLS in Windows said the drive was okay, and should be 3TB, but nope. I found the problem eventualy.... it was the USB to SATA adapter! The drive was reporting 512byte PHYSICAL blocks, when it was supposed to be 4096bytes... and nothing would fix that. It was the darned USB interface.
To fix, I created a USB stick with the "kirkwood" distribution using my laptop (running ubuntu)... for a tip, dont worry about using bsdtar, just use native tar and ignore the thousands of errors...
so instead of: bsdtar -xpf ArchLinuxARM-kirkwood-latest.tar.gz
use: tar -zxvf ArchLinuxARM-kirkwood-latest.tar.gz
ignore the "SHILLY" errors...
TIP: also copy the ArchLinuxARM-kirkwood-latest.tar.gz to that USB as well... will use again!
It took me 3 USB sticks to get one that worked... I was using cheapo/free ones I had and they would not boot... I used a 16G Lexar and it worked perfectly... so quality does matter!
Anyway - after doing that, I rebooted with the USB and with the drive connected to the SATA port, used the USB image Linux environment to partition the drive with parted... easy enough to do. Used GPT, created a 20G Linux partition, a 2G swap partition, and the rest (2.7TB) as an NTFS partition. (not formatting yet).
Did the normal filesystem creation on the new 20GB partition (I think it was sda1 for the drive): mkefs -j /dev/sda1
Then did the same "tar -xzvf Arch....." to place the OS image on the HDD.
I then rebooted... and..... NOTHIN!
Using the console cable again, I was able to see that the UBOOT environment was saying that there was a corrupt GPT... and I also found out on google that this is because the version of UBOOT used on the machine did not support the larger drives. I followed this simple process:
1) booted from the USB stick again
2) pacman -U
http://archlinuxarm.org/builder/testing ... pkg.tar.xz3) rebooted without the USB stick
The system then ran perfectly.
Most of my headaches ended up being related to the USB to SATA cable I was using... but the other issues were troubling.
So, in the end, I had the following items to do, and I am working perfectly now:
1) get serial cable connected to access to uboot
2) update the MAC address in firmware
3) boot from a good USB stick image and update UBOOT firmware to support large disks
4) use parted (not fdisk) to configure a proper GPT partition table structure while the hard drive is connected via SATA (dont connect to another machine to work on the drive using a USB to SATA connection!)
Kudos to the kirkwood distro for having most items configured. I did have to use pacman to install wget and (parted I believe), but that was minor stuff.
The Seagate GoFlex Home is now working perfectly as a SAMBA server and running other software (btsync/rslsync) and using the entire drive's storage perfectly!
--------------
some errors seen to help index this for people to find:
Warning: failed to set MAC address
print_part_efi: *** ERROR: Invalid GPT ***
tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
ignoring malformed pax extended attribute
seagate goflex home bricked