web-dev-qa-db-ja.com

外付けドライブにUbuntu Linuxをインストールした後、外付けドライブがないと内蔵ドライブで再起動できません

Macbook proでEFIブートを使用しています。 （マシンが古すぎるため、UEFIを使用できません。）

内蔵ドライブには、Ubuntu Linux 20.04があります。

ライブUSBから外部ドライブにUbuntu Linux 20.04をインストールするという残念なアイデアがありました。 （私は増分バックアップを使ってクローンを作成しようとしていますが、これは既存のソフトウェアがLinuxにはできないようです。）

外付けドライブを接続して起動すると、GNU GRUB 2.04ブートメニューが表示されます。デフォルトでは、外付けドライブが最初に起動しますが、起動するかどうかを選択できます内蔵ドライブ。

外付けドライブが接続されていない場合、GRUBシェルに陥り、起動できません。 非起動をレスキューする方法GRUB = Linuxでは2 しかし、常に「カーネルパニックが終了しました...ルートファイルをマウントできません...」という結果に終わりました.

とにかく、GRUB Shell、なしで起動できる限り、Ubuntu Linuxを正常に起動するには内部ドライブを復元する必要があります。

これは非常にシンプルに見えます。

内蔵ドライブで起動して外付けドライブを取り外した後、Sudo update-grubを試しましたが、役に立ちません。

Sudo efibootmgrを使用して起動順序を変更しようとしましたが、常にGRUB Shell）になるため、さらに悪化します（幸い、変更は元に戻せます）。

可能であれば、最終的にはGRUBを削除したいと思います。 MacはGRUBを必要としません。これは、Altキーを押して起動すると、すべての起動可能なパーティションがシンプルなグラフィカルメニューに表示されるため、EFIパーティションを選択して起動するのが非常に簡単になるためです。その上にGRUBなしで。

最初の回答の後に編集（ありがとう）

「何らかの原因でGRUBが書き換えられました。）はい、これはライブのUbuntu Linuxインストーラーであり、実際には危険です。もっと慎重にすべきだったのは、内部ドライブのマウントを解除することです。外付けドライブにUbuntuLinuxをインストールする前に、実際、内線ドライブの/ boot/efiに何か変更があったことがわかりました。 MacOSXの起動後にUbuntuEFIの起動に失敗する =。

再起動後、外付けドライブを接続した状態で、新しい状況を発見しました。GRUBメニューがないため、GRUBシェルを使用せざるを得ませんでしたが、幸いなことにできました。 ls（以前は外付けドライブのみではなく）内部ドライブとこのチュートリアルを適用する 非起動をレスキューする方法GRUB 2 to内蔵ドライブで起動します。

そのため、起動を自動的に実行し、可能であれば、外付けドライブで起動するオプションを維持する必要があります。

内部ドライブのgrub.cfg：

mac2011-linux# pwd      
/boot/efi/EFI
mac2011-linux# more ubuntu/grub.cfg
search.fs_uuid 770e447c-7411-4cc7-bce4-b71504d828c3 root hd2,gpt4 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

個別のブートファイルシステムがないため、プレフィックスは正しいです。 blkidで、uuid 770e447c-7411-4cc7-bce4-b71504d828c3が外付けドライブの/dev/sdb4であることがわかります。これは正しくありません。きれいに修正する方法は？

mac2011-linux# ls
Apple  BOOT  tools  ubuntu
mac2011-linux# mac2011-linux# ls -l BOOT
total 5367
-rwx------ 1 root root 1677176 mai 25 14:54 bootx64.efi
-rwx------ 1 root root 1334816 mai  8 21:48 BOOTX64.EFI-old
-rwx------ 1 root root 1213032 mai 24 23:04 fbx64.efi
-rwx------ 1 root root 1269496 mai 24 23:04 mmx64.efi
mac2011-linux# ls -l ubuntu
total 4183
-rwx------ 1 root root     108 mai 24 23:04 BOOTX64.CSV
-rwx------ 1 root root     126 mai 24 23:04 grub.cfg
-rwx------ 1 root root 1677176 mai 24 23:04 grubx64.efi
-rwx------ 1 root root 1269496 mai 24 23:04 mmx64.efi
-rwx------ 1 root root 1334816 mai 24 23:04 shimx64.efi

