☰

「警告! UUID=xxx が存在しません。シェルにドロップします!」 この xxx 値はどこでどのように変更できますか? grub 構成のどこに保存されますか?

tag-icon • tag-icon linux grub uefi bios uuid
「警告! UUID=xxx が存在しません。シェルにドロップします!」 この xxx 値はどこでどのように変更できますか? grub 構成のどこに保存されますか?

サーバーにはディスクがいくつかあり (RAID 用)、さまざまなディストリビューションをテストするためのブート パーティションもいくつかあります。あるとき、最新 (10 バスター) の Debian 32 ビットと最新 (10 バスター) の Debian 64 ビットを持っていましたが、何らかの理由で、Debian 64 ビットを下位のパーティションに移動することにしました (dd を使用して、新しい UUID を設定し、そのパーティションの /etc/fstab で更新)。その後、移動した Debian があったパーティションに最新 (20.1 Ulyssa) の Linux Mint Cinnamon をインストールしました。Linux Mint をインストールすると update-grub が実行され、Debian 64 用の新しいパーティションが取得されるため、問題が発生するとは思っていませんでしたが、その時点で Debian 64 ビットが動作しなくなりました。ルート パーティションが見つからないことを示しています。

これについてはいくつかコメントがあります。Debian のインストール プロセスでは、UEFI モードで grub をインストールしようとすると、非 UEFI パーティションが動作しなくなる可能性があると警告してくれるので、非常に便利です (BIOS 互換モードで起動するように提案されます)。Mint はこの点をあまり気にしていないようです。そのため、Mint は grub を UEFI モードで構成しました。しかし、奇妙なことに、Debian 64 の動作は停止しましたが、Debian 32 は停止しませんでした。

正直に言うと、grub のプロセスは私にとって決して明確ではありませんでした。しかし、私が理解できないのは、Debian 32 から grub を再インストールして更新しても問題が解決せず、両方のパーティション (Debian 32 と 64) の /etc と /boot (サブディレクトリを含む) で、失敗した UUID を持つファイルを見つけようとしていることです。最終的に、起動時に Debian 64 の grub コマンド ラインを編集し、Debian 64 から grub を再インストールして更新することで問題を解決しました。

しかし、私が本当に理解したいのは、この UUID がどこに保存されているか (なぜ見つけられなかったのか)、そしてなぜ Debian 32 パーティションからこの問題を解決できなかったのかということです。

編集: 明確にするために: 起動中に grub メニューからカーネル パラメータを編集して、root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx を root=/dev/sdxx に置き換えることで起動できました。その後の grub 復元プロセスで initrd は変更されませんでした。ただし、/etc および /boot 内の圧縮されていないファイルでは、この UUID 値 (xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx も xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx も) を見つけることができませんでした。

編集2: わかりました...私が探していたのは/boot/grub/grub.cfg（Archemarに感謝）でしたが、検索で正規表現を間違えたため見つかりませんでした。

find /boot /etc -type f -print0 | 
    xargs -0 grep -li 'a9c85b02-?751e-?48b5-?b85e-?df60d20b5d3e'

grep 正規表現は ? を認識しません。代わりに {0,1} を使用するべきでした... :'(

find /boot /etc -type f -print0 | 
    xargs -0 grep -li 'a9c85b02-\{0,1\}751e-\{0,1\}48b5-\{0,1\}b85e-\{0,1\}df60d20b5d3e'

しかし、Debian 32 パーティションから grub を再インストールして再構成したときに動作しなかった理由は説明されていません。他の Linux パーティションの認識は、/boot/grub/grub.cfgそれらのパーティション内の解析に基づいているのでしょうか? :-o

答え1

VMware でブート + システム ディスクを 800Gb ディスクから 16Gb に移動するときに同様の問題が発生しました。パーティションとファイルをコピーするだけでは (800Gb ディスクから 16Gb へ)、800Gb ディスクを削除するだけでは不十分でした (カーネルのブートは OK ですが、/UUID が見つかりません)。(そして残念なことに、この場合、VMware のスナップショットはロールバックの安全策として役立ちませんでした)

  • マウントポイントはあります/etc/fstabが、2 fstab
  • 平野fstabは/etc
  • secret/etc/fstabがブートディスクのパーティション内にある場合initrd.gz(またはそれに類するものがある場合) 、この fstab はOS の (ルート FS)/bootを指す UUID を保持します。/

initrdこの OS から起動した場合は再構築してください。

または、別の OS から起動した場合は、initrd.gzgzip 圧縮された cpio なので、「単に」 fstabファイルを抽出し、編集して、 に戻しますinitrd.gz。

関連情報