I've been trying to install Arch Linux. After the installation, it shows the BIOS screen and after that there just comes a message that says "No bootable device found".

I have retried the whole scenario now some times, still it just shows the same message...

At installing, I have followed the Unofficial Beginner's Guide from the ArchLinux wiki.

Here is what I did:

First of all, I wiped the hard drive (on which before the wipe was Windows Vista installed) and put GPT on it by using gdisk. Then I set up some partitions, which now look as the following (output of 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     

Then I mounted the root partition (sda2) to /mnt, after that also the boot and the home partition (sda3 and sda5) to /mnt/boot and /mnt/home and at the end formatted and activated the swap partition (sda4).

Now I began installing the base system. After selecting the mirrors, I installed base and base-devel.

At the end of the install I generated an fstab.

Then I finally chrooted into /mnt, set up some Locales, set a root password and then installed and configured Grub2, exactly as it is explained here.

At the end I exited from the chroot environment, unmounted the partitions and rebooted. You know the rest... It just showed the message that it coudn't find any bootable devices.

By the way, I tried to install it on this computer.

  • 1
    Is the output of dd if=/dev/sda bs=1 skip=510 count=2 2>&- | hexdump (or xxd instead of hexdump) equal to 55aa? If not the MBR is bad.
    – Runium
    Apr 1, 2013 at 16:36
  • The output was the following: 0000000 aa55 0000002 If the MBR is bad, how you say, is there something I can do to make it good again?
    – brgr
    Apr 1, 2013 at 18:00
  • No. That looks OK. (0000000 and 0000002 are offset) aa55 is correct MBR signature (55aa on little endian system).
    – Runium
    Apr 1, 2013 at 18:06
  • @Sukminder, I may be missing something, but the OP said he used GPT, not MBR.
    – JMCF125
    Feb 25, 2014 at 20:31
  • 1
    @JMCF125: GPT also uses MBR. Instead of a full partition table it holds one partition of maximum size. The GPT data usually start at offset 512 (After MBR). upload.wikimedia.org/wikipedia/commons/0/07/… MBR holds stage one of boot loading. Logical Block Address 0 -> Legacy MBR.
    – Runium
    Feb 26, 2014 at 10:07

4 Answers 4


I had same problem and by searching I found that uuid of root / partition is wrong in grub.cfg you can try this:

  1. Boot from live archlinux media
  2. mount /dev/sdxx /mnt (sdxx is your root partition)
  3. arch-chroot /mnt
  4. grub-mkconfig -o /boot/grub/grub.cfg
  5. grub-install


  • I have done all this already at the first try. However, I tried to do it again as you explained and got an error on grub-install: it said there would be no Bios boot partition on /dev/sda, while there actually is one.
    – brgr
    Apr 2, 2013 at 8:59

OK. Became a bit long for comment. This is not directly related, but only to explain the aa55 comment.

When the Basic Input/Output System (BIOS) starts it does a Power-On Self Test (POST), check hardware etc. Then it looks for devices that are both bootable and active by order given by CMOS (Your configuration in BIOS – which in turn is given by a Complementary Metal Oxide Semiconductor). When it finds a disk that has 0xaa55 at offset 510 it loads that section of the disk, (sector 1), into memory and leave control to it on address 0x00000 of that code. Those 512 bytes are the Master Boot Record (MBR).

That code, in this case "GRUB - boot", check various bytes of these 512 in addition to ask BIOS for various information. In this process it locates which disk has rest of GRUB and load that section of the disk into memory – then that part of code gets control. That one mounts kernel etc. and leaves control to that.

Using GPT the image GRUB loads from within MBR is located in the bios_grub partition, - which you have, and is big enough, etc., so can't see how that could be wrong.

On "No bootable device found." message from BIOS – one can have the case that MBR of boot disk is corrupted, if MBR ends in 0xaa55 and the MBR is corrupt one usually get an other error - or the system simply hangs.

Anyhow. This is weird. I notice you have no partition marked as "boot". Using GPT that is correct, - but, though it is forbidden, you could try to flag one e.g. sda5 as boot. In gparted: (learned that (g)parted also alter GPT which whan do not want)fdisk :

# Toggle bootable:
# Check (could be an asterisk marking boot partition):
# Save changes:

It could be that your BIOS is doing more then it should and checking the partition table in MBR.

EDIT – Update to comment:

AFAIK it doesn't matter which one you set as it is not actually used. Point being, for whom ever say no "bootable device found", they shall be satisfied. The sda1 is not a boot partition in the traditional sense, but space for GRUB boot files.

In a traditional partition layout (not GPT) you have typically something like:

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 ]
      |                  |
      |                  |

