Rarpberry Pi 2 向け 32bit FreeBSD/arm 13.2 って、USB HDD にOSを入れて、HDDから起動できるはずなのですが、なぜか SATA HDDを入れた外付けHDDから起動させようとすると、fstab に記述されているファイルシステムをマウントする前に以下のような画面になり、最終的に mountroot プロンプトに落ちてしまいます。OSが起動しない!
ファイルシステムをマウントする段階で、
Root mount waiting: CAM
Root mount waiting: CAM
Root mount waiting: CAM
Root mount waiting: CAM
が何行も続いた後、
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
Root mount waiting for: CAM
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
Root mount waiting for: CAM
と出てきたあと、mountroot> プロンプトが出てきて終わり。
mountroot> でコマンドモードになるものの、キーボード入力は受け付けず。なので手動入力でファイルシステムを指定することは出来ず。
「(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00」が出てくるので、HDDハードウェア故障と考え USB HDDボックスに入れていたHDDを別のSATA HDDと交換。
しかし、HDDを交換しても症状は変わらず。
PC上に置いていたOSイメージファイルが壊れた?USBケーブルやHDDボックスハードウェアの問題?
freebsd.org の ftp サイトから、「FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img.xz」をもう一度ダウンロードし直し、USB HDDに焼き直しました。そして、再トライ。「Root mount waiting: CAM」表示回数は異なるものの、結局 mountroot シェルに落ちて終わり。
では、なぜ、昨年まで私の FreeBSD/arm 13.2 は USB HDD から起動し、動作していたのか?
答えは、USB HDDケースが PATAタイプだったためのようです。ケースとHDDのインタフェースの違いにより、このようなケースになるとは思いもよらなかった。
RPI2 32bit FreeBSD のファイルシステムとして外付けHDDを選んだ時、そのHDDがSATAかATAで違いがあるとは考えなかった。手近にあったものを選択しただけ。それで問題なく動作していたのでPATAからSATAに替えてOSが起動しなくなるなんて思いもよらなかった。SATA→USB チップのせいかな~?
理由は不明ながら、PATAを積んだ外付けHDDなら Root mount waiting: CAM にならないという事がわかったので、故障したHDD を取り外し、別のATA HDDを接続し、armv7-generic sd イメージを書き込んでRPI2に接続したところ、確かに「Root mount waiting: CAM」は出なくなった。
しかし、今度は以下の通り。
ums0 on uhub1 ums0: on usbus1 ums0: 5 buttons and [XYZT] coordinates ID=26 ums0: 0 buttons and [T] coordinates ID=0 uhid0 on uhub1 uhid0: on usbus1 mountroot: waiting for device /dev/ufs/rootfs... Mounting from ufs:/dev/ufs/rootfs failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/ufs/rootfs vfs.root.mountfrom.options=rw Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ugen1.5: at usbus1 umass0 on uhub1 umass0: on usbus1 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI device da0: 40.000MB/s transfers da0: 19623MB (40188960 512 byte sectors) da0: quirks=0x2
HDD上のrootファイルシステム認識が、ファイルシステムマウントコマンド に間に合わない。
ファイルシステムをルートにマウントしようとして、ファイルシステムが見つからないので結局 mountroot に落ちる。落ちてしまった後に、ファイルシステムが認識されるから、OSが起動しない。
ただし、この時はコマンドプロンプトがキーボード入力を受け付けるので、手動で「ufs:/dev/ufs/rootfs」とファイルシステムをタイプすれば、OSは起動する。
HDDが壊れるまで動いていたのは、HDD初期化時間性能の違いっぽい。
壊れたHDDは、Western Digital 製。初期化が遅いHDDは、IBM/Hitachi製。
Western Digital 製HDDは寿命が短いので重要データ保存には向かないとわかってはいたのですが、初期化の性能(?)は良いみたい。毎回、再起動の度に、キーボードをつないで、ファイルシステムのパスを入力するわけにはゆかないので、またWD製HDDを使うか、その他の手持ちPATA HDDをひとつづつ試すか、はたまた SATA HDDボックスを別のものに交換してみるか。
WordPressデータベースをHTTPサーバーから分離したいということで RPI2 + USB HDDの構成としましたけど、これほど扱いづらいとは予想もしていなかった。
追記:
外付けUSB HDDから起動させるとき、ファイルシステムを認識するまでの時間が足りない 問題を解決する方法が見つかりました。
/boot/loader.conf の中に、
kern.cam.boot_delay=”10000″
と書き込んで、遅延を追加すればいいとのこと。
試してみたところ、「Root mount waiting for: CAM」行が複数挿入され、
ums0 on uhub1 ums0: on usbus1 ums0: 5 buttons and [XYZT] coordinates ID=26 ums0: 0 buttons and [T] coordinates ID=0 uhid0 on uhub1 uhid0: on usbus1 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM ugen1.5: at usbus1 umass0 on uhub1 umass0: on usbus1 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI device da0: 40.000MB/s transfers da0: 19623MB (40188960 512 byte sectors) da0: quirks=0x2
となり、自動起動に成功。