タグ: NAS

えーと、うちのNASはBuffaloの「HS-DHGL」。

確か、2006年頃に発売された製品だったか。いわゆる、家庭向けのLinkStationで、DLNA機能とか付いているけれど、ほとんど使ったことはなく、純粋にNASとしてしか使っていない。購入以来、HDDが容量不足になったのでHDDを換装してあったり(今、1TBのHDDがささってたはず)、ファームウェアも書き換えてあって、iSCSIとかしゃべれたりするのだが、これまた使っていない(汗)telnetログインできるんだが、なんだかエラーを吐いてるのが見える（WebのGUIにアクセスした途端に、error.cgiがCPUを食い始める…という）ので精神衛生上よろしくないかもしれない。

一応、このLinkStationにはUSB-HDDを接続して、そこにNASの中身をバックアップを取っていたんだが、このUSB-HDDがたまに書き込み不良になって、NASから切り離されたりする…というわけで、そろそろリプレースするか、となんとなく思い始めている。

とはいえ、次もLinkStationでは芸がないので、Atomを使った箱を作って、そこに「FreeNAS」をインストールしてしまおうかと。FreeNASは、名前の通り、FreeBSDベースと言うことで、あこがれのZFS(…RAIDカードなしに、RAID6相当の冗長性を確保できるのはいいと思うんだけど）も使えるし、GUIも付いているので管理も楽そうだ。うちのWindows7マシンからはiSCSIでマウントすることもできそうだし、…なかなか興味深い。

とりあえず、HDDがごそっとささるAtom箱を作るところからかー。

こちらのエントリーに書いたように、ウチのNASの「HS-DHGL」のファームウェア更新に失敗し、とりあえず、中身をいじってなんとか復旧はさせたけれど、ついでなので、HDDを交換することにした…と。

まずは、買ってきた「WD10EADS」をSATA-USBケーブルに接続して、Ubuntuが入っているThinkpadに接続。で、自動マウントされるので、全部アンマウント。ドライブが/dev/sdbで見えてたので、

fdisk /dev/sdb

で、こちらのページを参考にしながら、領域を確保。ま、/bootの200MBは、このまま200MBで確保するのがいいのか迷ったけれど、そのまま200MBで確保しておいた。で、後は、mkfs.xfsとかのコマンドを使ってパーティションにファイルシステムを作った。

とはいえ、このままだとHDDの箱ができただけなので、NASとしてはbootせず…と。

で、Buffaloのサイトから適当なファームウェアをダウンロードしてきて、Windows上で解凍するといくつかファイルが現れる。Google先生に聞いた感じでは、この中のいくつかのファイルを/bootに放り込んで起動させれば、NASとして使えるようになるらしい。

どうやら、以下のファイルが/bootにあればよさげ…と。

• initrd.img
• hddrootfs.img
• u-boot.buffalo.updated
• uImage.buffalo

ただ、initrd.imgとhddrootfs.imgは、imgって拡張子になってはいるけれど、実態はパスワード付ZIP

らしく、そのパスワードは…インターネットのどこかにあるらしい…と。(笑)

これらのファイルをHDDの/bootにコピーして、HDDをHS-DHGLに接続しなおして起動すると、(おそらく普通に)NASとして使えるようになるはずだが、設定はきれいさっぱり初期設定状態なので、最初にセットアップした手順でほいほい設定すればよさげ。

で、もともと入っていたHDDに入っているデータは、NASにぶら下がっているUSB-HDDにバックアップを取ってあったので、そこから書き戻し。xfsを扱えるLinuxマシンだと、もともとのHDDを覗けるので、データを引っ張り出して、NASに書き込めばいいんじゃないかと。

自宅のNASは、Buffalo LinkStation HS-DHGL。普通に使えていたので、ファームウェアをそのまま放置していたが、ふと、思いついて行進してみたら、「ACP STATE FAILURE」が出て失敗。再起動してみたり、もう一回ファームウェアを更新してみたり、いじくっているうちにまともに起動しなくなった(汗)

でも、google先生に聞いてみたら、同じような症状に直面している人が少なくないらしく、なんとかできるような気がしてきた(笑)

で、どうやら、HS-DHGLのケースを開けて、HDDを取り出さないといけないらしいので、じゃあ、ついでにHDDも交換しておくか(汗)ということで秋葉原へ行って、Western Digitalの「WD10EADS」を買ってきた。FAITHで\7,480。WD10EADSに交換することで、容量が320GB->1TBに増えることになる。

さて、いきなり新HDDにするのもアレなので、もともと入っていたHDDでなんとか起動する状態に戻してみようということで、作業にとりかかった。

こちらのblogを拝見したら、「ACP STATE FAILURE」が出てファームウェアの更新が失敗してしまう原因は、/boot領域にゴミが溜まってしまい、容量不足になって、ファームウェアのデータの書き込みに失敗することのようだ。対処法は、/boot領域のお掃除をすること…と。

/bootの容量不足で書き込み失敗ってのはなんともお粗末な印象…。

で、HS-DHGLの中身はどうやら、ARMで動いているLinux箱みたいなので、/boot領域のファイルシステムはext3になっているらしい。そこで、HS-DHGLのネジをいくつか外して、HDDを露出させて、UbuntuがインストールされているThinkpadを用意して、SATA-USBなケーブルでHDDを接続してみた。(事前に調べた情報で、Linux箱とはいえ、「/」とデータが収められているパーティションはxfsみたいなので、Ubuntuのパッケージマネージャから、xfs関係のモジュールをインストールしておいた)

そしたら、HDDはいくつかのパーティションが切られていて、/bootはext3だけど、システム領域(「/」ですな)と、ネットワーク越しに見えるデータ領域はxfsが使われていることを確認。

/bootがだいたい200MBほど確保されているけど、ファームウェアのデータがだいたい100MB近く。そもそも余裕がある設計になっていないようだ。

うーむ、未確認な妄想だけど、ファームウェア更新完了時に、新旧2つファームウェアのデータが/bootに存在することが必要で、再起動後に新ファームウェアからHDDにデータが展開された後に旧ファームウェアが削除されたりする仕組みなのだろうか。こういう仕組みだとすると、ファームウェアのバージョンアップに伴う肥大化によって200MBという領域が微妙に不足する(300MBくらい確保してたら回避できるのかも)のが、ACP STATE FAILUREの原因と言うことになるのかも。てか、そうでもないと、200MBの領域に100MBのデータを書き込むのに失敗する理由がよくわからん。もしかして、ファームウェアの更新処理に旧ファームウェアの削除処理が入っていないとかいうオチなんだろうか(汗)

ま、とりあえず、/bootに落ちているhddrootfs.buffalo.updatedとかhddrootfs.imgを削除(なんで同じようなファイル名で同じようなサイズのファイルが2つも落ちているんだろう)。ただ、rootが所有者なので、sudoしながらrmで削除。で、Ubuntu側でアンマウントして、HS-DHGLに接続しなおして起動してみたら、とりあえず起動したが、smbやWebインターフェイスなどは起動していないので、ファームウェア自体は書き込まれていない感じだろうか。というわけで、ネットワーク越しに北米バッファロー(汗)のサイトから落としてきた最新ファームウェア(Ver.2.11?)を書き込んでみたら、再起動がかかって、しばらく経過したら、Webインターフェイスにアクセスできるようなったので、とりあえず成功したっぽい。

HDD換装につづく。