Linkstation 400

From NAS-Central Buffalo - The Linkstation Wiki
Jump to: navigation, search

Summary

In December 2014 I purchased some Buffalo Linkstation 421DE's. They were pretty inexpensive ($90 on sale at NewEgg) and look like they had decent performance. Being a Linux enthusiast I wanted to see if I could do a little more with the unit, ideally ending up with Debian running on the thing. What follows is what I've done (so far) with my LS421DE's.

Initial Setup

Being the diskless model, the unit doesn't come with 'firmware' on it. In reality, the 'firmware' (which isn't exacty 'firm' in the traditional firmware sense) is stored on the hard drive(s), of which there are none to start. This is a really frustrating part of the Out of Box experience, but understandable, especially for the low price of this unit. So, to get things up and runnning, you'll need to put at least 1 drive in and do a firmware update. At the time of this writing, I updated my 421DE to v1.33. And to get it to work with new or already used drives I had to edit the LSUpdater.ini file, changing the NoFormatting value from 1 to 0:

[Flags]
VersionCheck = 1
NoFormatting = 0

Then run LSUpdater.exe, and it should find the unit and you'll be asked if you want to format the drive(s). Make sure you don't have any data on them that you care about before you say yes!

SSH Access

Well, I didn't use the ACP_Commander method. Instead I just removed the single drive I had in the unit (after power down) and modified the root filesystem with another Linux host. It took a few tries, but I enabled the ssh daemon, primarily by editing /etc/init.d/rcS to start sshd.sh and changing the /etc/init.d/sshd to start regardless of the presence of sshd and the SFTP option. I also edited /etc/sshd_options as described. In the end I did end up with SSH access as other have achieved. Yay!

After 'formatting' using the LSUpdater.exe software (or at the factory), the first hard drive is partitioned like so:

~# parted /dev/sdf print
Model: ATA ST4000DM000-1F21 (scsi)
Disk /dev/sdf: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      17.4kB  1024MB  1024MB  ext3         primary
 2      1024MB  6144MB  5119MB               primary
 3      6144MB  6144MB  394kB                primary  bios_grub
 4      6144MB  6144MB  512B                 primary
 5      6144MB  7168MB  1024MB               primary
 6      7168MB  3992GB  3985GB               primary

This is for a 4TB drive BTW and I have it on a USB dock on a nearby Linux box. To get at the filesystems you'll do something like this (as root, or add sudo in front):

# mdadm --assemble --run /dev/md11 /dev/sdf1
mdadm: /dev/md11 has been started with 1 drive (out of 2).
# mount /dev/md11 /mnt
# ls -l /mnt
total 200048
-rw-r--r-- 1 root root     35766 Dec 25 08:17 conf_save.tgz
drwxr-xr-x 2 root root      4096 Oct 31  2007 grub/
-rw-r--r-- 1 root root 188966282 Oct  7 05:28 hddrootfs.buffalo.updated.done
-rw-r--r-- 1 root root  11966319 Oct  7 03:58 initrd.buffalo
-rw-r--r-- 1 root root     24629 Dec 25 08:17 log.tgz
-rw-rw-rw- 1 root root    725924 Sep 13  2013 u-boot.buffalo
-rw-r--r-- 1 root root   2894368 Oct  7 03:57 uImage.buffalo
# umount /mnt
# mdadm --stop /dev/md11

Clearly based on the above, the first partition holds some boot files. This is what is mounted at /boot on the running Linux system, and is indeed what the u-Boot bootloader loads from (kernel is uImage.buffalo and initrd is initrd.buffalo). The 2nd partition is the one we're after, so do the same as the above, but for partition 2:

# mdadm --assemble --run /dev/md12 /dev/sdf2
mdadm: /dev/md12 has been started with 1 drive (out of 2).
# mount /dev/md12 /mnt

Then, to enable SSH, edit /mnt/etc/init.d/sshd.sh, commenting out the following lines as shown:

