grub.cfgから "search"コマンドを正しく削除する方法は?

grub.cfgから "search"コマンドを正しく削除する方法は?

私はグルーブが何でも「検索」したくありません。私は私のルートファイルシステムがどこにあるかを知っており、常にそこにいます(/dev/sda1)。そして、グルーブが他のルートを見つけるために接続されているすべてのドライブを見たくない。間違った一つ)。

カーネルロードラインでUUIDの使用を無効にすることができました。

GRUB_DISABLE_LINUX_UUID=true

では/etc/default/grub、しかし結果は次のようになります。/boot/grub/grub.cfg まだ次の行があります。

search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  3f8c2b36-5d8f-40ac-9b63-7d1445805925

私はこのようなことをしたくありません。検索されたくない別の言葉。私は「os-probing」をもっとオフにしました。

GRUB_DISABLE_OS_PROBER=true

searchこれにより、接続されている他のディスクから自分のシステムのバックアップコピーが見つかりませんが、使用しないようにしたUUIDだけでなく、grubでそのコマンドのインスタンスが実行されることも望ましくありません。

私は地球虫が嫌いです。root=/dev/sda1システム全体を調査することなく、コンピュータが起動して存在しない可能性があるUUIDを見つけたいと思います。 LILOを起動した1999年と同じです。

実際にやるよ使用LILOやsyslinuxのようなもの(Ubuntu以外の場合はgrubを使用するため、カーネルの更新を維持するにはほとんど強制的にgrubを使用する必要があります)。私はそれが人間が可能な最も単純な構成であることを望むだけです。 (これはまだgrub.cfg 200行が生成されることを知っていますが、まあそうです)。

答え1

grub-mkconfig動作方法は次のとおりです。検索したコアごとにGRUBメニュー項目を自動的に作成します。しかし、何が欲しいのか、何をしているのかを知っていれば、使用する必要はありません。簡単な構成まったくそうではありません。なぜならあなたはgrub.cfgあなたのものを書くことができるからです。

grub-mkconfig実際にはいくつかの制限があります。編集または作成して/etc/grub.d/40_customリストの最後に追加のカスタムメニュー項目を追加できますが、/boot/grub/custom.cfgメニュー項目の順序を変更したりタイトルを変更したりするには、メニューに保存されているメニュー項目をいくつか変更する必要があります/etc/grub.d/。未来。同時に、このように書くのが簡単になると思う人は、書くのが簡単になると思うgrub.cfg人にそれをするように励ます。 電源オンシェル型スクリプト)、ディストリビューションが提供するシステム自動実行 grub-mkconfig を無効にします。

ここでは、必要なだけ簡単な設定を含む1つのメニュー項目(無効なメニュー)しか持てません。ここでこのカーネルを起動したいと言えます。それがすべてです。

1行はmenuentry { }200行ではなく5行にすることができます。

覚えている:

  • まず、カスタムメニュー項目をカスタムメニュー項目に追加してテストします。
  • システムでこれを無効にした場合は、カーネルを更新するたびに手動で更新する必要がありますgrub-mkconfiggrub.cfg

答え2

ルートファイルシステム情報は、実際には/dev/sda1カーネルブート引数stringの一部としてroot=/dev/sda1Linuxカーネルに渡される以外にGRUBにはまったく使用されません。

GRUBが知っておくべきことは、システムファームウェア呼び出しでディスクに使用される識別子、GRUBコアイメージに含まれていないGRUBモジュール、カーネル、および自己構成ファイルをロードするときのinitramfsファイルです。

クラシックBIOSベースのシステムでは、この識別子のデフォルト形式は16進バイトです。 0x80はBIOSが検出した最初のディスクを表し、0x81は2番目のディスクを表します。 GRUBはそれを独自の識別子((hd0)0x80、0x81 (hd1)、そしてすぐに)にマッピングします。

