Freelink upgrade to lenny with SATA-USB adapter
Usual warnings and caveats apply. This is my experience using a Linkstation Live v2. Normally, from what I've read, this should work for the Linkstation Pro, or indeed any device where you can gain access using a SATA<->USB cable and where the boot and rootfs partitions are accessible. But as always, "you brick it... you bought it."
The goal was to make the Linkstation work with a USB sound card, and thus to act as a media player, not a media server. With this in mind and using Add_a_USB_sound_card as a proof of concept, I installed Freelink following the instructions on FreeLink_for_the_LinkStation_PRO/LIVE. The first problem was Alsa which didn't play well on the 2.6.12 kernel that came with Freelink. After a lot of searching I found that there was a problem with the Alsa tools when running an kernel with OABI userspace tools. This is well-documented on-line. I needed a full "Armel" (EABI) system.
My first attempts to upgrade the kernel to a vanilla 2.6.28 were disastrous and resulted in the box going into a reboot every 30 seconds, before even allowing a connection. Since it wasn't attempting to contact a TFTP server, I couldn't get it to go into [EM_Mode] and I didn't own a serial cable, I was left with no option but to access the drive directly. So I browsed around and found a SATA<->USB adapter that I could use to access the HDD without complete disassembly. The version to the right requires that the either the HDD be removed, or the device be hacked apart.
- The kernel source, available from . You want the most recent version where possible. Check the list in Buffalo_ARM9_Kernel_Port to see at which point support was added for your box.
- A Debian Lenny rootfs. I used .
- The SATA<->USB cable shown above, or something similar.
- A Linkstation Live (Or possible other model) running Freelink (Presumably this would work straight out of the box, but I didn't do it that way, so I'm not going to say that it'll work).
Modifying and connecting the adapter
The second time I connected the adapter, I decided to take it apart. The case comes apart fairly easily and you'll need to pull off the plastic cover from the switch and then use a pair of wire cutters to cut the switch shorter. With that done, the HDD can be connected by removing the front of the Linkstation case and the daughterboard. If you have nimble fingers you won't even need to remove the side panel. See Disassemble_the_LS_Pro_v2_/_LS_Live_v2 for further instructions. Since the switch on the adapter will be near inaccessible, you will need to connect the adapter to the HDD, then plug it into the USB port and connect the molex connecter which provides power.
- Follow the instructions in Buffalo_ARM9_Kernel_Port to create a kernel and modules for your Linkstation.
- Connect the drive and mount the partitions. They should appear as /dev/sdXY. Assuming a default partitioning and /dev/sdb as the root you should see
- sdb1 = The boot partition
- sdb2 = The root filesystem
- sdb4 = The extended partition containing the rest
- sdb5 = A swap partition
- sdb6 = The media partition (You do want to store stuff on this, right?)
- In a default setup sdb2 and sdb6 will be in XFS format. As of 08 Jan 2009 there are ongoing issues with XFS on Arm. I had an error on my rootfs after only two boots. It is worth switching to another filesystem. I used ext3 as I'm familiar with it, but there appears to be a strong consensus on using JFS for the media partition.
- Back up the old root system. You will want to be able to revert if anything goes wrong. From within the mounted system use
tar cjf /path/to/backup.tar.bz2 *
- Reformat to a new filesystem if you wish to do so.
- Decompress the Lenny image using the following from within the mounted system:
tar xf /path/to/lennyimage.tar.gz
- Copy your uImage.new kernel image to the boot partition. In the boot partition rename uImage.buffalo to uImage.old and then rename uImage.new to uImage.buffalo.
- Install your modules under /lib on the rootfs.
You now need to make a few modifications to the rootfs
- Set up networking. I modified /etc/hostname and /etc/hosts to reflect what I wanted the box to be called.
- Make /var/man writeable by user "man", otherwise you'll get errors whenever man pages are installed. I don't believe that the following command represents a security risk, but you are modifying access permissions. The worst is that someone will edit your man pages! ;-)
chown -R man:root /var/man
- Edit /etc/apt/sources.list to use your local mirror if you want.
- Put it all back together. Probably best to just connect the daughterboard while you test it. That way, if something doesn't work you can easily take it apart again.
- Power up the unit and hold your breath. When it's finished booting, you can connect using ssh email@example.com with the password "lspro". Don't forget to change the password!
- Run aptitude update to get the package lists and get installing. Congratulations; You are now running a Lenny / Armel system!
If anyone else makes this work, it'd be good to hear about it here.
Similar approach but using debootstrap
I used a similar approach on my Linkstation Pro, so I think it is worth documenting here. Also, some of the lessons learned might be relevant.
Rather than using the abovementioned image, I followed some of the instructions at http://wiki.debian.org/ArmEabiHowto to use debootstrap to create a Lenny armel install in /armel-chroot. I have plenty of room in / because I installed a 1TB disk and made / 5GB. I bind-mounted the original / into /armel-chroot/orig for convenience when hacking. I then kept 2 terminals open, one with a shell in the chroot and one with a shell in the original environment, both logged in via SSH. In the chroot I mounted standard things like /proc, /sys and /dev/pts. I decided to be less conservative than the ARM EABI HOWTO so, from within the chroot, I gradually installed all of the packages I needed into the chroot, transferring configuration files into the chroot as I went. One by one I shutdown the services/daemons running outside the chroot and restarted them inside the chroot. By the end of this process the whole system (apart from the kernel and some early boot stuff) was running from the chroot! Logging in with SSH meant I now ended up in the chroot! I wanted a fresh install but also wanted to maintain as much of my configuration as was necessary, so I painstakingly used diff to compare /etc and /armel-chroot/etc so I could make the appropriate configuration changes in /armel-chroot.
I also installed the micro-evtd package that is now included in Lenny.
Once I was confident that everything was setup right, I tried to shutdown the system but found that my chroot tricks had stopped any possible communication with init. So, I manually shutdown as many services/deamons as possible, typed "sync", logged out, waited a few seconds and then powered down the Linkstation Pro.
I then removed the disk and attached it to my laptop via my SATA-USB adapter. I followed an approach similar to the one at http://wiki.debian.org/ArmEabiHowto to move the directories (on the filesystem mounted from /dev/sdb). I moved most of the subdirectories of the original root partition to a directory called /oabi-root and moved the subdirectories of /armel-chroot to /. Note that, during the whole installation and configuration process above, I did not deconfigure or remove any software from outside the chroot - if this whole process were to go horribly wrong then I could just move all of the directories back and get my old system running again.
I decided to try the existing arm (rather than the new armel) initramfs - so my system isn't yet fully armel. I already has a custom Linux 184.108.40.206 kernel with all of the required options. The only boot-time change I made was to comment out references to miconapl and use the call to micro_evtd from the new boot_options file (the one that ships with the above image).
## Reset fan as micocontroller does not do this after reboot #miconapl -a fan_set_speed stop ## Watch-dog reset to 250 secs #miconapl -a system_set_watchdog 250 ## Clear error LED indication #miconapl -a led_set_code_information clear ## Indicate it ran #miconapl -a bz_imhere 1 b4 a4 ## Reset watchdog & fan as micocontroller does not do this after reboot micro_evtd -q -s 013501,013300
I wasn't sure how this would work because I not sure if the lines in boot_options are run from the initramfs or once control is transferred to the OS that resides on disk.
I then reattached the disk to my Linkstation Pro and booted it.
I use a zd1211rw-based wireless USB adapater with this particular Linkstation Pro and wasn't sure how it would work. I also have a static address assigned to the wired ethernet interface, for exactly these situations.
The wireless failed to work. I also found I couldn't login via SSH or telnet. However, using nmap I found that all the expected ports were open. The system was up and running... I just had some permission-related problems somewhere. So, I shutdown the Linkstation Pro and reconnected the disk to my laptop... and fixed the problems after checking a few log files.
In order of possible relevance to others...
- For whatever reason, eth1 became wlan0. This was neat... but unexpected... so I had to edit /etc/network/interfaces to configure wlan0. I left the configuration for eth1 there and made a copy for wlan0.
- Always install the firmware for your USB wireless adapter - it won't work with out it! ;-) I had actually downed the interface from the old environment and brought it back up from the chroot. This worked... because I didn't powered down the adapter in any way, so the firmware was already loaded.
- If you use /etc/hosts.allow and /etc/hosts.deny to restrict access to services, make sure hosts.allow knows about your static emergency address on eth0, otherwise you won't be able to login. :-)
Apart from that, it just worked.
The above description is pretty high level. I'm very experienced with Linux so I was happy to do this "by the seat of my pants", with this page and the ARM EABI HOWTO as references. If anyone wants more details then let me know and I'll post them. I'm also happy to move this to a new page if that seems like the right thing to do.
- Martin Schwenke <firstname.lastname@example.org>
- JonSenior - Running vanilla kernel 2.6.28 on a Freelink installed Linkstation Live v2.