覚えておいてください、私は台無しにされたラップトップについてあなたに話しましたか？さて、詳しく説明しましょう。イメージングおよびリカバリソフトウェアを使用してテストを行っていましたが、テストが完了したら、プロセスがどの程度うまくいったかを確認したいと思いました。よくない、それが判明しました。 GRUBはそこにありましたが、メニューのエントリは最初は機能しませんでした。それをすぐに修正すると、Windows 10が起動せず、自動修復も行われず、マルチブートセットアップのシステム上のディストリビューションの半分（合計8つのうち）も起動しないことがわかりました。 、緊急モードに入ります。ディストリビューションの全容について話し合っています。お好きなものを選んでください。
さて、GRUBの回復は非常にトリッキーでした-私が考えることができた方法はどれもうまくいきませんでした、そして私はブートローダーを正しく構成するためだけにテストディストリビューションをインストールすることになりました。次に、DIDが機能するディストリビューションの1つを開始し、データの損失がないことに気付きました。すべてがそこにあり、すべてのパーティションは正気で全体であり、ファイルは適切な場所にあり、LinuxとWindowsが含まれていました。この記事では、この問題をどのように解決したか、そしてどのように修正したかを示したいと思います。続編では、Windows10でも同じことを行います。便利な演習です。フォローしてください。
問題の詳細
ネオンをスターターとして次の演習を行いましたが、2011年から2012年頃以降、ほぼすべてのディストロに適用されます。つまり、KDEネオンが起動を開始し、緊急シェルにドロップします。システムから、journalctl -xbを実行して起動ログを確認し、何が問題だったのかを把握する必要があると言われました。さて、これに遭遇したのはこれが初めてではありません。少し前にFedoraで同様の問題を処理しました。
しかし、ここでは、問題は少し異なっていました。はい、ブートログには/ boot / efiの問題が示されていましたが、これが発生した理由は別の問題が原因でした。緊急セッションでログを取得してコピーした方法がわからない場合（そのようなものが必要な場合）、コンテンツをファイルにコピーしてから、ライブセッション（redirect>またはteeコマンドを使用）で取得できます。 ）、または問題を修正したら、journalctl -x --boot=-1を使用して最後のマイナス1ログをダンプできます。それはあなたにとって最新のテクノロジーです。
Dec 06 12:57:09 tester systemd [1]：/ dev / disk/のファイルシステムチェックの依存関係が失敗しました
-件名：ユニットsystemd-fsck @ dev-disk-by \ x2duuid-641C\x2d39CE。サービスが失敗しました
-定義者：systemd
-サポート：http：//www.ubuntu.com/support
-
-ユニットsystemd-fsck@ dev-disk-by \ x2duuid-641C\x2d39CE.serviceが失敗しました。
-
-結果は結果です。
Dec 06 12:57:09 tester systemd [1]：/ boot/efiの依存関係が失敗しました。
-件名：ユニットboot-efi.mountが失敗しました
-定義者：systemd
-サポート：http：//www.ubuntu.com/support
-
-ユニットboot-efi.mountが失敗しました。
解決策
何が悪かったのだろうと思っていました。 dev-disk-by全体が大きなヒントでした。スワップパーティションのUUIDが変更されたときにスローブートの問題を修正する方法を示したときのことを覚えていますか？ / boot / efiがシステムの起動プロセスで重要であることを除けば、これは非常に似ているように見えました。
/ etc / fstabを開きましたが、実際、スワップパーティション（dev / sda10）のリストされたUUIDが正しくありませんでした。このファイルには、パーティションエントリが以前はデバイス番号であったことを示すコメントも含まれていますが、その後、問題を引き起こすだけの「モダン」で「役立つ」UUIDナンセンスに変更されました。
＃インストール中に/ dev/sda10にスワップがありました
UUID =8140c8d0-1e33-42c1-8c3c-828449adfe08 none swap swap 0 0
UUIDを/dev/ sda10に変更して再起動すると、すべてが桃色になりました！
これを行うために必要なコマンド
さて、少し遅くしましょう。したがって、これは、システムが正しいデバイス番号または識別子を使用しているかどうかを確認する方法です。まず、fdisk-lを使用してパーティションを一覧表示できます。このコマンドは、すべての異なるパーティションとそれらのファイルシステムの概要を示します。このようにして、システムの基本的な理解を得ることができます。特に、ルートパーティション（/）が必要であり、個別の/ bootパーティションがある場合があります。これは、UEFIシステムでよくあることです。また、個別の/ homeを使用している場合もあります。また、オプションの個別のスワップパーティションがある場合もあります。これらには、/ dev / sda2、/ dev/sda8などのデバイス番号が付けられます。
問題は、Linuxディストリビューションの最新リリースがデバイスを/ etc / fstabにマップする方法から始まります。このファイルは、システムの起動時に、どのデバイスを自動マウントする必要があるかについて解析されます。以前は、デバイスはfdiskのように、dev / XdYZとして参照されていました。ここで、Xはディスクのタイプ（通常は文字hまたはs）を示し、Yはデバイスの文字（システムBIOSによって順序付けられたもの（例：a、b））です。または同様のもの）、Zはパーティション番号になります。たとえば、/ dev / sdb3は、SATA / SCSI/PCI-E接続タイプの2番目のディスク上の3番目のパーティションを意味します。
実際、「最新の」ディストリビューションはUUIDを使用します。これは人間を意味しない数字と文字の文字列であり、a45f-cc9aのように、パーティションを一意にマップすることを目的としているため、ディスクの順序が何らかの理由で変更された場合でも、システムは起動できます。おそらく企業では理にかなっていますが、家庭環境では、これは絶対的で完全にナンセンスです。systemd、新しいネットワークインターフェイスの命名規則、新しいネットワーク管理ツールなど、ほとんどすべての「最新の」ソリューションのように。哲学については後で詳しく説明します。
/ etc / fstabに間違ったUUIDがリストされている場合、システムはこれらのパーティションをマウントできません-壊れた構成をチェック、検索、または修復する機能がないため、メカニズムは非常に不安定です-起動できなくなる可能性がありますシステム。 UUID文字列は人間にはまったく役に立たないため、この状況を迅速にトラブルシューティングすることも不可能です。
blkidコマンドを使用してデバイスUUIDのリストを確認できます。次に例を示します。
blkid
/ dev / mapper / sda3_crypt：UUID ="TpZGKB-31Lq-U1Ap-BZJCcX" TYPE ="LVM2_member"
/ dev / mapper / kubuntu--vg-root：UUID ="dcae17fd-7cfe -c0b721e "TYPE =" ext4 "
視覚的に比較して、何が欠けているのかを把握する必要があります。次に、/ etc/fstabを手動で修正します。
現代、あなたはその言葉を使い続けます...
単純な現実は次のとおりです。私は15年以上Linuxを使用しています。人生のある時点で、私は約40のデータセンターに分散された約50,000台の物理サーバーを備えた美しいHPCセットアップを処理していました。私は、新旧のテクノロジーを使用して、ビジネスシステムとホームシステムを共有していました。
古いBIOS+MBR + GRUB+initから新しいUEFI+GPT + GRUB2 + systemdに移行して以来、壊れたシステムに遭遇しました。これらのソリューションには、魔法のような、回復力のある、または改善されたものは何もありません。それらは、確かに、業界におけるいくつかの実際の技術的限界を解決します。しかし、それらはまた、人間によるデバッグとトラブルシューティングが非常に難しい、はるかに堅牢でないセットアップを導入します。たとえば、ディスクの順序が乱れたために、システムが破壊されたのを見たことがありません。しかし、単純なデバイス番号表記の代わりにUUIDを使用することで、システムが破壊された例を数多く見ました。
GRUBの修正は、最悪の場合、512バイトのデータをあちこちにコピーし、テキストファイルを編集するという簡単なことでした。今では、EFIなどを使用して、新しいインターフェイスにアクセスするのはほぼ科学的な宗教です。壊れたLinuxの起動を修正することは問題ではありませんでした。そして今、私はバイナリログをテキストに解析し、システムが不安定である理由を理解する必要があります。 「存在しない問題に。たとえば、UUIDのことです。 ipとifconfigの違い。 enp0s0、または新しいネットワークカード識別子が何であれ、eth0よりも優れている、賢い、または直感的であるのはなぜですか？以前は論理的で、イーサネット=ethです。
ホームユーザーがボックスの内外でハードディスクを頻繁に追加または削除したり、BIOS設定で遊んだりする必要があるシナリオは何ですか？そうではありません。では、なぜ家庭用システムには不十分なソリューションが付属しているのでしょうか。 Linuxは本質的にホームソリューションを意図したものではなく、私は馬鹿のように感じているからです。
そして、これはほんの始まりに過ぎません。時間が経つにつれて、私たちはより多くの抽象化、抽象化、抽象化、自動化、マシン最適化されたがらくたを持ち、あなたは最新のWhatever asaServiceを送り出しているエンティティの慈悲に頼らなければなりません。デバッグできないため、このナンセンス全体が爆発する時点が来るでしょう。あるいは、人間が最初に見たり経験したりすることを意図されていなかった醜いプロトコルを使用して、自分で管理するのはマシンに任されます。貧弱なデザインについて話します。
結論
まず、この記事がお役に立てば幸いです。 Linuxシステムが起動していないほとんどの場合、おそらく/bootまたは/boot/efiに関係する問題に直面しています。その場合は、ある程度自信を持ってログを読んでから、initrdとinitramfsのバグ（上記のリンク）で示したように、コンポーネントが欠落しているか壊れているかどうか、またはシステム構成が間違っているかどうかを確認してください。 、および存在しないリソースを参照しようとしています。私たちの場合、起動が遅い問題のように、パーティションに偽のUUIDを使用したことが原因でした。
これは、システムレベルで解決する必要があります。しかし、私が以前に何度も指摘したように、検証はLinuxでは問題ではありません。開発者は自分のことをして先に進みます。哲学について、全体像について考えることを気にする人は誰もいません。しかし、それはソフトウェアの考え方です：関数->出力。関数の外にあるものを気にせず、関数をカプセル化します。
堅牢なシステムは、実際に既存のデバイスとファイルシステムを調べて、構成に問題があるかどうかを判断しようとします。堅牢なシステムでは、重要なファイルのバックアップがあり、それらを参照しようとします。堅牢なシステムは、いくつかの異なる方法で何かを試み、意味のある方法で失敗する前に物事を相互に関連付けます。 Linuxやその他のシステムには、今日ではそのどれも存在しません。スマートな自己修復メカニズムを発明するよりも、貧しい技術者の大群を維持する方が安価だからです。そして、それがあなたの家であなたに起こった場合、まああなたは単なる担保です。したがって、人々が自由とオープンソースについて話すとき、彼らは間違ったことについて話しているのです。難読化されたソリューションの開発に使用される場合、オープンソースは何に役立ちますか？私は悲しいです。オフ私は泣きました。