最近USBからUbuntu 18.04をインストールしました。私がしたことはすべて14から16に、16から17にアップグレードしたときと同じで、これまで毎回動作します。 USBイメージで18を実行するとき、「Erase ubuntu 17 and install ubuntu 18」を選択しました。私の問題は次のとおりです。 Grub2がロードされますが、間違ったパーティションで誤った設定ファイルを使用しているようです。 Ubuntuを実行するには、ルートディレクトリを設定し、ルートディレクトリを含む正しい/dev/sda8ファイルとファイルを設定する必要がありますlinux（使用するファイルがある場所でもあります）。上記のファイルがBIOSパーティションを指していることがわかります。私の質問は、Ubuntu（場所）で更新された設定ファイルをgrubで使用するにはどうすればよいですか？これを変更すると、何かが深刻に壊れるか心配ですが、そうでない場合は、cfgファイルの内容を使用するだけで十分でしょうか？initrd/dev/sda8/bootgrub.cfggrub.cfgdev/sda1/EFI/ubuntu/grub.cfg/dev/sda5/dev/sda8/boot/dev/sda1sda8
fdisk -l参照用の端子出力は次のとおりです。
Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 468991 262144 128M Microsoft reserved
/dev/sda3 468992 816990982 816521991 389.4G Microsoft basic data
/dev/sda4 816992256 818726911 1734656 847M Windows recovery environment
/dev/sda5 818726912 818728959 2048 1M BIOS boot
/dev/sda6 935913472 939819007 3905536 1.9G Linux swap
/dev/sda7 942651392 976773119 34121728 16.3G Microsoft basic data
/dev/sda8 818728960 935913471 117184512 55.9G Linux filesystem
ファイルの/dev/sda1/EFI/ubuntu/grub.cfg内容は次のとおりです。(hd0,5)これはBIOSパーティションです。
search.fs_uuid 7e076866-97b4-4d3c-b864-491137212645 root hd0,gpt5
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
答え1
今後この問題を発見してご使用の方のためにクラウド初期化サーバー（たとえば、MAAS経由の専用サーバー、仮想化ソフトウェア、または「クラウド」プロバイダーを介した仮想サーバー（VPS）など）には非常に簡単な修正があります。
この問題はどのように発生しましたか？
仮想マシンの1つのrootfsを元のルートパーティションから新しいディスクに移行しました。update-grubもともとrootfsのPARTUUIDを使い続けていることがわかりました。まず、chrootでの実行に関連する問題であると知り、手動でUUIDを修正し/boot/grub/grub.cfgて再起動しました。
新しいrootfsパーティションから起動した後、update-grub新しいディスクで実行されている物理マシンで実行すると、正しいUUIDで動作することを望んで実行しました。残念ながら動作しませんでした。
インターネットを検索してStackExchangeの質問を見つけましたが、1つの回答で役立つ可能性のある追加の設定/boot/efiファイルがあることを確認することをお勧めします。もちろん、/boot/efi/boot/grub/grub.cfgハードコーディングされたFS UUIDが含まれていることがわかりました。
root@host ~ # cat /boot/efi/boot/grub/grub.cfg
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
search.fs_uuid 897a358a-acba-4b07-867c-33d1ca3b28dc root hd0,gpt1
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
これを修正しましたが、.NETで無効なPARTUUID設定がfs_uuidまだ完全に修正されていません。update-grub/boot/grub/grub.cfg
しかし、最終的にコマンドログに疑わしい設定ファイルが見つかりましたupdate-grub。
root@host ~ # update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/40-force-partuuid.cfg'
Sourcing file `/etc/default/grub.d/50-cloudimg-settings.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-71-generic
Found initrd image: /boot/initrd.img-5.4.0-71-generic
Found linux image: /boot/vmlinuz-5.4.0-24-generic
Found initrd image: /boot/initrd.img-5.4.0-24-generic
done
問題の最終修正
うーん… Sourcing file '/etc/default/grub.d/40-force-partuuid.cfg'- 強制的にパートトイド？犯人のようです。
root@host ~ # cat /etc/default/grub.d/40-force-partuuid.cfg
GRUB_FORCE_PARTUUID=897a358a-acba-4b07-867c-33d1ca3b28dc
もちろん、間違っているがGRUB構成で継続的に設定されたパーティションUUIDが含まれていました。
GRUB_FORCE_PARTUUID私のrootfsパーティションのPARTUUIDに変更して再実行した後、update-grubついにgrub.cfgで正しいPARTUUIDを使用しました。 :)
一般化する
システムでこの問題を解決するには、まずルートファイルシステム（および/または別々のパーティションがある場合は起動パーティション）のファイルシステムcloud-initUUID（）とパーティションUUID（）を書き留めておく必要があります。UUID=PARTUUID=blkid
root@host ~ # blkid
/dev/sda1: UUID="wcrpSm-QCZu-VN3A-I503-sQqQ-5xfw-76r5bd" TYPE="LVM2_member" PARTUUID="bec389fc-4274-5245-babb-7d90674f1662"
/dev/sdb2: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="072E-C819" TYPE="vfat" PARTUUID="78730ead-03d3-e14d-b4fe-ee0abf4f0ad5"
/dev/sdb3: UUID="6cea6786-510a-4fba-871b-7811b63b3453" TYPE="xfs" PARTUUID="530c353b-0be8-e34e-affb-bd5c2332abc7"
私の場合、/dev/sdb3rootfsとブートパーティションでした。
次に、/boot/efi/boot/grub/grub.cfg目的のエディタ（たとえば、nanoまたはvim）で開き、UUID部分をfs_uuid XXXX-XXXXファイルシステムのUUIDに置き換えます。たとえば、私の場合6cea6786-510a-4fba-871b-7811b63b3453
次に、/etc/default/grub.d/40-force-partuuid.cfgUUID値を開き、それをGRUB_FORCE_PARTUUID=PARTITION UUID（PARTUUID）に置き換えます。私の場合は530c353b-0be8-e34e-affb-bd5c2332abc7。
最後にupdate-grub- を実行し、/boot/grub/grub.cfg正しいFS UUID + PARTUUIDを使用していることを確認します。
誤ったUUIDのため、initramfsに閉じ込めずにGRUB設定を更新して再起動できるようになりました。 :)
答え2
コメントで述べたように、grub.cfg「BIOSブート」パーティションの目的と、複数のファイルが異なるパーティションに分散している理由が混乱しています。私の考えでは、ファイルを1つだけで十分grub.cfgで、LinuxとWindowsを起動できるはずです。
もう1つは、アップデートしたいライブUSBがEFIモードで作成され起動されていることを絶対に確認することです。いいえレガシー BIOS ブートモード。これを確認する簡単な方法は、USBで起動し、/sys/firmware/efiファイルがあることを確認することです。それ以外の場合は、EFIモードで起動しません。
私はWindows / Linuxと非常によく似たデュアルブートシステムを持っています。確認すると、grub.cfgLinuxシステムのルートパーティションの/ boot / grubフォルダにファイルが1つしかないことがわかりました。 EFIシステムパーティションは、起動中に/boot/efiにマウントされます。
EFIパーティションの変更に関する質問に関しては、grub.cfgそうすることはできません。実際、grub.cfg何らかの理由で複数のファイルが必要な場合は、自動更新ツールが正しく処理するのではなく、ファイルを直接維持することをお勧めします。まず、自動的に生成されたファイルをバックアップします。ファイルを変更する前に、grubコマンドラインから起動コマンドをテストすることもできます。何かを台無しにした場合に起こる最悪の状況は、GRUBコマンドプロンプトに入り、手動で起動コマンドを入力する必要があります。これを行う方法がわからない場合は、ライブUSBから起動してファイルを復元/復元する必要があるかもしれません。
もう1つは、手動で変更すると、次にgrub.cfgGRUBが自動更新を実行するときに上書きされる可能性があることです（この場合、update-grub commandLinuxディストリビューションでは無効になります）。
答え3
助けてくれた@Time4Teaに感謝します。非常に簡単な解決策があることがわかりました。 akagrub.cfgにあった以前に投稿したファイルはプレフィックスをからに変更し、私が作成したファイルがある場所がその場所です。 nanoで上書きし、Ubuntuからインストールして保存しました（grub端末を使用してUbuntuで手動起動した後）。以下は、小さな変更を含む新しいファイルです。(hd0,1)/EFI/ubuntu/grub.cfg/dev/sda1/EFI/ubuntu/grub.cfg(hd0,gpt5)(hd0,8)grub.cfgsudo update-grub2/dev/sda1/
search.fs_uuid 7e076866-97b4-4d3c-b864-491137212645 root hd0,gpt5
set prefix=(hd0,8)'/boot/grub'
configfile $prefix/grub.cfg
答え4
「GRUB_FORCE_PARTUUID試行initrdlessブート」エラーが発生し、Virt-managerで実行されているUbuntuクラウドイメージを取得しようとして長い検索の最後にここまで来た場合は、こちらをご覧ください。https://askubuntu.com/questions/1375589/what-are-the- Different-versions-available-as-ubuntu-cloud-images
上記のように、/etc/default/grub.d/40-force-partuuid.cfgファイルでこの行をコメントアウトし、他の2つのファイルを移動することはupdate-grub。