Mailinglist Archive: opensuse-bugs (5243 mails)

< Previous Next >
[Bug 811408] parted mklabel gpt_sync_mbr does not boot

Petr Uzel <puzel@xxxxxxxx> changed:

What |Removed |Added
InfoProvider|puzel@xxxxxxxx |agraf@xxxxxxxx

--- Comment #9 from Petr Uzel <puzel@xxxxxxxx> 2013-03-28 13:53:03 UTC ---
(In reply to comment #8)
from what you wrote I don't understand the difference between gptsync and the
suse parted extension.

As you can see in the fdisk outputs, parted's gpt_sync_mbr extension used first
three slots
in the pMBR to mirror first three GPT partitions. 4th slot in pMBR is used
to protect the GPT header itself (it's in sector 1). This 4th entry (type 0xEE)
is also
used to 'recognize' that this is a protective MBR.

On the other hand, gptsync recognized that the first GPT partition contains
some EFI stuff and as
such it is not needed to be visible by legacy tools, so it used the first slot
in pMBR to
1) mask first GPT partition
2) mark the MBR as protective one (with 0xEE type)

There is one more difference in the fdisk outputs from comment #0 and #3: the
sector of the linux root partitions: I assume it is expected (the partitions
simply different length), but better double check this, please.

both are targeting the legacy BIOS and the ability to
boot in that mode if GPT is not supported. I wasn't able to boot with a legacy
bios (the one qemu or VMware provides) if I use sync_mbr label code from

I still don't understand why legacy BIOS refuses to boot from the partition
create with parted gpt_sync_mbr. Is it really the BIOS which fails? Does it
write any error message?
Is there a source code of the BIOS available?

The idea of a consistent mapping is fine but I don't think it makes the legacy
bios implementations happy.

If I knew what exactly those implementation dislike, we could think about
parted to avoid it...

I'm fine if you are saying that the intention of the sync_mbr label in parted
is different from gptsync and that you don't consider this as a bug. In that
case I will follow the gptsync way and will try to get a package into the suse

So far I don't see a bug; switching the "sync algorithm" to the same one as
gptsync uses
does not sound like a good idea to me. I'm afraid that if we did it, it would
only mean that we would break booting on some other platforms.

imho the parted label is also not upstream. so either way, it stays hacky

Yes, this whole gpt_sync_mbr is an ugly and fragile hack which should be
avoided whenever possible.
But since we have to live with that, I'd better avoid touching it.

Thoughts ?

Perhaps Alex has some more ideas/comments...

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >