https://bugzilla.novell.com/show_bug.cgi?id=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c2 --- Comment #2 from Michael Chang 2013-03-13 08:43:24 UTC --- (In reply to comment #1)

Formatting is correct (there are even distros doing that on every bootloader update). There is nothing preventing you from having multiple boot partitions for multiple operating systems.

Re Windows boot: Michael, can you find out if it is GRUB2 issue or installer issue?

I don't know, :( probably it's windows loader refused to boot from secure boot enabled mode .. that (error) message is not part of grub2 and I thought grub2 started window loader already and things|trouble belongs to windows loader's realm ... To be sure that the chainloaded image is the one used by secure boot .. could you please help to dump .. $ efibootmgr -v Let's see which loader we have to use ... -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c4 Michael Chang changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |nrickert@ameritech.net --- Comment #4 from Michael Chang 2013-03-13 09:03:47 UTC --- Hi Neil, Please help to provide output of $ efibootmgr -v 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c6 --- Comment #6 from Neil Rickert 2013-03-13 13:56:37 UTC --- Created an attachment (id=529544) --> (http://bugzilla.novell.com/attachment.cgi?id=529544) Output of "efibootmgr -v" when secure boot is disabled. The output from "efibootmgr -v" depends on whether secure boot is enabled or disabled. This attachment is for disabled. I provide a second attachment with it enabled. When asking for this output, you probably should specify whether you want it with secure boot enabled or disabled. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c8 --- Comment #8 from Neil Rickert 2013-03-13 14:20:29 UTC --- The error message (for problem 2) is most likely coming from Windows (the early stages of booting). I don't see it as a big problem, since everything works if I disable secure boot. And, as best I can tell, secure boot has no value to the end user. It seems to be a Microsoft strategy to reduce software piracy, particularly to reduce cheating by OEMs. In my opinion, the booting of Windows (Vista, Windows 7, Windows 8) is poorly designed and poorly documented. A question: I have 12.3 installed for secure boot. When I try to boot Windows, I see the grub2 menu, then select Windows. As I understand it, the UEFI BIOS is checking a signature on a shim, before it proceeds, and the shim is checking a grub signature. When I attempt to boot Windows, is anything checking the Windows signature? It seems to me that the way Windows should be booted, is that grub should tell the UEFI boot manager to select Windows on the next boot, and then it should do a reset to force a new boot. Otherwise, I think suspect that the security of the Windows booting is not checked. (I notice this is set for 13.1 Milestone 0; it should probable say 12.3 Final) -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c10 --- Comment #10 from Michael Chang 2013-03-14 04:49:33 UTC --- (In reply to comment #6)

