これはばかげているように聞こえ、重複がたくさんあるように見えるかもしれませんが、私はほぼ3日を費やして、見ないで解決策を探しました。私の/ bootパーティション(すべてのvmlinuzおよびinitrdファイルと一緒に)、それで私はライブメディアからの標準的な回復方法を試しました(私のシステムがLVMパーティションとEFIモードでインストールされたのでいくつかの変更があります):
mkdir /mnt/fedsys
mount /dev/Fedora/root /mnt/fedsys
mount /dev/sda2 /mnt/fedsys/boot
mkdir /mnt/fedsys/boot/efi (I had to create a new efi dir since it was lost)
mount /dev/sda1 /mnt/fedsys/boot/efi
mount --bind /proc/ /mnt/fedsys/proc
mount --bind /sys/ /mnt/fedsys/sys
mount --bind /dev/ /mnt/fedsys/dev
chroot /mnt/fedsys
ここまでは問題なく動作し、grub.cfgファイルを再生成してみました。
grub2-mkconfig -o /boot/efi/EFI/Fedora/grub.cfg
ただし、次のメッセージで失敗します。
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
device-mapper: reload ioctl on osprober-linux-sdd1 failed: Invalid argument
Command failed
done
次に、エラーを無視して、grubのインストールに進みます。
grub2-install /dev/sda
そして、それは次の出力を与えます:
Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
Installation finished. No error reported.
そして、再起動すると、grubプロンプトが表示されます。さて、問題はvmlinuzもinitrdもどこにでもあるという事実にあると思います(もちろん、/ dev/sda2を削除したため)が、それらを再構築するか、システムを起動する方法を見つけることができません。
私に何ができる?ライブメディアからこれらのファイルを再構築する方法はありますか?私が救出しようとしているシステムは、EFIモードとLVMでFedora 2564ビットを実行していました。
同様の問題が発生し、誤ってブートパーティションを削除してしまいました。 @Marekによる回答は、場合によっては非常に役立つことがわかりました。参考までに、使用したコマンドを記述します(@Marekの回答は一般的だったため、いくつかのコマンドをオンラインで検索する必要がありました)
私はFedora30PCを持っています。ブートパーティションは/dev/sda3
にあり、ルートパーティションはFedora-root
という名前のLVLMにあります。 rootアカウントですべてのコマンドを実行しました。
Fedoraライブメディアから(USBドライブから)起動しました
ルートパーティションをマウントします
mount /dev/mapper/Fedora-root /mnt
mount /dev/sda3 /mnt/boot
cp /boot/vmlinuz-$(uname -r) /mnt/boot/
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
/mnt
に変更します。chroot /mnt
initramfs
を生成しますdracut /boot/initramfs-$(uname -r).img $(uname -r) -v
grub2-mkconfig -o /boot/grub2/grub.cfg
なんらかの理由で、initramfs
の生成が非常に遅く、システムで終了できませんでした(ステップ6)。ただし、ファイルシステムをchrootしなかった場合、コマンドは正常に機能しました。そのため、3からの手順をスキップしました。また、ルートシステムを指すようにdracut
構成を変更する必要がありました。
したがって、新しい手順は次のとおりです。
dracut
構成のルートの場所をポイントしますecho "root=/dev/mapper/Fedora/root" > /etc/dracut.conf.d/kernel.conf
kernel
を再インストールし、initramfs
[.____を生成します。]dracut /dev/sda/initramfs-$(uname -r).img $(uname -r) -v
mount /dev/mapper/Fedora-root /mnt`
mount /dev/sda3 /mnt/boot
cp /boot/vmlinuz-$(uname -r) /mnt/boot/
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt
grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg
NVIDIA所有者への注意
NVIDIA GPUを使用しており、インシデントの前に独自のドライバーをインストールしていました。
ライブメディアから復元されたカーネルは、Nouveauドライバーを使用していました(Fedoraのデフォルトドライバーであるため)。復元されたカーネルも最新バージョンではありませんでした。その後、GUIインターフェイスを使用してkernel
を更新すると、NVIDIA独自のドライバーが使用されました。
これは、システムの修正を試みることができる一般的な方法です。パッケージ名はディストリビューションによって異なる場合があるため、詳細をグーグルで検索する必要がある場合があります。
/mnt
)。/boot
とあなたが持っているかもしれない他のもの。-o bind
フォルダー/dev
、/proc
、および/sys
を使用して、ライブメディアルートから/mnt
のhddルートにマウントします。/mnt
に安全にchrootできます。それはあなたに完全に機能するシステムを与えるはずです。編集: chrootすることにより、ローカルの書き込み可能なディスクインストールの環境に入ります。すでに実行中のプロセスとカーネルを除いて、すべてのライブラリと実行可能ファイルがこの環境から使用されるため、インストールされているパッケージマネージャーとパッケージデータベースを使用できます。 /dev
、/proc
、および/sys
のマウントは、ハードウェアへのアクセスとプロセスの制御を可能にするために必要です。/boot
で新しいLinuxイメージを生成するために必要になります。 grubを適切に構成し、ネットワークにアクセスしてパッケージをダウンロードします。 Chrootingは、別のディストリビューションのライブメディアを使用する必要がある場合に特に便利です。
Grubの再インストールに関しては-パッケージ名はディストリビューション間で異なる可能性がありますが、grub *を再インストールしても害はありません。パッケージをインストールするだけでは不十分な場合があることを忘れないでください。構成をセットアップした後、grub-install
を実行する必要がある場合もあります。
最初にブート修復ディスクを試してみることをお勧めします。MBRの問題のほとんどが修復されます。この記事も役立つかもしれません。 https://www.linux.com/learn/how-rescue-non-booting -grub-2-Linux