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).

One more dumb question...
 

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?

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

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.

Testers wanted for an UEFI-able installer
 

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.

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.

Just noticed: Is there specific reason why -current still has ELILO 3.14?

ELILO got an update with a "MAJOR" bugfix to version 3.16 this year:

I tried today to install Slackware64 14.1 as second OS, on UEFI-powered mobo, and I'm unable to attach "Slackware" entry to Windows' 8.1 menu properly.
- both Windows 8.1 and Slckware 14.1 boot properly, when I select their respective positions in UEFI (just switching on every boot to setup is really cumbersome)
- I tried to attach Slackware's boot-menu entry using EasyBCD 2.2 - yes, it appeared, and now I have a boot menu, allowing selection

The problem is, that everytime when I select "Slackware", it complains:

"Windows failed to start. [..] File: \EFI\SLACKWARE\ELILO.EFI

Status: 0xc000007b

Info: The application or operating system couldn't be loaded becasue a required file is missing or contains errors."

Well of course I've got this file along with kernel copy - which has been done on automatic by Slackware's installator. But it seems, somehow it can't find this (or it can't run this?).

What actually should I do to fix this problem?

It is probably better to post your question as a separate thread. Otherwise it will be lost in the large number of posts regarding UEFI support in Slackware.

You tried to add "ELILO.EFI" to the Windows boot menu. The error message says that the Windows boot loader cannot load "ELILO.EFI". That is correct, because the Windows boot loader can only load Windows files and it cannot load normal UEFI programs or boot loaders. Therefore you cannot add ELILO to the Windows boot menu.

Windows cannot chain boot to any other UEFI boot loader or operating system. You have to modify the computer's UEFI firmware boot menu to load ELILO. Either add ELILO to the computer's firmware boot menu or replace the firmware boot menu entry for Windows with ELILO. Then add an entry to the ELILO menu to chain to the Windows boot loader, "bootmgfw.efi". ELILO can chain load the Windows boot loader, "bootmgfw.efi".

Some people have also found that Windows will put its boot loader back as the default firmware boot entry if that is changed. To avoid that problem, make a backup copy of the "/efi/microsoft/boot/bootmgfw.efi" file to another location and then replace the "bootmgfw.efi" file with the "elilo.efi" file. You have to name the ELILO file "bootmgfw.efi". Then add the backup copy of "bootmgfw.efi" to the ELILO boot menu for booting Windows.

EasyBCD is not able to "fix" the limitation of the Windows UEFI boot loader. The Windows boot loader can only load Windows EFI files and not normal UEFI files. Even though Windows uses the file extension ".EFI" for some files such as "WINLOAD.EFI", those files are not normal UEFI files. The Windows boot loader cannot chain to or boot normal UEFI files that have the ".EFI" extension. So, the Windows UEFI boot loader is only useful for booting Windows and nothing else. It is misleading of Microsoft to use the ".EFI" file extension for anything except "bootmgfw.efi". That is the only Microsoft file that is really a UEFI executable file.

You also cannot add files such as "WINLOAD.EFI" to the ELILO boot menu even though they end in the ".EFI" file extension. Those files are not normal UEFI programs or boot loaders, and they can only be loaded by the Windows EFI boot loader. You can add the Windows "bootmgfw.efi" file to the ELILO boot menu because that is a normal UEFI boot loader program.

The old BIOS boot loader for Windows works differently. It can chain boot to any boot sector that has been copied into a 512-byte file. In the past, people have added other operating systems to the Windows boot menu. With UEFI that is no longer possible because Microsoft has not implemented it. EasyBCD depends on the BIOS boot loader for Windows in order to chain boot other operating systems. Windows uses a special boot menu entry "APPLICATION BOOTSECTOR" to load those boot sector files. The Windows UEFI boot loader does not support "APPLICATION BOOTSECTOR" menu entries.

