ReadyNASを普通に使っている限りは全く気にする必要はないが、何か問題が起きたりしたときに、そもそもReadyNASの中はどうなってるのかということに興味が湧くのは自然だと思うので、その流れの話。
（このエントリは一続きのエントリの5/5）
4.1. ReadyNASの構成（推測）
ReadyNASが何かといえば、LinuxをOSとして稼働する/RAID構成で/NAS専用のPC、ということになる。アプライアンスのLinux機としては普通のPCに近いが、普通のPCと特に違うのは、
- オンボードにOSのインストールイメージを持っていること
- ブートプロセスが少し変わっていること
ただ、Netgearの人はこういう話をあまり正面から書いてくれてない。あくまでアプライアンスであってユーザーの心配することではないし、SSHでログインすれば分かる人には分かるだろう、と説明の必要を感じてないのかもしれない。したがって、自分の推測がかなり入っているし、自分はLinuxに特に詳しいわけでも何でもないので、その前提で。
本当にトラブルに陥って回復作業をしなければいけないときは、素直にNetgearのサポートに頼った方がいい。
先に用語について。ReadyNASでは、そのファームウェア＝専用にカスタマイズされたLinux＝OSのことをRAID
iatorと呼んでいる。よく似た名前でRAID
arもあるが、こちらはクライアント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から
インストール |
| スワップ | 256MB | 512MiB | | |
ユーザー
データ | 残り | 残り | | |
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）の場合の方法。
- 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ファイルをコピーすれば、実行時にそれを選ぶことができる。
- このUSBメモリを前面のUSB3.0ポートに挿し、backupボタンを押した状態で電源ボタンを押して離す。電源が入って自動的にUSBメモリにアクセスが行われ、2分ぐらいで自動的に電源が落ちる（ここまでbackupボタンは押したまま）。
- 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を開始する方法。
- 後面のResetスイッチをピンで押した状態で電源ボタンを押して離す（Resetスイッチは押したまま）。Act以外のLEDが全部点灯したらResetスイッチを離す。
- これで管理用のブートメニューに入ったので、backupボタンを3回押し、HDD2のLEDだけが点灯した状態（OS Reinstallが選択された状態）にする。ここで後面のResetスイッチを押すと、選択が確定され、OS Reinstallが開始される。
ちなみに、このブートメニューとLEDの関係は以下のようなもの（
Readynas Ultra 2 how to resets etc...）。
| 電源 | HDD 1 | HDD 2 | backup
(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を開始する方法。
- 後面のResetスイッチをピンで押した状態で電源ボタンを押して離す（Resetスイッチは押したまま）。Act以外のLEDが全部点灯したらResetスイッチを離す。
- これで管理用のブートメニューに入ったので、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
ともあれ、諸々を考え合わせると、以下のような推測を立てられる。
- ブート時にはBIOSがいわばオンボードのUSBメモリであるNAND Flashをブートデバイスとし、
- NAND Flashから（syslinuxか何かのブートローダーを介して）Linuxのカーネル（kernel、initrd.gz）がロードされて起動し、
- 後はカーネルが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を試してみるのが基本。
