It would be greatly appreciated for someone to point out URLs of installation instructions that are geared towards Linux beginners/novices
–or-- if some kind expert would take the time to lay out an explanation of necessary, as well as critical option selection.
It is working for me with a Dell Inspiron 660. However, selecting windows from the grub2-efi menu only worked with secure-boot disabled. There may be a fix for that coming through soon (I hope) from Bug 809038. I am testing that fix, so it is now working for me with secure boot.
I have not found a way to boot opensuse from the Windows boot manager in a UEFI system. I am suspecting that it is not possible. That’s why EasyBCD is not working for you.
That will work. However, if “/dev/sda2” is the EFI partition used by Windows, it is possible that the next time you boot Windows it will wipe out your boot entry. It probably depends on the specifics of your BIOS.
If you have enough free space to create a new EFI partition, and use that instead, then you will probably avoid that problem. A 100M partition would be sufficient. You would need to format the partition as FAT32, and assign it a type ID for EFI (type ID should be “ef00” if you use “gdisk”).
The ZDNET article is a bit wrong. It gives the impression that all is not working with UEFI. And they are right about that. But it is not all the fault of UEFI. Part of the problem is that linux folk (that includes me) are still on a learning curve for this.
I actually have it working pretty well at the moment, though this depends on some updates that have not yet been sent out to 12.3 users.
Right now, when I boot, a grub2-efi menu comes up. It gives me a choice of
12.3 (my first installed 12.3 system on that box)
12.3 advanced options
Windows 8 (that is the system that came with the box)
12.3 on a different partition (my second linux install on that box)
12.3 on a different partition advanced options
All of these work, and the all work with secure boot enabled.
I am quite confident that I could install Fedora 18, and add that to the menu.
I have not tried this, but I’m pretty sure that I could install some other linux, say slackware or puppy, and add to the menu. But I would probably have to disable secure boot before I could boot to those systems.
By the time opensuse 13.1 comes out (should be November), UEFI booting will be worked out pretty well.
I am the author of the ZDNet article. I would be very interested to know where you find that the article “implies that all is not working with UEFI”, and if that is the case where you further find that the article implies it is “the fault of UEFI”.
My intent with that article was to make it clear that the situation as it stands today is that it is not easy to get multi-boot working with UEFI (it is in fact not), and further to make it clear that the primary “fault”, if you want to assign one, is with the “idiot-proofing” recovery that variouis OEMs have incorporated in their systems.
I also believe that I specifically said that of the distributions I have tried, openSuSE comes the closes to installing and working properly for a relatively simple dual-boot Linux/Windows 8 setup, and if the UEFI configuration didn’t keep getting rewritten to run the Windows Boot Loader by default, it would in fact work completely out of the box. If you happen to be blessed with a system which doesn’t monkey around with the UEFI configuration on every boot, then you are a very lucky person; of the three systems I have tried, HP and Acer both do that, and Samsung just turns the system into a door-stop, so it doesn’t matter.
If your system is “working pretty well at the moment”, but depends on changes which are currently not available, well that is somewhat interesting information but is not particularly useful to pretty much any other user in the world.
Anyway, I appreciate whoever took the time to link to my article here, and I hope that it proves to be useful to some openSuSE users in the real world, who have to deal with real systems, which have real configurations, and actually do have exactly the real problems that I described, and which I tried to provide information and solutions for.
Yes, you made that clear. And that’s what I meant by “all is not working with UEFI”. Apologies if you found my wording to be misleading.
I’ll also note that I have only tested one system - a Dell. From the reports I read on the net, some manufacturers make things a lot harder.
I’ve been through that. It seems to be due to a poor decision by Microsoft, together with a limitation of the UEFI firmware. I do not know if all firmware does this, but mine does.
The way of avoiding this, is to use a different EFI partition for linux, and not attempt to share the one used by Windows.
I’ll describe the “changes which are currently not available”.
The first of those changes fixes the booting of Windows (and presumably other operating systems). If I use a different EFI partition for linux, the grub2-efi menu entry for Windows doesn’t work in secure-boot mode. Fixing that was one of the changes. Until the update comes out, you can turn off secure-boot, and then the menu entry for Windows works. Or you can rely on the BIOS boot menu to select Windows.
The second change has to do with the case where there are two linux installs on the same computer. The generated grub2-efi configuration was getting bad commands for starting the alternative linux. Until that update comes through, the work-around is to hand-craft a “grub.cfg” that works. And, at present, there is not much guidance for that on the net.
Let me add some thanks to the fine folk from the opensuse project, who have been working on solving these problems. All I did was discover some bugs, report them, and test the proposed solutions. The real work was done by the opensuse folk who provided the fix. This is open source cooperation at its best.
And a final note: as best I can tell, BCDEDIT and EasyBCD are useless to linux users in a UEFI system. Or, to be more accurate, I spent a lot of time looking and could not find any documentation on how to make them work. I also experimented, but my experiments all failed. If there is a way to use the Windows boot manager to boot linux with UEFI, then it does not seem to be documented. My best guess is that it cannot be done. I do hope Microsoft make changes there.
On Tue 09 Apr 2013 11:06:05 AM CDT, nrickert wrote:
And a final note: as best I can tell, BCDEDIT and EasyBCD are useless
to linux users in a UEFI system. Or, to be more accurate, I spent a lot
of time looking and could not find any documentation on how to make them
work. I also experimented, but my experiments all failed. If there is
a way to use the Windows boot manager to boot linux with UEFI, then it
does not seem to be documented. My best guess is that it cannot be
done. I do hope Microsoft make changes there.
This DELL E5510 UEFI works fine (albeit with windows 7) but the HP
ProBook 4525s is like this, however gummiboot overcomes this.
Gummiboot creates a /boot/efi/EFI/Boot directory and copies
gummibootx64.efi to the above directory an calls it bootx64.efi, you
could try that with the grubx64.efi file. I think the efi searches in
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.3 (x86_64) Kernel 3.7.10-1.1-desktop
up 7:18, 3 users, load average: 0.05, 0.06, 0.05
CPU Intel® i5 CPU M520@2.40GHz | GPU Intel® Ironlake Mobile
I can’t thank you enough for this additional information. I believe that it clears up two areas of problem and confusion that I was having. I had seen with the very first UEFI Secure Boot installation that I made that Fedora 18 actually creates a new EFI boot partition, rather than sharing the one which had been created by Windows. It never occurred to me why they had done this, but your explanation makes a lot of sense. I will test this again to be sure. Your second comment above also explains why the Fedora installations I have tried were never able to boot any other Secure Boot installations - they were on a separate EFI Boot partition. This was actually the largest reason that I started to focus my Linux EFI Secure Boot efforts on openSuSE, because its grub was able to boot both Windows 8 and Fedora 18 with Secure Boot enabled.
Third, I agree with you whole heartedly in commending the openSuSE developers for their hard work and excellent results on this. It took me totally by surprise, because I had been following the 12.3 development since milestone 0, and there was no UEFI Secure Boot support in the installation, and then suddenly in the Beta phase it appeared, and it all worked amazingly well. Great Work!
Finally, I totally agree that both BCDedit and easyBCD are completely useless on UEFI systems. I have literally spent hours fighting with both of them to no avail.
And yes, please do some more testing of this. I only have access to one UEFI box.
For opensuse, I’m expecting this to all come together well by the time 13.1 is out. And, hopefully, those opensuse updates to grub2-efi will have been pushed upstream where other linux distros can benefit from them.
On Tue 09 Apr 2013 03:06:01 PM CDT, nrickert wrote:
> Gummiboot creates a /boot/efi/EFI/Boot directory and copies
> gummibootx64.efi to the above directory an calls it bootx64.efi, you
> could try that with the grubx64.efi file. I think the efi searches in
> alphabetical order…?
I’ve been planning try that, except I’m not sure whether I should copy
“grubx64.efi” or “shim.efi”. I don’t understand enough about how the
secure booting works.
For the benefit of other readers:
Normally, the firmware boots based on what is in NVRAM. However, if
there is nothing in NVRAM, then it looks for “/EFI/Boot/bootx64.efi” in
the EFI partition (or maybe partitions).
Unfortunately, I tried re-installing Fedora 18 with a separate EFI Boot partition, and on reboot it still rewrote the UEFI boot parameters so that it took the Windows Boot Loader first. This was on the HP dm1-4310, so I assume this means that at least HP is so aggressive about “repairing” the boot configuration that it can’t even be protected by using a different EFI partition.
If I install opensuse using the same EFI partition as Windows, then at first everything looks good. But, once I reboot, the Windows entry has disappeared from NVRAM and as a booting option from the BIOS. Presumably the BIOS (or, actually, the UEFI firmware) has removed it. However, booting Windows from the grub menu works. And then Windows puts back its entry in NVRAM, after which the firmware removes the entry for opensuse.
If I install opensuse using a different EFI partition, then neither the UEFI firmware nor Window will change that. The entry for opensuse stays first on the BIOS boot order, though I can change the order through the BIOS.
What you are describing with HP sounds harder to deal with.
There’s some Microsoft documentation somewhere that I found, indicating that Windows looks in the EFI partitions, and copies all boot entries into its BCD file (boot configuration data). And, then, at future times it checks and puts back some entries that the EUFI firmware might have removed. So you might be seeing some sort of strange interaction between Windows and the UEFI firmware.
In my case, I added a second hard drive for linux. I initially installed using an EFI partition that I created on the second drive. Perhaps that would work with HP. I subsequently tested with a second EFI partition on the first drive, and that also works fine with my Dell BIOS.
In one of my google searches, I came up with a suggestion (from a ubuntu user, I think). His idea was to copy the linux boot efi files to overwrite the Windows boot file. That way, Windows would think its booting is still installed and wouldn’t overwrite it. And then the grub menu could start windows from the efi file in “/boot/efi/EFI/Boot/bootx64.efi”. It sounds like an ugly hack. It does indicate the kind of things people are trying in order to get around some of the UEFI implementation problems.
… how does one contact an actual Microsoft programmer for further insight? I spent several hours getting bounced back and forth when I contacted Microsoft Windows customer support (their only suggestion was to use EasyBCD)