#if [ "${SUPPORT_SFTP}" = "0" ] ; then
#        echo "Not support sftp on this model." > /dev/console
#        exit 0
#fi

The SUPPORT_SFTP variable comes from /etc/nas_feature, so you'd think you could just set that variable to 1, but the stock initrd image will overwrite this on boot. You can certainly edit the initrd image to fix/change this, which I'll add in a bit, but for initial SSH access, commenting out the lines above seems the most straightforward (to me). Anyways, now the SSH server can start, but won't yet, until you add it in /mnt/etc/init.d/rcS. Somewhere near the end of that file, you can launch sshd. I added it to the list as shown below:

echo "** step final(after bootcomplete) **"
for cmd in sshd.sh diskmon.sh hdd_late_check.sh check_initialization.sh usb_late_check.sh daemonwatch.sh
do
        exec_sh ${cmd}
done

So, ssh will start, but it's not configured correctly yet. Edit /mnt/etc/sshd_config and uncomment the lines:

Port 22
PermitRootLogin yes

And if you want to login, you probably need to know the root password. Perhaps it's one of the known Buffalo passwords, but you'll likely want to change it to something you could type yourself. So edit the password field in /mnt/etc/shadow, perhaps as a copy of the password on your Linux box/VM, or use the following line to set the password to 'password':

root:$6$D91gn.N4$1h0cLNX4AUuFRm1oMy8ZxdYfisKXa/8nwzI3xP7f8ILxYLQCHTyst5syKbqKPYGeL7SzjRFm1F4PH3HvTlaD4/:10933:0:99999:7:::

Obviously, once you log in via ssh, you'll want to change this!

I think we're ready now, so

# umount /mnt
# mdadm --stop /dev/md12

Put the drive back into the NAS, boot up, wait a bit, and hopefully you can ssh in!

Problems

I did the above steps on the 1st of 2 drives. I had to add the '--run' to force the assembly of the partition so that I could mount them. On the next boot (with the 2nd drive still in place) it wiped out most of my changes (all except for /etc/sshd_config). Booting without the 2nd drive seems to solve this, but I'm not sure what happens when put the 2nd drive back in (testing now..) Okay, so it still works after adding the 2nd drive (after booting once without it). However:

[root@LS421DE515 ~]# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md10 : active raid0 sda6[0] sdb6[1]
      7782874112 blocks super 1.2 512k chunks

md0 : active raid1 sdb1[1]
      999872 blocks [2/1] [_U]

md1 : active raid1 sda2[0]
      4995008 blocks super 1.2 [2/1] [U_]

md2 : active raid1 sdb5[1]
      999424 blocks super 1.2 [2/1] [_U]

unused devices: <none>

So the /boot, /, and swap which are raid 1's on both drives are only half there. md1 is using the drive in bay 1 (the one I modified), md0 and md2 are on the bay 2 drive. These need to be re-built and re-assembled, which I'd think the Buffalo firmware would handle when replacing a drive. The following fixed mine up:

mdadm --manage --add /dev/md0 /dev/sda1
mdadm --manage --add /dev/md1 /dev/sdb2
mdadm --manage --add /dev/md2 /dev/sda5

