How to Fix the Buffalo Linkstation NAS – Partition Not Found Error

Buffalo-LinkStation-220-1024x576-e90e950d78fb74df

Recently I picked up a Buffalo Linkstation 220 to play around with at home as I felt that I could use a bit of additional storage to play around with. Note that this previous statement is pretty much a lie. I have tons of storage, and was really just looking for an new toy to play around with. Basically I just had a few disks laying around that I wanted to put to use.

However, much to my dismay the I was unable to configure the device once I shoved in the disks, powered it up, and connected to it with the Buffalo Smart Phone Navigator. I figured that this was not a big deal however, so I tried the installable Windows App from my Windows 7 Vm. The Buffalo NAS Navigator was also able to connect to the device, however the device showed that it was currently booted in what was called “Emergency Mode”. Not sensing a real emergency, I did not panic.

See borrowed image below.

buffalo_unbrick_001

Fortunately the site that I borrowed the above image from (here) and this site (here) give advice on how to fix the issue. First step is to download the Buffalo Linkstation Firmware Updater that you can get here. Both pages advise you to modify the LSUpdater.ini file. However their instructions did not work for me. The exact changes, and the LSUpdater.ini in its entirety are below.

[code language=”css”]

[Application]
Title = BUFFALO LinkStation Series Updater Ver.1.62
WaitReboot = 1200
WaitFormat = 600
WaitFileSend = 600
WaitDiscover = 120

[Target]
ProductID = 0x80000000
ProductID2 = 0x0000001D
ProductID3 = 0x0000300D
ProductID4 = 0x0000300E
ProductID5 = 0x00003011

Name = LinkStation

[Flags]
VersionCheck = 0
NoFormatting = 0

[SpecialFlags]
Debug = 1

[/code]

At this point you launch the updater again, and select “Update“. This fully partitions the drives and then updates the firmware. This process takes a while, so be patient. Now you can launch the NAS Navigator and configure the device.

Disk I/O Monitoring on the Asus RT-AC66U Router

asus-rt-ac66uThe Asus RT-AC66U, like many home routers that are on the market today, allow you to connect a USB drive to one of its onboard USB ports and share this disk out to your network.  Via the RT-ACC66U, you can share your NAS disk via CIFS or NFS. My configuration has a 1TB unmirrored drive used for temporary scratch storage, and as a network landing area for files that I want to backup.

Note that this is my 4th article on hacking the RT-AC66U. You can check out my other articles below if you are interested.

As you must already know, the Asus RT-AC66U runs Busybox, which is a very small but powerful embedded Linux distro. Because of this there are a lot of familiar commands available via the CLI. However, don’t get to comfortable, as this is still a very foreign land.

Note that this article assumes that you have ssh or telnet working and can log into your RT-AC66U via the CLI.

As I have stated before, you can use the ipgk command to search for and install packages. In the example below I searched for iostat, but found dstat instead. Either one was fine for my purposes…. at least initially.

admin@RT-AC66U:/tmp/home/root# ipkg list | grep iostat
dstat – 0.7.0-1 – dstat is a versatile replacement for vmstat, iostat, netstat, nfsstat, and ifstat

Now that I know what to install, I need to install it.

admin@RT-AC66U:/tmp/home/root# ipkg install dstat
Installing dstat (0.7.0-1) to /opt/…
Downloading http://ipkg.nslu2-linux.org/feeds/optware/oleg/cross/stable/dstat_0.7.0-1_mipsel.ipk
Configuring dstat
Successfully terminated.

Now that dstat is installed lets run it. The switches “rad” enable i/o stats and enable disk stats. The “-D” option allows us to specify a disk by name.

admin@RT-AC66U:/tmp/home/root# dstat -rad -D sda

The command above output what you see below.

dstat-screen-shot

As I mentioned above, dstat is most definitely, a very useful command. However, so far I have not been able to figure out how to get it to display the percentage utilized for a drive, which is rather easy to do with iostat.

Xenserver 6 – Create an Addtional Local Storage Respository with Thin Provisioning Support

ShippingSo recently I deployed 3 XenServer 6 hosts with local storage only. Our need was to virtualize approx 6 very old Centos QA servers running on ancient hardware.

Since I did not have any dedicated network/san storage at my disposal I stuck 6, 146 SAS drives in each server and carved them up into a 410GB raid 10 array.

However the XenServer install did not detect this secondary logical disk, so I had to figure out how to manualy create a storage repository using this new drive.

The first thing that I needed to do was to see how the disk was identified by the OS, for this I used fdisk

#fdisk -l

Disk /dev/sdb: 440.3 GB, 440345714688 bytes
255 heads, 63 sectors/track, 53535 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Using the output above I was easily able to determine that my secondary drive was /dev/sdb.

So first this i did was to determine the UUID of the host that I was logged into

xe host-list

Which spit out the output below

# xe host-list
uuid ( RO) : 4a9971f7-1e59-4e02-b849-04d206ee7b2b
name-label ( RW): xen01
name-description ( RW): Default install of XenServer

