2011/04/08

ReadyNASとは何か

ReadyNASを普通に使っている限りは全く気にする必要はないが、何か問題が起きたりしたときに、そもそもReadyNASの中はどうなってるのかということに興味が湧くのは自然だと思うので、その流れの話。

(このエントリは一続きのエントリの5/5)

4.1. ReadyNASの構成(推測)


ReadyNASが何かといえば、LinuxをOSとして稼働する/RAID構成で/NAS専用のPC、ということになる。アプライアンスのLinux機としては普通のPCに近いが、普通のPCと特に違うのは、
  • オンボードにOSのインストールイメージを持っていること
  • ブートプロセスが少し変わっていること
ただ、Netgearの人はこういう話をあまり正面から書いてくれてない。あくまでアプライアンスであってユーザーの心配することではないし、SSHでログインすれば分かる人には分かるだろう、と説明の必要を感じてないのかもしれない。したがって、自分の推測がかなり入っているし、自分はLinuxに特に詳しいわけでも何でもないので、その前提で。

本当にトラブルに陥って回復作業をしなければいけないときは、素直にNetgearのサポートに頼った方がいい。

先に用語について。ReadyNASでは、そのファームウェア=専用にカスタマイズされたLinux=OSのことをRAIDiatorと呼んでいる。よく似た名前でRAIDarもあるが、こちらはクライアントPCからネットワーク上のReadyNASをモニターするためのソフト。何でこんなややこしい名前にしたのか知らないが。

いきなりだが、ReadyNASの構成とRAIDiatorのアップデート/回復の関係を整理。
場所Duo
(Sparc)
(X-RAID)
Ultra 2
(x86)
(X-RAID2)
RAIDiatorのアップデート/回復の影響
Frontview
/USBメモリ
からの
アップデート
(注1)
OS
Reinstall
(注3)
Factory
default
(注4)
BIOSオン
ボード
NAND
Flash
(64MB)
Flash ROM
(2MB)



Linux
カーネル
NAND
Flash
(128MB)
書き換え
Linux
インストール
イメージ
(RAIDiator
ファイル)
OS (Linux
ユーザー
ランド)
(RAIDiator)
HDD
(2台
とも)
2GB
(初期に
約350MB
を使用)
4GiB
(初期に
約370MB
を使用)
書き換え
(注2)
OSをNAND
Flashから
インストール
パーティション
を作成し直して
(ユーザーデー
タは消える)、
OSをNAND
Flashから
インストール
スワップ256MB512MiB
ユーザー
データ
残り残り
DRAM
メモリ
SO-
DIMM
DDR-
SDRAM
(初期は
256MB)
DDR3-
SDRAM
(初期は
1GB)
(注1)USBメモリからのアップデートを確認したのはUltra 2のみ。
(注2)既にインストールされているバージョンと同じ場合は書き換えない。
(注3)何かの事情でNAND FlashとHDDのRAIDiatorのバージョンが違う状態になった場合、自動的にOS Reinstallが行われる。ただし、これがうまく行かず、起動できない状態になることもあり、そのときは手動でOS Reinstallが必要。
(注4)そのReadyNASで稼働する状態になったHDD以外を入れた場合、自動的にFactory defaultが行われる。ただし、これがうまく行かず、起動できない状態になることもあり、そのときは手動でFactory defaultが必要。なお、同じ機種同士であればそのままのHDDで稼働する模様。

4.2. アップデート/回復手段


なぜこう言えるのかはひとまず置いて、具体的な方法について説明すると、

Frontviewからのアップデート


基本簡単。ただし、古いバージョンに戻せない制限付きのことがあるので、リリースノートに注意。

USBメモリからのアップデート


ReadyNASがまともに起動せず、Frontviewが使えない場合や、Frontviewからは古いバージョンに戻せない制限がある場合でも可能だったりする。

以下はUltra 2(x86)の場合の方法。