Clearly, the better approach is to make these changes to the firmware updater's root fs image instead. Then the raid will be in sync from the beginning, you don't need to swap drives in/out and if it's already done for you, and you don't even need a running Linux system to make the changes (although I'm not sure if there are license issues with publishing these images.) The ACP commander approach also avoids these issues since it's done on a live system.

New Problem: SSHD get's killed! When doing certain operations in the web UI, the ssh server get's killed. It sometimes get's restarted, sometimes not. In particular, when I insert a USB drive, the SSH server goes away until the USB drive is removed or unmounted. I'm still digging into this one...

Debian Wheezy

So, now that I had SSH access, I wanted to install stuff, Debian in particular. So I did a debootstrap install for the armhf, roughly as described here. After that I now have a Debian Wheezy install running in a chroot area (on a USB flash drive) and can install just about whatever I want without messing up the stock 'firmware'.

Serial Console

I did some digging around on the hardware and figured out where the serial console lines are. Based on the data sheet, UART0 must be on either of 2 pins near the marked corner of the Marvel 370. Some traces come out that way towards R265 and R106, and sure enough, there appeared to be some 115200 UART signaling on the R106 pad during bootup. Following the traces around, it looked like these signals get routed over to two 4-pin connectors (not populated) on the edge of the board (J11 and J12). But the signals didn't actually show up. First, the are two resistors by J11 that need to be populated (0 ohm I'd assume) to connect the lines. But even that isn't enough. Here's the bit I don't understand: the lines run under U6/U7 (not sure why it's labelled twice), which is the serial flash just up and back from the 370 as the unit normally sits. The signals are good before they run under the chip and not present after, with no vias in the PCB in that areas. So.. I de-soldered the serial flash and lo and behold, there are 2 0402 footprints underneath the flash chip that are obviously not populated. The cleanest solution to this I had was to jumper from the R265 and R106 resistors right to one of the 4-pin connectors. I then put a .100" header in the other 4-pin connector and connected a 3.3V FTDI USB TTL cable to it (GND, TX, and RX to the proper pins) and I've got U-Boot console access!

BootROM 1.08
Booting from SPI flash
DDR3 Training Sequence - Ver 2.3.5
DDR3 Training Sequence - Ended Successfully
BootROM: Image checksum verification PASSED

=========================
==== Welcome to YANAGI ==
=========================

 ** LOADER **


U-Boot 2009.08 ( 8月 28 2013 - 21:36:20)Marvell version: 1.1.3 NQ
U-Boot Addressing:
       Code:            00600000:006AFFF0
       BSS:             006F8360
       Stack:           0x5fff70
       PageTable:       0x8e0000
       Heap address:    0x900000:0xe00000
BUFFALO_BOOTVER=0.13
Board: Buffalo LS-M 88f6710
SoC:   MV6710 A1
CPU:   Marvell PJ4B v7 UP (Rev 1) LE
       CPU @ 1200Mhz, L2 @ 600Mhz
       DDR @ 600Mhz, TClock @ 200Mhz
       DDR 16Bit Width, FastPath Memory Access
PEX 0: Root Complex Interface, Detected Link X1
PEX 1: Detected No Link.
DRAM:  512 MB
       CS 0: base 0x00000000 size 512 MB
       Addresses 14M - 0M are saved for the U-Boot usage.
SF: Detected MX25L8006E with page size 256, total 1048576 bytes
NAND:  512 MiB
u-boot envinit tval=e4b4c857
FPU not initialized
USB 0: Host Mode
USB 1: Host Mode
Shutting down unused interfaces:
       AUDIO
       TDM
Modules/Interfaces Detected:
       SDIO
       RGMII0 Phy
       RGMII1 Phy
       PEX0 (Lane 0)
       PEX1 (Lane 1)
       SATA0 (Lane 2)
       SATA1 (Lane 3)

Marvell Serial ATA Adapter
Integrated Sata device found

MAC Address : 10:6F:3F:xx:xx:xx
MMC:   MRVL_MMC: 0
Net:   egiga0, egiga1 [PRIME]
hit any key to switch tftp boot.
Hit any key to stop autoboot:  0
switched to TFTP boot.
Hit any key to stop autoboot:  0
BUFFALO>>

Note: the above is with no hard drive connected. If drives are present, you see HDDx Power ON and a scan of the drive before the 'MAC Address :' line...