Created an attachment (id=529544) --> (http://bugzilla.novell.com/attachment.cgi?id=529544) [details] Output of "efibootmgr -v" when secure boot is disabled.

When asking for this output, you probably should specify whether you want it with secure boot enabled or disabled.

Thanks. Next time I will. But in general the secureboot enable|disable shouldn't affect the efibootmgr -v result unless your firmware doing something nasty .. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c13 Alberto Planas Dominguez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aplanas@novell.com --- Comment #13 from Alberto Planas Dominguez 2013-03-14 09:11:12 UTC --- Uhmm ... I have a Lenovo x230 with secure boot for testing and working. I installed Windows 8 with secure boot enabled. Initially I configured the installation in a way that Windows 8 can reclaim all the hard disk (bye bye data). I booted Windows 8 and work as expected. After that I installed openSUSE 12.3 DVD version from a USB stick. YaST2 detect the EFI partition and try to resize the partition. This is ok, because the initial size was 100MB. This is the default size after a clean Windows 8 installation. I enabled the secure boot option in YaST2 and.. everything was ok. I tested booting Windows 8 and openSUSE from the UEFI internal boot manager and both booted ok. Also I tested booting both OS using the GRUB chainload with success. The entry that GRUB create for Widnows 8 boot Windows 8. IDK how to confirm this bug. This Lenovo machine has a nasty bug in the firmware related with the SecureBoot variable (sometime the SB is activated but the variable is 0x00 instead of 0x01). Maybe I will retest the full process again with a QEMU + Tianocore instance. May I suggest to Neil to confirm the MD5 or SHA1 of the DVD? I see the Problem#1 behavior in pre Build-094 images, but not before. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c Jeffrey Cheung 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c17 --- Comment #17 from Neil Rickert 2013-03-14 14:19:59 UTC --- This is partly guessing. I think I can surmise what is happening. In my case, there are two hard drives - call the Drive-0 and Drive-1. Window 8 is on Drive-0, and opensuse is on Drive-1. What seems to be happening, is that the Windows boot is looking for its BCD on Drive-1 rather than on Drive-0. Presumably, when the UEFI BIOS boots the grub2-efi bootloader, it is somehow setting Drive-1 to be the default drive, and Windows is picking that up. If I do: efibootmgr -n 04 # set next boot to be Windows reboot Windows does boot correctly. It seems to be only when UEFI has started grub2-efi on Disk1 and grub2-efi has then started Windows, that this goes wrong. Presumably, if I had use the EFI partition from Disk0, I would not have this problem. If my surmise is correct, then I see this as really a Microsoft bug. It's perhaps even a security bug. When using secure-boot, Windows should be insisting on getting the correct BCD, and that would be the one on Disk-0. The only sensible work-around I can suggest, would be for grub2-efi to have an option to specify what is to be booted next, then reset the system so that the UEFI BIOS starts the boot to Windows. Perhaps you can pass that upstream as a suggestion to the grub2-efi maintainers. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c19 --- Comment #19 from Neil Rickert 2013-03-14 15:49:06 UTC --- Created an attachment (id=529742) --> (http://bugzilla.novell.com/attachment.cgi?id=529742) Yast logs (gzipped tar file) -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c21 --- Comment #21 from Thomas Fehr 2013-03-14 16:22:24 UTC --- Thanks, during fstab import we set to format everything that belongs the system. Pre 12.3 this was fine for /boot/efi since every install had its own boot partition. Now as we consider "/boot/efi" as a shared partition between multiple OS installations this is of course dangerous. I will change the code to not mark "/boot/efi" to be formatted in that case any more. Similar reasons caused "/boot" not being proposed to be formatted. So far yast2-storage is not prepared to have "/boot" and "/boot/efi" as different filesystems. Change will be in SLES11 SP3 code base but it is too late for 12.3. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c23 --- Comment #23 from Andrey Borzenkov 2013-03-17 04:58:22 UTC --- (In reply to comment #8)

It seems to me that the way Windows should be booted, is that grub should tell the UEFI boot manager to select Windows on the next boot, and then it should do a reset to force a new boot. Otherwise, I think suspect that the security of the Windows booting is not checked.

It's not possible to do right now, but somebody else asked about support for EFI variables in grub2. Adding commands to read/write them is relatively trivial and allows grub2 to set one time next boot entry and reboot.(In reply to comment #9)

(In reply to comment #7)

My guess, when secure boot enabled, windows will protect it's boot config from altered and refuse to boot if any validation failed. When chainload by grub2 (or any other chainloader ..) without a explicit bcd passed it refused to process ..

We can extract information from EFI boot variable, I'm just not sure how to pass what is effectively binary object (EFI is using UTF-16 unless I'm mistaken) via grub.cfg. It sounds like extra reboot is probably the most simple solution. (In reply to comment #17)

This is partly guessing. I think I can surmise what is happening.

In my case, there are two hard drives - call the Drive-0 and Drive-1. Window 8 is on Drive-0, and opensuse is on Drive-1.

So you have two ESP, one on each disk?

What seems to be happening, is that the Windows boot is looking for its BCD on Drive-1 rather than on Drive-0.

You can easily test it by reinstalling grub2 on the first disk, where windows is located, and booting from 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c25 --- Comment #25 from Neil Rickert 2013-03-17 16:47:15 UTC --- comment 23:

You can easily test it by reinstalling grub2 on the first disk, where windows is located, and booting from it.

I'll probably do that later today, and report back on the results. Thanks for the rest of your feedback. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c27 --- Comment #27 from Andrey Borzenkov 2013-03-18 06:05:31 UTC --- (In reply to comment #26)

Next, I tested booting Windows 8. And that worked fine.

It is not clear - did you try to boot Windows from grub2 menu? Was it successful?

Running "efibootmgr" from the rescue boot does not show any opensuse boot options.

Does your system offer "Boot from file" (often in "Boot maintenance" or "Boot manager" submenu) or access to EFI shell? Then you should be able to start grub2 directly. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c29 --- Comment #29 from Neil Rickert 2013-03-18 15:10:45 UTC --- Responding to comment #27

It is not clear - did you try to boot Windows from grub2 menu? Was it successful?

Yes, with grub2-efi installed in "/dev/sda1", I successfully booted Windows from the grub menu. Secure boot was enabled at the time. That was just before Windows removed the grub entry from nvram. I have since reinstalled grub in "/dev/sdb1" (for my original 12.3 install). I did this using the rescue image, mounting the various file systems, doing a "chroot", then getting into Yast (curses version) and reinstalling the booter. Yast seemed to have all of the defaults correct. That got me back to the earlier status, as reported at the start of this bug report. Namely, Windows appeared in the grub menu, but gave an error when trying to boot. I have since disabled secure boot, and now booting Windows works without problems, as long as I don't enable secure boot. Evidently UEFI is a can of worms, and is going to cause grief to linux users.

Does your system offer "Boot from file" (often in "Boot maintenance" or "Boot manager" submenu) or access to EFI shell?

No, I could not find a way to do that. There is a way to change the boot preference order for nvram boot entries. For that, there's a section "Hard Disk Drivers" with two entries (Currently opensuse-secure and Windows Boot Manager (if I recall correctly). Changing one of those automatically changes the other, so I think this is just setting the boot preference for existing entries. The only change that is possible, is selecting between the two names in each line. It is looking to me as if there can only be one entry with a particular name, so adding "opensuse-secure" to the first disk erased the corresponding entry for the second disk. And it is also looking as if there can be only one entry per physical disk. Adding "opensuse-secure" to the first disk apparently removed the entry for Window. And Windows (which still booted from grub menu) did not like that, and put its entry back, thereby erasing the entry for opensuse-secure. I am now thinking that if I want two opensuse installs, using the two EFI partitions (one per disk), then I should set only one of those to secure boot. That way, one will be called "opensuse-secure" and the other just "opensuse". Hopefully, that would avoid the name conflict. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c31 --- Comment #31 from Neil Rickert 2013-03-18 18:11:42 UTC ---

Could you show Windows menu entry?

This is from grub.cfg on the install that boots from second disk: ---- cut here ---- menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-960A-3282' { insmod part_gpt insmod fat set root='hd0,gpt1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 960A-3282 else search --no-floppy --fs-uuid --set=root 960A-3282 fi chainloader /efi/Microsoft/Boot/bootmgfw.efi } ---- end cut here ---- For the other install, the menu entry is identical, with the exception of the penultimate line, which is: chainloader /EFI/Microsoft/Boot/bootmgfw.efi I am doubting that the change from "efi" to "EFI" is why the second of those works, but I can manually edit grub.cfg and test it. While we are discussing grub.cfg, there's another discrepancy. I now have the two installed systems, and each has a grub.cfg entry to boot the other. But those entries do not specify an "initrd" in the command line. When I boot the alternate opensuse (the one supposedly booting from first disk), but using the grub menu from the one booting from the second disk, there is no plymouth splash, and the prompt for encrypted swap and home gets lost in the noise, though I did manage to boot it. During the brief time the system was booting the other way (from the grub in /dev/sda1), I never actually tested booting the alternative linux. But, without initrd, that would not have worked at all since that install depends on an encrypted LVM for which initrd is a requirement. So there's something wrong with the way that the alternative linux is being picked up for grub.cfg . I'll probably add a manual "configfile" entry as a workaround for that. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c33 --- Comment #33 from Michael Chang 2013-03-20 10:12:30 UTC --- Hi Neil, Is you bios AMI ? -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c36 --- Comment #36 from Neil Rickert 2013-03-23 15:50:45 UTC --- An update. First, thanks again to Michael for suggesting (commennt #32 ) that I use the distributor field to change the system name. That turned out to be very useful. Here's what I tried: 1: I created a second EFI partition on "/dev/sda". That new partition is "/dev/sda7" 2: I changed my second install to mount "/dev/sda7" as "/boot/efi" (in place of sda1) 3: I used the distributor field to change the name to "openSUSE_alt 12.3" 4: I reinstalled grub2-efi for that system. Result: The reinstalled system showed up as opensuse_alt-secure in "efibootmgr" output. The Windows boot entry in nvram was not erased. The nvram entry for my original install (named "opensuse-secure") was not erased. However, I still cannot boot Windows in secure boot mode from the boot menu for "opensuse_alt-secure" These seem to be the rules that are being followed by my UEFI BIOS: No duplicate system names allowed in nvram Only one named system in nvram for a particular efi partition Windows 8 seems to be following these rules: The BCD (boot configuration data) should be in the EFI partition that the UEFI Bios starts, and therefore booting to Windows won't work in secure mode if the UEFI Bios first starts a system using a different UEFI partition. There must be a Windows entry in nvram. If there isn't, then Windows will put it back there when it next runs, even if that erases entries for other systems. As a result of my testing, here is my advice for installing opensuse on a UEFI system that already has Window 8: 1: DO NOT use the EFI partition that is used by Windows. If necessary, create a new EFI partition for this. Otherwise Windows may erase your nvram entry. 2: Tell users to turn off secure-boot on their systems. With secure-boot on, they won't be able to boot Windows from grub2 menu. They will be able to boot Windows with secure boot by using "efibootmgr -n" to specify that Windows is the next system to boot, and then rebooting. We need the workaround suggested in comment #17, before secure-boot can be recommended. But it is fine to specify "secure-boot" when setting up grub2-efi. And a note of frustration. A work around for the problem of Windows erasing the nvram entry, would be to start linux from the Windows boot manager. I have not been able to find out how to do this in UEFI system. I have seen kludgy work-arounds. One suggestion was to copy the linux boot efi file (typically "shim.efi" over the Windows efi file, and modify the grub2 menu so that it boots Windows using the other copy of the Windows booter (the one in "/EFI/BOOT" in the efi partition). -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c38 --- Comment #38 from Andrey Borzenkov 2013-03-23 19:36:20 UTC --- (In reply to comment #34)

It also looks as if os-prober, as used in grub, is broken. Looking at grub.cfg for my secondary opensuse_alt, I notice that it use "linuxefi" with "initrdefi". But if I look at the main grub.cfg, its attempt to boot the secondary install using "linux" and no "initrd" clause at all. That's broken. I'll probably open a new bug report on that after some more investigation.

Yes, please open separate bug report. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c40 --- Comment #40 from Michael Chang 2013-03-25 06:33:36 UTC --- (In reply to comment #37)

(In reply to comment #30)

...

OK, so it is not extra boot parameters and must be path to image file.

Root device was not correctly set in secureboot code path.

Oops . too bad.

@mchang: Michael, could you please help to test the fix. It needs proper signing, so I did not even publish repo.

home:arvidjaar:bnc:809038/grub2

This is tricky right now 1. It seems no way to retrieve the public certificate used to validate the signed image in the user's home project though the osc command or any other means. :( 2. Currently grub2 package only provides server signed binaries (whether signed by SUSE by user's own signkey) we may have to consider providing an unsigned image (say grub2-unsigned.efi) to make things easier for local signing. 3. pesign just aborts badly if --remove-signture (segv. fault).. What I wanted to do is to strip off the signatures in grub.efi and re-signing it with my own local key then end up with this unexpected fail. :( 4. Related to #3, current firmware don't play with multiple signed images so we can't sign an image multiple times. For the time being, I will try to branch your home project to create a unsigned grub2.efi to work my local signing and give the signed image and certificate to Neil for test. The wiki page has more elaborate about the (local) signing and (MOK) key enrolling process. (See booting a custom kernel) http://en.opensuse.org/openSUSE:UEFI -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c42 --- Comment #42 from Michael Chang 2013-03-25 11:55:08 UTC --- Hi Andrey, I just submitted grub2 package which includes grub.der to verify the signed image srid #160916 Hi Neil, If Andrey and you agree to go this way, follow the instruction below to test .. $ update package from andrey's repo - This step will install grub.efi signed by andrey's home project, you need to enroll his keys(cert.der) to MOK, ref to steps below to enroll it - If your uefi firmware supports custom mode, better use it instead of MOK, just point your firmware it path of grub.der to load it - You can re-install grub2 package in 12.3 DVD to have SUSE signed loader again $ cp /usr/lib64/efi/grub.der /boot/efi $ reboot $ disable secure boot setting in bios menu $ save settings and reboot $ in grub menu press 'c' key $ type chainloader (hd0,gpt1)/EFI/opensuse/MokManager.efi boot $ select "Enroll key from disk" $ navigate to the cert.cer file and press enter $ follow the instructions to enroll the key. Normally this should be pressing '0' and then 'y' to confirm $ reboot $ enable secure boot setting in bios menu $ save settings $ test -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c44 Andrey Borzenkov changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|mchang@suse.com |nrickert@ameritech.net --- Comment #44 from Andrey Borzenkov 2013-03-25 12:44:08 UTC --- (In reply to comment #43)

Somehow I miss the step how to obtain it. The only thing I can get from OBS is PGP key. Is it possible to convert it into required certificate?

OK, I see, you added it to package itself, it is just confusing that you call it grub.der and cert.cer in different places. Neil, if you feel like testing it 1. Add repo zypper ar bnc://arvidjaar:home:bnc:809308/standard bnc809308 zypper refresh bnc809308 zypper dup -r bnc809308 2. You will get /usr/lib64/efi/grub.der. You will need to enroll it in your firmware. May be you need to rename it to grub.cer, not sure. Michael? 3. Then you should be able to boot using new grub in secure mode and test Windows 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c46 --- Comment #46 from Neil Rickert 2013-03-25 14:41:43 UTC --- Reply to comment 44 Yes, I plan to test this. Some clarification would help. In Comment 42, Michael gives the following grub command: chainloader (hd0,gpt1)/EFI/opensuse/MokManager.efi As it happens, the version of opensuse that I can directly boot is using my second hard drive for booting (for its efi partition). So I think I need to change that to: chainloader (hd1,gpt1)/EFI/opensuse/MokManager.efi I'll appreciate any comments. If none, I'll probably try that anyway. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c48 --- Comment #48 from Neil Rickert 2013-03-25 15:06:05 UTC --- Reply to comment 41:

It seems not Windows but the firmware erroneously erases the entry during reboot.

Yes, I believe to be true. During my testing, I reinstalled grub on my secondary installation of 12.3, putting it back into the Windows EFI partition, but with the name "opensuse_alt-secure". Immediately following that, I used "efibootmgr" and it showed both the Windows entry and the "opensuse_alt-secure" entry. (The entry for "opensuse-secure", using an EFI partition on the second drive was also there). I then booted into opensuse again. And, "efibootmgr" now showed that the Windows entry was missing. So it looks as if the efi firmware only allows one nvram entry per EFI partition, and enforces this on reboot. I then booted into windows from the entry in grub from my secondary install. And when I next booted the system, the nvram entry for my secondary install (for "opensuse_alt-secure") was gone. But the entry for "opensuse-secure" (my primary install) was there, and I could set that back to be the default. That the efi firmware only allows one entry per EFI partition is not itself a big problem. The really big problem is that Windows then insists on putting its own entry back there. It does not need to do that. I was able to boot Windows without that nvram entry. If not having the nvram entry prevented booting Windows, then I would have needed a repair boot from install media. My rant about Windows: 1: It should not routinely force its entry into the UEFI nvram. That comes across as looking like a monopolistic practice, though I suspect it is really more a matter that they didn't think this through. 2: If they really want everybody to use the Windows Boot Manager, then there needs to be a way to use the Windows Boot Manager to boot another system that is defined in the EFI partition. I could not find a way of doing this, and I could not find anything in their documentation. They do have a provision for OSLOADER entries, but those are defined for loading legacy systems such as with NTLDR. There is actually an entry in the Windows BCD for "opensuse-secure", given the type "firmware application". I tried adding that to the Windows boot menu, but it was ignored. Maybe I could have added as a tool (like their memory checker) and have it available after hitting F8 - I did not test that. I am wondering whether something like the old LOADLIN could be revived in a suitable way to be used as a legacy OSLOADER from the Windows Boot Manager. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c50 --- Comment #50 from Andrey Borzenkov 2013-03-25 16:46:09 UTC --- (In reply to comment #49)

# zypper ar obs://arvidjaar:home:bnc:809308/standard bnc809308

Sorry, it is day of typos. Name does not matter but URL was all wrong. bor@opensuse:~> sudo zypper ar obs://home:arvidjaar:bnc:809038/standard bnc809038 Добавление репозитория 'bnc809038' .....................................[готово] Репозиторий 'bnc809038' успешно добавлен Включён: Да Автоматическое обновление: Нет Проверка GPG: Да URI: http://download.opensuse.org/repositories/home:/arvidjaar:/bnc:/809038/stand... bor@opensuse:~> sudo zypper refresh bnc809038 Получение метаданных репозитория 'bnc809038' ...........................[готово] Сбор кэша репозитория 'bnc809038' ......................................[готово] Указанные репозитории обновлены. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c52 --- Comment #52 from Michael Chang 2013-03-26 06:15:09 UTC --- I know why, the packaged cert (grub.der) is incorrect thus secure boot check failed, firmware then try booting next entry (windows). I'm fixing it and please retest again when repo ready. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c54 --- Comment #54 from Andrey Borzenkov 2013-03-26 14:53:41 UTC --- (In reply to comment #53)

Hi Andrey,

Please check srid #161087. Thanks.

Is ready. Neil, simply update from the same repo. You probably need to disable secure boot once to be able 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c56 --- Comment #56 from Michael Chang 2013-03-27 03:42:12 UTC --- (In reply to comment #55)

Michael (comment #52 ):

Yes, I had guessed that there was a problem installing the key. It would be nice if MokManager said something (even a one word "failure" or "success").

As long as the x509 certificate is well formed, MokManager will accept if it's not a duplicate one and spaces for firmware variables are enough. Yeah it should be verbose for the result. :)

Andrey (comment #54 and earlier).

It is now working.

Kudos to Andrey who always fix terrible bugs to us (not only grub2) :D -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c58 --- Comment #58 from Andrey Borzenkov 2013-03-27 13:39:48 UTC --- (In reply to comment #57)

This is incorrect. Instead of packaging certificate to package, osc could retrieve the certificate (PEM format) for us. An example:

So we do not need to push your patches to package certificate? -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c60 --- Comment #60 from Michael Chang 2013-03-28 03:14:49 UTC --- Submitted. SRID#161508. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c62 --- Comment #62 from Bernhard Wiedemann 2013-03-29 09:00:21 CET --- This is an autogenerated message for OBS integration: This bug (809038) was mentioned in https://build.opensuse.org/request/show/161694 Maintenance / -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c64 --- Comment #64 from Neil Rickert 2013-03-29 18:20:14 UTC --- While I have your attention: I noticed some strangeness this morning (on my UEFI box). I'll describe. Let me know if you think a new bug report is warranted. Background: Windows 8 is installed to use "/dev/sda1" as the EFI partition for booting. My primary opensuse install uses "/dev/sdb1" as its EFI partition, and boots as "opensuse-secure". Andrey's patch is installed there. My secondary opensuse uses "/dev/sda1" as its EFI partition, and boots as "opensuse_alt-secure", though it usually does not show up in the BIOS boot menu, so I boot it via the grub menu from my primary install. Todays events: 1: I booted into my secondary opensuse, and ran online updates. That apparently caused a grub2 reinstall (I think a udev or udisk update or similar). When I rebooted, it was the grub menu from my secondary opensuse that greeted me. This was unexpected, but only because I wasn't paying attention. Running "efibootmgr" showed that "opensuse-secure" and "opensuse_alt-secure" were in nvram, with "opensuse-secure" as the default. Windows was gone. This was not a surprise, based on prior experience. It seems to be the firmware that removes Windows during reboot. 2: I booted into my primary opensuse (from the BIOS boot menu), and then ran online updates. This time, I ran "efibootmgr" before I rebooted. That showed "opensuse" and "opensuse-secure" as the only nvram entries. The entry for "opensuse_alt-secure" was gone. The entry for "opensuse" was listed as default. Note that the "opensuse" and "opensuse-secure" both referenced "/dev/sdb1" (by its gpt GUID) as the EFI partition. 3: I rebooted. That gave me the "opensuse-secure" boot menu. Although plain "opensuse" had been the default, that was not used, probably because my system has Secure Boot enabled. I ran "efibootmgr" to see what was in nvram. It showed two bootable systems. Those were "opensuse-secure" and the first hard drive (the entry from "/EFI/BOOT/bootx64.efi"). The latter would presumably have booted Windows. 4: I booted into Windows, expecting that to add back its entry to nvram. I then had to get into BIOS settings, to make the "opensuse-secure" entry the default. And then, booting back into opensuse-secure (my primary install), I ran "efibootmgr" which showed "Windows" and "opensuse-secure" entries, with "opensuse-secure" as default. Here's what bothers me about all of this: A: It looks as if the re-install of "opensuse-secure" deleted the entry for "opensuse_alt-secure". I don't think it should be doing that. However, the reinstall of "opensuse_alt-secure" did not remove the entry for "opensuse-secure". My guess is that everything that matches "distribution-name"* is being removed. B: If it is installing "opensuse-secure" then I don't think it should also install "opensuse" into nvram. If I turn off secure-boot" the "opensuse-secure" entry still works. If I had disabled secure boot, I am now wondering whether the firmware might have deleted the "opensuse-secure" entry in place of deleting the "opensuse" entry. C: I think it's a mistake to reinstall grub whenever "mkinitrd" is run. (I recall objecting to that for a 12.2 milestone release). Reinstalling grub (in this case, grub2-efi) has repercussions for the booting of other systems than opensuse. In my opinion, it should not be done unless necessary (say, after an update of grub2-efi or grub2), or after a deliberate reinstall by the owner. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c66 --- Comment #66 from Andrey Borzenkov 2013-03-30 03:23:25 UTC --- (In reply to comment #64)

Here's what bothers me about all of this:

Please open separate bug report, let's not hijack this one. -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c68 --- Comment #68 from Benjamin Brunner 2013-04-02 14:41:20 CEST --- Andrey, unfortunately the build for ppc and ppc64 fails. Could you have a look at it please? https://build.opensuse.org/package/live_build_log?arch=ppc&package=grub2.openSUSE_12.3_Update&project=openSUSE%3AMaintenance%3A1528&repository=openSUSE_12.3_Update_ports -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c70 --- Comment #70 from Benjamin Brunner 2013-04-02 17:38:38 CEST --- This would be nice. I'll add the new submission to the running update. 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c72 --- Comment #72 from Bernhard Wiedemann 2013-04-02 20:00:11 CEST --- This is an autogenerated message for OBS integration: This bug (809038) was mentioned in https://build.opensuse.org/request/show/162255 Maintenance / -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c75 --- Comment #75 from Bernhard Wiedemann 2013-04-09 17:00:09 CEST --- This is an autogenerated message for OBS integration: This bug (809038) was mentioned in https://build.opensuse.org/request/show/163452 Maintenance / -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c77 --- Comment #77 from Neil Rickert 2013-04-11 00:56:24 UTC --- The patch for this showed up today. It is broken. Secure-boot no longer works. This has been reported as bug 814098 -- 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=809038 https://bugzilla.novell.com/show_bug.cgi?id=809038#c79 --- Comment #79 from Neil Rickert 2013-04-11 04:23:39 UTC --- Oops, sorry. That was a typo. It should be bug 814756 -- 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.