I have the same problem on my motherboard; and despite what has been said about doing research before buying and market forces making manufacturers behave, the reality is that here in the US, if you don't want to build your own computer, or if you do and want a workstation board for dual Xeon, your almost certainly going to be getting an ASUS, or so it seemed to me. The problem is that ASUS doesn't support Linux in general and doing research on the BIOS is an exercise in futility, as the documentation is entirely vague and doesn't keep up with BIOS revisions.

On my ASUS board, there are two choices UEFI-Secure Boot, or other OS. Oddly enough the machine came loaded with UEFI-Secure boot on, and Windows 7 loaded on MBR. No Linux DVD was allowed to boot, nor was the Slackware UEFI USB drive I made. I disabled Secure boot to other OS, Win 7 still booted, after automatically installing new drivers, and I can boot now. I tried re-enabling Secureboot/UEFI (it is one option only), and after a few blue screens, Win 7 refused to boot again and I went back to "Other OS". My question is: am I running UEFI without Secure boot, or presumably legacy mode, and if I use GPT, is that going to be an issue? I'll probably just wipe Windows out anyway and run a VM as needed.

As root try
then try if you are in UEFI mode the vars directory will exist and be populated
That's the best I can do. Have not experimented with secure boot or windows
I believe UEFI requires GPT, but not sure
john

Only Windows 8 or Windows Server 2012 can be booted with "Secure Boot" enabled. Other Windows operating systems do not have signed components and keys to allow booting with "Secure Boot" enabled.

Windows 7 cannot be booted with "Secure Boot" enabled. To boot Windows 7 using UEFI, it must be 64-bit and installed in a GPT. The UEFI firmware must also be 64-bit. To boot Windows 7 using BIOS, it must be installed in an MBR partition.

There are really three separate options for booting, though your BIOS may not allow you to set them individually.

1. UEFI versus BIOS booting
2. MBR versus GPT
3. Secure boot versus unlimited booting

BIOS booting uses the boot sector (first sector) on hard disks or the binary "El-Torito" boot image on an optical disk. An El-Torito image is usually just a binary bootloader, although it is possible to emulate a floppy or hard disk.

UEFI booting requires an EFI System Partition (ESP) that can be defined in either in a MBR or GPT partition table. UEFI booting looks for EFI bootloader "applications" in a number of locations, including NVRAM variables and the ESP on each disk drive. Bootloader applications are not raw binary. They are programs using the PE (Portable Executable) format. UEFI booting from optical disks uses a binary "El-Torito" image, but it is a special format that is not compatible with BIOS booting. Essentially the "El-Torito" image is a binary image of a FAT file-system that is used as an EFI System Partition. The "El-Torito" image must be "no-emulation" even though it essentially is similar to an emulated floppy image. The EFI bootloader applications are loaded from the ESP on the optical disk.

The only requirement for a GPT is to support disks greater than 2 TB. UEFI should work fine with an MBR partition table, providing that it contains an EFI System Partition.

Secure boot requires that the EFI bootloader application is signed, and the appropriate key is installed in the UEFI firmware. The bootloader should also check signatures of anything that it loads, though UEFI does not enforce that requirement or specify how bootloaders should do that.

Windows, however is much more restrictive about its requirements. I think that's mostly because Microsoft was lazy. Booting Windows on a GPT requires a 64-bit OS and UEFI. You cannot boot Windows from a GPT in BIOS mode. UEFI booting on Windows requires a 64-bit OS and 64-bit UEFI firmware. Windows 32-bit does not support UEFI or GPT booting. Windows either boots using BIOS or UEFI and that is chosen when Windows is installed. It cannot be easily changed after the fact. To install or repair Windows you must make sure that you boot the Setup disc using the correct method (BIOS or UEFI). This also presents a problem if you want to switch a pre-installed Windows system to boot using BIOS. If your UEFI firmware doesn't support a mixture of BIOS and UEFI booting, you may have to reinstall Windows to dual boot a different OS using BIOS mode.

The easiest way around the Windows limitations is to use BIOS booting. However, that won't work if your boot disk is larger than 2TB. One solution is to use a solid state disk for BIOS booting. If you have to boot Windows from disk larger than 2TB then you must use GPT, UEFI and a 64-bit Windows OS.

You will see confusing terminology regarding booting. The term "Legacy" or "Other OS" could refer to any of the three different features that I mentioned or more than one of them. Some firmware incorrectly assumes that ALL BIOS booting will only use an MBR and ALL UEFI booting will only use a GPT.

The UEFI version of Windows boot loader, "bootmgfw.efi" only supports loading Microsoft applications such as "winload.efi". Those ARE NOT in the same format as normal UEFI appplications or boot loaders. That is why the Windows boot loader cannot chain to a different EFI boot loader. The Windows EFI boot loader is pretty much only useful for loading Windows and nothing else. I think that using the ".efi" file extension for the Microsoft images like "winload.efi" is misleading since they are not really EFI applications.

Unfortunately, the only way to find out what your particular UEFI firmware can support will require experimentation. Keeping that in mind, it is a good idea to completely back up the entire system that you get from a vendor, including the EFI System Partition and the firmware (if you are going to update that). Make sure that you create any factory restore discs and test them so that you can re-install Windows.

