[Bug 811408] New: parted mklabel gpt_sync_mbr does not boot
https://bugzilla.novell.com/show_bug.cgi?id=811408 https://bugzilla.novell.com/show_bug.cgi?id=811408#c0 Summary: parted mklabel gpt_sync_mbr does not boot Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: puzel@suse.com ReportedBy: ms@suse.com QAContact: qa-bugs@suse.de Found By: --- Blocker: --- I tested the suse extension in parted to create a sync MBR inside the GPT I also tested gptsync (the version with patches from Debian) to double check that it's not something I broke. In short the table gptsync wrote worked the result parted wrote doesn't I tested this inside the kiwi codebase: EXEC [/usr/sbin/parted -s /dev/loop0 mklabel gpt_sync_mbr 2>&1] EXEC [/usr/sbin/parted -s /dev/loop0 unit s mkpart primary 2048 12295 2>&1] ==> vfat EFI jump partition EXEC [/usr/sbin/parted -s /dev/loop0 unit s mkpart primary 12296 421903 2>&1] ==> Linux boot partition EXEC [/usr/sbin/parted -s /dev/loop0 unit s mkpart primary 421904 2498432 2>&1] ==> Linux root partition EXEC [/usr/sbin/parted -s /dev/loop0 unit s set 2 type 0x83 2>&1] EXEC [/usr/sbin/parted -s /dev/loop0 unit s set 3 type 0x83 2>&1] EXEC [/usr/sbin/parted -s /dev/loop0 unit s set 1 boot on 2>&1] EXEC [mkfs.ext3 -i 16384 -F -O resize_inode -N 64960 /dev/mapper/loop0p3 2>&1] ==> rootfs EXEC [mkfs.ext3 -i 16384 -F -O resize_inode -N 64960 -L 'BOOT' /dev/mapper/loop0p2 2>&1] ==> bootfs EXEC [mkdosfs -F 16 -n 'EFI' /dev/mapper/loop0p1 2>&1] ==> efi The partition table written in the MBR looks like this: fdisk -l /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw WARNING: GPT (GUID Partition Table) detected on '/tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw: 1279 MB, 1279262720 bytes 255 heads, 63 sectors/track, 155 cylinders, total 2498560 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xc15921c7 Device Boot Start End Blocks Id System /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw1 * 2048 12295 5124 83 Linux /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw2 12296 421903 204804 83 Linux /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw3 421904 2498432 1038264+ 83 Linux /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw4 1 1 0+ ee GPT Partition table entries are not in disk order changing the boot flag to another partition did not help to make it boot in legacy BIOS mode. When I write a new table via gptsync into the same raw disk I can boot it. I have tested legacy and EFI boot via qemu legacy: qemu-kvm /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw efi qemu-kvm -L /usr/share/qemu-ovmf/bios /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw Thanks -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c1
--- Comment #1 from Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c
Petr Uzel
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c2
Petr Uzel
changing the boot flag to another partition did not help to make it boot in legacy BIOS mode. When I write a new table via gptsync into the same raw disk I can boot it.
Could you please attach 'fdisk -l $dev' of a table written with gptsync? I would like to see what is the difference compared to what parted created. While at it, please also attach 'dd if=$disk bs=512 count=34' of the working and non-working partition table. Thanks! -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c3
--- Comment #3 from Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c4
--- Comment #4 from Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c5
--- Comment #5 from Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c6
Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c7
Petr Uzel
(don't know why you need 34 * 512 bytes though) Because I was typing faster than thinking :) First sector is indeed enough.
The problem here is that hybrid (synced) MBR is a hack [*] and as such it is not covered by any specification (UEFI). So our parted does the synchronization in a certain way (always sync first three GPT partitions unless they are bigger than 2TB [**]) while gptsync does it apparently in other way. The whole idea behind this is to make it possible to boot on architectures where BIOS/bootloader/OS does not understand GPT (basically old versions of grub, some broken BIOSes and Windows older than Vista). This makes me wonder: do you really need the partition table to be hybrid GPT? What would be the problem if it was "normal" GPT? [*] http://www.rodsbooks.com/gdisk/hybrid.html [**] The idea here is to have consistent mapping: first GPT partition maps to first pMBR partition and so on. This is intentional; idea is that tools accessing partitions (grub) do not need to care whether they're referring to pMBR or GPT partitions. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c8
Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c9
Petr Uzel
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.
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c10
Marcus Schaefer
Perhaps Alex has some more ideas/comments...
Alex pointed me to you :) As you are saying you'd better don't touch it I'm more and more convinced it's easier to follow the gptsync way as it's an extra package which I also could remove again. It also fits better into the workflow as it's a single step and does not interact with the primary partition step. imho both solutions are hacky so it's up to the Studio people to speak up if we really need this @Cornelius: I hope this report provides enough information for you to get an impression. if not let's talk in person. if yes what's your opinion about hybrid EFI/legacy-BIOS images now ? Thanks -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c11
Cornelius Schumacher
From a user's point of view it would be bad if an image downloaded from Studio would not boot on the hardware, because there is a mismatch of what the image expects and what the hardware provides (or the virtualized hardware).
That's where the request for the hybrid boot came from. From what I understand this might create additional problems, though, so it might actually not solve the problem. The remaining questions for me are: * When building images in legacy mode, for how many people it would not work out of the box? * When building images in uefi only mode, for how many people it would not work out of the box? * When building images in hybrid mode, for how many people it would not work out of the box? How do our installation media do this? They also need to boot, do we provide different media for different hardware? -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c12
--- Comment #12 from Jiri Srain
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c13
Petr Uzel
Perhaps a stupid question, anyway: Does uEFI really need GPT partition table to boot?
And vice versa: do any of the expected target platforms really have issues with booting from (non-hybrid) GPT? -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c14
--- Comment #14 from Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c15
Alexander Graf
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c16
Petr Uzel
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c17
--- Comment #17 from Petr Uzel
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c18
Petr Uzel
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c
Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c19
Marcus Schaefer
https://bugzilla.novell.com/show_bug.cgi?id=811408
https://bugzilla.novell.com/show_bug.cgi?id=811408#c20
--- Comment #20 from Marcus Schaefer
http://bugzilla.novell.com/show_bug.cgi?id=811408
ralph roth
http://bugzilla.novell.com/show_bug.cgi?id=811408
Petr Uzel
http://bugzilla.novell.com/show_bug.cgi?id=811408
Sebastian Parschauer
http://bugzilla.novell.com/show_bug.cgi?id=811408
http://bugzilla.novell.com/show_bug.cgi?id=811408#c24
Sebastian Parschauer
participants (1)
-
bugzilla_noreply@novell.com