最近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設定を更新して再起動できるようになりました。 :)