1 members found this post helpful.

I should mention a pitfall that I've seen with new computers. Many vendors provide their own installer for Windows. That installer typically runs the first time you start up the computer. If you change the BIOS settings before you finish installing Windows, you may install Windows in the wrong boot mode (UEFI versus BIOS).

The installers use the Windows Pre-installation Environment (Windows PE). That is capable of booting in multiple ways, and may boot and install Windows even when the installed Windows will not boot.

If you run into this problem, I suggest that you create the repair discs using the factory restore or utilities (if you can run them). You will then have to reinstall Windows with the correct firmware settings (BIOS or UEFI). You may be able to use the factory restore without booting from the restore discs, but I recommend creating them just in case the factory restore partition is deleted.

1 members found this post helpful.

Quick question regarding GPT partioning. I have a very recent BIOS only motherboard (not UEFI). And just for testing purposes, I was wondering if you could use GPT for the hard drive, install slackware-current-RC3 and boot to it with a BIOS motherboard.

Yes, this should work on nearly all BIOSes. A very few older ones don't like it if there's not an MBR partition table with a partition marked as bootable (or so I've heard -- it works on every machine here that I've tried, including a relatively old Core2Duo box).

To make easy for Windows users to burn a Slackware (or slint) installer on an USB key, I've cooked a specific ISO image with the same content as in usbbot.img, but in addition an /isolinux directory including files isolinux.bin, iso.sort and case occurring efiboot.img.

I did that to test usage of 'rufus' to make the bootable USB installer as it needs an ISO bootable image as input file.

That works as then, booting from the USB key in e.g. an EFI enabled VM, /EFI/BOOT/message.txt is displayed and booting occurs, but that leads me to ask one more (sorry :-) dumb question, just out of curiosity: why does the DVD installers use grub, but the USB installer elilo instead?

Attached Files

make_slint_usbiso.sh.txt (16.5 KB, 10 views)

Because elilo is smaller. I'd use it on the DVD as well, but it doesn't work there.

1 members found this post helpful.

Oh, I see, thanks!

@ Erik FL: That's what I thought, so when I got the machine and saw Secure Boot/UEFI, I assumed it was UEFI only and that the disk was GPT. However, it didn't allow anything to boot other than Windows because of "Secure mode" the BIOS refused to start any other efi program on a USB, AND the disk was MBR, according to fdisk and gdisk, with no EFI partition. When I re-enabled Secure boot/UEFI, and used a Fedora disk that can supposedly boot Secure Boot, it offered to write hashes for various efi files (presumably to NVRAM) to allow booting. I did make a system rescue disk first. The whole thing is weird.

@AlleyTrotter; I'll try that as asoon as I can.

I had an adventure with EFI that didn't go as well as some of the options here sound, it was drawn out but it worked. I noticed there's EFI binaries included in the new slackware, that's nice and would have been useful. Though, I didn't want to use ELILO, either. I just used the slackware 13.37 x64 cd to boot legacy mode, install the OS to the gpt disk like Volkerding said to earlier in this thread, then I booted into a live cd environment with an arch x64 cd, downloaded source for linux 3.4.x(I think that's the one where EFI stub support started) and compiled an EFI stub-enabled kernel after chrooting into the slackware install on disk. Just put that kernel into your esp, and you should be good to go. rEFInd can be installed via windows 8 and can automatically detect and set up an entry (and a cool icon for slackware) for EFI-enabled kernels so long as the linux kernels are named vmlinuz-*. Though, you can set up your own stanzas too if you need. Also its nice and handy to have the EFI shell loaded onto a disk somewhere so either your motherboard or rEFInd(or whatever manager you choose to use) has the option of dropping you to an EFI shell so you can boot things manually or tinker around with configs if you need.

Trying to install slackware64-current from USB on an Acer Aspire with UEFI and rEFInd failed. rEFInd could not see the USB stick. Moving /syslinux/EFI/BOOT to /EFI/BOOT on the USB stick and editing /EFI/BOOT/elilo.conf to load /syslinux/huge.s and /syslinux/initrd.img fixed it so the install now works normally under UEFI.

In this directory: http://slint.fr/pub/64-current/
you'll find an hybrid image, that can be used to make either a CD/DVD or USB installer, as you like.

Instructions to burn the image on Linux or Windows are provided.

I would like some kind souls try it on real UEFI machines, as I don't have any at hand.

This is just an installer, so you'll need additionally a source of -current packages.

Caveat: this installs some internationalized packages. If you don't want them, after installation just use upgradepkg to replace them with the genuine version. They all have _slint in their name, but SlintLocales which is a new package. Or slackpkg upgrade-all && slackpkg clean-system if you prefer.

Burned it to GPT/UEFI on USB using Rufus under Windows, disabled Secure Boot, and it booted OK. I didn't try the actual installation yet, as I'm waiting for 14.1... but I'm tempted to. The hardware is a Rampage IV Extreme with BIOS version 4502 and 4930K CPU.

1 members found this post helpful.

Thanks mostlyharmless. Well, I assume that if you install it now you'll just have to do some upgradepkg when 14.1 will be released, but that's your machine

Other reports welcome as well, of course.