https://bugzilla.novell.com/show_bug.cgi?id=811408 https://bugzilla.novell.com/show_bug.cgi?id=811408#c9 Petr Uzel <puzel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|puzel@suse.com |agraf@suse.com --- Comment #9 from Petr Uzel <puzel@suse.com> 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 end sector of the linux root partitions: I assume it is expected (the partitions has 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 parted.
I still don't understand why legacy BIOS refuses to boot from the partition table 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 patching 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 distro.
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: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.