web-dev-qa-db-ja.com

BIOSモードでUbuntuをインストールしましたが、BIOSにアクセスできなくなりました

少し待ってから、これをトピック外としてフラグを立ててください。 Ubuntuをインストールした直後にすべてが発生したため、これがUbuntuに関連しているとは思えません。

これで、私は何が起こっているのか説明し続けると言いました：

Ubuntuの最新バージョンをダウンロードしてインストールしました。この方法を好み、インストールプロセスを完了したため、BIOSモードが必要でした。次に、GNOMEをインストールして再起動しました。このすべての後、BIOSにアクセスできなくなりました。

これは初めてのことではありません。過去に発生し、セカンダリHDDを使用してブート修復でブートパーティションを切り替える問題を解決しましたが、そのドライブにWindowsパーティションがないため、これ以上できません。

これは私のドライブです：

Disk /dev/sdb: 119,2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcaa3841c

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1  *     2048 250068991 250066944 119,2G 83 Linux

ブート修復を試みたとき、プロセスの最後に、grubが正常に機能するようにパーティションリストの先頭に500MBのパーティションを作成する必要があると言われましたが、もう1つの問題があります。

GPartedは動作を停止しました。これを起動しようとするとエラーになります：

Created symlink /run/systemd/system/-.mount → /dev/null.
Created symlink /run/systemd/system/mnt-Archive.mount → /dev/null.
Created symlink /run/systemd/system/mnt-Linux\x20Games.mount → /dev/null.
Created symlink /run/systemd/system/run-user-1000.mount → /dev/null.
Created symlink /run/systemd/system/tmp.mount → /dev/null.
/usr/sbin/gpartedbin: error while loading shared libraries: libgtkmm-2.4.so.1: cannot open shared object file: No such file or directory
Removed /run/systemd/system/-.mount.
Removed /run/systemd/system/mnt-Archive.mount.
Removed /run/systemd/system/mnt-Linux\x20Games.mount.
Removed /run/systemd/system/run-user-1000.mount.
Removed /run/systemd/system/tmp.mount.

それに言及したい：

  • はい、正しいボタンを使用してBIOSを入力していると確信しています
  • bIOSスプラッシュ画面はありません
  • いいえ、迷惑メールを送信しても何も起こりません DEL BIOSを入力するキー
  • はい、キーは正常に動作します
  • はい、私はすべてのドライブを抜こうとしました
  • はいCMOSをリセットしようとしました
  • はい、OSをBIOSモードでインストールし、ターミナルで確認しました。

これは、boot-repairからの出力です

Boot successfully repaired...

これは、正しくブートするためにパーティションを作成する必要があることを示すメッセージアラートです。

[現在使用中のOS-Ubuntu 17.04]のブートファイルは、ディスクの先頭からはほど遠いものです。 BIOSがそれらを検出しない場合があります。 /bootパーティション（EXT4、> 200MB、ディスクの開始）を作成した後、再試行することができます。これは、gPartedなどのツールを介して実行できます。次に、[Boot Repair]の[Separate/boot partition：]オプションでこのパーティションを選択します。 （ https://help.ubuntu.com/community/BootPartition ）

bootgrub2partitioninguefi
4
1500822802299

BIOSからEFIへの切り替え以来、EFIがセットアップユーティリティの起動を拒否するという報告がかなりあります。パターンを認識できるほど十分にこれらを追跡していません（たとえば、特定のファームウェアベンダーやマザーボード/コンピューターブランドは他のものよりも多くの問題を抱えていますか？）が、これは間違いなくOSのバグではなくファームウェアのバグとして認められます。ただし、OSがブート順序などのファームウェア設定に加えた変更によってトリガーされる場合があります。あなたの場合の異常なことは、BIOS/CSM /レガシモードのインストールを行ったことです。つまり、OSのインストールはそのような変更を行うべきではありません。私の推測では、ファームウェア自体のEFIモードからBIOSモードブートへの変更により、バグが顕在化したと考えられます。または、他のファームウェア設定を変更した可能性があります。

この問題を回避するには、次のようないくつかの方法があります。

  • ハードディスクを取り外して、コンピューターを起動できます。通常、これによりセットアップユーティリティが起動されます。
  • UbuntuをEFIモードで起動した場合（たとえば、この方法でインストーラーが起動した場合）、シェルでSudo systemctl reboot --firmware-setupと入力すると、ファームウェアセットアップユーティリティが再起動します。
  • 一部のEFIモード（BIOSモードではない）ブートマネージャーは、ファームウェアセットアップユーティリティを起動するオプションを提供します。 GRUBにはこの機能がありますが、Ubuntuでデフォルトで有効になっているかどうかはわかりません。BIOSモードバージョンを使用しているので、この点は重要ではありません。あなたはすることができます/、しかし、USBフラッシュドライブまたはCD-Rで私の rEFIndブートマネージャ を使用します（私がするページに両方のダウンロードイメージがありますリンクしました）。このオプションは、（小さい）アイコンの2行目に表示されます。必要に応じて、rEFIndを使用して通常のインストールをEFIモードで起動し、systemctlを使用することもできます。