What is surprising to me is that there has not been more criticism of Microsoft for hijacking the ".EFI" file extension to create a non-standard Microsoft executable image format. Also, very few people have pointed out that the Windows boot loader cannot load normal UEFI programs or boot loaders. That is not required by the UEFI standard, but it is certainly a reasonable expectation for a well behaved and flexible boot loader. Not only that, it's easy because most of the software is already a part of UEFI.

Thanks for your prompt reply.

How this can be done? Could I have an example? ELILO's docs contain several examples of multiboot "many Linuxes to choose from", as if it was more common case than "Linux + Windows on same disk". Could you post an example to follow?

UEFI executables (.EFI) files are just 64 bit Windows .EXE files (PE/COFF), a format under control of Microsoft. Your Slackware Linux kernel is just a ELF executable embedded in an PE (.EXE/.EFI) file due to the EFI stub configuration option. UEFI even uses the Windows x86-64 calling convention. From Microsoft's POV using a customized PE named .EFI for stage 2 of their own boot process makes perfect sense technically, because they own it completely.

Microsoft ist not "hijacking" .EFI, they invented it. They own this so-called "standard". In fact almost everything PC-firmware-related was defined by IBM, Microsoft or Intel at some point. That's how you boot your PC now: You run a specially crafted .EXE files on a 64 bit version of MS-DOS*) stored inside the mainboard ROM firmware. ;) So ELILO is more similar to LOADLIN than to LILO.

*) You can think of UEFI as 64 bit MS-DOS. It operates on FAT, allows primitive device drivers, direct hardware access and uses single tasking with full-screen access. Unlike the 16 bit original for the 8088 it provides a pixel-oriented framebuffer.

Really a pity, somehow OpenFirmware didn't make it (except older Sun machinery).

Um, probably has to do with the simple fact that there isn't a "singular powerful" backer to push things forward... instead, it gets a lot of backers with differing opinions on how things should proceed.

Doesn't take much to form a schism that grinds things to a halt.

If I'm not mistaken, Intel was responsible for the EFI standard that morphed into UEFI. So, really Intel invented UEFI. UEFI is not a 64-bit MSDOS. MSDOS uses the BIOS for I/O and thus can boot anything supported by BIOS extension ROMS. The low-level drivers for MSDOS are in the BIOS. UEFI cannot use BIOS extension ROMS found in older hardware. UEFI does not provide a mechanism for boot sector loading, although most UEFI firmware supports that non-standard feature. UEFI is a lot closer to Windows Pre-installation Environment (setup) than it is to MSDOS.

The Microsoft EFI PE format has a different section type than normal EFI PE images. I'm not complaining about Microsoft doing that, only the fact that they used the ".EFI" file extension when it was intended for the normal EFI PE format. I suppose one can argue about who used the ".EFI" file extension first. However, the UEFI standard claims the ".EFI" file extension for boot loaders and executable files compatible with UEFI.

Why did Microsoft choose not to support adding standard EFI programs to the Windows boot menu? That would be helpful for things like the EFI command shell, diagnostics or other boot loaders. It seems that Microsoft is trying to prevent users from easily booting other operating systems. In addition, the Microsoft boot loader resets the firmware boot options to boot the Windows boot loader, ignoring the user's preferred boot order set in the firmware. People should not be forced to rename their boot loader to "/efi/microsoft/boot/bootmgfw.efi" in order to use an alternative boot loader.

Actually ELILO is more similar to rEFInd Boot Manager without a GUI. The actual loading is not done by ELILO at all, it just provides a menu. All of the loading functions for UEFI executable files are a standard part of the UEFI firmware. That is why it is so ridiculous of Microsoft to not support loading standard UEFI executable files. They literally just have to call a UEFI function with the correct file name and the UEFI firmware does the rest.