[参考] 非公式だが、公式FAQからリンクされている方法
Unofficial ReadyNAS USB Recovery Guide for x86-based Systems

  1. ReadyNAS_x86_USB_Flash_Recovery-4.2.12.zipをダウンロードする。これを展開してusbrecovery.exe(NETGEAR USB Recovery Utility)を実行すればUSBメモリが作成される。

    なお、このユーティリティの実行にはVisual C++ 2005 SP1 Redistributable (x86)が必要。また、これにはRAIDiatorファイル(4.2.12)が同梱されているが、同じフォルダに新しいRAIDiatorファイルをコピーすれば、実行時にそれを選ぶことができる。

  2. このUSBメモリを前面のUSB3.0ポートに挿し、backupボタンを押した状態で電源ボタンを押して離す。電源が入って自動的にUSBメモリにアクセスが行われ、2分ぐらいで自動的に電源が落ちる(ここまでbackupボタンは押したまま)。

  3. USBメモリを抜き、普通に電源を入れると、アップデート作業が行われて起動する。
ちなみに、自分のDuoではUSBメモリによるアップデートに成功したことは、相当粘ってみたが一度もない。どこかに問題があるのだと思う。一方、DuoにはPCと直結してTFTPでアップデートする方法があるが、Ultra 2でも同様の方法があるのかは不明。

OS Reinstall


HDDにあるOSをNAND Flashにあるインストールイメージを使って書き換えるもの。ユーザーデータには触らないので、ユーザーデータが失われることはない。

ただし、これを開始する操作はFactory defaultにごく近いので、一歩間違えるとFactory defaultになってユーザーデータは失われる。もし誤ってFactory defaultが開始されかけたときは、電源ケーブルを引き抜いてでも止めなければいけない。

以下はUltra 2(x86)の場合にOS Reinstallを開始する方法。

[参考] 日本公式サイトにある説明
ReadyNAS Ultra2 : RAIDiator (ReadyNAS OS) の再インストール

  1. 後面のResetスイッチをピンで押した状態で電源ボタンを押して離す(Resetスイッチは押したまま)。Act以外のLEDが全部点灯したらResetスイッチを離す。

  2. これで管理用のブートメニューに入ったので、backupボタンを3回押し、HDD2のLEDだけが点灯した状態(OS Reinstallが選択された状態)にする。ここで後面のResetスイッチを押すと、選択が確定され、OS Reinstallが開始される。
ちなみに、このブートメニューとLEDの関係は以下のようなもの(Readynas Ultra 2 how to resets etc...)。
電源HDD 1HDD 2backup
(USB)
ブートメニュー開始
1回目Normal---
2回目Factory default---
3回目OS Reinstall---
4回目Tech Support---
5回目Skip Vol Check--
6回目Memory Test--
7回目Test Disk--
(注)Actは関係ない。

なお、OS Reinstallの後も一部の設定は残ってたりするので、OSのパーティションをフォーマットしてからインストールするのではなく、上書きインストールをする模様。

Factory default


最も根本的かつ破壊的な手段で、HDDをチェックした後、全てのパーティションを作成し直した上で(ユーザーデータは消える)、OSをNAND Flashにあるインストールイメージからインストールするもの。

なお、工場出荷時の状態にリセットするといっても、RAIDiatorをアップデートしたことがあれば、NAND Flashのインストールイメージも書き換えられているので、文字通り工場出荷時の状態に戻るわけではない。

以下はUltra 2(x86)の場合にFactory defaultを開始する方法。

[参考] 日本公式サイトにある説明
ReadyNAS Ultra2 : 工場出荷時の設定への戻し方

  1. 後面のResetスイッチをピンで押した状態で電源ボタンを押して離す(Resetスイッチは押したまま)。Act以外のLEDが全部点灯したらResetスイッチを離す。

  2. これで管理用のブートメニューに入ったので、backupボタンを2回押し、HDD1のLEDだけが点灯した状態(Factory defaultが選択された状態)にする。ここで後面のResetスイッチを押すと、選択が確定され、Factory defaultが開始される。