ブート修復は、ファームウェア before GRUB（またはUbuntuが提供するその他のもの）の問題が原因でコンピューターを制御するため、問題を解決する可能性が非常に低いことに注意してください。 。

セットアップユーティリティを開いたら、ファームウェアをデフォルトにリセットするオプションを使用すると問題が解決する可能性がありますが、それを約束することはできません。構成を考えると、CSMをオンに戻すか、ディスクにEFIモードブートローダーを追加して、再度ブートする必要があります。いずれかの手順を実行すると、少なくとも問題が再現されるリスクがあります。

これはファームウェアのバグであるため、メーカーからのアップデートを探すことは価値があります。アップデートがない場合は、バグを報告することをお勧めします。製造元は、バグの存在を知らないとバグを修正できません。

このケースは、EFIモードで起動する利点の1つを示していることに注意してください。ブートマネージャまたはOSからファームウェアセットアップユーティリティにアクセスする方法があります。 EFIモードブートは通常、少し高速です。大規模（2TiB以上）のディスクでは制限が少なく、セキュアブートをサポートし、最新のハードウェアではネイティブブートモードです（以下に説明するように、混乱を引き起こす可能性が低いことを意味します- 私のこのページ ）であり、BIOSモードでの起動よりも小さな利点がいくつかあります。これらの理由から、BIOSモードのインストールを行う説得力のある理由がない限り、新しいハードウェアにEFIモードでインストールすることをお勧めします。

ディスクの先頭から遠くにあるブートファイルに関する苦情は無視してかまいません。これはBIOSで繰り返し発生する問題であり、「遠い」という定義は時間とともに変化します。ディスクは119.2 GiBであり、/dev/sdbではなく/dev/sdaの出力を表示したという警告があるため、/dev/sdaが大きく、そこにブートローダーがインストールされている場合は、問題。最近のほとんどのコンピューターでは、BIOS（またはEFIのCSM）が最大2 TiBを読み取ることができるため、それより小さいディスクであれば問題ありません。

あなたのGPartedの問題は他の何かとは無関係だと思いますが、問題を抱えています。ディスクが故障していることを示している可能性がありますが、特にコンピュータがハングしたり完全にクラッシュした場合は、ランダムなファイルシステム破損の可能性が高くなります。これを調べることを強くお勧めしますが、これはあなたの主な問題とは別の問題であると思われるため、ここではアドバイスしません。

7
Rod Smith

私はこのような問題を解決しました：

  1. PCの電源を切ります。
  2. 電源ケーブルを抜きます。
  3. ビデオカードとラムを抜く
  4. プラグを抜く モボ電池
  5. ドライバーを使用してCMOSをリセットします
  6. 電源ボタンを押して、マザーボードの充電を解除します
  7. Moboバッテリー、電源ケーブル、ビデオケーブルを（マザーボードに）再接続します
  8. スロット1にはラムを1本だけ使用します
  9. PCの電源を入れ、BIOSスプラッシュ画面を待ちます
  10. BIOSが表示されたら、PCの電源を切り、すべてを再度接続してBIOSにアクセスします
  11. BIOSが1から繰り返し表示されない場合、すべてを差し戻す前に15〜20分待機します

SSDに初めてLinuxをインストールしたとき、それは確かにパーティションの問題でした。どういうわけか、Ubuntuは、レガシー（BIOS）モードでインストールしてもUEFIモードであると判断したため、grubでブートパーティションを探していました。最初にLinuxをインストールしたときに「すべてを削除してインストール」をクリックしても、インストーラーはUbuntuの追加パーティションを作成しませんでした（これは実際にレガシーモードでインストールドライブを起動したためです！）。

ドライブのバックアップを作成し、クリーンインストールを行うことをお勧めします。

将来のエラーを防ぐために、UEFIモードまたはレガシー（BIOS）モードでインストールするかどうかに関係なく、カスタムインストールモードを使用します。

  1. 以前のすべてのパーティションを削除して新しいパーティションテーブルを作成する
  2. 「EFIパーティション」としてフラグが設定された追加のプライマリ500mbパーティション（空き領域から）を作成
  3. Ext4プライマリパーティションとしてフォーマットし、/をマウントポイントとして使用して、OSにすべての空き領域を割り当てます（スワップ領域用により多くの空き領域を残したい場合）。
  4. 500mb efiパーティションを作成したドライブをUbuntuがgrubをインストールできるパスとして設定します（例：ドライブが/ dev/sdaで、efiパーティションが/ dev/sda2の場合、パーティションとして/ dev/sdaを選択します！）
  5. リストから作成した最大のパーティションをクリックし、最後に[インストール]をクリックします。
0
1500822802299