OK. Became a bit long for comment. This is not directly related, but only to explain the
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
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:
a [DISK NUMBER]
# 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
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
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
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:
Backup current MBR:
dd if=/dev/sda of=/path/mbr-backup bs=512 count=1
Create image from
Code TEST below, saved to file
as -o test.o test.s
objcopy -O binary test.o test.img
test.img file to MBR:
dd if=test.img of=/dev/sda bs=512 count=1
.globl start, _start
movb $0x48, %al
movb $0x65, %al
movb $0x6c, %al
movb $0x6c, %al
movb $0x6f, %al
movb $0x21, %al
movb $0x0e, %ah
. = _start + 0x1fe
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.