BUFFALO>> printenv
sn=xxxxxxxxxxxxxxxxxxx
eth1addr=10:6F:3F:xx:xx:xx
serverip=192.168.11.1
ipaddr=192.168.11.150
deviceid=_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
SerialNo=xxxxxxxxxxxxxx
stdin=serial
stdout=serial
stderr=serial
console=console=ttyS0,115200
enaMonExt=no
pexMode=RC
setL2CacheWT=no
sata_dma_mode=yes
sata_delay_reset=0
enaExtDisk=no
MALLOC_len=5
ethprime=egiga1
netbsd_en=no
vxworks_en=no
bootargs_root=root=/dev/sda2 rw initrd=0x2600040 panic=5
bootargs_end=:10.4.50.254:255.255.255.0:KW40:eth0:none
image_name=uImage
load_addr=0x02000000
buffalo_ver=BOOTVER=0.13
uboot_date=UBOOT_DATE="2013/08/28"
kernel=uImage.buffalo
initrd=initrd.buffalo
autoload=n
bootcommon=setenv bootargs $console $bootargs_root $bootargs_func $buffalo_ver $uboot_date $mtdparts $bootsystem; ;sf protect off; bootm 0x1200000 0x2600000
bootcommon-u=setenv bootargs $console $bootargs_func $buffalo_ver $uboot_date $mtdparts $bootsystem; ;sf protect off; bootm 0x1200000
tftpbootcmd=tftp 0x1200000 $kernel; tftp 0x2600000 $initrd; setenv bootsystem tftpboot=yes; run bootcommon
idebootcmd=ext2load ide 0:1 0x1200000 /$kernel; ext2load ide 0:1 0x2600000 /$initrd; setenv bootsystem hddboot=yes; run bootcommon
usb1bootcmd=setenv usbActive 0;usb start;fatload usb 0 0x1200000 /boot/uImage370;sf protect off;run bootcommon-u
usb2bootcmd=fatload usb 0 0x1200000 /boot/uImage.buffalo;fatload usb 0 0x2600000 /boot/initrd.buffalo;setenv bootsystem usbboot=yes;run bootcommon
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:0x2000000(boot),0x1e000000(rootfs)
nandbootcmd=fsload 0x1200000 /$kernel; fsload 0x2600000 /$initrd; setenv bootsystem nandboot=yes; run bootcommon
failbootcmd=bootfail
bootcmd=for i in $bootorder; do run ${i}bootcmd; done
standalone=fsload $load_addr $image_name;setenv bootargs $console $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm $load_addr;
disaMvPnp=no
bootdelay=3
ethaddr=00:50:43:b4:57:c8
ethmtu=1500
eth1mtu=1500
mvNetConfig=mv_net_config1=1,(00:50:43:11:11:11,0:1:2:3:4),mtu=1500
usb0Mode=host
usb1Mode=host
usbActive=0
yuk_ethaddr=00:00:00:EE:51:81
nandEcc=1bit
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
enaAutoRecovery=yes
eeeEnable=no
pcieTune=no
hdddelay=7
bootorder=nand fail tftp
ethact=egiga1

Environment size: 2239/65532 bytes

SD Card

While messing around with the PCB, I also put on an SD card socket and put a card in--hoping that it would show up in Linux. No dice so far. The kernel reports an mmc device, but it doesn't detect the card, so no /dev/mmcblk0 or /dev/mmcblk0p1 to speak of.

TODO

I'm hoping to flesh this page out some more with pictures and more detail over the next few weeks.

I plan to boot to a stock Debian Wheezy (or maybe even Jessie) soon, bypassing the buffalo firmware. If/when I get that done, I'd be happy to post some files and instructions needed to do this without any case opening/electrical hacking (if possible.)

I'd also like to run a more recent vanilla kernel instead of the buffalo provided one. This may be useful for getting the SD card slot to work, but I'm unsure of all the support needed for the mapped LEDs, the power switch, fan control, etc, so we'll have to see.

Maybe the Mini PCIe connector could be populated as well, but that looks like it'd involve adding the associated caps/resistors, and I'd have to figure out the values. Perhaps not worthwhile...

--Imlizking (talk) 01:49, 19 December 2014 (UTC)