| 1 |
2014-04-19 12:34 GMT-03:00 Tom H <tomh0665@×××××.com>: |
| 2 |
> On Sun, Apr 13, 2014 at 11:08 AM, Jonathan Callen <jcallen@g.o> wrote: |
| 3 |
>> On 04/12/2014 08:19 AM, Tom H wrote: |
| 4 |
>>> |
| 5 |
>>> You can have a gpt partition table with BIOS but if you want to boot from that disk, you need a |
| 6 |
>>> bios_boot partition (which the OP has) for grub to embed a binary. |
| 7 |
>> |
| 8 |
>> Technically, I don't think you need a bios_boot partition if you leave enough space between the |
| 9 |
>> partition table and the first partition (I don't recall having a problem when my first partition |
| 10 |
>> started 2048 sectors (1MiB) into the disk). |
| 11 |
> |
| 12 |
> You're correct if you're talking about an msdos-labelled disk with |
| 13 |
> bios firmware because having the first partition start on 2048 as it |
| 14 |
> does now rather on 63 as it used to because the post-mbr gap will |
| 15 |
> always be big enough for grub to embed core.img. |
| 16 |
> |
| 17 |
> But on a gpt-labelled disk with bios firmware, there's a <something> |
| 18 |
> mbr into which grub embeds boot.img but there's no post-mbr gap. So a |
| 19 |
> bios_boot partition's needed in order to embed core.img (IIRC parted |
| 20 |
> calls it grub_bios or bios_grub). |
| 21 |
> |
| 22 |
|
| 23 |
As I could not fix it, I solved it making backup, formating with |
| 24 |
ms_dos table, and restoring backup. :P |
Archives