「grub-install /dev/sda failed」エラーでUbuntuのインストールが失敗し続けるのはなぜですか？

20.04LTSと22.04LTSをインストールできないのと同じ問題が発生しました。

ついに問題を解決しました。 Ubuntuインストーラが失敗した後、USBライブUbuntuで再起動し、起動リカバリを再実行しました。効果はとても良いです。

具体的には：

• Nvidia 3090グラフィックカードが2枚あります。

• GRUBメニューから「Install Ubuntu」を選択すると、黒い画面が表示されます。したがって、インストールのためにUSBライブUbuntuに入るには、eGRUBメニューの追加acpi=off（nomodesetまたは役に立たない「Secure Graphics」を選択）を押す必要があります。

• それからこれを見つけました。「NVMeにGRUBをインストールできません」、ブートリカバリの実行結果は「NVRAMがロックされています。」。

  私のSSDに以前のインストール中に何らかの方法でロックが追加されたため、ブートリカバリは何も変更できないとします。代わりに、次のメッセージが表示されます。「NVRAMロック」。を実行するとcd /targetすぐに入ります。

• 再起動後に実行すると、エラーメッセージがcd /target表示されますnot a directory。次に、起動リカバリを実行します。問題が解決しました。

また、AskUbuntuの投稿に基づいてGRUBを手動でインストールしてみました。ところで、私の母国語が英語ではなくて、どのドライブをどのドライブにインストールするべきかを混乱させたようです。 「デバイス/ハードウェア/ドライブ」という用語がUSBスティックを指しているのか、SSDを指しているのかは実際にはわかりません。

NVram Locked/sys/firmware/efivarsこのツールを使用すると、Linuxでefibootmgrアクセス可能なUEFI NVRAM変数に書き込む際にいくつかの問題があるようです。

/mnt/chrootdir以下にインストールして接続してchroot失敗したインストールにアクセスするには、質問に対する回答のアドバイスに従った場合接続したUbuntuの質問をお願いします、両方に機能に重要な別のサブファイルシステムが含まれているため、どちらもmount --rbind代わりに使用することをお勧めします。mount --bind/dev/sysgrub-install

• /dev/ptschroot環境で使用できないとエラーが発生しますunable to allocate pty: No such device。
• chroot環境で使用できない場合、/sys/firmware/efi/efivarsUEFI NVRAM変数への書き込み試行は失敗します。これが主な問題です。

しかし、それでも役に立たない場合はお読みください。Roderick W. Smithが書いた素晴らしいウェブページです。は、他のオペレーティングシステムまたはUEFIファームウェアの実装の欠陥によって引き起こされる可能性があるいくつかの問題を説明し、解決策を提供します。

ディスクに次の内容を含むファイルがsda1あるようです。efi/ubuntu/grub.cfg

search.fs_uuid 2D07-0F0A root hd0,gpt1 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

これは間違っているようです。ファイルシステムUUIDでESPパーティション（）を見つけ、sda1次のものを含むLinuxルートファイルシステムでなければならないとします。しかし、Linuxルートではなく、UEFI ESPと同様に/boot/grubそうではありません。sda1ファイルシステム

ファイルには次の内容を含める必要があります。

search.fs_uuid 25f0e88-f20a-4350-9df0-ee8c57ecc455 root hd0,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

GRUBがで始まっても、有効な設定を見つけることができるように（または）efi/ubuntu/grub.cfgにコピーできます。efi/BOOT/grub.cfgsda1efi/BOOT/BOOTx64.efi

この設定ファイルは、ESPがファイルシステムUUIDを介してgrubx64.efi実際のUbuntuルートパーティション（）を見つけ、そこから必要なGRUBモジュールをロードし、ESPから実際のGRUB設定をロードするようにします。sda2/boot/grub/grub.cfgsda2

UEFIフォールバック/リムーバブルメディアブートパスでも、ブートファイルセット全体を使用できるようにコピーする必要がefi/ubuntu/grubx64.efiあるかもしれません。efi/BOOT/grubx64.efisda1

ブート回復出力のこの部分は、実際には次のように生成されますefibootmgr -v。

BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0004
Boot0003* UEFI: TOSHIBA TransMemory 1.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/HD(2,GPT,9240a165-d190-4ab6-8a12-46dc207b42ee,0x71e8a0,0x2130)..BO
Boot0004* UEFI: ST2000DM001-1ER164  HD(1,GPT,22c1dbaf-a26e-4408-a6f9-d1fc06b0d615,0x800,0x100000)/File(EFI\boot\bootx64.efi)..BO

これは現在USBから起動していますが、システムファームウェアが（sda1PARTUUIDで識別されたファイルフォールバック/リムーバブルメディア起動パスを使用）から起動する準備ができていることを示します（ESPのファイルシステムなので、2c1dbaf-a26e-4408-a6f9-d1fc06b0d615EFI/boot/bootx64.efivfatしなければならない大文字と小文字は区別されませんが、一部のUEFIファームウェア実装は大文字と小文字を区別しません。したがって、ESPに対して上記の変更を加えることができれば、システムはsda1。

UEFIモードで通常のUbuntuシステムを実行できる場合は、sudo grub-install /dev/sdaブートローダの書き換えを再試行してUbuntuのNVRAMブート変数を自動的に書き換えることができます。または、efibootmgr次のコマンドを使用してブート変数の問題を直接参照できます。

sudo efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\ubuntu\\grubx64.efi -L Ubuntu 

（このコマンドを使用するには、ファイルシステムを/dev/sda1にマウントし、/boot/efiファイルefivarfsシステムをにマウントする必要があります。/sys/firmware/efi/efivars両方の条件は、通常のUbuntuブートプロセスによって自動的に処理される必要があります。）

「NVram Locked」などのエラーが引き続き発生する場合は、UEFI実装にバグがある可能性がありますが、少なくとも代替/リムーバブルメディアパスを使用してUbuntuで起動できます。