Part of the problem is the graphical Windows boot menu. Microsoft boots a large portion of the Windows operating system in order to provide that graphical menu. That means switching back to a stand-alone UEFI system is difficult after the graphical boot menu has been displayed. The graphical boot menu doesn't really boot anything. It just continues running Windows after Windows has mostly been loaded. If you choose to boot anything besides Windows from the Windows graphical menu, the system has to be completely restarted to the text-based boot loader. All the graphical menu does is set the "next" menu entry to be booted and then restart the entire computer. And, of course if you install some other boot loader, the Windows graphical boot menu does not work as expected. It boots to some other boot loader instead of booting the graphical menu entry you chose. Or, if you're really unlucky it does boot what you chose, but it replaces your boot loader with the Windows boot loader first. Most people don't realize that all the smoke and mirrors is going on until the Windows boot menu misbehaves.

Microsoft could have implemented the graphical boot using UEFI graphics drivers just like rEFInd. They chose to use as little of UEFI as possible and make their Windows UEFI system as incompatible and inflexible as possible. It was probably a great business decision but I think it did a disservice to Windows users.

I could be wrong but I'm not sure ELILO can chainload other OS (non-Linux) kernels or Windows bootmgfw.efi, it complains that bootmgfw.efi is not a bzImage kernel image for example. Grub2 however can, the following works on my laptop:

So having 2 different boot managers installed already - I'll need 3rd one, for my 2 OS-es?

Nope... You'll use Grub2 as the loader for Linux instead of elilo (necessitating going into the EFI partition to remove elilo.efi). That, will allow you to chainload to windows.

~~~~~

Personally, I'm having difficulty in figuring out just why anyone wants to chainload with UEFI? I understood the necessity before UEFI... but the whole point of UEFI is to have some OS "independence" with being able to choose a boot loader (which in turn, allows one to choose an OS to boot).

How about try... rEFInd? http://www.rodsbooks.com/refind/

That seems to me to be a decent choice... I mean, you can leave your current loader alone and have a boot choice. Then install something else in the future without too much fuss.

For myself... I'm pretty content with leaving either Slackware or Windows 8.1 as a default direct boot. Then switch as needed via BIOS boot menu, or changing the default. I mean, I don't plan on switching back and forth many times in one day. Once I get into a groove of working on something, probably stick to on OS for a few weeks...

But that being said... I might give rEFInd a try.

So finally, before I spend another afternoon fighting with this: is ELILO able to chainload Windows - or not?

In your opinion entering each time UEFI's setup to switch to other system is less cumbersome, than just selecting it from some kind of boot menu? Well, I don't think so.

Fourth boot-manager? It seems, having 2 OS-es I'll soon have 4 boot managers - while I need just one, allowing me selection of OS. If ELILO doesn't allow this, why it's installed by default in Slackware?

you're misunderstanding quite a bit there.

firstly, having a boot menu means that there's a few second delay while it waits for you to choose an OS, or default select and move on. going into the BIOS menu isn't for everytime I boot up... and it's because I don't intend to swap OSes often. I did say, I would most likely stick to one for a while. so directly booting into an OS is faster than waiting for a menu. what's the difference between tapping up and down in a boot menu verses hitting F7 to open my bios boot menu, then tapping up and down to select... the difference being all of one key. I would only dig into the bios itself the change the default if I know i'm gonna be booting into whatever is not the current default OFTEN.

secondly elilo is NOT chainloadable according to a number of sources.. previous poster for one. the person that maintains the site I just linked to for another... wiki is a third, etc.

and finally, if you use rEFInd, you won't have 4 boot managers... unless you have four separate OS installations.

rEFInd is a boot manager that allows you to choose among the installed boot loaders.

windows.efi is a boot loader.
elilo is a boot loader that can "act" as a manager
grub2 is a boot loader that can "act" as a manager too
efi stub loader... is self explanatory, i would hope.

with efi stub loader being intergrated into linux kernal 3.3 and after... we won't need elilo or grub2 to load linux. but again... if you use grub2, you WON'T be using elilo. one or the other *per linux installation*

when you boot up, it goes to rEFInd.. that presents you with boot options... then you boot.

