Want to dual boot Mint and Win 8 - UEFI questions

[ElectricRider]

I just learned about my new PC having UEFI with it's Windows 8 installed. Trying to load from USB , i could never see the usb from the boot options so i researched to find it's the UEFI causing the problems.

My Bios does give me the option to disable Secure Boot and it also tells me that I will not be able to load windows. Is it safe to disable secure boot, switch to Legacy Bios run the Mint 14 Live or regular DVD to either check out or install to hard drive ( provided i can see it as a boot option) then go back to windows 8 by re-enabling the secure boot option? I want to be sure this wont screw up my MBR or whatever UEFI is using before I try it.

Thanks..

Also, i have read the thread above on the modified EFI bootloader and i would try that But that thread is kinda complicated for me and I'm not sure i wont royaly screw something up.. i wish there were better very clear instructions for using that tool.

Oh yeah.. and for Mint 14.. is it true it has both Mate and Cinnamon, so it really doesn't matter which version you choose to install.. you can always switch? i got that impression from this article: http://www.extremetech.com/computing/14 ... e-bad-bits

[grimdestripador]

It seems the FUD (Fear, Uncertainty and Doubt) from the WarMachine ($$) is deterring another linux mint install.

I don't want you to be the guinne pig, but what happends if you disable secure boot. Does windows still boot?

[ElectricRider]

Well, I did just try it. I was leery of trying it because at one point i looked at those bios settings and on hitting disable for secure boot got a message saying windows may not boot. Well i was lucky.. i tried it and windows still booted. I can always get back into Bios to change it back - and I'll need to because manually switching like this is not good for everyday use.

I'm lucky in that I do have an option to use legacy bios because many new PC's do not have this option at all. For everyone on a new laptop with windows 8 retail preinstalled they will have UEFI enabled. Microsoft requires this from the OEM's or they cannot build the system with Windows 8 retail. Those that don't have a legacy bios option are more screwed than i am.. at least i can access legacy bios if i need to.

Now the question is, Whats my next step? I understand Ubuntu has it's own bootloader for UEFI (as does fedora)( this is one way around the problem) and The Linux Foundation is working on getting a secure boot key from Microsoft to to incorporate into Linux which is another way around the problem - http://www.linuxfoundation.org/news-med ... pen-source

Does the bootloader Mint is using work the same way as Ubuntu ( is Mint using Ubuntu's UEFI bootloader in other words) and is it already build into Mint 14 ( or the procedure for setting up a Mint 14 install) or do i have to use another tool and some other non normal set of instructions to make it all work? This information is not clear on the site that i can see.

[wayne128]

I don't have Win8.
For the Asus laptop, preinstall Win7, it came with UEFI.
I had it set as legacy.

Then install some linux OSes.
and use EasyBCD from Neosmart, add entry to Grub2..
and it boots Linux OS via chainloading.

YMMV.

[ElectricRider]

That may be a possible solution yes But I understand it is not ideal to operate this way .. many people say why use UEFI at all 1) because this legacy bios mode is a scaled down version and may not work as you like and 2) it's supposed to be so much better optimized causing the hardware to work much better in your system and giving you more control over the options you have. ( I know, this still remains to be seen)

Being hardware able to take full advantage of UEFI Is supposed to be like going from Dos to Windows Xp - you wouldn't go back to dos once you've used windows Xp, or is the difference between 16 bit and 32 or 64 bit apps for example or that would be like giving up a Cadillac for a VW bug you wouldn't do it. I'm just going on what I've read so far, and am by no means able to verify any of this.

If this is the direction the industry is going to solve many of the limitations with the 25 year old Bios then everyone needs to get on board. Linux is trying to get on board with it, apparently they doo see the need for UEFI. I understand Bios was never supposed to be used as we have it today and each time hardware changed bios had to be re-hacked and patched to make it work which introduced all sorts of problems. UEFI is a way to fix these problems.

Here is a good article explaining the deference between the old bios and UEFI and why it's better now to use UEFI. http://h30565.www3.hp.com/t5/Feature-Ar ... r/ba-p/198

[viking777]

Those that don't have a legacy bios option are more screwed than i am.. at least i can access legacy bios if i need to.

Tell me about it

This information is not clear on the site that i can see.

Nothing clear has ever been written about Uefi and its implementation. The closest you can get are srs5694's posts. Although they might confuse you as well, but at least he seems to understand it and he tries to explain it rationally (although such explanations are impossible really due to the irrational nature of the problem caused by multiple hardware manufacturers presenting multiple home made 'solutions').

When (or if) you get it going Uefi is better - definitely. The problem you are left with though is that you are now so scared to do anything new (like install a new distro for example) because it is completely impossible to predict what will happen if you do so.

Secure boot is different - you just disable it and forget it.

[srs5694]

I just learned about my new PC having UEFI with it's Windows 8 installed. Trying to load from USB , i could never see the usb from the boot options so i researched to find it's the UEFI causing the problems.

