前回はGrub2からboot1.efiをloadしてFreeBSDを起動する方法を書きましたが、今回はGrub2からloader.efiを「load」してFreeBSDを起動する方法を書いておきます。
尚、これは「kFreeBSDコマンドを用いてloaderを起動する」のとは異なります。UEFI環境ではloader.efiもまたefiコマンドであることを利用し、「Chainloaderコマンドでloader.efiをロードしてFreeBSDを起動する」方法で、BIOS環境では利用できない方法です。
今の所Grub2のkFreeBSDコマンドはheadless bootしか出来ず、多数の環境変数を自分で設定する必要があるのですが、Chainloader経由でloader.efiを起動した場合、通常と同様にコンソール画面が利用できるという利点があります。また、下記に例を示しますが、起動するGPTパーティションを設定で明記する必要がある為、複数パーティションに異なるバージョンのFreeBSDがインストールされている場合、Grub2上のmenuで起動パーティションを切り替えることができます。
例えば、gpt5のFREEBSD_UFSパーティションから起動する場合は、Grub2側に以下のように設定ファイルを記述します。
#2016/12/29 丸山さんの指摘を受けてzfsのパスの記述を修正。
尚、残念ながらUbuntu 14.04LTSのGrub2-efiはFreeBSD 11.0Rのzfsパーティションを認識してくれません。
zfsパーティションから起動するにはFreeBSD 11.0Rのports(or pkg)のgrub2-efiを使用する必要があります。
FreeBSDのGrub2にはUbuntuのupdate-grubのように設定ファイルをEFIパーティションにコピーする便利なコマンドがありませんので、手動でEFIパーティションをmountして設定する必要がありますが、詳細は省略します。
実はFreeBSDのportsのgrub2を使えばzfsパーティションを認識してくれるのを知ったのは最近で(^^;、それまではzfsを認識できない以上、この方法は実用性がないとずっと思ってました。
なので、私のboot1パッチに対するmaintainerのコメントがようやく腑に落ちて、パッチが採用されないことに納得が出来た次第です。
#やっと書く時間がとれた。
P.S.
EFIパーティション上のgrub.cfgに以下の例のような記述をすれば、FreeBSD側のgrub.cfgを読み込ませることも可能です。
尚、これは「kFreeBSDコマンドを用いてloaderを起動する」のとは異なります。UEFI環境ではloader.efiもまたefiコマンドであることを利用し、「Chainloaderコマンドでloader.efiをロードしてFreeBSDを起動する」方法で、BIOS環境では利用できない方法です。
今の所Grub2のkFreeBSDコマンドはheadless bootしか出来ず、多数の環境変数を自分で設定する必要があるのですが、Chainloader経由でloader.efiを起動した場合、通常と同様にコンソール画面が利用できるという利点があります。また、下記に例を示しますが、起動するGPTパーティションを設定で明記する必要がある為、複数パーティションに異なるバージョンのFreeBSDがインストールされている場合、Grub2上のmenuで起動パーティションを切り替えることができます。
例えば、gpt5のFREEBSD_UFSパーティションから起動する場合は、Grub2側に以下のように設定ファイルを記述します。
#!/bin/sh menuentry "Chainload FreeBSD 11 loader" -- class freebsd { insmod ufs2 insmod chain set root='(hd0,gpt5)' chainloader /boot/loader.efi }また、gpt10のFREEBSD_ZFSパーティションから起動する場合は以下の設定となります。
#2016/12/29 丸山さんの指摘を受けてzfsのパスの記述を修正。
#!/bin/sh menuentry "Chainload FreeBSD 11.0 loader" -- class freebsd { insmod zfs insmod zfsinfo insmod chain set root='(hd0,gpt10)' zfsinfo (hd0,gpt10) chainloader /@/boot/loader.efi }zfsの場合、chainloaderの引数は「/"ルートファイルシステムのマウントポイント"@"loader.efiのパス"」という記述となります。
尚、残念ながらUbuntu 14.04LTSのGrub2-efiはFreeBSD 11.0Rのzfsパーティションを認識してくれません。
zfsパーティションから起動するにはFreeBSD 11.0Rのports(or pkg)のgrub2-efiを使用する必要があります。
FreeBSDのGrub2にはUbuntuのupdate-grubのように設定ファイルをEFIパーティションにコピーする便利なコマンドがありませんので、手動でEFIパーティションをmountして設定する必要がありますが、詳細は省略します。
実はFreeBSDのportsのgrub2を使えばzfsパーティションを認識してくれるのを知ったのは最近で(^^;、それまではzfsを認識できない以上、この方法は実用性がないとずっと思ってました。
なので、私のboot1パッチに対するmaintainerのコメントがようやく腑に落ちて、パッチが採用されないことに納得が出来た次第です。
#やっと書く時間がとれた。
P.S.
EFIパーティション上のgrub.cfgに以下の例のような記述をすれば、FreeBSD側のgrub.cfgを読み込ませることも可能です。
search.fs_uuid 1ee4b7eb1b9d940c root hd0,gpt10 hd0,gpt10 set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg
> chainloader /zroot@/boot/loader.efi
>
>zfsの場合、chainloaderの引数は「/"zfsプール名"@"loader.efiのパス"」という記述となります。
の部分はちょっと違うように思います。私の環境では
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank103 11.4G 32.0G 19K none
tank103/ROOT 10.8G 32.0G 19K none
tank103/ROOT/10.3R-Latest 10.6G 32.0G 10.2G /
tank103/ROOT/10.3R-initial 6.67M 32.0G 6.02G /mnt
tank103/ROOT/10.3R-p6 30.3M 32.0G 9.91G /
tank103/ROOT/10.3R-pkg 235M 32.0G 10.1G /
(以下略)
# beadm list
BE Active Mountpoint Space Created Nickname
10.3R-initial - - 70.1M 2016-12-03 11:55 10.3R-initial
10.3R-pkg - - 235.6M 2016-12-04 00:50 10.3R-pkg
10.3R-p6 - - 122.4M 2016-12-04 22:53 10.3R-p6
10.3R-Latest NR / 10.6G 2016-12-04 23:26 10.3R-Latest
のようになっていて、
chainloader /tank103@/boot/loader.efi
chainloader /tank103/ROOT/10.3R-latest@/boot/loader.efi
chainloader tank103/ROOT/10.3R-latest@/boot/loader.efi
chainloader /tank103/10.3R-latest@/boot/loader.efi
はいずれも成功しません。
chainloader /ROOT/10.3R-latest@/boot/loader.efi
は成功します。GNU GRUB version 2.02-beta2です。
なお、 man zfs や man zpool を読むと、zfsのpool nameとfile system
name は厳格に区別して使っているようで、私の例で言うと
"tank103" は pool name、頭にスラッシュが無い "tank103/ROOT/10.3R-Latest"
は file system name で、ここから先頭の pool name を取り去った
"/ROOT/10.3R-Latest" には名前が定められていないように思います。