web-dev-qa-db-ja.com

Arch Linuxのインストール後、「起動可能なデバイスが見つかりません」というテキストが表示されるだけです

Arch Linuxをインストールしようとしています。インストール後、BIOS画面が表示され、その後、「起動可能なデバイスが見つかりません」というメッセージが表示されます。

シナリオ全体を何度か再試行しましたが、それでも同じメッセージが表示されるだけです...

インストール時には、ArchLinux wikiの非公式の初心者向けガイドに従っています。

これが私がしたことです：

まず、ハードドライブ（ワイプの前にWindows Vistaがインストールされていたもの）をワイプし、gdiskを使用してGPTをそこに配置しました。次に、いくつかのパーティションを設定しました。パーティションは次のようになります（partedの出力）。

Model: ATA ST9160310AS (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system     Name                 Flags
 1      1049kB  2097kB  1049kB                  BIOS boot partition  bios_grub
 2      2097kB  107MB   105MB   ext2            Linux filesystem     
 3      107MB   21.6GB  21.5GB  ext4            Linux filesystem     
 4      21.6GB  30.2GB  8590MB  linux-swap(v1)  Linux swap           
 5      30.2GB  160GB   130GB   ext4            Linux filesystem

次に、ルートパーティション（sda2）を/ mntにマウントし、その後、ブートとホームパーティション（sda3とsda5）を/ mnt/bootと/ mnt/homeにマウントし、最後にフォーマットしてスワップパーティション（sda4）をアクティブにしました。

次に、基本システムのインストールを開始しました。ミラーを選択した後、baseとbase-develをインストールしました。

インストールの最後に、fstabを生成しました。

次に、/ mntにchrootし、いくつかのロケールをセットアップし、ルートパスワードを設定してから、Grub2をインストールして構成します。説明どおりに ここにあります 。

最後に、chroot環境を終了し、パーティションをアンマウントして再起動しました。残りはわかっています...起動可能なデバイスが見つからないというメッセージが表示されただけです。

ちなみに、 this コンピュータにインストールしてみました。

arch-linuxbootsystem-installationgrub2
8
brgr

私は同じ問題を抱えていて、検索すると、ルート/パーティションのuuidがgrub.cfgで間違っていることがわかりました：

  1. ライブArchLinuxメディアから起動
  2. mount /dev/sdxx /mnt（sdxxはルートパーティションです）
  3. Arch-chroot /mnt
  4. grub-mkconfig -o /boot/grub/grub.cfg
  5. grub-install

仕上げます。

4
amirhossein sobhani

OK。コメントが少し長くなりました。これは直接関係はありませんが、aa55コメントを説明するためだけのものです。

Basic Input/Output System（BIOS）が起動すると、Power-On Self Test（POST）を実行し、ハードウェアなどを確認します。次に、両方が起動可能なデバイスを探しますCMOS（BIOSでの設定– Complementary Metal Oxide Semiconductorで指定される）の順序でアクティブになります）0xaa55のあるディスクが見つかった場合オフセット510で、ディスクのそのセクション（セクター1）をメモリに読み込み、そのコードのアドレス0x00000に制御を任せます。これらの512バイトはマスターブートレコード（MBR）です。

そのコード、この場合は "GRUB-boot"で、これらの512のさまざまなバイトをチェックし、BIOSにさまざまな情報を要求します。このプロセスでは、残りのGRUB=がどのディスクにあるかを特定し、ディスクのそのセクションをメモリにロードします。その後、コードのその部分が制御を取得します。カーネルなどをマウントし、制御をそのままにします。

GPTを使用すると、画像GRUB MBR内からのロードは、bios_grubパーティションにあります-所有していて、十分に大きいので、それがどのように間違っているのかわかりません。

On "No bootable device found。"メッセージがBIOSから– MBRが0xaa55で終了し、MBRが破損している場合、通常、他のエラーが発生します-またはシステムがハングするだけです。

とにかく。これは奇妙です。 "boot"とマークされたパーティションがないことに気づきました。正しいGPTを使用しますが、禁止されていますが、フラグを1つ設定することもできます。ブートとしてsda5。 Gparted： （（g）partedもGPTを変更したくないことを学習しました）fdisk：

# Toggle bootable:
a [DISK NUMBER]
# Check (could be an asterisk marking boot partition):
p
# Save changes:
w

BIOSが必要以上のことをしていて、MBRのパーティションテーブルをチェックしている可能性があります。

編集–コメントを更新：

AFAIKは実際には使用されないので、どれを設定してもかまいません。重要なことは、誰も"bootable device found"を言わないということですが、それらは満たされなければなりません。 sda1は、従来の意味でのブートパーティションではなく、GRUBブートファイル用のスペースです。

従来のパーティションレイアウト（GPTではない）では、通常、次のようなものがあります。

0x000 [Master Boot Record] <- Partition table say Partition 2 is active
                                                       |
0x200 [ GRUB module 1    ] <- core.img from GRUB       |
                                                       |
0x400 [ Partition 1 Swap ]                             |
      |                  |                             |
      |                  |                             |
      |__________________|                             |
                                                       |
0x... [ Partition 2 ext4 ]                             |
      | * Active         | <- AKA boot ----------------+
      |                  |
      |__________________|

0x... [ Partition 3 ext4 ]
      |                  |
      |                  |
      |__________________|

つまり、3つのパーティションになります。 HDD iのオフセット0x400より前のすべてrawバイト –パーティションの一部ではないなど。

ここでbootパーティションはPartition 2です。これはLinuxのシステムパーティションです。

GRUBモジュール1ファイルは、MBRの直後で最初のパーティションの前にあります。どこにでも置くことができますが、通常は同じディスク上にあり、MBRディスクのオフセット512にあります。

また、GPTシステムでは– GPTはディスクのそのセクションを使用するため、これらのGRUBファイルを別の場所に移動する必要があります。これがbios_grubの目的です。core.imgを=に保存するにはGRUB 2。

"set boot flag"は単に暗闇の中でのショットであり、それが機能すれば驚くでしょう。しかし、どこかで始まった。

EDIT2：

これを行うとどうなりますか？

  1. 現在のMBRをバックアップ：

      dd if=/dev/sda of=/path/mbr-backup bs=512 count=1

  2. 以下のCode TESTから画像を作成し、ファイルtest.sに保存します。

    as -o test.o test.s
objcopy -O binary test.o test.img

  3. test.imgファイルをMBRにコピーします。

    dd if=test.img of=/dev/sda bs=512 count=1

  4. Boot

コードTEST：

    .file "test.s"
    .text
    .code16
.globl start, _start
start:
_start:
    jmp go
    nop
go:
    movb $0x48, %al
    call prnt_chr
    movb $0x65, %al
    call prnt_chr
    movb $0x6c, %al
    call prnt_chr
    movb $0x6c, %al
    call prnt_chr
    movb $0x6f, %al
    call prnt_chr
    movb $0x21, %al
    call prnt_chr
    ret
prnt_chr:
    movb $0x0e, %ah
    int  $0x10
    ret
    . = _start + 0x1fe 
    .Word   0xaa55

MBRを復元するには：

dd if=/path/mbr-backup of=/dev/sda bs=512 count=1

これは単に「こんにちは！」と出力するはずです。 MBRがロードされている場合は画面に戻り、停止します。 qemu-system-x86_64、qemu-system-i386、VirtualBox、静止したIntel PC 32および64ビットで実行してテストしました。

2
Runium

私は間違っていて、正しいことをしていないかもしれませんが、最初はあなたと同じ問題を抱えていました。しばらくして、私は here that GRUB has to have a 512MB EFI partition, with a vfat filesystemを見つけました。これは、システムをEFIとしてインストールする場合です。

EFIの場合、vfatファイルシステムとブートフラグが有効になっている小さな（512 MiB以下）パーティションを探しています。

これは、パーティションを作成するときにこの事実を予測する必要があることを意味します。そうする間（たとえばcfdiskを使用）、/ dev/sdX1をEFIとして設定し、それをFAT32ファイルシステムにフォーマットする必要があります（インストールプロセス中にmkfs.vfat -F32 /dev/sdX1コマンドを使用）。その場合のみ、grubが認識されます。

Syslinuxはext2パーティションでも動作すると思います。

ArchをEFIとしてインストールしない場合は、おそらくwikiで確認できます。この場合、これ以上のサポートはできません。

私はこの投稿が古いことを知っていますが、これは誰かがここに来て解決策を見つけたいと思っている場合のためです。

0
Razakhel