That would mean 3 partitions. Everything before offset 0x400 on the HDD i raw bytes – as in not part of any partition etc.

Here boot partition is Partition 2 which is system partition with linux.

The GRUB module 1 files reside just after MBR and before first partition. It can reside anywhere, but usually on same disk and at offset 512 of MBR disk.

Also on a GPT system – GPT uses that section of the disk for itself, thus one have to move those GRUB files to another location. That is what the bios_grub is for - to store core.img for GRUB 2.

The "set boot flag" is merely a shot in the dark, - and would be surprised if it works. But one has start somewhere.


What if you do this:

  1. Backup current MBR:

      dd if=/dev/sda of=/path/mbr-backup bs=512 count=1
  2. Create image from Code TEST below, saved to file test.s by:

    as -o test.o test.s
    objcopy -O binary test.o test.img
  3. Copy the test.img file to MBR:

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

Code TEST:

    .file "test.s"
.globl start, _start
    jmp 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
    movb $0x0e, %ah
    int  $0x10
    . = _start + 0x1fe 
    .word   0xaa55

To restore MBR do:

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

This should simply print "Hello!" to the screen if the MBR was loaded, then stop. Tested it by running under qemu-system-x86_64, qemu-system-i386, VirtualBox, stationary Intel PC 32 and 64 bit.

  • First of all thank you for your help. Could you please explain to me why I should set sda5 as boot partition. Isn't sda1 a better option to set as boot partition, as it is here just for that?
    – brgr
    Apr 1, 2013 at 19:22
  • Ok, I've tried this now, but sadly with the same result...
    – brgr
    Apr 1, 2013 at 20:09
  • What should it have listed?
    – brgr
    Apr 2, 2013 at 8:44
  • Ok, I have now also tried your second advice, still with no result :(
    – brgr
    Apr 2, 2013 at 9:50
  • Yes it is listed.
    – brgr
    Apr 2, 2013 at 17:47

I may be wrong and haven't done the right thing, but I've had the same problem as you at first. After a while, I've found here that GRUB has to have a 512MB EFI partition, with a vfat filesystem. This is in case you install your system as EFI:

For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the boot flag enabled.

This means that you have to anticipate this fact when creating your partitions. While doing so (with cfdisk for example), you'll have to set your /dev/sdX1 as EFI, then format it to a FAT32 filesystem (with the command mkfs.vfat -F32 /dev/sdX1 during the installation process). Only then grub will be recognized.

I assume Syslinux can work with your ext2 partition though, if you feel like trying it.

If you don't install Arch as EFI, you probably can check on the wiki whatsoever. I'm not able to help any further in this case.

I know this post is old, but this is in case someone comes here and hopes to find a solution.

  • 1
    Answering old posts is fine and even encouraged. However, please edit your answer and highlight the part that actually answers. What was the solution you found? What statement? Providing a link to another page that might contain an answer is not an answer. Instead, please quote the relevant section directly in your answer so all information is contained here.
    – terdon
    Feb 19, 2016 at 11:59
  • The answer was there, just quoted from the link I provided, not highlighted though. Thanks for pointing that out. Please tell me if you feel like something else is necessary.
    – Razakhel
    Feb 19, 2016 at 14:44
  • Real quote added now. And corrected the 512MB (at least), it was the other way around...
    – Razakhel
    Feb 19, 2016 at 15:16

This can be caused by some buggy UEFI implementations.

A workaround that fixed it for me (when nothing else did) was to use the --removable option with grub-install, as in:

# grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB --removable

I also re-ran grub-mkconfig -o /boot/grub/grub.cfg before rebooting. Not sure if that's necessary but it didn't hurt.

Source: Arch BBS: [SOLVED] No bootable device on uefi boot

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .