[Bug 781688] New: Dual installation of openSUSE after Windows 7 on UEFI system makes Windows unbootable
https://bugzilla.novell.com/show_bug.cgi?id=781688 https://bugzilla.novell.com/show_bug.cgi?id=781688#c0 Summary: Dual installation of openSUSE after Windows 7 on UEFI system makes Windows unbootable Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Major Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: arvidjaar@gmail.com QAContact: jsrain@suse.com Found By: --- Blocker: --- Created an attachment (id=506692) --> (http://bugzilla.novell.com/attachment.cgi?id=506692) Patch to accept Windows created PMBR as valid protective MBR User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0 It appears that on UEFI platform Windows 7 during installation always creates protective MBR with maximum possible size 0xFFFFFFFF instead of using actual device size. SUSE parted includes patches parted-gpt-mbr-sync.patch and parted-gpt-sync-mbr-label.patch which add Hybrid MBR support. Unfortunately these patches are very strict in detecting protective MBR; on above installation they assume system has Hybrid MBR and rewrite it. The result is that Windows no more boots - selecting Windows bootloader from UEFI boot menu kicks you back in menu after several seconds of "Windows loading files ..." progress bar. Attached patch makes parted more tolerant and allows to accept Windows created protective MBR as well. In my testing it appears that once PMBR was fixed, Windows is happy with it and does not try to rewrite it again. It seems to be installer-only "feature". This was hit by several users, details are in this thread: http://forums.opensuse.org/english/get-technical-help-here/install-boot-logi... Reproducible: Always Steps to Reproduce: 1. Install Windows 7 on UEFI system (VMware VM works just fine) 2. Install openSUSE on the same disk as Windows 7 3. Try to boot Windows 7 from UEFI menu Actual Results: After displaying "Windows loading files ..." for several seconds user is returned to UEFI menu. Booting Windows becomes impossible. Expected Results: Windows continues to boot after openSUSE installation. -- 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=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c
kk zhang
https://bugzilla.novell.com/show_bug.cgi?id=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c
Steffen Winterfeldt
https://bugzilla.novell.com/show_bug.cgi?id=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c1
Michael Chang
https://bugzilla.novell.com/show_bug.cgi?id=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c2
Michael Chang
https://bugzilla.novell.com/show_bug.cgi?id=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c3
Petr Uzel
It appears that on UEFI platform Windows 7 during installation always creates protective MBR with maximum possible size 0xFFFFFFFF instead of using actual device size.
Ouch! So much for the UEFI Spec implementation by MS :/ OTOH, hybrid MBR is an ugly hack not following spec either. What a mess...
SUSE parted includes patches parted-gpt-mbr-sync.patch and parted-gpt-sync-mbr-label.patch which add Hybrid MBR support. Unfortunately these patches are very strict in detecting protective MBR; on above installation they assume system has Hybrid MBR and rewrite it. The result is that Windows no more boots - selecting Windows bootloader from UEFI boot menu kicks you back in menu after several seconds of "Windows loading files ..." progress bar.
Attached patch makes parted more tolerant and allows to accept Windows created protective MBR as well. In my testing it appears that once PMBR was fixed, Windows is happy with it and does not try to rewrite it again. It seems to be installer-only "feature".
So if we did a maintenance update of parted in 12.2 with your patch and let affected users boot 12.2 and fix partition table with new parted, Win7 would boot again, correct? Please confirm/clarify. -- 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=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c4
Andrey Borzenkov
So if we did a maintenance update of parted in 12.2 with your patch and let affected users boot 12.2 and fix partition table with new parted, Win7 would boot again, correct? Please confirm/clarify.
You mean after it already had been corrupted? I do not think so, this patch is aimed at preventing damage during installation. If partition is already mangled, it can be fixed using gdisk (gptfdisk) option "write new protective MBR". I do not think parted supports this. -- 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=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c5
Petr Uzel
(In reply to comment #3)
So if we did a maintenance update of parted in 12.2 with your patch and let affected users boot 12.2 and fix partition table with new parted, Win7 would boot again, correct? Please confirm/clarify.
You mean after it already had been corrupted? I do not think so, this patch is aimed at preventing damage during installation.
In 12.2, we unfortunately can't prevent the damage during installation - even if we do maintenance update of parted, it won't get to installation media.
If partition is already mangled, it can be fixed using gdisk (gptfdisk) option "write new protective MBR". I do not think parted supports this.
If parted detects there is no hybrid MBR, it will assume there is standard protective MBR. And if we convince parted to write to the disk (e.g. by toggling a boot flag on one of the partitions), it should write proper protective MBR -> windows should boot again. So if we do maintenance update with your patch, I think users should be able to fix the Win7 boot with one or two simple invocations of parted. But before submitting the maintenance update, it would be awesome if somebody with the affected system could test it (I will create the RPMs). Andrey, Michael: would any of you guys be able to test (or know somebody who can) the procedure to fix broken boot of Windows7? -- 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=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c6
Andrey Borzenkov
(In reply to comment #4)
If partition is already mangled, it can be fixed using gdisk (gptfdisk) option "write new protective MBR". I do not think parted supports this.
If parted detects there is no hybrid MBR, it will assume there is standard protective MBR.
It's too late. If we let SUSE modify partition table during installation, it changes it into hybrid MBR. Any invocation of parted (with or without my patch) after that will see hybrid MBR and won't change it. The only way to change it is to "force replace" MBR with valid PMBR and parted does not provide this option.
And if we convince parted to write to the disk (e.g. by toggling a boot flag on one of the partitions), it should write proper protective MBR -> windows should boot again.
See above. It sees hybrid MBR - it will write hybrid MBR back.
So if we do maintenance update with your patch, I think users should be able to fix the Win7 boot with one or two simple invocations of parted.
users will be able to fix it with a single invocation of gdisk. I am not aware how it can be done using parted, alas. But patch (or equivalent fix) must be applied to prevent damage in the future versions.
But before submitting the maintenance update, it would be awesome if somebody with the affected system could test it (I will create the RPMs).
It is trivial to reproduce in VM. If you like I can test it, but I *know* :) it won't help. Sorry. -- 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=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c7
Petr Uzel
It's too late. If we let SUSE modify partition table during installation, it changes it into hybrid MBR. Any invocation of parted (with or without my patch) after that will see hybrid MBR and won't change it. The only way to change it is to "force replace" MBR with valid PMBR and parted does not provide this option.
Ah, of course you're right. 'Funny' fact is that with 'upstream' parted it would be possible, because that one does not have any support for hybrid MBR and always writes proper protective MBR :/
users will be able to fix it with a single invocation of gdisk.
Right, gdisk is the right tool to fix this.
I am not aware how it can be done using parted, alas. But patch (or equivalent fix) must be applied to prevent damage in the future versions.
Sure, I'll push it to factory ASAP. -- 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=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c8
--- Comment #8 from Andrey Borzenkov
'Funny' fact is that with 'upstream' parted it would be possible
Sure. See http://forums.opensuse.org/english/get-technical-help-here/install-boot-logi... -- 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=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c9
Petr Uzel
https://bugzilla.novell.com/show_bug.cgi?id=781688
https://bugzilla.novell.com/show_bug.cgi?id=781688#c10
--- Comment #10 from Bernhard Wiedemann
participants (1)
-
bugzilla_noreply＠novell.com