as for elilo being installed by default... you could skip over it as an option... just like you could skip over lilo. not everyone does multi-boot. because multi-boot is NOT the common denominator, they chose what works for them. like I said earlier... with the usage of UEFI, chainloading isn't necessary anymore (though people CAN use it if they really want).

p.s. considering I didn't have to do ANYTHING to have multiple boot options from an UEFI menu... compared to the venerable headache you must be feeling now, just trying to figure out how to get a boot menu up... I'd say, yeah... it is less cumbersome. do you plan on swapping EVERYTIME you boot?

to simplify things... for you... you have two options.

#1 replace elilo (bye-bye) with grub2 (hello)... you have one boot loader (grub2), chainload into another boot loader(windows).

#2 install rEFInd... then at boot, choose between linux and windows. that's one boot manager and two boot loaders. elilo for booting into linux, or whatever windows' efi is for booting into windows.

well, you do have a third... but you've already voiced your dislike for it... use the UEFI boot menu to pick and leave your installation alone without installing or uninstalling anything else.

You just answered, what the difference is: less "tapping" and shorter waiting time, while selecting the desired OS. Having functional boot-manager I just need to hit "Enter" (or nothing at all, just wait 3 seconds) - or "Down", then "Enter" (to boot Windows).

Indeed: maybe not everyone does multi-boot; but since multi-boot allows you either to boot single OS, or multiple installed OS-es, then - in fact - IT IS "common denominator", since it'll work for everyone, right?

Besides: take a look at all the examples of "multiple boot different Linuxes installed on single machine" in ELILO's docs. Does it make more sense, than single example for "Linux / non-Linux OS selection at boot time"? Not knowing the statistics, I bet, that there are far, far more people dual-booting Linux-Windows, than die-hards having 3 Linux distros installed on the same machine.

Well, maybe indeed that rEFINd is the answer. Really disappointed with ELILO. Yes, also with that Windows' boot-manager - it's really irritating, that they do all they can, to prevent use of anything else but Windows.

Maybe I'm missing something (I have this mobo only 2nd day). Yes, I've got in setup the selections, which I can use - well the problem is, that there doesn't show up any boot-menu when starting the machine. I have to enter the setup with "Delete", then dig into proper menu, switch the boot option, "Save and Exit"... really cumbersome.

No, I don't "dislike" it - it just doesn't show up. And I can't see a way to bring it onto the screen. How did you do it in your UEFI?

yes... you missing one little detail. my laptop isn't limited to one way.

for my laptop the option is... F2 OR F7 during POST.

F2 - enter BIOS, where I can change the default boot option for future boots... plus selecting the OS for booting now.

F7 - brings up the boot menu, where I can pick which OS to boot into NOW.

lets say my default is windows...

everytime I boot, without hitting either F2 or F7, it automatically goes to windows.

if I want to go to linux this one time, I hit F7 during POST, and it'll display windows and linux as the options. then i pick linux.

if I hit F2, eventually, I get to a screen with a bunch of boot related options....

top half is "boot ORDER:" windows then linux (can be changed to linux THEN windows)
bottom half is "boot into:" windows OR linux... which immediately exits BIOS and boots into my choice there

edit: nope, not F10... F8 if it's the same BIOS as my desktop (I don't dual boot in my desktop, so I don't use it).

maybe F10 was my older laptop... or TAB?

OMG... it was F11 - thanks, now it does make some sense. I'll try that rEFInd in my free time, anyway.

Explains a bit to me too... I thought the (F11) boot menu was what you were trying to avoid... Not realizing until the previous post that you actually meant digging through BIOS (Delete).

"Wintel" developed EFI to boot Windows on Intel Itanium. The distinction between Microsoft and Intel makes no sense in this context.

Actually it can use them and it does. Without "Legagy ROMs" supported by a "compatibility support module" (CSM) most PCs manufactured in the past years won't boot at all. Of course there is also a new EFI ROM format containing EFI device drivers which must be signed by Microsoft, this is not in wide use yet.