Ubuntuディレクトリが実際に読み取られるかどうかはわかりません。自分でインストールしたgrubx64.efiのコピーであり、GRUB対象の内部ドライブを作成しているため、bootx64.efiが読み取られることを知っています。

これでGRUBができました。少なくとも、Linuxに慣れるまではそれを保持しますが、混乱を避けるためにrEFIndを追加したくありません。

私はこれを見つけました GRUBのArchLinux記事 特にUEFIシステムのセクション。これにより、GRUBインストールを確認することができました。Sudo apt install grub2-common grub-efi-AMD64を実行し、Sudo update-grubを繰り返して、内部の正しいパーティションを指す新しい/boot/efi/EFI/ubuntu/grub.cfgを取得しました。ドライブ。これにより、内蔵ドライブでの再起動が正常に修正されます。

したがって、GRUBがシステムに正しくインストールされていなかったようです。これは、Ubuntu Linux 20.04ディストリビューションの小さな欠陥の可能性があります。

外付けドライブUbuntuLinuxも機能するかどうかを確認する必要があります。

ubuntugrubuefimacintosh
2
Pierre ALBARÈDE

何かが原因で内部ディスクのGRUBが書き換えられ、外部ディスクから構成をロードしようとしている可能性があります。

まず、外部ディスクに完全に入力されたEFIシステムパーティションがあること、および/etc/fstabが外部ディスクのESPを正しくマウントしていることを確認しますto /boot/efi。何かが足りない場合は、grub-install --force-extra-removable /dev/sd<external disk>を使用してGRUBを外部ディスクに再インストールします-ただし、first正しいESP = /boot/efiにマウントされます。

再起動してefibootmgr -vを使用します。 BootCurrent値と対応するブートエントリをチェックして、システムが実際にdid外部ディスクから完全に起動し、内部ディスクのブートローダーにフォールバックしなかったことを確認します。これで、内部ディスクから完全に独立しているはずの外部ディスク上に完全に機能するGRUBがあることがわかりました。

次に、ESPinternalディスクのパーティションをマウントし（まだマウントされていない場合）、<mountpoint of internal ESP>/EFI/ubuntu/grub.cfgの内容を確認します。小さなGRUB約3行の構成ファイルで、メインのロード場所を示しますGRUB構成ファイル。通常はUUIDでファイルシステムを参照します。次のようになります。

serch.fs_uuid <UUID of the filesystem containing /boot> root
set prefix=($root)'/grub'
configfile $prefix/grub.cfg

はい、最初の行でrootについて言及していますが、必ずしもLinuxルートファイルシステムを意味しているわけではありません。これは、GRUBのルートを指します。これは、メインのGRUB構成ファイルとGRUBのモジュールディレクトリを含むファイルシステムです。 。Debian/ Ubuntuでは、Linuxルートファイルシステムまたは別の/bootファイルシステム（/bootが別のファイルシステムの場合）の場合があります。

/bootディレクトリがLinuxルートファイルシステムに含まれている場合、2行目は代わりにset prefix=$(root)'/boot/grub'になる可能性があります。 prefix変数が正しく設定されると、GRUBは、そこからGRUBモジュール（他のファイルシステムタイプのサポートなど）を自動ロードできるようになります。

これは、内部ディスクで失敗したGRUBを修正するのに十分な場合があります。それでも問題が解決しない場合は、外部ディスクから起動し、内部ディスクのルートファイルシステムを/mntにマウントします。内部ディスクの/boot（別のファイルシステムとして存在する場合）から/mnt/boot、内部ディスクのESPから/mnt/boot/efiなど）、内部ディスクの完全なファイルシステムツリーがマウントされるまで/mnt。次にchrootしてください：

mount -o rbind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o rbind /sys /mnt/sys
chroot /mnt /bin/bash

これで、grub-install /dev/sd<internal disk>を使用して、内部ディスクにGRUBを再インストールできるようになります。その後、外部ディスクを抜いた状態でシステムを再度起動できるようになります。

GRUB=を取り除くことは技術的には可能ですが、ブートローダーをまったく使用しない（つまり、カーネルに組み込まれたUEFIスタブを使用する）と、カーネルブートオプションが非常に扱いにくくなります。最初に、UEFIブートエントリを編集できるものでブートし、必要なブートオプションを追加/変更してから、「ブートローダーレス」Linuxで再度ブートする必要があります。代わりに、rEFIndやsystemd-boot。

2
telcoM