[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 <ms@suse.com> 2013-03-25 14:52:33 UTC --- Created an attachment (id=531528) --> (http://bugzilla.novell.com/attachment.cgi?id=531528) patch for kiwi master to reproduce the problem the attached patch applies to the kiwi master branch and can be used to build an image with parted's gpt_sync_mbr support. - apply the patch - edit /usr/share/kiwi/image/suse-12.3-JeOS/config.xml + set firmware="efi" syncMBR="true" in the vmx <type> sections - build with: kiwi --build suse-12.3-JeOS --type vmx -- 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#c Petr Uzel <puzel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High Status|NEW |ASSIGNED -- 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#c2 Petr Uzel <puzel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |ms@suse.com --- Comment #2 from Petr Uzel <puzel@suse.com> 2013-03-27 14:34:16 UTC --- (In reply to comment #0) I don't see any problem with the pMBR (from the fdisk output).
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 <ms@suse.com> 2013-03-27 15:09:37 UTC --- ok here is fdisk information from a working image with gptsync 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: 1280 MB, 1280311296 bytes 255 heads, 63 sectors/track, 155 cylinders, total 2500608 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: 0x5f9a2a45 Device Boot Start End Blocks Id System /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw1 1 12295 6147+ ee GPT /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 2500480 1039288+ 83 Linux -- 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#c4 --- Comment #4 from Marcus Schaefer <ms@suse.com> 2013-03-27 15:13:01 UTC --- Created an attachment (id=532169) --> (http://bugzilla.novell.com/attachment.cgi?id=532169) dd if=... of=/tmp/mbr-gptsync bs=512 count=34 this is the mbr and some more data from a working image with gptsync (don't know why you need 34 * 512 bytes though) -- 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#c5 --- Comment #5 from Marcus Schaefer <ms@suse.com> 2013-03-27 15:18:25 UTC --- Created an attachment (id=532170) --> (http://bugzilla.novell.com/attachment.cgi?id=532170) dd if=... of=/tmp/mbr-parted bs=512 count=34 and here is the mbr plus some data from a table written with parted and the label type gpt_sync_mbr. This one did not boot -- 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#c6 Marcus Schaefer <ms@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|ms@suse.com | --- Comment #6 from Marcus Schaefer <ms@suse.com> 2013-03-27 15:20:03 UTC --- if you need more, just let me know -- 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#c7 Petr Uzel <puzel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |ms@suse.com --- Comment #7 from Petr Uzel <puzel@suse.com> 2013-03-27 16:49:40 UTC --- Thanks for the data. (In reply to comment #4)
(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 <ms@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|ms@suse.com |puzel@suse.com --- Comment #8 from Marcus Schaefer <ms@suse.com> 2013-03-27 20:28:34 UTC --- I know that the UEFI spec doesn't allow an MBR to be embedded in the GPT and that there will be firmware which will refuse to boot such a thing in UEFI mode if an MBR is detected. The reason why I'd like to be able to create hybrid images is that SuSE Studio requested it. So there will be an option which allows the user to create EFI hybrid images also mentioning the risk. in kiwi speak there is the syncMBR="true|false" attribute available. With gptsync I was able to implement that. Thus kiwi supports: - legacy only - uefi only - legacy/uefi hybrid (risky) from what you wrote I don't understand the difference between gptsync and the suse parted extension. 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. The idea of a consistent mapping is fine but I don't think it makes the legacy bios implementations happy. 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. imho the parted label is also not upstream. so either way, it stays hacky Thoughts ? -- 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#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.
https://bugzilla.novell.com/show_bug.cgi?id=811408 https://bugzilla.novell.com/show_bug.cgi?id=811408#c10 Marcus Schaefer <ms@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|agraf@suse.com |cschum@suse.com --- Comment #10 from Marcus Schaefer <ms@suse.com> 2013-03-28 14:54:28 UTC --- Thanks for the explanation. when I wrote that I did no understand the differences then I meant more why the "design" of the table layout differs between the tools although they are targeting the same goal. But you explained that as well my concern is that I can't make it boot with a legacy bios which is no problem when using gptsync. As I wrote a simple qemu smoke test outlined that it does not boot and I also provided the relevant information to you about this. The system try to boot from the disk but hangs at that point forever this means it is seen as a bootable disk but it can't boot from it for some reason. I think it would be easy for you to reproduce this with plain qemu
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 <cschum@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED CC| |cschum@suse.com InfoProvider|cschum@suse.com | --- Comment #11 from Cornelius Schumacher <cschum@suse.com> 2013-03-28 16:48:38 UTC ---
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 <jsrain@suse.com> 2013-03-29 10:22:39 UTC --- Installation media (DVDs) are different - they contain one filesystem spread through the whole media. No partition table. Perhaps a stupid question, anyway: Does uEFI really need GPT partition table to boot? -- 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#c13 Petr Uzel <puzel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |cschum@suse.com --- Comment #13 from Petr Uzel <puzel@suse.com> 2013-03-29 10:39:17 UTC --- (In reply to comment #12)
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 <ms@suse.com> 2013-03-29 11:28:04 UTC --- I will come back to the other questions after my vacation just one point to clarify. the installation iso's are not affected here. On an ISO image there is no GPT and our iso's are created in a way that they can boot via EFI and via isolinux. So this is all about disk images were a legacy bios needs an MBR to see it as a bootable disk and EFI needs a GPT to see it as a bootable disk more later Happy Easter -- 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#c15 Alexander Graf <agraf@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |agraf@suse.com --- Comment #15 from Alexander Graf <agraf@suse.com> 2013-03-29 15:30:56 UTC --- The source code of QEMU's BIOS is of course available. You can find it here: http://www.seabios.org/SeaBIOS As for booting, any actual BIOS shouldn't care about the GPT or any syncing that happens, or the protective partition. So I'd actually assume the issue you're facing here is a lot easier than that. The way BIOS boots is usually by reading executable code from the disk's sector 0. The code in there then tries to find the first active MBR partition, reads the first sector from that and executes it again. Does your generated image contain a valid MBR boot sector? It should be quite easy to check with hexdump -C on the image. -- 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#c16 Petr Uzel <puzel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|cschum@suse.com | --- Comment #16 from Petr Uzel <puzel@suse.com> 2013-03-29 15:44:07 UTC --- Bingo, thanks! I'll check what I can do about it. -- 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#c17 --- Comment #17 from Petr Uzel <puzel@suse.com> 2013-03-29 16:39:53 UTC --- Created an attachment (id=532672) --> (http://bugzilla.novell.com/attachment.cgi?id=532672) Write boot code to hybrid pMBR -- 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#c18 Petr Uzel <puzel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |ms@suse.com --- Comment #18 from Petr Uzel <puzel@suse.com> 2013-03-29 16:43:26 UTC --- With patch from previous comments, parted writes generic bootcode to the hybrid pMBR. This is the same bootcode which parted writes to standard MBR, and is different from what gptsync uses (gptsync uses bootcode from syslinux), but AFAIU those two should be functionally equal. Marcus, could you please retest once again, this time with parted package from obs://home:puzel:branches:Base:System/parted ? Make sure the boot partition in hybrid pMBR has boot flag on. 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#c Marcus Schaefer <ms@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|parted mklabel gpt_sync_mbr |kiwi: parted mklabel |does not boot |gpt_sync_mbr does not boot -- 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#c19 Marcus Schaefer <ms@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|ms@suse.com | --- Comment #19 from Marcus Schaefer <ms@suse.com> 2013-04-15 15:10:42 UTC --- Hmm, sorry no difference to the old behavior: fdisk -l /tmp/mytest/LimeJeOS-openSUSE-12.3.x86_64-1.12.3.raw 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 2494336 1036216+ 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 I tested with parted from here: http://download.opensuse.org/repositories/home:/puzel:/branches:/Base:/Syste... rpm -q parted: parted-2.4-102.1.x86_64 boot flag is correctly set. btw I support both parted sync label and the gptsync tool in the latest version of kiwi. You could easily build an image the following type: <type image="vmx" filesystem="ext3" boot="vmxboot/suse-12.3" format="vmdk" bootloader="grub2" firmware="efi" syncMBR="true"> -- 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#c20 --- Comment #20 from Marcus Schaefer <ms@suse.com> 2013-04-15 15:14:55 UTC --- even worse in non gpt sync mode this parted version causes grub to fail the installation: grub2-bios-setup: info: writing 0x400 bytes. grub2-bios-setup: error: blocklists are invalid. switching back -- 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.
http://bugzilla.novell.com/show_bug.cgi?id=811408 ralph roth <rroth@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rroth@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=811408 Petr Uzel <puzel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|puzel@suse.com |sebastian.parschauer@suse.c | |om -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=811408 Sebastian Parschauer <sebastian.parschauer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ms@suse.com Flags| |needinfo?(ms@suse.com) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=811408 http://bugzilla.novell.com/show_bug.cgi?id=811408#c24 Sebastian Parschauer <sebastian.parschauer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #24 from Sebastian Parschauer <sebastian.parschauer@suse.com> --- Thanks, closing as gdisk workaround is used. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com