Then I ran the following command to create my new SR on /dev/sdb on xen01

xe sr-create host-uuid=4a9971f7-1e59-4e02-b849-04d206ee7b2b content-type=user type=ext device-config:device=/dev/sdb shared=false name-label=”Local storage 2″

Then I confirmed that the new SR was created

xe sr-list host=xen01

Note that one fo the things that I found most odd with this process is that you do not actually create a partition on your disk before turning it into a storage repository.

How to Check Mulitpathing in Veritias Volume Manager

Multipass-01Today while working in the Datacenter,  I accidentally destroyed a fibre cable running to one of our database servers. All the databases went poof and the DBAs freaked out. After I reminded them that this was a non-production database I went about running a new fibre cable.

Being that this box was dual pathed back to the SAN, the server should have had additional paths back to its disks and the databases should have keep running along just fine. However,  as luck would have it, the secondary path was down at the time I destroyed the primary.

Anyway after reseating the secondary fibre and running a new primary cable I was able to verify that I had multiple connections back to the disks with the following commands.

# vxdmpadm getdmpnode dmpnodename=3pardata0_4641

NAME                 STATE        ENCLR-TYPE   PATHS  ENBL  DSBL  ENCLR-NAME 
==============================================================================
3pardata0_4641       ENABLED      3PARDATA     4      4     0     3pardata0

Where 3pardata0_4641 is the disk name and PATHS is obviously the number of paths back to the SAN disk.

Even better yet you can check DMP (dynamic multipath status) for all disks with the command below.

vxdmpadm getdmpnode

LSI MegaCLI — Check For Failed Raid Controller Battery

701590_rusty_batteryThere are several tools that you can use to monitor and configure and LSI SAS controller, however as I have found, some are easier than others to use and some do not always display the correct information.

In my case my controller is a SAS 9260-8i, and when building a server I always make sure that I install the MegaRaid Storage Manager gui for configuring disks and setting up email alerts. However I have often found that this tool is sometimes confusing to use for other tasks so I also make sure that I install the MegaCLI (command line interface). Both utilities can be downloaded directly from LSI here.

MegaRaid Storage Manager installs to /usr/local/MegaRAID Storage Manager, while the cli installs via rpm to /opt/MegaRAID/MegaCli.

Anyway to check the battery status run the following (note i am running 64 bit os)

#>./MegaCli64 -AdpBbuCmd -aAll

Your output will be lengthy – but look for the line below to know if you need to replace your BBU.

Battery Replacement required            : Yes

Two additional usefully commands are:

  • megacli -AdpAllInfo -aALL lists all the adapters in the machine
  • megacli -PDList -aALL lists all disks and enclosures

Note that there is an open source CLI called Megactl, and while its quick and easy to use to see a quick list of your disks and their statuses, its not shown itself to be accurate when it comes to detecting whether or not a battery has failed. You can get it here

Additonal Megacli command can be found here; https://twiki.cern.ch/twiki/bin/view/FIOgroup/DiskRefPerc

Removing a Virtual Disk from CentOS/RHEL via vSphere Client

PxdxaDisco08 When you right click on a VM via the vSphere client and click edit setting you will see your hard disk enumerated as follows:

Hard disk 1 - Virtual Disk

Hard disk 2 - Virtual Disk

However CentOS/RHEL enumerates your disks using a different nomenclature. See below:

Disk /dev/sda: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1044     8385898+  83  Linux
/dev/sda2            1045        2349    10482412+  83  Linux
/dev/sda3            2350        2610     2096482+  82  Linux swap

Disk /dev/sdb: 268.4 GB, 268435456000 bytes
255 heads, 63 sectors/track, 32635 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       32635   262140606   83  Linux

[[truncated]]

While you can assume that the your first disk listed in ESX is your first disk listed via the OS, this is not always the case. You can attempt to compare disk sizes to further determine which disk is which, however the sizes do not always match up.

The best way to identify disks is via the Virtual Device Node, which is visible via the virtual disk properties in ESX and via the command lsscsi in Centos/OS.

More than likely lsscsi is not installed via default so you are going to either need to install via yum, or download a rpm and install. Once installed run as seen below

>lsscsi
[0:0:0:0]    disk    VMware   Virtual disk     1.0   /dev/sda
[0:0:1:0]    disk    VMware   Virtual disk     1.0   /dev/sdb
[0:0:2:0]    disk    VMware   Virtual disk     1.0   /dev/sdc
[0:0:3:0]    disk    VMware   Virtual disk     1.0   /dev/sdd

The first two numbers are unique to the scsi controller and the second two numbers indicate the disk number which can be seen in the disk properties in the vsphere client properties.

For example in vmware Hard disk 4 has a virtual device id of “SCSI (0:3) Hard Disk 4, and by running lsscsi I know for sure that this disk is /dev/sdd. Now I can remove the disk with confidence from esx and have to worry that I removed the wrong disk.