I have just installed Debian 8.3 jessie on my HS-DH320GL (HS-DHGL) LinkStation Live (v1).
I had some issues with the installation, so I decided to describe the process here in case it helps anyone. Perhaps some of this can be incorporated into the Wiki. I do not feel confident enough to edit the Wiki myself.
It was not immediately obvious to me that the Debian project itself has installers for the latest versions of Debian specifically for a handful of Buffalo NAS devices, presumably based on groundwork done by this community.
I upgraded the HDD to 4TB, because the original 320GB is no longer a useful size for me. I chose a WD Red WD40EFRX, in large part because this has 512e sectors, which I'd read were necessary for the LinkStation
Knowing what I know now, I would probably do it something like this:
- Install new blank drive in LinkStation.
- TFTP boot into stable relase LSPro Debian installer.
- Install Debian, partitioning drive appropriately. (2TB partition size limit requires attention.)
- Attempt to boot LinkStation. If it fails, TFTP boot into foonas to check U-boot environment. Make corrections if necessary.
- Boot Debian and configure it.
However, the rather roundabout and experimental process I actually followed was:
- Clone existing opened stock firmware onto new drive and partition it. Install it in LinkStation.
- Test; it worked. I could access the web interface and SSH in as before.
- Attempt to install Debian from within the stock firmware. Hack at it a bit to try and make it work. Fail to boot into the Debian installer.
- Remove HDD from LinkStation and, using laptop, replace uImage.buffalo with foonas one. Reattach HDD, fail to boot.
- Remove HDD from LinkStation and repeat clone from original drive, putting the new drive back into a known good state. Fail to boot. (Oh dear... no going back now!)
- Attempt to TFTP boot foonas; fail.
- Obtain USB to serial TTL adapter to read terminal output from LinkStation. Determine cause of failure to TFTP boot as user error setting up TFTP server.
- TFTP boot foonas. Attempt to install Debian from within foonas. Fail to boot Debian installer.
- Successfully TFTP boot the Debian installer. Install Debian, repartitioning drive as part of installation.
- Fail to boot new Debian installation.
- After much puzzling, determine that U-boot environment variable bootcmd was incorrect. Fix it.
- Successfully boot Debian.
- Configure Debian a little.
- Realise that I am running the testing release.
- TFTP boot the Debian installer for the stable release.
- Installer hangs while booting.
- Realise that there is a separate installer for the LSPro. Try that one. It works.
- Install Debian again.
- Boot Debian and configure it again.
Having said that it was unnecessary, cloning the original system and booting it from the new HDD was a useful test, because it ruled out the new HDD in later troubleshooting.Debian installer
To summarise what I learned about ways of booting the Debian installer:
- The config-debian script doesn't work properly on opened stock firmware.
- The config-debian script does work in foonas.
- The config-debian script is unnecessary if you TFTP boot the Debian installer, provided your U-boot environment is good.
In my stock firmware, it seemed that /boot was mounted from /dev/ls_disk1_1 and not from /dev/sda1, which prevented the config-debian script from working.
The links on the NAS-Central wiki
and Debian's own installation guide
both point to the testing
release of the Kurobox Pro
installer, even though that is the stable
installation guide. If you want the stable
version or the LSPro
version, you need to get it from http://http.us.debian.org/debian/dists/stable/main/installer-armel/current/images/orion5x/network-console/buffalo/
. Or, replace "stable" in that URI with the name of the specific release you want (e.g. "jessie").
The stable (jessie) installer for Kurobox (as opposed to the LS Pro) doesn't even boot successfully on my LS Live, while the testing (stretch) installer for Kurobox works but results in a system that takes one or two minutes during the boot process to scan flash blocks and spew the resultant errors to the console. Presumably this relates to the extra flash memory that Kuroboxes have. The stable (jessie) installer for LS Pro results in a system that doesn't do this scanning, and therefore boots much faster! I have not tested the LS Pro installer for the testing release.TFTP booting
The easiest way to initiate a TFTP boot of the LinkStation, for me, was to put it into an unbootable state and try to boot it. Depending on the reason it cannot boot, it will either do an error beep or an Emergency Mode siren beep, but in both cases it will be attempting to TFTP boot. The error codes flashed by the red LED can be somewhat misleading. Mine suggested a fan problem or flash ROM error, neither of which related to the real problem. You can silence the beeping by pressing the power button briefly.
One way to make the LinkStation unbootable and initiate a TFTP boot is to install a blank HDD, or erase the HDD (if that's appropriate to what you are doing). Another is to rename the uImage.buffalo on /boot partition on the LinkStation's HDD to some other name (e.g. uImage.buffalo.disabled). When renaming the uImage.buffalo like this, I also renamed the initrd.buffalo for good measure, but that is probably unnecessary. Another way to make the system unbootable, but not one I recommend anyone to deliberately use, is for the U-boot environment to be incorrect. I only mention this because that is what happened unintentionally with my LinkStation.
You can also initiate a TFTP boot by using the serial terminal to interrupt the boot process. This is somewhat more involved.
Having initiated a TFTP boot, you need to connect the LinkStation to a network where it can access a TFTP server at the IP address 192.168.11.1 (by default). This would typically be a temporary, direct Ethernet connection to a laptop or similar, rather than a full-blown network. In its error state/Emergency Mode, the LinkStation will be repeatedly attempting to to download uImage.buffalo and initrd.buffalo from the TFTP server. When the TFTP server is accessible and has the appropriate files, the next download will succeed. Having downloaded the files, the LinkStation will stop beeping (if you hadn't already silenced it) and will boot from the files it downloaded. If it can't download the files after many, many attempts, the LinkStation gives up, beeps, and powers off. You can just power it back on again for more attempts.
If the TFTP boot does not appear to be working, double check that your TFTP server is working! Attempt to download the two required files from your TFTP server using a TFTP client, even if you do it on the same machine that is running the server. If I had bothered to do this, I could perhaps have avoided wiring up a serial terminal to the LinkStation!
If you are booting foonas, you need to provide an initrd.buffalo, but it is not used by foonas, so you can just use any initrd.buffalo, such as the one for the Debian installer or the stock firmware.
A suitable TFTP server to run on a Debian-derived system is provided by the package tftpd-hpa. Run sudo dpkg-reconfigure tftpd-hpa to configure it. Run sudo /etc/init.d/tftpd-hpa start to start the daemon. I'd recommend removing the package from your system when you've finished using it.Other details
This is a collection of other things that might be useful for people to know.Serial terminal
With hindsight, accessing the LinkStation's serial terminal was not strictly necessary, but it would certainly have taken me a lot longer to troubleshoot the problems I had without it. I purchased a USB to Serial TTL Cable with 3.3V signalling. There are many such devices available with various form-factors and connectors.
Since the serial connection was only going to be temporary, I laid the LinkStation on its side and used some bent, plastic-coated metal paper clips as springy solid-core wires to make the connection to the LinkStation's unpopulated serial header. Having stripped some plastic from each paperclip end, I hooked the paperclips into various parts of the metal chassis to hold them in position and used their springiness to press them against the sides of the through-holes in the PCB. I stuck them in place with some tape for good measure. My serial adapter was supplied with a single-pin header connector on the end of each wire, which fitted the free ends of the paperclips well.TAKE CARE
if you do this! There are reports of people shorting out their serial header with inappropriate connectors, and there are dangerous voltages in close proximity. Switch the LinkStation off and remove the power supply before rigging something like this up, to protect the LinkStation and yourself. Make sure the paper clips are not shorting out onto each other, the metal case or anything else, particularly the AC input jack! Don't forget they could touch each other on the other side of the PCB if you push them through too far. I covered the exposed AC input terminals with tape to avoid touching those.
If the serial adapter is USB-powered (as opposed to powered by the serial header), you do not need to attach the VCC terminal. RXD, TXD and GND are sufficient. I was not able to determine what voltage VCC should be on the LinkStation's serial header, so it was safer to leave VCC disconnected. (Most adapters provide 5V, even though the signalling is 3.3V.) Make sure the unused 5V terminal can't short onto anything!
minicom is a suitable program to use to access a serial terminal using a GNU/Linux system.My incorrect U-boot environment
The reason my LinkStation would not boot after first attempting to run the Debian installer was that the "bootcmd" U-boot environment variable was incorrect. I suspect this was changed by the config-debian script when I ran it in the stock firmware, perhaps because it was the Kurobox version or perhaps because I was attempting to run on firmware it wasn't designed to run on. I was getting an error message, seen on the serial terminal, of "Wrong image type for bootm command". The offending environment variable was:
bootcmd=ide reset; ext2load ide 0:1 $(default_kernel_addr) /$(kernel); ext2load ide 0:1 $(default_initrd_addr) /$(initrd); setenv bootargs $(bootargs_base); bootm $(default_kernel_addr)
To see the value of this variable, it was necessary to boot into foonas and run fw_printenv. Even though you can interrupt the boot process through the serial terminal and issue the printenv command, directly within U-boot, this particular environment variable gets altered when you do that, so you never get to see its original value that way.
The problem with this bootcmd environment variable was that $(default_kernel_addr) and $(default_initrd_addr) were not defined anywhere. As a result, since this part of the command was not throwing an error, these non-existent variables were presumably both resolving to some nonsense address (perhaps 0x00000000). Since they were both resolving to the same nonsense address, U-boot was loading both the kernel and the initrd into that same nonsense memory location, one on top of the other. Then, when it tried to boot the kernel, it found the initrd, because that was the last thing to be loaded! Hence, "wrong image type". (It is nice that it has the intelligence to distinguish between kernels and intrds.)
My solution was simply to create the two extra environment variables that were missing, by running these two commands in foonas.
fw_setenv default_kernel_addr 0x00100000
fw_setenv default_initrd_addr 0x00800000
I copied the memory addresses from the def_tftp environment variable, where they are used for the same purpose of loading the kernel and initrd. I could have simply replaced the references to these variables with the actual addresses, but creating the two variables was easier.Downloading things from the internet in foonas
If you boot foonas using TFTP, then there is a good chance it won't have a network connection while it boots up, because it's linked to your TFTP server instead of your normal network. If you haven't connected it to a network before it brings up the network interface, you can make it obtain an IP address using DHCP by simply bringing the interface up again in using ifup. (You might need to take it down first using ifdown.) This enables you to use wget to download things like the Debian installer from within foonas.Partitioning
The LinkStation (or, more specifically, the version of U-boot it uses) requires an msdos partition table. msdos partition tables have a maximum partition size of 2TB.
To partition my 4TB drive, I ended up with this scheme:
#1 ext3 207MB /boot
#2 ext4 10GB /
#3 [extended partition; ~1.9TB]
├ #5 swap 10GB
└ #6 LVM max (fill remaining space)
#4 LVM 2TB
I made the /boot partition exactly same size as it had been in the stock firmware. This is not necessary, but it was a convenient number to use.
You can configure LVM within the installer. I put both of my LVM physical volume partitions into the same volume group, and created a single ~3.9TB logical volume in that group, which I formatted as ext4 and mounted on /home.
The Debian installer does not seem to provide a way to explicitly define the size of an extended partition. Instead, you create logical partitions and it assumes you want them to go into an extended partition that fills the available space. Therefore, having defined partitions #1 and #2, if I attempted to define partition #5 next, I would receive an error about the extended partition being too large for the msdos partition table, because it was trying to create an extended partition almost as large as the entire disk. The way to avoid this was to create the partitions in the order #1, #2, #4, #5, #6. This way, when #5 is created, the extended partition #3 is implicitly required to fill the ~1.9TB space between #2 and #4, which is an acceptable size.