`rm -rf / --no-preserve-root` は BIOS を台無しにする可能性がありますか?

`rm -rf / --no-preserve-root` は BIOS を台無しにする可能性がありますか?

システム全体を tarball 化し、その後 foobar 化された場合にそのシステムを復元する場合のおおよその速度を確認するために、会社のシステムに不可欠ではないものの、機能していると便利なワークステーションに、主要なシステムの 1 つを部分的にクローン化しました。システム全体の tarball の作成時間を計測し、問題がないことを確認するために検査しました。

それから走りましたrm -rf / --no-preserve-root。今までにそんなことをする機会がなかったので、とても楽しかったです。最初は。

ボックスを再起動しても何も表示されませんでした。「Dell」のロゴも、BIOS のオプションも、何も表示されませんでした。

ドライブを別のボックスに接続したところ、残念なことに UEFI パーティションがあることがわかりました。Command of Death によってそのパーティションが事実上破壊されたのだと思います。

現在は機能していない別のドライブをワークステーションに接続しましたが、ワークステーションはまだ何も動作しません。

誰かこのようなものを見たことがありますか、または何を探すべきかについて提案がありますか? そのrmコマンドを実行すると、ボックス全体がこのようにひどく台無しになるのはなぜですか?

更新:デルに箱を返送しました。偶然なのか、状況が原因なのか正確には判断できませんでした。ドロナスの説明ただし、dronus の回答は、これが起こる可能性のある理由を説明しているので、受け入れます。さらに、将来同じことをしないように他の人に警告することになります。誰かが Dell がバグのある UEFI を使用している記録を見つけたら、それは役立つでしょう。

答え1

まれに、Samsung および Lenovo のノートブックの一部シリーズをすでに破壊した悪名高い UEFI バグのいくつかを引き起こした可能性があります。

仕組みは次のようになります。UEFI 仕様では、設定やデバッグ情報を保存するために OS がアクセスできる不揮発性メモリ (nvram または eeprom) が提案されています。Linux は実際にカーネル パニックが発生した場合にこの機能を使用します。ルート ファイル システムが信頼されなくなった場合 (カーネル コードで例外が発生した後など)、読み取り専用に切り替えられます。これで UEFI 機能が使用できるようになり、デバッグ情報が不揮発性メモリに書き込まれます。これまでのところ、これは良いアイデアのように思えます。データは後で取得され、クラッシュの原因を調査するために使用できます。

しかし、バグのある UEFI ファームウェアの一部では、不揮発性メッセージ メモリの管理ルーチンが壊れています。メッセージによっては、これらのファームウェアはメッセージ メモリの初期化時にクラッシュします。通常は起動直後にクラッシュします。VGA の初期化にさえ至らない場合もあり、その場合はマシンが完全に壊れているように見えます。上記のケースでは、ソフトウェアによる解決策はなく、マザーボードを交換する必要がありました。

を実行すると、、またはrm -rf / --no-preserve-rootなどのカーネルファイルシステムを走査および削除するときに別のカーネルバグがトリガーされる可能性があり/sys、最終的にカーネルパニックが発生し、最終的に上記の不揮発性メッセージメモリのバグがトリガーされる可能性があります。/dev/proc

答え2

いいえ、そのコマンドを使用して BIOS (レガシーまたは UEFI) をこのように破壊することはできません。

たとえ UEFI パーティションを破壊できたとしても、コア BIOS ファイルはマザーボード上の不揮発性メモリ (主にフラッシュベース) に保存されているため、影響を受けません。

UEFI パーティションは追加のソフトウェア コンポーネント (例: デバッガー、ドライバー、ecc) をホストしますが、有効な UEFI パーティションがなくてもマシンは BIOS を起動する必要があります。

答え3

楽しいですが、rm -rf /その小さな牢獄の中でのみ大混乱を引き起こすことができます。つまり、その牢獄とは、与えられたパーティションです。ディスクの MBR を台無しにしたり、コンピューターを魔法のように破壊したりすることはできません。

あなたの場合は何か他の問題があります。

答え4

/sys/firmware/efi/efivars特殊ファイルシステムすべてのEFI変数を含む。ベンダーが従わなかった場合ベストプラクティスrm -rf重要なものを消去したためにファームウェアが混乱した可能性があります。

関連情報