Twitterでの[[このtweet>https://twitter.com/ao_kenji/status/1073836123934183424]]がきっかけ。このやりとりが発端となり、[[河豚板のUEFI対応>https://twitter.com/yoshi_kaw/status/1074110733577637888]]を開始する。BIOS)による起動方法からの置換えを意図している。・UEFI用のパーティション(ファイルシステムとしてはFAT)を持つ。・そのパーティション内に起動用の実行バイナリが格納されている。このバイナリファイルは*.EFIの拡張子を持ち、UEFIアプリケーションと呼ばれる。Record)に替わるものとしてUEFIの一部として定義されている。OpenBSDの場合に現状で考えられる起動方法とパーティショニングのパターンを以下に示す。-ハードウェア上のファームウェアがHDDのセクタ0にあるMBRブートコードを実行する。Record)に実行を移す。--OpenBSDでは、PBRは/usr/mdec/biosbootが用いられる。-PBRはOpenBSDのルートファイルシステム上にある/bootを実行する。--この/bootが「boot>」プロンプトを表示し、カーネル起動に関するユーザからの指定を受け付ける。-bootは指定にしたがって、該当するカーネルを起動する。Area)として設定される。Areaの中にdisklabelによるBSDパーティションが作成され、ファイルシステムやスワップ領域として使われる(参考:[[他のBSDユーザのためのOpenBSD管理入門>http://fuguita.org/index.php?EBUG%CA%D9%B6%AF%B2%F1%2F20171118_OpenBSD%B4%C9%CD%FD%C6%FE%CC%E7#lde54a06]])。\efi\BOOT\BOOT*.EFIという実行ファイル(EFIアプリケーション)があれば実行する。-OpenBSDのEFIアプリケーションは、「boot>」プロンプトを表示し、カーネル起動に関するユーザからの指定を受け付ける。これは、MBR起動の場合の/bootに相当する。-EFIアプリケーションは指定にしたがって、該当するカーネルを起動する。(保護MBR)というものが書き込まれている。これはfdiskなどのMBRを扱うユティリティが誤ってMBRを書き換えないようにするためのものである。Area内の管理については、MBRの場合と同じ。UEFIとしてEFIアプリケーションがロードされるが、パーテショニングとしてMBRが使われるパターン。amd64のインストールメディアやarm64で使われている。amd64のインストールメディアとarm64とでは細かい箇所で異なっている部分がある(右図はarm64)。-arm64ではUEFI用のパーティション内にはU-BOOTも書き込まれている。BIOS・UEFIのどちらでも起動する。UEFI共にセットアップしたもの。BIOS・UEFIのどちらでも起動することが期待できる。規格上は定義されていない方法。-現状ではMBRとGPTとを同時に変更するツールがないため、作成後にパーテショニングを変更することが困難。2015年に安岡昌彦氏によりカーネルにUEFI対応の機能が[[実装された>https://marc.info/?l=openbsd-cvs&m=144115942223734&w=2]]。現在では、インストーラ含め、関連ユティリティがUEFI/GPTに対応している。BIOS、UEFIのいずれからでも起動可。BIOS、UEFIのどちらで起動したかによって、パーティショニングのデフォルトも変わる。パーティションのメンテナンスツール[[fdisk(8)>https://man.openbsd.org/fdisk]]は、パーティションの初期化時にオプションによってMBRかGPTかを指定する。OpenBSDでは、ブートローダの書込みに[[installboot(8)>https://man.openbsd.org/installboot]]を使用する。-ISO版は変更しない。-img版は、以下のように対応する。BIOS/MBRにする(UEFIアプリケーションが供給されていないため)。BIOS/UEFIのいずれでも使用できるようにする。--arm64版は、UEFI/MBRにする(オリジナルのOpenBSD/arm64と同じ)。読み出しは次回起動時に「起動モード3」を指定する。MBRを用い、かつパーティションを全て作成する場合、右図のようになる。「プラットフォーム毎の対応表」を見るとわかるように、ブート方法、及びパーティションテーブルの選択肢はプラットフォーム毎に変わってくる。BIOSを選択できてもOSが対応していないため、意味がない。ユーザが「データ保存のみ」を選択した場合はブートローダが不要となる。以上より選択の組合せは以下のようになる。この複雑さを緩和するため、今回の改修では/usr/fugutia/etc/usbfadm.confというファイルを新設した。記述することで、UEFI起動を選択肢からはずせるようにした。arm64の場合は以下の理由から、さらなる処理が必要となる。Sysのパーティションタイプを変更する必要がある。-OpenBSD/arm64はHDMI出力が実装されておらずシリアルコンソールとなるため、OpenBSD/arm64をインストールする際はピンヘッダにUSBシリアルなどを用意し、シリアル端末を接続する必要がある。--FuguIta/arm64では、インストール作業の敷居を下げるため、配布物をメディアに書き込んで起動した段階でSSHによるリモートアクセスが可能となっており、シリアルI/Fを用意せずとも使用できるようになっている。--そのため、FuguIta/arm64は他のプラットフォーム用と異なり、SSHアクセスを可能にするための各種設定や、その設定を用いて自動的に起動する設定がdパーティションに書き込まれている。arm64のusbfadmでnewdriveを実行してリマスタリングを行う場合、これらdパーティションに書き込まれている内容もセットアップする必要がある。--よって、新しいusbfadmでは、newdriveコマンドの実行の最後の部分に/usr/fuguita/etc/usbfadm_postproc.shというシェルスクリプトを実行するようにした。FuguIta/arm64では、[[usbfadm_postproc.sh>https://github.com/ykaw/FuguIta/blob/master/lib/usbfadm_postproc.sh.arm64]]に上で説明したようなプラットフォーム固有の処理が書き込まれている。MBRとする機能は持っていない。開発の初期段階では、プロセッサエミュレータ[[QEMU>https://www.qemu.org/]]を用いて開発を行った。-最初は、手動でfdiskなどを動かして挙動を調査したり、動作の安定していないスクリプトを動かしたりするため、実ディスクに誤ったパーテション情報を書き込んでしまうおそれがあるため。BIOSとUEFIを頻繁に切り替えて作業をするため、実ハードウェアの作業では手間と時間が掛かるため。(SMBIOS)として動作する。Firmware)>https://github.com/tianocore/tianocore.github.io/wiki/OVMF]]を指定する。パーティション操作を行う対象となるディスクイメージファイルはrawイメージとした。これにより、[[vnconfig(8)>https://man.openbsd.org/vnconfig]]を用いて[[vnodeデバイス>https://man.openbsd.org/vnd]]のディスクとして実環境でも扱えるようになった。usbfadmが一通り動作するようになってからはプラットフォーム依存部分を開発・動作確認したり、河豚板のリリースに組込む必要があるため、実ハードウェアにて開発を行った。-河豚板のソースコードはfuguita.org上のCVSリポジトリで管理されている。copyをNFSマウントし、ソースコードを共有する。→開発者は一人だけなので、同じファイルを同時に編集することはない。-すべてのプラットフォームでの作業が終了したら、fuguita.org上でcommitを行い、CVSリポジトリを更新する。