UEFI is already a typical single-tasking Disk Operating System on its own and it looks like it has been developed by Microsoft. So the moniker "MS-DOS" fits perfectly. Unlike a traditional 16 bit BIOS UEFI depends on using a disk, the "EFI system partition" is stored on the hard drive.

The Windows boot selector is only intended to select a Windows installation to boot. Also this would compromise "Secure Boot".
Just set a new firmware default using BCDEDIT.

Goobers provided an excellent and detailed answer but let me add this. You can bypass the F11 boot menu altogether (F9/F12 on different machines here) once you install rEFInd or Grub2 (I use Grub2). Trying to do this through the bios is a bit tortuous!
You'll need to correctly create the new efi file entry and set the desired boot order, then you'll be dealing with just one menu. No keystrokes needed here when I'm booting slackware, lots of keystrokes though to get to Windows since it's near the bottom of my menu :D
See the sample commands below (create, list, set boot order).

Your point has some merit, considering that Microsoft controls licensing of the FAT file-system used in UEFI. However, Intel officially claims the intellectual rights to EFI. Of course, UEFI pretends to be an open standard, which I think is worse than no standard, because companies then use proprietary methods and call them a stadard.


I expect compatibility support to be gone just as soon as computer retailers feel they can get away with removing that. The reality is we're moving closer and closer to a Windows only PC. I suspect that we will eventually have to buy "Linux" PCs separately from Windows PCs.

If UEFI is an MS-DOS, it is a poor replacement. For example it does not even read the ISO 9660 file-system on a CD or DVD. It only can read the FAT32 EFI partition stored in an El-Torito boot record of an optical disc. When I see people providing utilities to set disk parameters and flash firmware running on UEFI instead of MS-DOS then I will believe that UEFI has really become as functional as MS-DOS and BIOS. So far companies seem to be implementing what they like of UEFI and leaving out whatever they feel is inconvenient or unprofitable.


How does allowing a user to choose to boot what they want compromise secure boot? Couldn't the boot manager allow users to install certificates for what they want to boot, just like the certificates for the Windows boot manager? Security is always the excuse for taking away liberty.

People have tried to make the Windows boot manager respect the firmware default with mixed results. In some cases Windows re-installs itself as the firmware default (or the computer UEFI firmware does that). This is another case where nobody knows whom to blame because both Microsoft and computer manufacturers don't document exactly how their software works.

I will admit that I have not used UEFI yet. The only computer that I got with UEFI would not boot Windows 7 in UEFI mode. It came with Windows 8 (I would have chosen Windows 7 if that was allowed). The computer retailer was not interested in helping me at all. So, I changed it to use BIOS booting and the BIOS firmware.

To end on a positive note, although we disagree about some things, you obviously have well thought out opinions and persuasive arguments. I tend to be a skeptic. When I don't have a lot of information I sometimes take contrary positions just to hear the opposite side of the story.

I've been writing software in the computer industry since 1978, and dealing with "standards" and the reality of how they are actually implemented by commercial interests. A classic example is the RS232 standard. IBM and other large companies implemented that standard however they chose and basically left it up to the small fish to figure out how to deal with it.

I am very concerned about whether retail computer hardware will continue to be Linux friendly. It will boil down to whether hardware and software developers will provide Linux drivers or release the information needed for open source developers to write their own drivers. Actually, I'm even concerned about how well new computers will continue to support Windows 7. MIcrosoft obviously wants to sell Windows 8 and computer retailers don't like supporting anything but what they are currently selling (if even that).

FYI Fedora is now shipping in (at least some of) its ISO images a file BOOTX64.EFI in addition to grubx64.efi. According to Peter Jones on IRC, " BOOTX64.EFI isn't grub; it's shim [...] our boot media works on macs as well as newer non-Mac UEFI machines that can use Secure Boot, and that's what shim helps with."

Ref. https://github.com/mjg59/shim

