web-dev-qa-db-ja.com

Arch ubuntuマルチブートの修正

ラップトップにUbuntu 16.04がプリインストールされています。 Windows 10とArchをインストールしました。 Archにgrubをインストールしたとき、奇妙なことに気づきました。os-proberでubuntuパーティションが見つかりませんでした。次に、デフォルトでUbuntuがインストールされているパーティション（/dev/sda3）を開き、別のbootフォルダーを保持していることを確認しました。私の実際のESP（/dev/sda1）は、/boot/efiの/dev/sda3（ubuntuパーティション）にマウントされます。さらに、Ubuntuはefi/ubuntu/shimx64.efi（ESP）の/dev/sda1にある独自のefi実行可能ファイルを使用して直接起動されます。 Ubuntuは/bootの/dev/sda3に独自のカーネルを保持していますが、Archはそのカーネルを/dev/sda1に直接インストールしました。それでは、この混乱を解消し、efi/grub of /dev/sda1内に単一のgrubスタブを作成し、別々のカーネルを使用してUbuntuとArchの両方のインストールを管理する方法を教えてください。

boot16.04dual-bootgrub2uefi
1
Subhranil

まず、いくつかの用語を明確にしたいと思います。LinuxのEFIブートローダーのコンテキストでは、「EFIスタブ」はLinuxカーネル自体に組み込まれているブートローダーを指し、カーネルをEFIプログラムとして起動できるようにします。この用語を使用して任意のEFIブートプログラムを参照しているようですが、その使用は混乱を招く可能性があります。

対処しました、Arch上のos-proberはUbuntuのインストールを検出するはずです。なぜそうしなかったのかはわかりませんが、Archのos-proberはUbuntuではなくArchの一部なので、Archフォーラムで質問したいかもしれません。 OTOH、私のアドバイスに従えば、ArchのGRUBを使用しないので、この点は議論の余地があります。

Archのカーネルには、カーネルを更新しても変更されない固定名が付けられますが、Ubuntuのカーネル名にはバージョン文字列が含まれているため、新しいカーネルがインストールされると変更されます。カーネルを参照するGRUB構成ファイルはGRUBを制御するOSによって作成されるため、これは重要です。したがって、ArchのGRUBを使用する場合は、Ubuntuカーネルを更新するたびにArchでGRUBを再構成する必要があります。これは厄介である可能性があります。 UbuntuのGRUBであるOTOHを使用している場合、Archカーネルを更新するときにその構成を更新する必要はありません。 （新しいUbuntuカーネルをインストールすると、UbuntuのスクリプトによってUbuntuのGRUBが自動的に更新されます。）したがって、2つの方法のうち、ArchのGRUBではなくUbuntuのGRUBを使用することをお勧めします。

いずれかのディストリビューションでefibootmgrを使用して、UbuntuのGRUBに切り替えることができます。

  1. Sudo efibootmgrと入力して、エントリのリストを表示します。 ArchとUbuntuのBootOrder行とBoot####エントリに注意してください。 BootOrder行は、コンピューターが特定のブートエントリを起動しようとする順序を示します。 OSを考えると、ArchのGRUBがBootOrderリストの最初になる可能性があります。
  2. UbuntuのBoot####番号を特定したら、-oのようにefibootmgrにSudo efibootmgr -o 0004,0002,000Aオプションを使用して、ファームウェアに新しいブート順序を渡すことができます。これにより、最初にBoot0004が使用され、それが失敗した場合はBoot0002が使用され、最後の2つが失敗した場合は最後にBoot000Aが使用されるように設定されます。もちろん、詳細はあなたによって異なります。 Ubuntuのエントリが最初であることを確認する必要があります。システムがsomething Ubuntuエントリが失敗した場合。

再起動すると、UbuntuのGRUBが表示されますが、Archのエントリがある場合とない場合があります。 Sudo update-grubを実行して、新しいUbuntu GRUBメニューを生成し、再試行できます。これにより、Archのカーネルが検出される場合と検出されない場合があります。そうでない場合は、/etc/grub.d/40_customを編集するか、 GRUB Customizer を使用してArchのエントリを追加します。次のようなものが機能するはずです。

menuentry "Arch Linux" {
    set root=(hd0,1)
    linux /vmlinuz-linux root=/dev/sda5 ro quiet splash
    initrd /initramfs-linux.img
}

これは単なる例であり、改善される可能性があります。他に何もなければ、おそらくroot=/dev/sda5オプションを変更してArchの真のルート（/）パーティションを指す必要があります。 ArchのGRUB設定を調べたり、この例を改善したい場合や問題がある場合は、Archフォーラムで助けを求めることができます。

上記の代替として、GRUB以外のものを使用できます。ほとんどのブートローダーは、GRUBよりも手動構成の方が多く必要ですが、その手動構成はGRUBの手動構成よりも簡単です。利用可能なものの概要については、 Linux用EFIブートローダーのマイページ を参照してください。私自身の rEFIndブートマネージャー は、ブートするたびにカーネルをアクティブにスキャンするため、マルチブートシナリオの構成が簡単になる傾向があり、構成ファイルを更新し続ける必要がありませんカーネルの更新ごと。 OTOH、Archのカーネル名は変わらないため、UbuntuのGRUBを使用する場合、通常のマルチディストリビューションGRUBの問題に悩まされることはないので、rEFIndはこのスコアの改善にはなりません。

最後のポイント：構成により、ArchカーネルはEFIシステムパーティション（ESP）に保存されます。これは一般的なArch構成ですが、ESPが十分に大きいことを確認する必要があります。時々ESPは100 MBほど小さい（またはおそらくさらに小さい）場合があり、カーネルを配置すると余分なスペースがほとんど残らない場合があります。 df /boot/efiのように、dfを使用して、パーティションで使用され、使用可能なスペースの量を確認できます。 ESPがほぼ満杯の場合、Archカーネルを別の場所に配置することができます。 ArchではESPを使用してカーネルを保存するのが一般的ですが、必須ではないため、他のことを行うことができます。

4
Rod Smith