上記の(注4)のとおり、そのReadyNASで稼動する状態になっているHDD以外を入れた場合(空のHDDや普通のPCで使っていたHDDを入れた場合、Duo(Sparc)で稼動していたHDDをUltra 2(x86)に入れた場合、またはその逆も含まれる)は、起動時に自動的にFactory defaultが行われる。この辺は少し怖いところ。

ただし、これがうまく行かず、起動できない状態になることがある。法則性はよく分からないが、以前にReadyNASで使っていたHDDを一旦別の用に使い、再びReadyNASで使おうとしたときに起こった(RAIDarに「ルートファイルシステムが壊れています」と表示される。このルートファイルシステムとはRAIDiatorのOSのあるパーティションを指しているようなので、それがない状態では当然ではある)。

そういうときは手動でFactory defaultを開始すれば回復できた。

4.3. ReadyNASの構成に関する推測


話は戻って、ReadyNASの構成に関して。基本的に、馴染みのあるx86のUltra 2を中心に話を進める。

まずメモリの構成については、Netgearの資料に記載がある(Letter of Volatility)。これを見るまで、Ultra 2のAMIBIOSがNAND Flashにあるのか、(普通のPCのように)独立したFlash ROMにあるのか分からなかったが、答えは後者だった。

HDDのパーティション


パーティションについては、実はログ(「全てのログ」の方)に出ている。まずDuo(HDDは5400.5の320GB)の方で、「fdisk -l」の結果らしきpartition.logを見ると、
Disk /dev/hdc: 320.0 GB, 320062447616 bytes
255 heads, 63 sectors/track, 38912 cylinders, total 625121968 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x53c9a337

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1              32     4096031     2048000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/hdc2         4096032     4608031      256000   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/hdc3         4608032   625105615   310248792    5  Extended
/dev/hdc5         4608040   625105615   310248788   8e  Linux LVM

Disk /dev/hde: 320.0 GB, 320062447616 bytes
255 heads, 63 sectors/track, 38912 cylinders, total 625121968 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

この中のhdc1のパーティションがOSのあるルートで、hdc2はスワップ、その後ろの拡張パーティション中のhdc5にユーザーデータの入ったLVMがある。

さらに「df -h」の結果らしきdisk_usage.logを見ると、
Filesystem            Size  Used Avail Use% Mounted on
/dev/hdc1             2.0G  352M  1.6G      18% /
tmpfs                  16k     0   16k       0% /USB
/dev/c/c              294G  270G   24G      92% /c

OSのあるhdc1の使用量が分かる。また、ユーザーデータは/dev/c/cにマウントされていることも分かる。

同様に、Ultra 2(HDDは5K500.Bの500GB)のpartition.logを見ると、
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xbe56265a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              64     8388671     4194304   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2         8388672     9437247      524288   fd  Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sda4         9437248   976768064   483665408+   5  Extended
/dev/sda5         9437256   976768064   483665404+  fd  Linux raid autodetect

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              64     8388671     4194304   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2         8388672     9437247      524288   fd  Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sdb4         9437248   976768063   483665408    5  Extended
/dev/sdb5         9437256   976768064   483665404+  fd  Linux raid autodetect

Disk /dev/md0: 4293 MB, 4293906432 bytes
2 heads, 4 sectors/track, 1048317 cylinders, total 8386536 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/md1: 536 MB, 536805376 bytes
2 heads, 4 sectors/track, 131056 cylinders, total 1048448 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/md2: 495.2 GB, 495272132608 bytes
2 heads, 4 sectors/track, 120916048 cylinders, total 967328384 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/dm-0: 489.8 GB, 489894707200 bytes
255 heads, 63 sectors/track, 59559 cylinders, total 956825600 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