UEFIシステムでは、UEFIシェルを実行し、そのmapコマンドを使用してUEFIパーティション識別子を表示できます(ファームウェアが検出した順序で)。 UEFI 認識ファイルシステムがある最初のパーティションはfs0:、2 番目のパーティションはfs1:、等など。フルディスクおよびRAWパーティションアクセスは、たとえばblk0:GRUBのUEFIバージョンを介して行われ、コンテンツがロードされるディスクまたはパーティションを識別するには、これらのもの(またはマシンで読み取り可能なUEFI API等価物)を使用する必要があります。 GRUBは主に独自のファイルシステムドライバを使用するので、blkN:ファームウェア識別子を(hdN)

searchコマンド

search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1

これは、コマンドで利用可能な最良の情報(特にBIOSベースのシステムでは最善の推測である可能性があります)に基づいて書き込み後にハードウェア構成が勝つと仮定すると、後続のコマンドに必要なファイルを含むgrub-mkconfigパーティションが起動(hd0,msdos1)時に存在する可能性があります。これが最も高いことを意味します。構成ファイルを変更しないでください。

--set=rootこの検索コマンドの目的は、rootGRUBの変数がこの検索の結果であるすべてのパーティションを指すように設定することです。

searchしたがって、このコマンドの後に必要なファイルがディスクの最初のパーティションにあり、ファームウェアが常にそれを最初のディスクとして検出することがわかっている場合は、searchこのコマンドを次のように置き換えることができます。

set root=(hd0,msdos1)

注:GRUBroot変数の設定は、Linuxカーネルのルートファイルシステムとはまったく関係ありません。唯一の目的は、パス名を使用してディスク上のファイルを参照する後続のGRUBコマンドのルートパス(ディスク/パーティションを含む)を定義することです。

クラシックBIOSスタイルの起動プロセスで合理的に確信できる唯一のことは、BIOS設定ですべてのディスクが起動可能に選択されていることです(BIOS設定に複数のディスクがリストされている場合、BIOSは現在起動しようとしています)。それから)起動順序)はBIOSディスク0x80 ...としてアクセスできるので、GRUBの場合(hd0)


BTW、Debian、Ubuntuは単にデフォルトのブートローダなので、GRUBを「使用」します。必要に応じてGRUBを削除して、お気に入りのブートローダに置き換えることができます。唯一の要件は、適切なディレクトリで構成を更新するための独自のスクリプトを作成することです/etc/kernel/。 GRUBの場合、これらのスクリプト/etc/kernel/postinst.d/zz-update-grub/etc/kernel/postrm.d/zz-update-grubこれは、パッケージ管理システムとGRUB構成の間の唯一の接続です。

新しいカーネルパッケージがインストールまたは削除されるたびに、そのディレクトリ内のすべてのスクリプトが実行されます。ディレクトリliloから実行されるスクリプトを配置すると、Ubuntuアップデートを使用すると、デフォルトでGRUBと同様にLILOをシームレスに使用できます。postinst.dpreinst.d

2012年には、当時GRUBに問題を引き起こすファームウェアバグがある初期のUEFI実装システムがありました。 rEFIndがこのバグを回避できることを発見し、それを使用してDebianのGRUBをrEFIndに置き換えました。ファームウェアが修正されたバージョンに更新され、GRUBがUEFIのバグの多くの解決策を受けたにもかかわらず、当時作成した単純なスクリプトをバックアップブートローダーとして8年間実行してきました。

Debian の最新バージョンは実際に rEFInd をパッケージ化し、パッケージに似たスクリプトを含んでいます。ディストリビューションに含まれる他のブートローダパッケージの場合も同様です。 UbuntuにLILOまたはSyslinux用のパッケージがある場合は、それをインストールして、パッケージにカーネルpostinstall / postrmスクリプトが含まれていることを確認できます。それでは、「ただ働く」ことがわかります。


ディスクまたはファイルシステムを複製する習慣がある場合は、新しい複製が元の複製と一緒にシステムに表示されるようにするには、その複製のUUIDを変更することをお勧めします。この問題これに関する多くの提案があります。

LVMのSANレベルのスナップショットを持つエンタープライズ環境では〜しなければならないクローンを作成したらすぐに再統合します。そうでなければ、クローンとオリジナルが同じシステム(かつて存在し、問題を解決し、vgimportclone友人だったシステム)に現れると、痛みを伴う世界に陥ります。他の種類の環境では、まだ良い考えかもしれません。

関連情報