As I understand it, a Mint image file written to a USB flash drive is not bootable in EFI mode. This isn't an EFI problem per se; it's a problem with the way the Mint image file was created. (Fedora 18's image file is bootable when written to a USB flash drive.) The same Mint file, burned to an optical disc, is bootable. I've seen reports that writing the image file to a USB flash drive using UNetbootin is bootable, so if your computer lacks an optical drive, I recommend using UNetbootin to prepare your USB flash drive.

My Bios does give me the option to disable Secure Boot and it also tells me that I will not be able to load windows.

Then it's giving you a paranoid FUD warning. I've seen several reports (including yours in a subsequent post in this thread) of pre-installed Windows 8 booting just fine when Secure Boot is disabled. I have yet to see a report of Windows 8 failing to boot because of disabling Secure Boot.

That said, there are legitimate security reasons for leaving Secure Boot enabled. Getting Mint to boot in that way will require a different approach than you're contemplating, though -- see below....

Also, i have read the thread above on the modified EFI bootloader and i would try that But that thread is kinda complicated for me

I have no idea what the "thread above" is. There have been numerous threads that touch on Secure Boot on this forum. If you mean to refer to a specific thread, be sure to include a link.

i tried it and windows still booted. I can always get back into Bios to change it back - and I'll need to because manually switching like this is not good for everyday use.

The easiest approach is to leave Secure Boot disabled. Windows will continue to boot, and at the moment the risk is low -- Secure Boot is intended to protect against EFI-specific boot-time malware, and to the best of my knowledge, no such malware yet exists in the wild. (I have heard of a couple of "proof of concept" attacks created by security researchers, but AFAIK those aren't being used for actual attacks against real-world computers.) Of course, if you leave Secure Boot disabled, there's always a chance that you'll get hit in the first wave of an actual EFI boot-time malware attack, but the chances of that are lower than the chances of getting hit by existing BIOS boot-time malware.

If you do want to enable Secure Boot for both OSes, read on....

I'm lucky in that I do have an option to use legacy bios because many new PC's do not have this option at all.

I haven't heard of any new x86-64 PCs that lack legacy BIOS support, although many do ship with that support disabled via a firmware option. For the moment, the ability to boot legacy/BIOS OSes is still too important for manufacturers to risk shipping computers that can't handle it. No doubt that will change in time, and it's entirely possible that some obscure product today lacks legacy/BIOS support, but such systems are extremely rare, at least in the x86-64 world.

I understand Ubuntu has it's own bootloader for UEFI (as does fedora)( this is one way around the problem) and The Linux Foundation is working on getting a secure boot key from Microsoft to to incorporate into Linux which is another way around the problem

It's both more and less complicated than this. Secure Boot works by examining the signatures (if present) on EFI boot loader programs and comparing them with public keys held in the firmware. This is conceptually similar to signing an e-mail with GPG; if the signature matches a public key that's on file, the program/message is reasonably certain to come from the claimed source. If not, it could be forged or simply unsigned.

Microsoft has at least two keys that are being included in most or all x86-64 UEFI PCs. It uses one to sign its own binaries and it uses the other to sign third-party binaries. Competing OS vendors, as well as the vendors of emergency recovery utilities, drivers, etc., can then have their EFI binaries signed so that they work on standard PCs. Red Hat/Fedora, Canonical/Ubuntu, and Matthew Garrett have all signed up with Verisign to have Microsoft sign their binaries. For various reasons, the approach used by all of these parties (and probably more in the future) is to sign a relatively simple boot loader (called shim) that has the effect of adding checks for its own key to the keys held in the firmware. This means that follow-on boot loaders (like GRUB) can be signed using keys that the Linux vendor controls, rather than with Microsoft's keys. In most cases, a chain of trust is maintained up through the kernel, meaning that GRUB requires that the kernel (and sometimes kernel modules) must be signed with the Linux vendor's keys. RH/Fedora, Canonical/Ubuntu, and Garrett have all already released signed versions of shim, but each one includes a different built-in key, and so will launch only the programs and kernels released by that vendor. (See below for extensions, though.)

The Linux Foundation's approach is a little different, in that its PreBootloader program doesn't require signing of the EFI binaries; instead, it requires that the user who's physically present when the computer boots authorize launching a given binary. Although the LF was aiming for a release some time ago, they ran into some technical difficulties, and since then they seem to have made significant changes to their program. So far they haven't released a signed version of PreBootloader, although its source code is available.

The upshot of all this is that simply replacing Mint's GRUB with Ubuntu's or Fedora's GRUB won't do you a bit of good, even if you include Ubuntu's or Fedora's shim. The reason is that Ubuntu's or Fedora's signed GRUB will refuse to launch Mint's unsigned kernels. In principle, you could use Ubuntu's or Fedora's signed kernels instead of Mint's kernels, but then you've got the question of how to deal with kernel upgrades, how to create an initial RAM disk, etc. IMHO, this is not a viable long-term solution.

There is another approach, though: Fedora's and Garrett's versions of shim include the ability to load arbitrary keys, known as machine owner keys (MOKs), and store them in NVRAM. Thus, you can create your own MOK (with both public and private components), add it to shim's MOK list, and sign whatever binaries and kernels you like. In theory, signing Mint's GRUB (which doesn't check Secure Boot signatures) should get any kernel to boot -- but of course that slighly increases the risk, should pre-boot malware begin to target Linux. Alternatively, you could use a boot loader that verifies signatures via shim and sign your own kernels.

Currently, setting this up for Mint is a bit complex. See my Web page on the topic for details; or my page on using rEFInd with Secure Boot if you're interested in using rEFInd as your boot manager. If you want to use this approach, I strongly recommend installing Mint with Secure Boot disabled and then setting it up in your working Mint. Trying to retrofit Secure Boot into the Mint installer just adds layers of complexity to the problem.

[srs5694]

Nothing clear has ever been written about Uefi and its implementation. The closest you can get are srs5694's posts. Although they might confuse you as well, but at least he seems to understand it and he tries to explain it rationally (although such explanations are impossible really due to the irrational nature of the problem caused by multiple hardware manufacturers presenting multiple home made 'solutions').

Thanks. (I think! )

When (or if) you get it going Uefi is better - definitely. The problem you are left with though is that you are now so scared to do anything new (like install a new distro for example) because it is completely impossible to predict what will happen if you do so.

I disagree; UEFI is just different from BIOS. When I first started with PCs, I found BIOS boot loaders to be quite confusing. I didn't understand them, I didn't understand how they interacted with each other and with OSes, I didn't know where the code was stored, etc. Today, many users are in that place even for BIOS, but the overall level of knowledge about BIOS is pretty high, and it's easy to find information on the Web to help you resolve a problem. Nonetheless, a user with limited understanding who installs a new OS on a computer (especially one with multiple existing OSes) is taking a risk -- the new OS might easily replace the existing MBR code with a new boot loader that does an inferior job. Recovering from that can be quite difficult for a newbie. Even an experienced user might have trouble if the new OS overwrites the MBR code without making a backup. This might require digging out disused recovery tools and trying to find a version of the MBR boot loader that works with other installer boot loader components. I've had to completely re-do BIOS boot loader installations more than once because of mis-matched versions of GRUB on my disk and on my recovery tools, for instance.

UEFI is actually more predictable than is BIOS in this respect, with the caveat that a really badly written OS installer can make for a Bad Day with any firmware. If the OS installer is even marginally competently written, it won't overwrite existing boot loaders; the worst it will do is make its own boot loader the default. With a decent EFI implementation, you can then select your desired OS and use efibootmgr or a similar tool to restore that desired OS to be the default. Even with a bad EFI, you can use something like a rEFInd CD or USB flash drive to get into your desired OS, or use a tool in your new OS to change the EFI default. At worst, for a newbie at both firmware types, this is no harder than the BIOS solution. At best, for somebody with moderate knowledge with both, it's likely to be easier.

The problem is that the level of knowledge (both in individuals' heads and collectively in the form of Web pages and other documentation) about EFI is much lower than the level of knowledge about BIOS, at least on average. This makes it difficult for novices to get good information, and lots of people who were moderately skilled or even expert at BIOS issues are reduced to the level of novices for EFI. This makes it seem like EFI is a lot worse, but it's not. One possible exception is that EFI is still new enough that there are still a lot of buggy EFI implementations out there, and they create complications and require system-specific workarounds, the likes of which are rare in the BIOS world.

Secure boot is different - you just disable it and forget it.

I generally agree with this advice, although if you're paranoid or adventurous, you can work with Secure Boot.

[ElectricRider]

So my solution is to use Unetbootin? Er.. still confused here and yes srs5694, i read your post.. thank you for replying to me. The post "above" I was referring to was your New EFI boot loader available: rEFInd post.. i was confused about is it a bootloader i can use to solve this problem or is it a boot manager as you say on your website.

I do not want to work within legacy bios mode. I want to use UEFI and have Mint ( or any other distro.. I'd like to install Zorin 6 and My 2nd personal favorite next to Mint, Vector Linux too each in a separate partition, all 4 quad booting with windows 8 using UEFI. ) If you can help me solve this problem with all these distros, I'd give you my first born and let you borrow my wife for a month or two. LOL

So, are you saying even though unetbootin should make the USB bootable in UEFI the OS if it installs still may not boot with my system in UEFI mode ( with a dual boot option at startup?)

I will consider using your tool for a boot manager if i can understand all this and get everything working. ( otherwise i'd normally use EasyBCD but that may only work for legacy bios master boot records.)

[srs5694]

My advice: Take it a step at a time, starting with getting the installer to boot in EFI mode. Use UNetbootin if necessary. If that works, move on to installing, then booting the installation, then tweaking the boot loader to your satisfaction, then installing the next OS. Post back at whatever point you run into problems. There are too many steps, and too many potential problems, to cover every eventuality -- but be aware that a potential problem is not a certain problem. Many people install in EFI mode with few or no problems, so getting hung up on the potential problems before you start is a sure way to never get anything done.

The one potential problem you should be concerned with at this point is your boot mode: If you boot the installer in BIOS mode, Mint will do a BIOS-mode installation, which will be harder to get working than will be an EFI-mode installation. Thus, you should verify that the installer has booted in EFI mode rather than in BIOS mode. You can check this by dropping to a shell and looking for the presence of a directory called /sys/firmware/efi. If it's present, you've booted in EFI mode. If it's absent, you've probably booted in BIOS mode and should stop there and try to get an EFI-mode boot.

[ElectricRider]

O.k. I'll try Unetbootin with Mint 14 and see if it installs and verify if it's using bios or UEFI mode. I'll report back once I'm at that point. Thanks.

Edit: tried with Unetbootin.. UEFI boot doesn't see the USB. i was using a USB to save the few dvds I have but I will try a dvd anyway.. I think i read that UEFI should be able to read from dvd/cd at boot. Although on my machine, i cannot enable UEFI without secure boot. Secure Boot must stays enabled anytime UEFI is enabled.

Nope.. that didn't work either. Looks like I'll just have to keep my system in Legacy Bios mode. Darn. i really didn't want to do that.

[viking777]

I hope ElectricRider wont mind me asking srs a question - it may be relevant to you too.

srs, can you help me with this statement:

Thus, you should verify that the installer has booted in EFI mode rather than in BIOS mode. You can check this by dropping to a shell and looking for the presence of a directory called /sys/firmware/efi. If it's present, you've booted in EFI mode. If it's absent, you've probably booted in BIOS mode and should stop there and try to get an EFI-mode boot.

Maybe there is a misunderstanding of terminology here, but what exactly do you mean by "installer booted in EFI mode"? Do you mean the live DVD/Usb? Because to me the installer is the program that you start from within the live DVD not something that you boot from.

Second part of that question, I have just booted 8 different live dvd's - all bang up to date. Not one of them had the directory /sys/firmware/efi anywhere to be seen. You might say then that I have booted in bios (legacy) mode, but that is impossible because the machine I run has no legacy mode available to it. It runs Uefi only. I have /sys/firmware/efi on my hard drive right enough but never from any boot medium. This makes it a tad difficult to see what mode I am installing in.

I promise I am not trying to hassle you, trick you, embarrass you or anything else like that, in all probability this is yet another in a series of misunderstandings that I seem to have a huge propensity for recently, but you have a lot to say that is very important to folks around here and I would like to try and understand it a little better for my own benefit as well as everyone elses.

TIA viking777

[blue_bullet]

I have been following the 2 main threads on this and am doing a good job of staying confused despite Rod's, Viking's and others attempts to clarify. Here's my experience. I have installed Linux Mint 14 KDE (64 bit) on my HP Pavilion DV7-4083cl Laptop and a ZT Systems-885mi desktop via BIOS using a USB for the install. Both systems were purchased from Costco and have been great. I have also installed the 32bit version via USB on an old Dell Inspiron 1420. Again no problem. I have used the same 64 bit USB and a DVD trying to install on a new HP DV7T-7200 Quad Edition with UEFI with no luck. I notice 14.1 is available for Mate and Cinnamon but not for KDE. That may be my issue, i.e. that the Mint developers reissued 14 for Mate and Cinnamon allowing for a EFI installs and did not do that for KDE. I have not found anything on that as of yet. I have Secure Boot disabled and can still boot Windows 8. With the USB or DVD inserted and those moved up in the boot order I get a message saying Check Media [failed] then it goes on to boot Windows 8. Legacy mode is grayed out so I may not be able to enable that. I don't know if this helps any of you experts but thought I would add it as Rod says he has not loaded Mint 14 yet.

I will continue follow the threads and am willing to try any suggestions anyone might have. Costco has a 90 day return policy on computers so I can return it if HP insists on keeping the hood shut via their implementation of UEFI. I like the new computer (bang for the buck wise) and do not normally buy things just to return them, but I will in this case if the EFI consortium insists on this sort of multi-faceted implementation.

Hope this helps. Any suggestions are welcome. I will try them and report back.

edit: I meant to say USD or DVD inserted, I originally said installed.

[ElectricRider]

viking777 I don't mind at all. It might be relevant to me - if I can get that far LOL. For me I am thinking it's not worth the headaches to fight with all these I want to install. I hear the Secure Boot key from MS is only 100 dollars US. Last I read The Linux Foundation had trouble getting the right key from MS but it would be a better solution instead of using a hacked boot loader. I however am also in the camp that says It's not anyone's business what OS i want to install along with any other OS. If I wrote an OS from scratch, I'd have to pay MS for that if i wanted to dual boot it with Win 8. (in UEFI) Mint should charge Microsoft 200.000 dollars for a key so people can install Windows 8 along side of Mint !

[srs5694]

Edit: tried with Unetbootin.. UEFI boot doesn't see the USB. i was using a USB to save the few dvds I have but I will try a dvd anyway.. I think i read that UEFI should be able to read from dvd/cd at boot. Although on my machine, i cannot enable UEFI without secure boot. Secure Boot must stays enabled anytime UEFI is enabled.

There almost certainly is a way to enable UEFI-booting without Secure Boot. Microsoft requires that users must be able to disable Secure Boot on x86 and x86-64 computers that bear the Windows 8 logo. It's been a while since I've read the exact wording of the requirement, but I'm about 90% sure that Microsoft's certification requirements are written in such a way that switching between UEFI with Secure Boot anb a BIOS-mode boot are not sufficient. Even if they were, any computer configured like that wouldn't satisfy my own standards for quality. Personally, I'd return such a computer on principle. I suspect that's not the case, though; there's almost certainly a firmware setting you're overlooking, or maybe you need to activate (and deactivate) a certain combination of settings to get the result you want. One of the problems with Secure Boot is that manufacturers are free to slap whatever user interfaces they like on it, so it's hard to advise people about how to find the options that achieve certain desired goals, such as disabling Secure Boot.

If you really can't boot in UEFI mode with Secure Boot disabled, then you have three choices:

• Return the computer as a piece of junk, demand a refund, and buy something else in its place. This is what I recommend if you really can't boot in UEFI mode without Secure Boot.
• Install Mint in BIOS mode and then, from that mode and/or from Windows, install and configure an EFI-mode boot loader for Linux that also supports Secure Boot. You can then switch to UEFI-mode/Secure Boot booting and dual-boot Windows and Mint. This is possible, but it's harder than any other path.
• Wipe the hard disk, set the firmware to legacy/BIOS mode, install Windows in legacy/BIOS mode, and install Mint in legacy/BIOS mode. This will require that you have a retail copy of Windows, although you should be able to use the Windows serial number that came with the computer if it's the same version of Windows (not just Windows 8, but whatever edition it is). This is easier than the previous option, but still a lot of hassle.

Maybe there is a misunderstanding of terminology here, but what exactly do you mean by "installer booted in EFI mode"? Do you mean the live DVD/Usb? Because to me the installer is the program that you start from within the live DVD not something that you boot from.

In that context, I was referring to the installation OS, not just the installation program.

Second part of that question, I have just booted 8 different live dvd's - all bang up to date. Not one of them had the directory /sys/firmware/efi anywhere to be seen. You might say then that I have booted in bios (legacy) mode, but that is impossible because the machine I run has no legacy mode available to it.

I just booted a Mint 14.1 DVD under VirtualBox in EFI mode, and it does have a /sys/firmware/efi directory. This directory won't appear if the efivars kernel driver isn't available, but it seems to be built into the kernel on the Mint 14.1 DVD I tried. Still, you could try "sudo modprobe efivars" and check again just to be sure. You can also try "dmesg | grep -i EFI". On a recently-booted Linux system booted in EFI mode, this will produce copious output, as in:

Code: Select all

$ dmesg | grep -i EFI
[    0.000000] efi: EFI v2.10 by VBOX 64
[    0.000000] efi: efi:  ACPI=0x3f9ba000 efi:  ACPI 2.0=0x3f9ba014 efi:  SMBIOS=0x3f9bd000 efi:  MPS=0x3f9bc000 efi:
[    0.000000] efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x00000000000a0000) (0MB)
[    0.000000] efi: mem01: type=2, attr=0xf, range=[0x0000000000100000-0x0000000000107000) (0MB)
[    0.000000] efi: mem02: type=7, attr=0xf, range=[0x0000000000107000-0x0000000001000000) (14MB)
[    0.000000] efi: mem03: type=2, attr=0xf, range=[0x0000000001000000-0x0000000001fcd000) (15MB)
[    0.000000] efi: mem04: type=7, attr=0xf, range=[0x0000000001fcd000-0x000000001f000000) (464MB)
[    0.000000] efi: mem05: type=3, attr=0xf, range=[0x000000001f000000-0x000000001f00e000) (0MB)
[    0.000000] efi: mem06: type=7, attr=0xf, range=[0x000000001f00e000-0x000000003bb63000) (459MB)
[    0.000000] efi: mem07: type=2, attr=0xf, range=[0x000000003bb63000-0x000000003cc26000) (16MB)
[    0.000000] efi: mem08: type=1, attr=0xf, range=[0x000000003cc26000-0x000000003d0d6000) (4MB)
[    0.000000] efi: mem09: type=7, attr=0xf, range=[0x000000003d0d6000-0x000000003d586000) (4MB)
[    0.000000] efi: mem10: type=2, attr=0xf, range=[0x000000003d586000-0x000000003da78000) (4MB)
[    0.000000] efi: mem11: type=4, attr=0xf, range=[0x000000003da78000-0x000000003e04d000) (5MB)
[    0.000000] efi: mem12: type=7, attr=0xf, range=[0x000000003e04d000-0x000000003e0ad000) (0MB)
[    0.000000] efi: mem13: type=4, attr=0xf, range=[0x000000003e0ad000-0x000000003e0b5000) (0MB)
[    0.000000] efi: mem14: type=2, attr=0xf, range=[0x000000003e0b5000-0x000000003e11b000) (0MB)
[    0.000000] efi: mem15: type=7, attr=0xf, range=[0x000000003e11b000-0x000000003e11c000) (0MB)
[    0.000000] efi: mem16: type=4, attr=0xf, range=[0x000000003e11c000-0x000000003e120000) (0MB)
[    0.000000] efi: mem17: type=2, attr=0xf, range=[0x000000003e120000-0x000000003e135000) (0MB)
[    0.000000] efi: mem18: type=4, attr=0xf, range=[0x000000003e135000-0x000000003e151000) (0MB)
[    0.000000] efi: mem19: type=2, attr=0xf, range=[0x000000003e151000-0x000000003e160000) (0MB)
[    0.000000] efi: mem20: type=4, attr=0xf, range=[0x000000003e160000-0x000000003e16e000) (0MB)
[    0.000000] efi: mem21: type=2, attr=0xf, range=[0x000000003e16e000-0x000000003e1a6000) (0MB)
[    0.000000] efi: mem22: type=4, attr=0xf, range=[0x000000003e1a6000-0x000000003e1b5000) (0MB)
[    0.000000] efi: mem23: type=2, attr=0xf, range=[0x000000003e1b5000-0x000000003e1eb000) (0MB)
[    0.000000] efi: mem24: type=4, attr=0xf, range=[0x000000003e1eb000-0x000000003e1ec000) (0MB)
[    0.000000] efi: mem25: type=2, attr=0xf, range=[0x000000003e1ec000-0x000000003e228000) (0MB)
[    0.000000] efi: mem26: type=4, attr=0xf, range=[0x000000003e228000-0x000000003e22a000) (0MB)
[    0.000000] efi: mem27: type=2, attr=0xf, range=[0x000000003e22a000-0x000000003e25b000) (0MB)
[    0.000000] efi: mem28: type=4, attr=0xf, range=[0x000000003e25b000-0x000000003e25e000) (0MB)
[    0.000000] efi: mem29: type=2, attr=0xf, range=[0x000000003e25e000-0x000000003e270000) (0MB)
[    0.000000] efi: mem30: type=4, attr=0xf, range=[0x000000003e270000-0x000000003e278000) (0MB)
[    0.000000] efi: mem31: type=2, attr=0xf, range=[0x000000003e278000-0x000000003e28a000) (0MB)
[    0.000000] efi: mem32: type=4, attr=0xf, range=[0x000000003e28a000-0x000000003e28f000) (0MB)
[    0.000000] efi: mem33: type=2, attr=0xf, range=[0x000000003e28f000-0x000000003e2a4000) (0MB)
[    0.000000] efi: mem34: type=4, attr=0xf, range=[0x000000003e2a4000-0x000000003e2aa000) (0MB)
[    0.000000] efi: mem35: type=2, attr=0xf, range=[0x000000003e2aa000-0x000000003e2ab000) (0MB)
[    0.000000] efi: mem36: type=4, attr=0xf, range=[0x000000003e2ab000-0x000000003e2b0000) (0MB)
[    0.000000] efi: mem37: type=2, attr=0xf, range=[0x000000003e2b0000-0x000000003e2c2000) (0MB)
[    0.000000] efi: mem38: type=4, attr=0xf, range=[0x000000003e2c2000-0x000000003e2c7000) (0MB)
[    0.000000] efi: mem39: type=2, attr=0xf, range=[0x000000003e2c7000-0x000000003e2c8000) (0MB)
[    0.000000] efi: mem40: type=4, attr=0xf, range=[0x000000003e2c8000-0x000000003e2c9000) (0MB)
[    0.000000] efi: mem41: type=3, attr=0xf, range=[0x000000003e2c9000-0x000000003e2e1000) (0MB)
[    0.000000] efi: mem42: type=1, attr=0xf, range=[0x000000003e2e1000-0x000000003e315000) (0MB)
[    0.000000] efi: mem43: type=2, attr=0xf, range=[0x000000003e315000-0x000000003e316000) (0MB)
[    0.000000] efi: mem44: type=4, attr=0xf, range=[0x000000003e316000-0x000000003e32a000) (0MB)
[    0.000000] efi: mem45: type=2, attr=0xf, range=[0x000000003e32a000-0x000000003e32b000) (0MB)
[    0.000000] efi: mem46: type=4, attr=0xf, range=[0x000000003e32b000-0x000000003e32d000) (0MB)
[    0.000000] efi: mem47: type=2, attr=0xf, range=[0x000000003e32d000-0x000000003e32e000) (0MB)
[    0.000000] efi: mem48: type=4, attr=0xf, range=[0x000000003e32e000-0x000000003e332000) (0MB)
[    0.000000] efi: mem49: type=2, attr=0xf, range=[0x000000003e332000-0x000000003e335000) (0MB)
[    0.000000] efi: mem50: type=4, attr=0xf, range=[0x000000003e335000-0x000000003e336000) (0MB)
[    0.000000] efi: mem51: type=2, attr=0xf, range=[0x000000003e336000-0x000000003e338000) (0MB)
[    0.000000] efi: mem52: type=4, attr=0xf, range=[0x000000003e338000-0x000000003e341000) (0MB)
[    0.000000] efi: mem53: type=2, attr=0xf, range=[0x000000003e341000-0x000000003e344000) (0MB)
[    0.000000] efi: mem54: type=4, attr=0xf, range=[0x000000003e344000-0x000000003e7e7000) (4MB)
[    0.000000] efi: mem55: type=3, attr=0xf, range=[0x000000003e7e7000-0x000000003e951000) (1MB)
[    0.000000] efi: mem56: type=4, attr=0xf, range=[0x000000003e951000-0x000000003e952000) (0MB)
[    0.000000] efi: mem57: type=3, attr=0xf, range=[0x000000003e952000-0x000000003e9d3000) (0MB)
[    0.000000] efi: mem58: type=5, attr=0x800000000000000f, range=[0x000000003e9d3000-0x000000003e9f6000) (0MB)
[    0.000000] efi: mem59: type=3, attr=0xf, range=[0x000000003e9f6000-0x000000003ea20000) (0MB)
[    0.000000] efi: mem60: type=5, attr=0x800000000000000f, range=[0x000000003ea20000-0x000000003ea35000) (0MB)
[    0.000000] efi: mem61: type=0, attr=0xf, range=[0x000000003ea35000-0x000000003ea36000) (0MB)
[    0.000000] efi: mem62: type=4, attr=0xf, range=[0x000000003ea36000-0x000000003eed3000) (4MB)
[    0.000000] efi: mem63: type=3, attr=0xf, range=[0x000000003eed3000-0x000000003eede000) (0MB)
[    0.000000] efi: mem64: type=4, attr=0xf, range=[0x000000003eede000-0x000000003f83f000) (9MB)
[    0.000000] efi: mem65: type=7, attr=0xf, range=[0x000000003f83f000-0x000000003f843000) (0MB)
[    0.000000] efi: mem66: type=3, attr=0xf, range=[0x000000003f843000-0x000000003f8be000) (0MB)
[    0.000000] efi: mem67: type=5, attr=0x800000000000000f, range=[0x000000003f8be000-0x000000003f8cc000) (0MB)
[    0.000000] efi: mem68: type=3, attr=0xf, range=[0x000000003f8cc000-0x000000003f913000) (0MB)
[    0.000000] efi: mem69: type=5, attr=0x800000000000000f, range=[0x000000003f913000-0x000000003f922000) (0MB)
[    0.000000] efi: mem70: type=3, attr=0xf, range=[0x000000003f922000-0x000000003f92f000) (0MB)
[    0.000000] efi: mem71: type=5, attr=0x800000000000000f, range=[0x000000003f92f000-0x000000003f933000) (0MB)
[    0.000000] efi: mem72: type=5, attr=0x800000000000000f, range=[0x000000003f933000-0x000000003f94f000) (0MB)
[    0.000000] efi: mem73: type=6, attr=0x800000000000000f, range=[0x000000003f94f000-0x000000003f985000) (0MB)
[    0.000000] efi: mem74: type=6, attr=0x800000000000000f, range=[0x000000003f985000-0x000000003f99f000) (0MB)
[    0.000000] efi: mem75: type=9, attr=0xf, range=[0x000000003f99f000-0x000000003f9b5000) (0MB)
[    0.000000] efi: mem76: type=9, attr=0xf, range=[0x000000003f9b5000-0x000000003f9bb000) (0MB)
[    0.000000] efi: mem77: type=10, attr=0xf, range=[0x000000003f9bb000-0x000000003f9bc000) (0MB)
[    0.000000] efi: mem78: type=10, attr=0xf, range=[0x000000003f9bc000-0x000000003f9bf000) (0MB)
[    0.000000] efi: mem79: type=4, attr=0xf, range=[0x000000003f9bf000-0x000000003fee0000) (5MB)
[    0.000000] efi: mem80: type=6, attr=0x800000000000000f, range=[0x000000003fee0000-0x000000003ff00000) (0MB)
[    0.388221] efifb: probing for efifb
[    0.389496] efifb: framebuffer at 0x80000000, mapped to 0xffffc90000500000, using 10128k, total 2113535k
[    0.389500] efifb: mode is 1440x900x32, linelength=5760, pages=1
[    0.389500] efifb: scrolling: redraw
[    0.389502] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.404001] fb0: EFI VGA frame buffer device
[    0.458138] EFI Variables Facility v0.08 2004-May-17


This output might be missing on a system that's been up for a while, though, since the kernel ring buffer that the dmesg command reports is limited in size, so early entries get lost as new kernel messages accumulate.

If you boot in BIOS mode, there will be few or no EFI references in the dmesg output.

Overall, though, my suspicion is that you have booted in BIOS/legacy mode, despite your belief that your computer lacks this mode. I'm unaware of any current x86-64 computer that uses UEFI but that lacks BIOS/legacy support. Such computers can be made, but as I wrote earlier, they're extremely rare to non-existent. If you really think you've got such a beast, I'd be interested to know what it is (make and model).

Blue_bullet, I recommend you create a new thread for your problem, since trying to resolve two peoples' problems in one thread gets very confusing very quickly.

If I wrote an OS from scratch, I'd have to pay MS for that if i wanted to dual boot it with Win 8.

No, you wouldn't, although you could. At least three other possibilities exist:

• You could disable Secure Boot on the computer.
• You could use one of the signed shim 0.2 binaries (at least two are available, from Fedora and Matthew Garrett) and set it up so that they launch your own boot loader instead of GRUB. (Alternatively, you could use GRUB as your boot loader.) You'd then sign your boot loader and/or kernel with your own key and add that key as a MOK.
• You could reconfigure the computer's Secure Boot settings so that the system uses your keys instead of or in addition to Microsoft's. If you used your key instead of (rather than in addition to) Microsoft's key, you'd then need to sign Microsoft's boot loader with your key.

[viking777]

I just booted a Mint 14.1 DVD under VirtualBox in EFI mode, and it does have a /sys/firmware/efi directory. This directory won't appear if the efivars kernel driver isn't available, but it seems to be built into the kernel on the Mint 14.1 DVD I tried. Still, you could try "sudo modprobe efivars" and check again just to be sure. You can also try "dmesg | grep -i EFI". On a recently-booted Linux system booted in EFI mode, this will produce copious output, as in:

Its no wonder people get confused with this, none of the advice given above allows me to see anything relating to EFI when booting from a Mint 14 dvd.

My machine uses the Pheonix Secure Core Tiano v1.09 bios chip. This seems to have been totally disowned by Phoenix who have replaced it with version 2.x(this may be the problem) I have searched high and low for information about the 1.09 version but I can't find anything useful. There are other people complaining about similar problems eg.

1. I have a Phoenix SecureCore Tiano BIOS (which supports both UEFI & BIOS)
2. The BIOS has no option to select if UEFI/GPT or BIOS/MBR

How Phoenix can claim that the bios supports both Uefi and Bios when there is no option to switch between them I don't know (and there is no such option believe me - unless there is some sort of automatic detection and switching)

One thing I do know for certain is that you cannot flash version 1 to incorporate the features of version 2.

So I still don't know if I install a new distro or upgrade an existing one what mode I am installing in. All three of my distros appear in the ESP

Code: Select all

ls /boot/efi/EFI/
Boot/  manjaro_grub/  mint/  ubuntu/

ls /boot/efi/EFI/manjaro_grub/
grubx64.efi*  grubx64_standalone.cfg*  grubx64_standalone.efi*

ls /boot/efi/EFI/mint/
grub.efi*

ls /boot/efi/EFI/ubuntu/
grubx64.efi*

But when booted Mint and Ubuntu have the /sys/firmware/efi directory but Manjaro doesn't. Yet all three boot normally. Live dvd's also boot normally but likewise do not have the /sys/firmware/efi directory. Additional weirdness is that from both Manjaro and Mint the ESP partition is completely invisible both to the terminal and the file manager. From Ubuntu the partition is fully visible via either method.

Is it any wonder I am confused?

Edit. I just figured out the answer to the ESP invisibility - it wasn't listed in fstab. That illustrates the problem you see, my mind is so twisted up with trying to understand Uefi that I blame everything on that and overlook stuff that I have known for years

[ElectricRider]

Edit: tried with Unetbootin.. UEFI boot doesn't see the USB. i was using a USB to save the few dvds I have but I will try a dvd anyway.. I think i read that UEFI should be able to read from dvd/cd at boot. Although on my machine, i cannot enable UEFI without secure boot. Secure Boot must stays enabled anytime UEFI is enabled.

There almost certainly is a way to enable UEFI-booting without Secure Boot. Microsoft requires that users must be able to disable Secure Boot on x86 and x86-64 computers that bear the Windows 8 logo. It's been a while since I've read the exact wording of the requirement, but I'm about 90% sure that Microsoft's certification requirements are written in such a way that switching between UEFI with Secure Boot anb a BIOS-mode boot are not sufficient. Even if they were, any computer configured like that wouldn't satisfy my own standards for quality. Personally, I'd return such a computer on principle. I suspect that's not the case, though; there's almost certainly a firmware setting you're overlooking, or maybe you need to activate (and deactivate) a certain combination of settings to get the result you want. One of the problems with Secure Boot is that manufacturers are free to slap whatever user interfaces they like on it, so it's hard to advise people about how to find the options that achieve certain desired goals, such as disabling Secure Boot.

If you really can't boot in UEFI mode with Secure Boot disabled, then you have three choices:

• Return the computer as a piece of junk, demand a refund, and buy something else in its place. This is what I recommend if you really can't boot in UEFI mode without Secure Boot.
• Install Mint in BIOS mode and then, from that mode and/or from Windows, install and configure an EFI-mode boot loader for Linux that also supports Secure Boot. You can then switch to UEFI-mode/Secure Boot booting and dual-boot Windows and Mint. This is possible, but it's harder than any other path.
• Wipe the hard disk, set the firmware to legacy/BIOS mode, install Windows in legacy/BIOS mode, and install Mint in legacy/BIOS mode. This will require that you have a retail copy of Windows, although you should be able to use the Windows serial number that came with the computer if it's the same version of Windows (not just Windows 8, but whatever edition it is). This is easier than the previous option, but still a lot of hassle.

I have tried everything I know to try. Here is the give and take I had with my friends over at the Eightforums on disabling Secure Boot while still using UEFI mode. I get stuck in an endless loop when trying to access the UEFI Firmware Settings section. http://www.eightforums.com/tutorials/17 ... -uefi.html You'll see I and Brink ( The big cheese at Eightforums) even consulted my HP service manual and found the info lacking.

Number 2 may be an option. I'll give it a try. I like the PC. It's a quad with a fast video card and uses up to 4 gigabytes of ram for my gaming. It was all i could afford and I don't have the budget to replace it.. best bang for the 400 bucks i spent. I wont be able to find better if i trade this in. I have too much stuff on this PC already for option 3. If i can never make good use of UEFI, I'll just have to live with it and hope the future brings better UEFI support from everyone. You do have a point though.. i think I'll bug the folks at HP about this issue. Thanks.

Edit: Can you help me find conformation of This: "Microsoft requires that users must be able to disable Secure Boot on x86 and x86-64 computers that bear the Windows 8 logo." because if that's true, i need to let the HP folks know they are in error. I have opened a ticket with them about this issue. Thanks.
Edit: I found it here: http://superuser.com/questions/525889/i ... le-to-inst Seems this info is part of the Microsoft Hardware requirements for non ARM hardware. http://msdn.microsoft.com/en-US/library ... e/jj128256 See sections 14,17 and 18.

[srs5694]

How Phoenix can claim that the bios supports both Uefi and Bios when there is no option to switch between them I don't know (and there is no such option believe me - unless there is some sort of automatic detection and switching)

(Emphasis added.) Some manufacturers provide no explicit firmware options for switching between EFI and BIOS modes and instead rely on auto-detection of the boot mode. This is true of my Gigabyte GA-78LMT-2SP motherboard, for instance. (Actually, it does have an option, but only for optical disc boots, and it's very poorly worded -- when booting from a hard disk or a USB flash drive, the boot mode is selected by the firmware itself.) With such computers, you can force the boot mode only by providing a boot medium that supports only the boot mode you want to use. Most Linux distributions provide installation media that attempt to support both boot modes, which means that if your computer gives you limited or no options for selecting the boot mode, you're at the mercy of whatever algorithm the manufacturer provided to determine your boot mode.

One way around this issue is to use my rEFInd boot manager on a second boot medium. In its default configuration on PCs, rEFInd will boot only in EFI mode. (If you reconfigure the "scanfor" line in refind.conf, or if you're using a Mac, rEFInd will detect both EFI-mode and BIOS-mode boot loaders.) Thus, on a PC, if you want to force an EFI-mode boot, you can insert two boot media, one with rEFInd and the other with whatever distribution's installer that you want to boot. Use your firmware's boot manager to select the rEFInd medium and then use its boot menu to select the distribution's installer. It will then boot up in EFI mode (or not at all).

But when booted Mint and Ubuntu have the /sys/firmware/efi directory but Manjaro doesn't. Yet all three boot normally.

In that case, Manjaro is either booting in BIOS mode (which is unlikely if you're using a common boot manager outside of the firmware's own boot manager) or it's lacking an efivars driver. Try typing "modprobe efivars" in a root shell to load the relevant module.

I have tried everything I know to try. Here is the give and take I had with my friends over at the Eightforums on disabling Secure Boot while still using UEFI mode. I get stuck in an endless loop when trying to access the UEFI Firmware Settings section. http://www.eightforums.com/tutorials/17 ... -uefi.html You'll see I and Brink ( The big cheese at Eightforums) even consulted my HP service manual and found the info lacking.

Have you looked for a firmware update for your computer? Sometimes there are bug fixes in later releases. You might also try contacting tech support. They're generally useless, but it's possible you'll luck out. There's also an HP support forum that might be helpful.

[viking777]

Thanks for that reply srs, that makes sense I guess, but certainly doesn't make life any easier for me. What I don't understand though is why Ubuntu 12.10 (the distro I installed first) clearly installed in Uefi mode without any forcing from me (it created and mounted the ESP, I didn't). Are they the only people that have a truly Uefi compatible installation disk? I certainly installed that first because I had heard that was the case. However one of the many dvd's I tried last night was a Ubuntu one and that did not attempt to boot in Uefi mode (no /sys/firmware/efi present)

I will have a go with refind on a usb key, but the thought of booting a usb key in order to boot a dvd in order to install something is just about as nutty an idea as you can get, talk about moving backwards.

[glegg43]

I have a brand new HP desktop computer that came with Windows 8 and UEFI protected boot. I tried several different versions of Mint and Ubuntu with and without protected boot enabled and was not able to achieve an installation. I was also afraid of bricking (rendering unusable) the computer or creating dead partitions, which I have done multiple times on other computers. The solution is VirtualBox. It is free and works very well. Linux Mint 13 (Maya) 64 bit installed successfully and automatically set its screen size to match my 1920 x 1080 monitor. VirtualBox does not slow down the computer noticeably. An important advantage of VirtualBox is that if you do something wrong, it does not brick the computer or create a dead partition. You can delete an unwanted virtual machine and it is gone.