(I have hard time trying to make Slint hybrid ISO images Mac-compatible using "isohybrid -u -m" and won't try to add this shim stuff at the moment though ;) )

The CSM is also required to boot Windows, if you have an add-on graphics card installed.

This is already in effect. You can buy a 19" x86-based rack server, which is designed to run Linux, or you can buy a notebook PC, which is supposed to run Windows. Or you can get your Linux-based ARM development boards...

And this Shim is signed by Microsoft, so it is compatible with "Secure Boot" enabled.

dr.s, does grub2 check the efi partition? is it independent of the distro of linux it was installed with?

in my laptop, I have win8.1 in one SSD drive. a single 1 tb drive for storage. Then I added two mSATA drives, one of which got Slack. the other might get "hackintosh." suffice it to say, linux and windows have pretty much nothing to do with each other... kill one by wiping the partition (not necessarily drive, since the efi is partition next to the windows partition on the same drive) and the other wouldn't bat an eye.

I know that, in the past, prior to uefi, i had to set up chainloading, even if the OSes were on different drives... and wiping out one OS (down to erasing the partition), could potentially kill the other.

I guess my question is... would grub2 still run if you killed the linux partition via say... mistaken fdisk command (assuming only one distro of linux is installed).

edit: nevermind... found the answer... because grub2 can be installed in one of two ways, completely with support files in ESP or split with support files in the linux partition. so, if it's completely in esp, it won't be too bad if linux gets killed.

That is one of the things I like about GRUB2. What I dislike is the complicated way that it creates the boot menu and configuration file. If you don't care about customizing the boot menu it is fine.

GRUB2 is the only UEFI boot loader that I know of where you can put most of the boot loader in some partition other than the EFI system partition. Most of the UEFI boot loaders require the boot configuration, boot loader software and sometimes the kernel being booted to all be in the EFI system partition. ELILO, for example, requires the Linux kernel and initrd files to be in the EFI system partition. I think that Windows requires the boot loader software and boot configuration database to be in the EFI system partition, though "WINLOAD.EFI" and other Windows files can be in a separate Windows partition.

If you use GRUB2 to create your own UEFI compatible boot CDs or DVDs, watch out, because in that case some of the grub files can't be in the EFI system partition (on the CD/DVD). Those grub files have to be in the ISO9660 file system part of the CD/DVD. That's because grub can't access EFI system partitions on optical discs even though EFI can. EFI sees and uses the EFI system partition on a CD/DVD rather than the ISO9660 file system. The EFI system partition on a CD/DVD is a special El-Torito "no emulation" image containing just the FAT file system for an EFI system partition (with no partition table). This is one of the weirder things about the EFI standard, because it allows (and requires) partitioned CDs that use the El-Torito headers instead of a partition table to denote partitions. Normally it is expected that there will only be one "partition" on an optical disc and that will be the default EFI system partition.

Using the grub scripts to create an optical boot disc should create the required El-Torito and ISO9660 sections of the disc with the correct files. Usually, the only thing in the EFI system partition of the optical disc is the "EFI\BOOT\BOOTX64.EFI" file which contains the grub kernel image.

You might also want to download an EFI command shell compatible with your computer's UEFI firmware version. Then add the EFI command shell to the grub and/or firmware boot menu. The EFI command shell will let you set firmware variables, list files and look at the devices detected by the UEFI firmware. Although computer manufacturers don't always supply the command shell, it can be downloaded or built from the UEFI open source. Even if the version isn't exactly the same as the firmware it will often still work.

Yes Grub2 is independent, assuming you're using GPT of course and installing Grub2 to the EFI system partition. You install it once, then just manually edit the menu entries in the config file as needed, I do this when playing around with a new release/distro or even to boot an ISO image directly.

I'll be honest... I think rEFInd is prettier... I'd probably go with that (over grub2).:D

This thread has become unwieldy. Where do we stand at this point? I would like to buy a new machine and dual boot Slack and Windows, not because I am keen to run Windows, but because I need it for some things for my job. Last year I bought a used computer (built in 2007)with Win 7 that I am dual booting with Slack 14.1, but I would like something with a little more horsepower. However, I would rather stick with what I have for now than buy a lot of headaches. Any thoughts? Mike.

Open your own thread then, stating exactly what you plan to do and what are your questions.

Sorry, just trying to follow the protocol of not starting a new thread when one already exists.

I assume that such a "protocol" can be relevant only if you are sure that your issue is exactly the same as the topic of the existing thread. But that's only MHO, of course ;)

Well, probably I did not state my question clearly. The title of this thread is "Slackware on UEFI," and I imagine things have changed at least a little since the thread was first started, so my question is similar to the initial post: how compatible are Slackware 14.1, UEFI and Win 8 on the latest hardware?

On the Slackware side few things if any have changed. What matters is the specific UEFI firmware of your machine I think, as the implementation of the UEFI standard vary upon machines.

Well that's interesting: a standard that is not standardized. And people wonder why some of us can't stand Microsoft.

At least there is a specification for UEFI, so the situation is better than with BIOSes.

Also,

• The writers of the specification can't bear the responsibility of the way it is interpreted by firmware designers.
• The writers of the specification are not responsible of the exact version to which each firmware is compliant (or even worse a mix of versions, as seems to be the case for some implementations by Apple).
• The specification has to leave some freedom for some implementation's details. What freedom is left can be inferred in reading the specification, and sometimes is clearly stated in it.
• Microsoft alone can't bear responsibility for the specification of which it is not the sole writer, and the parts that have a Microsoft legacy (e.g. the format of the PE/COFF images) themselves benefit of a written specification.

PS Sorry to be a bit pedantic but a specification is not exactly a standard, as the latter should be released by some normative body, as e.g. ISO.

Member Response
 

Hi,

You can look at Slackware Doc Project search result for 'UEFI' that lists several good references; http://docs.slackware.com/start?do=search&id=uefi&fulltext=Search
If you then have questions then create a new thread to get help here at the Slackware forum using a descriptive title like; 'Slackware UEFI installation issues'. Just a suggestion.

I do like to suggest the following links for user that have issues when composing posts;Two memorable quotes;
Hope this helps.
Have fun & enjoy!
:hattip:

Member Response
 

Hi,
Unified Extensible Firmware Interface - Welcome to Unified ... provides user input & references for 'UEFI'. Plus do not forget Unified Extensible Firmware Interface (UEFI) wiki for useful information;Intel did originate 'EFI' along with other members, not just Microsoft.

Version 2.0 — UEFI Standard Based - Intel ; A PDF document composed by Intel for UEFI 2.0. Sadly, Intel has not provided a new PDF for V 2.4 that I could find.

Close; Ubuntu BIOS/UEFI Requirements - Ubuntu Hardware Debugging The above pertains to Ubuntu but does provide good references within that can provide some insight. Be sure to look at the References table links;You can look at: UEFI documents for additional information. Documentation for 'UEFI & BIOS' can be provided by Motherboard vendors, you can do a site search on vendor web site.

Hope this helps.
Have fun & enjoy!
:hattip:

Perfect.

Thanks dugan, I read the thread you linked, and some of the other stuff linked there. You seem to think it was easy to set up by following the Slackware UEFI readme, but a lot of other people seem to have had trouble with it, which still makes me hesitant. I'll have to do some more reading and pondering before I'm ready to commit money to new hardware.

As much as UEFI is standardized, mobo manufacturers still differ in their implementation much like BIOSes. In general it will work just fine. Some implementations are easier to work with, others harder.

As for stories about "bad" motherboard firmware, the worst problem I've heard of is that the boot menu would be built properly, but the default would stay at Windows, forcing you to press F-something to get into Linux on each boot. I personally wouldn't consider that a dealbreaker.

Thread:
http://www.linuxquestions.org/questi...ml#post5241406