こちらは完全にソフトウェアRAIDの状態を示していて、sda1とsdb1から成るmd0がOSのルート、sda2とsdb2から成るmd1がスワップ、拡張パーティション中のsda5とsdb5から成るmd2にユーザーデータの入ったLVMがある。

同じくdisk_usage.logを見ると、
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              4.0G  371M  3.5G  10% /
tmpfs                  16K     0   16K   0% /USB
/dev/c/c              455G  273G  182G  60% /c

OSのあるmd0の使用量が分かる。

また、同じくmdconfig.logを見ると、
Device         : /dev/md0
Create Time    : 1296968223
Update Time    : 1299155668
RAID Level     : 1
RAID Capacity  : 4193268
Disk Size      : 4193268
Chunk Size     : 0
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda1          0        8/ 1      8388608    6 [ Active Sync ]
  2   /dev/sdb1          1        8/17      8388608    6 [ Active Sync ]

Device         : /dev/md1
Create Time    : 1296968223
Update Time    : 1299119883
RAID Level     : 5
RAID Capacity  : 524224
Disk Size      : 524224
Chunk Size     : 65536
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda2          0        8/ 2      1048576    6 [ Active Sync ]
  2   /dev/sdb2          1        8/18      1048576    6 [ Active Sync ]

Device         : /dev/md2
Create Time    : 1296968223
Update Time    : 1299155668
RAID Level     : 5
RAID Capacity  : 483664192
Disk Size      : 483664192
Chunk Size     : 65536
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda5          0        8/ 5    967330809    6 [ Active Sync ]
  2   /dev/sdb5          1        8/21    967330809    6 [ Active Sync ]

RAIDの設定が分かる。OSのあるmd0はRAID1、ユーザーデータのあるmd2はRAID5と出ているが、X-RAID2はNetgearの独自拡張らしいので、その通りに取っていいかは不明。

