自宅の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換装につづく。