ちなみに、Ultra 2はRAIDiator 4.2.16で3TBのHDDに対応するが、そのためにHDDのパーティショニングが従来のMBRからGPTに変わる。その場合はどうなるかといえば、4.2.16-T33にアップデートしたUltra 2(HDDは5K500.Bの120GB)で「sgdisk -p」をすると、
Disk /dev/sda: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 316D3541-952B-44B0-ABC1-E150505DF780
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 8-sector boundaries
Total free space is 5108 sectors (2.5 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64         8388671   4.0 GiB     FD00  Linux RAID
   2         8388672         9437247   512.0 MiB   FD00  Linux RAID
   5         9437256       234436544   107.3 GiB   FD00  Linux RAID

同じく「df -h」をすると、
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              4.0G  376M  3.5G  10% /
tmpfs                  16K     0   16K   0% /USB
/dev/c/c              102G  257M  102G   1% /c

パーティション自体はMBRのときと変わってないのが分かる。というわけで、4.2.16にアップデートしたらパーティションはそのままGPTに横滑りする仕組みらしい。なお、HDDのセクタ0はしっかりprotective MBRになっていた。

以上でHDD内の大まかな構成は分かった。

カーネルの所在


オンボードのNAND Flashについて、そこにRAIDiator(ファームウェア)のインストールイメージが置かれていることは色々なところで書かれている。例えば、Netgearの人はPro(x86)についてこう書いている。
(Re: [Readynas Pro Business] 128MB or 256MB embedded flash?)
That is just where the firmware image is stored for re-install/factory installs, you cannot use the flash in user mode. Right now the firmware image is around ~65MB. Upon system install, an OS partition is created on the hard drives that is 4GB in size. That is where all applications/configuration is stored.

また、Sparc(機種は書いてないが時期的に)については、
(Re: general interest question about the firmware)
The firmware is stored on Flash RAM on the main board. The OS is installed to a 2GB partition on the drives.
(Re: iTunes Server won't go away)
The firmware will stay as whatever you have installed. When you update the system, the firmware is written to the NAND/Flash as well, which is the source during a re-install. It won't touch your data, but will set the network IP to DHCP and admin password to default (netgear1).

HDDにインストールされたOSの使用量から見て、NAND Flashにその(たぶん圧縮された)インストールイメージが入っているのは容易に理解できる。ただ、NAND Flashの役割が単にその倉庫だけなのか、あるいはブートプロセスに関わっているのかが分からなかった。

そこで、Ultra 2のHDD(5K500.Bの500GB)のセクタ0を見てみると、

パーティションテーブルは当然あるが、ブートコードの部分は空になっている(WindowsのDiskIDが付いているが、これはX61sに接続したときに書き込まれたものだと思う)。

さらに、OSのパーティションの中を見回しても、GRUBのようなLinuxのブートローダーがないことに気づいた。つまり、普通にHDDからブートしている形跡がない。

不思議に思いながら、ブート時の記録であるdmesg.logを見ると、その冒頭に以下の記述があった。
Linux version 2.6.33.7.RNx86_64.2.2 (jmaggard@calzone) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Oct 15 13:20:46 PDT 2010
Command line: initrd=initrd.gz console=ttyS0 sk98lin.LowLatency=Off,Off reason=normal BOOT_IMAGE=kernel

実はここでLowLatencyの設定がされてたりするが、それは置いといて重要なのは以下の部分。
  • initrd=initrd.gz
  • BOOT_IMAGE=kernel
これはinitrd(ブート初期のramdiskイメージ)としてinitrd.gzを、カーネルイメージとしてkernelをロードしているらしいが、OSのパーティションにはそれらしきものはなかった。

が、この2つのファイルには見覚えがあった。それはRAIDiatorのアップデート用のUSBメモリの中で。

実はこのUSBメモリはsyslinuxでブータブルになっていて、X61sでも途中まで起動できたりする。

さらに面白いのは、この設定ファイルであるsyslinux.cfgで、その中身が以下。
serial 0 9600 0

default Normal

label Normal
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=normal

label FactoryDefault
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=factory

label OSReinstall
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=os_reinstall

label TechSupport
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=diag

label SkipVolCheck
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=skip_fsck

label MemoryTest
kernel memtest

冒頭にシリアルポートの設定らしきものがあるが、その後には明らかに管理用のブートメニューと関係ありそうな記述が並んでいる。とくに、先頭のlabel Normalの部分はdmesg.logの冒頭と似ていて、カーネルイメージとしてkernelを、initrdイメージとしてinitrd.gzをロードするとの設定になっている。

ここで、ブート時にNAND Flashがどういう扱いになっているか調べてみると、ReadyNAS Pro(x86)でBIOSのブート時の画面が写っているものがあった(ReadyNAS Pro RNDP6350 Possible Flash Disk Boot Failure)。

ProのPCBにはVGAのピンが出ていて、こういう画面が出せたりするようだが、AMIBIOSがHDDを認識した後にこんな表示を出している。
Device #01 : SMI USB DISK *HiSpeed*
01 USB mass storage devices found and configured.

この「SMI USB DISK」に関して、Ultra 2のusb_devices.logに以下の記述があるのを見つけた。
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=090c ProdID=1000 Rev=11.00
S:  Manufacturer=SMI Corporation
S:  Product=USB DISK
S:  SerialNumber=AA04012700015822
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us

この「Vender=090c」で検索してみると、SMIは「Silicon Motion Inc.」を指すらしい。したがって、Proには(Ultra 2やUltra 4と同様に)Silicon MotionのNAND Flashコントローラがあり、これがブート時にBIOSでUSB接続の、たぶんブートデバイスとして認識されているのだと思う。

ということは、同じx86のUltra 2でもオンボードのNAND FlashがBIOSでブートデバイスとして認識されているのではないか、ということになる。ただ、それを直接確かめることはできないので(カーネルが起動する前のことなのでログにも残らない)、NAND Flashの中身を見られないか。

Ultra 2のdmesg.logには以下の記述があるので、NAND Flashはsdcとなっているらしい。が、色々試しても自分ではこれをマウントできず、中身は分からなかった。
scsi 4:0:0:0: Direct-Access     SMI      USB DISK         1100 PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: Attached scsi generic sg2 type 0
sd 4:0:0:0: [sdc] 244736 512-byte logical blocks: (125 MB/119 MiB)
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 43 00 00 00
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] Attached SCSI removable disk

ともあれ、諸々を考え合わせると、以下のような推測を立てられる。
  1. ブート時にはBIOSがいわばオンボードのUSBメモリであるNAND Flashをブートデバイスとし、
  2. NAND Flashから(syslinuxか何かのブートローダーを介して)Linuxのカーネル(kernel、initrd.gz)がロードされて起動し、
  3. 後はカーネルがHDD内のOSのパーティションからカーネル以外(ユーザーランド)をロードして起動する。
と、ここまで来たところで、そういうことはNetgearの人も書いている(断片的だが)のを見つけた。まずNVX(x86)についてこう書いている。
(Re: PAE (Physical Address Extention) for NVX Models)
It has some custom modules for handling the special hardware, and the kernel itself is not stored on disk, but in the firmware flash, so doing an apt-get won't do much.

また、全てのx86について、
(Re: Ultra 6 with 4.2.15 - GPT support?)
The Ultra (all x86) boot using BIOS to Internal Flash ROM. It mounts / (root) from the disks, but the boot process is in the flash.

Duo(Sparc)については、
(Re: Duo stuck in boot up flashing blue light)
The drives aren't needed for it to boot in telnet mode, it loads that boot image from the internal flash.

また別の人はNV+(Sparc)についてこう書いている。
(Re: T21: Trouble (re)booting after first application of update)
It does do the initial booting off the flash, so I suppose it's possible there are some bad blocks on the flash.

ということで、初期のブート(=カーネルのロード)はオンボードのNAND Flashから行われることが確定。

なお、Netgearの人はブートプロセスに関してこうも書いている。
(Re: VirtualBox version of x86 RAIDiator?)
Not possible at this time. It would take much changing on the boot code. Much of it is tied to hardware addresses (firmware location etc), so it would never find the boot flash.

これを見ると、NAND Flashには普通のファイルシステムはなく、ハードウェアのアドレスを直接叩くやり方になっているのかもしれない。

ちなみに、このカーネルはRAIDiatorをアップデートするとバージョンが変わるので、一緒にアップデートされる模様。USBメモリからアップデートした場合でもUSBメモリ中のkernelとは違うので、単純なコピーではない。
  • 4.2.13: 2.6.33.6.RNx86_64.2.1 #1 SMP Tue Jul 27 13:21:19 PDT 2010
  • 4.2.14: 2.6.33.7.RNx86_64.2.2 #1 SMP Wed Sep 29 17:22:45 PDT 2010
  • 4.2.15: 2.6.33.7.RNx86_64.2.2 #1 SMP Fri Oct 15 13:20:46 PDT 2010

シリアルポート

Duoの後面には診断用のシリアルポートが付いている(ReadyNAS DUO Reset Switch Location Image)。同じものはUltra 2の後面にもある。4pinのもので、ピンアサインも分かっているようなので(Running own code on the Infrant ReadyNAS)、もし興味があれば。

4.4. ReadyNASのHDDをPCで直接見る可能性

DuoとUltra 2は2台のHDDによるミラーリングなので、原理的には、どちらか1台を普通のPCに繋げばユーザーデータを見ることはできる。

ただし、DuoはハードウェアRAID(たぶん)のせいか、パーティションは普通のLinuxのPCと変わらないが、ユーザーデータはLVMで管理されていて、かつブロックサイズがx86のLinuxでは標準でサポートされてない16KBなので、これを読むのに四苦八苦してたりする(ReadyNAS Data Recovery - VMware recovery toolなど)。なお、暗号化はされてない。

以下はDuo(HDDは5K500.Bの120GB)のユーザーデータのある/dev/c/cを「dumpe2fs -h」したもの。
dumpe2fs 1.40.11 (17-June-2008)
Filesystem volume name:   c
Last mounted on:          <not available>
Filesystem UUID:          8adbb446-8d4d-4ec1-a6e1-2223841c5417
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              3590400
Block count:              7180288
Reserved block count:     0
Free blocks:              7089875
Free inodes:              3590376
First block:              0
Block size:               16384
Fragment size:            16384
Reserved GDT blocks:      128
Blocks per group:         65528
Fragments per group:      65528
Inodes per group:         32640
Inode blocks per group:   510
Filesystem created:       Wed Feb 16 19:24:25 2011
Last mount time:          Wed Feb 16 19:39:31 2011
Last write time:          Wed Feb 16 19:39:31 2011
Mount count:              4
Maximum mount count:      -1
Last checked:             Wed Feb 16 19:24:25 2011
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      552799a4-355e-4415-9b7c-2c78b4f7772b
Journal backup:           inode blocks
Journal size:             512M

また、Ultra 2の方はソフトウェアRAIDなので、そもそもパーティションが違う。ただ、ブロックサイズは4KB。

以下はUltra 2(HDDは5K500.Bの120GB)のユーザーデータのある/dev/c/cを「dumpe2fs -h」したもの。
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /c
Filesystem UUID:          01ce2742-6b27-49ea-b11a-ec7e7290767b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1675264
Block count:              26804224
Reserved block count:     0
Free blocks:              26649527
Free inodes:              1675241
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              16
RAID stripe width:        16
Flex block group size:    16
Filesystem created:       Wed Feb 16 18:12:28 2011
Last mount time:          Wed Feb 16 18:30:05 2011
Last write time:          Wed Feb 16 18:30:05 2011
Mount count:              5
Maximum mount count:      -1
Last checked:             Wed Feb 16 18:12:28 2011
Check interval:           0 (<none>)
Lifetime writes:          543 MB
Reserved blocks uid:      0 (user unknown)
Reserved blocks gid:      0 (group unknown)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      fe87f508-0a80-4ad7-a643-23ffa57bc308
Journal backup:           inode blocks
Journal features:         (none)
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0000001e
Journal start:            1

ここまで見て、これは普段からmdadmやlvmに慣れ親しんだLinux使いの人でもなければ太刀打ちできないと思う。いざとなればLinuxをインストールしたPCに繋げれば読めるだろう、というのは甘ーい幻想。お任せのアプライアンスなNASのために、それだけの苦労をするのも本末転倒なので、バックアップなど運用上の注意で何とかするのが結果的には楽だと思う。

なお、ReadyNAS本体が故障してHDDが生き残った場合、そのHDDを読む方法は、Netgearの公式では、同じ機種のReadyNASを入手してきて同じ順番で差せばそのまま稼働する、というもの。絶対どうしても、という場合はこれが確実かつ安全策ではある。

いずれにせよ、本体がハードウェア的に壊れた様子はないが、起動しなくなったり、OSがおかしくなったりした場合には、まずはOS Reinstallを試してみるのが基本。

2 コメント :

匿名 さんのコメント...

こんばんは、YDです。

NAS導入前の情報収集で記事が少なく、購入を躊躇していた時
googleから「ReadyNASを見る」の記事を見つけました。
以来ちょくちょく見に来てます。
大変参考になり、安心してRNDU2000を購入しました。

貴重な情報発信、ありがとうございます。

以上

EMO さんのコメント...

YDさん

参考になったようで何よりです。

Ultra 2はハードウェアとしては筋がいいのではないかと思うので、後はRAIDiatorの熟成ですね。4.2.16が出たばかりなので、もしブログとかお持ちでしたらレポートいただけるとありがたいです。