I just got Grub2 to work. It only uses 10 Mib and reads the kernel from the /kernels/huge.s directory.

First I created an efi version of grub2 by using package definitions from SlackBuilds.org

http://slackbuilds.org/repository/14.0/system/grub2/

First build and install these packages:
gnu-unifont
os-prober
help2man

Then build grub2, but change the grub2.SlackBuild to
include this on the ./configure:

--with-platform=efi --target=x86_64

and install it.


And the cdrom.efi (bootx64.efi) was created like this:

cd /usr/lib64/grub/x86_64-efi
MODS=$(ls *mod | xargs | sed -e 's/.mod//g')
echo $MODS
cd
x86_64-grub-mkimage -O x86_64-efi \
-o grub/cdrom.efi \
-c grub/cdrom.cfg \
-p /boot/grub \
-d /usr/lib64/grub/x86_64-efi \
$MODS

Where grub/cdrom.cfg is this:

set root=(cd0)
set prefix=(cd0)/boot/grub/

When executed it should look for a grub configuration as
the /boot/grub/grub.cfg file on the cdrom.

One more important detail. One must build the new efi Grub2 on Slackware 14 stable.

Slackware current gets lots of compiler errors trying to use the rusty old unpatched Grub2 libraries...

Are they really errors, or does Grub2 try to build with -Werror set? I've seen a lot of that lately...

I've had success dual-booting doing the following on my samsung smart pc pro. The default bootloader is NOT /EFI/Boot/bootx64.efi (even though it exists), but rather /EFI/Microsoft/Boot/bootmgfw.efi (the files /EFI/Boot/bootx64.efi and /EFI/Microsoft/Boot/bootmgfw.efi are identical).

1. install slackware64 in CSM/legacy mode (this has its own little difficulties but assuming you get through this...)
2. don't install any bootloader
3. boot (again in CSM/legacy mode) using install medium/usb bootstick from setup
4. mount EFI system partition (/dev/sda2 say) as root: mount /dev/sda2 /boot/efi
5. then
* copy refind_x64.efi, refind.conf-sample and possibly the icons and drivers_x64 subdirectories from the refind binary distribution to /boot/efi/EFI/Microsoft/Boot
* cd /boot/efi/EFI/Microsoft/Boot
* mv bootmgfw.efi orig-bootmgfw.efi
* mv refind_x64.efi bootmgfw.efi
* mv refind.conf-sample to refind.conf and make sure the default "scanfor" entry is uncommented
* create a subdirectory /boot/efi/EFI/ELILO and cp /boot/elilo_x64.efi to it
* create a subdirectory /boot/efi/EFI/slackware and copy the slackware64 huge kernel (e.g. vimlinuz-huge-3.8.4) from /boot to it
* create and put an entry in /boot/efi/EFI/ELILO/elilo.conf something like
Then reboot in UEFI mode. The refind splash screen should open with every possible UEFI boot target listed: kernels, bootloaders, etc including the slackware elilo entry as well as /EFI/Microsoft/Boot/orig-bootmgfw.efi and /EFI/Boot/bootx64.efi . Choosing either of these last two should boot into windows.

Once you know it is working you can edit the refind.conf to remove the extraneous options on the splashscreen. I have "textonly" uncommented, I only have "scanfor manual", I have "scan_all_linux_kernels" commented out and I have two manual entries at the bottom that look like:

Once you have got it working you can change to using the generic kernel with an initrd. Also in theory, you could just leave your kernel in /boot since refind can find it. However there are still difficulties in configuring elilo to then find the kernel anywhere except on /boot/efi/EFI so I would recommend just leaving it as above.

The beauty with this approach is that you don't need to rely on efibootmgr to inform the firmware of your new bootloaders. I tried doing this with efibootmgr but failed, either due to my own incompetence or some dastardly extra layer of samsung trickiness -- both possibilities are equally plausible. Refind saved me.

I hope this helps.

Cheers,

Michael

PS. It is also possible to install 32-bit slackware but you still need to use the slackware64 kernel and install the slackware64 kernel modules (this was my original setup). However Pat Volkerding has indicated that this is neither recommended nor supported.

@ michaelslack

Thanks 4 that,

Wow this method sounds promising, I can't wait to try it. Unfortunately I didn't bring my laptop with me and I'll be away until the weekend. (geez Friday seems soo far off!)

I too have been having troubles getting the efibootmgr to even get access let alone switch to rEFInd.

I was almost thinking of just installing a VM on windows & using Linux through that, but I'd rather not go that route.

Here is the last few lines of the first error I encountered:

This looks very similar to a bug reported in OpenWRT:

https://dev.openwrt.org/attachment/t...05/stdio.patch

After I fixed this bug I ran into another reported in SUSE:

https://build.opensuse.org/package/v...12ac25fb9475dc

The first problem you ran into is due to the new glibc deprecating the use of gets(). I actually hadn't ran into anything yet that was so shoddily written as to use this, so congratulations on winning this easter egg hunt! The patch, as you probably already know, is this one:

http://lists.gnu.org/archive/html/gr...HRnXiHYUrM.txt

The other problems are due to gcc-4.8.0 warning about code errors that previous versions of gcc didn't make note of, and grub2 (by default), failing on any compiler warnings. Passing --disable-werror to ./configure will work around that.

With those changes, I was able to compile grub2 on -current.

2 members found this post helpful.

DRAT!
Looks like I have to learn how-to grub2 or is it grub.efi
LOL!

john

If you don't change the NVRAM variables in the EFI system, then the first thing to boot will be "/EFI/Microsoft/Boot/bootmgfw.efi". That is because Windows configures the NVRAM variables when it is installed. You should be able to add rEFInd to the NVRAM boot configuration and set it as the first boot loader. To do that you either use a utility in Linux or the EFI command line. In that case it should not be necessary to replace the files in the Microsoft boot directory. Some people have reported that Windows later resets the boot order to put Windows first. I can't say if that is true or not.

It would be more accurate to refer to "/EFI/Boot/bootx64.efi" as the "backup" or "last chance" boot loader. It is only used if no other boot loader is found (in the NVRAM variables) or no other boot loader succeeds. Also, removable drives are usually searched for "/EFI/Boot/bootx64.efi" before non-removable drives.

In essence the "default" EFI boot loader is the boot loader configured to be first in the NVRAM variables. The last boot loaders tried are those found in "/EFI/boot" on removable and non-removable media.

Erik_FL
Do you know where the NVRAM variables are stored. I presumed it was in the firmware chip, however I recently had to replace a UEFI/BIOS chip on my motherboard and all the boot variables were still there on the first reboot. Seems like they are stored on the hard drive / SSD????
john

Most of the time they are stored in the same "flash" memory with the BIOS/UEFI firmware. They may be stored in a separate bank, so that erasing or upgrading the firmware does not necessarily erase the NVRAM variables. Most motherboards have other non-volatile settings that they need before they have access to a disk drive. The NVRAM variables are usually stored with the other non-volatile settings. The firmware also may create a default set of NVRAM variables if they are not present.

If you swapped the flash chip, then the new chip was probably tested on a system, and may have already contained NVRAM variables. If you didn't have to repair the Windows boot configuration then the default boot loader must have already been set to "/EFI/Microsoft/Boot/bootmgfw.efi".

There is a standard software interface to change the NVRAM variables, and the names of the boot configuration variables are defined in the UEFI specification. Windows (or any other OS) can change the boot configuration at any time. It's obvious that Windows changes the NVRAM variables when it is installed. Microsoft hasn't said anything about if or when Windows changes them after installation.

There is a variable named "BootXXXX" for each boot choice. The "XXXX" is a hexadecimal number that reflects the order that the choices were created, rather than the order they will be used. Each "BootXXX" variable has the boot loader path, options and other information. A separate variable named "BootOrder" defines the order that the boot choices will be tried. It contains just a list of hexadecimal numbers, like 0005, 000C, 0001, etc.

I haven't used any of the OS utilities to edit NVRAM variables so I can't say much about them. The UEFI command line allows editing variables, but it is probably the least convenient way to edit the boot configuration. The UEFI firmware may allow you to configure the boot order, or even add entries.

Operating systems that I've seen don't use the NVRAM variables for their own boot menus and one usually has to press a key during the UEFI firmware initialization to get a menu of the NVRAM boot choices.

Linux EFI boot loaders can chain to other EFI boot loaders. The Windows EFI boot loader cannot chain to other EFI boot loaders. To boot Linux you either have to put it before Windows in the boot order, or press a key to get a firmware boot menu.

Thanks Patrick! I was able to compile Grub2 for x86_64 efi on Slackware current.

Thanks Erik_FL
I had custom names ie Linux, LinuxB, and USBDrive for my boot variables each drive has a different variable name pointing to the EFI partition on its associated drive. So evidently there is more than one NVRAM chip on the motherboard, as all UEFI boot options were intact on the first boot with the new firmware chip.
Don't have / use windows so there is no windows boot manager. Strictly a Slackware machine.
Cheers
john

I have mixed results using Grub2 to boot several machines.

My Acer AMD machine works fine and here is a screen shot:



On the other hand I have no luck booting Intel machines with Intel motherboards.

I get the "Welcome to GRUB!" quote at the top of the screen, an error message:

Error: variable 'prefix' not set.

And then it just hangs. I get no prompt, nothing. I have to do a hardware reset to get out.

The GParted cdrom works fine on both machines, so what is the trick?

Are you referring to booting the DVD or booting from the hard disk?

For a DVD boot problem, put in the DVD, but use the firmware boot menu to start an EFI command prompt. On some firmware that might be listed as "Run an EFI application" or something similar. You may have to select the "shell.efi" file as the application to run. After starting an EFI command prompt you should be able to look at the files in the DVD's EFI System Partition. You can also look at the ACPI device path for the DVD. Take a look at the ACPI device path for the DVD on the machines that work, and on the ones that don't work. That may give you a clue about what's different.

I suspect that GRUB is having trouble parsing the ACPI device path for the GRUB EFI program image. That is used to set both the root and the prefix variable in GRUB. This could be bug in GRUB, so you may want to try updating the GRUB software if you don't have the latest.

How GRUB determines the prefix for an optical disc versus a hard disk is very different. For an optical disc, grub uses a default prefix "/boot/grub" and sets the root device to "(cd0)". GRUB then uses its ISO driver to access additional files. If GRUB does not recognize the ACPI device as an optical disc (from the ACPI path used to run GRUB) then GRUB will try to extract the prefix path from the path used to run GRUB. If GRUB is complaining about the prefix then it might not have recognized the boot ACPI device as an optical disc.

In order for GRUB to use the ISO file-system it has to determine the parent ACPI device of the file-system device used to run GRUB. For example, if GRUB program is on device "fs2:" then it has to find the full device name aliased to "fs2" and then extract the parent ACPI device part of that full device name. You can do the same thing by displaying the alias definition for the device (for example "fs2"). Look at the full device name on the computer that works versus the ones that don't. Is there a difference in the formatting or number of levels in the path?

Assuming that you do find something that you think is a problem with the DVD ACPI device path, you can manually add a boot entry for the DVD using a different (equivalent) ACPI device name for the DVD EFI partition. You can also run GRUB from a shell prompt using a full ACPI device path specifier instead of the alias (EX: don't use "fs2").

I have seen posts by some people about their EFI firmware not using a correct ACPI device name for the optical disk in the firmware boot menu. You might want to look for some of those posts. To correct the problem they had to edit the NVRAM variable with the optical disk's boot definition. The ACPI path is complicated, so there is a possibility that things like leading zeros or other details can cause problems.

I apologize for not being more specific, but I am still learning about how EFI identifies devices and I've seen that each EFI implementation is slightly different. You may find the UEFI documentation helpful in understanding some details.

Have you tested booting GRUB from a USB disk EFI system partition on the Intel machines? It would be interesting to find out if that works. I'm not sure if GRUB uses its own FAT file-system driver or the EFI driver to read from the EFI system partition. For the ISO file-system GRUB uses its own file-system driver and opens the optical disc as a raw block device using the ACPI device name.

If you're having trouble booting from the hard disk, try putting all the GRUB files, the kernel and the initrd in the FAT EFI System Partition on the first hard disk. That may work, where using another file-system such as ext4 might not. For something other than an EFI system partition GRUB has to open the EFI device as a raw block device using the ACPI device name. GRUB also has to load the module for the appropriate file-system, or the module has to be built into the GRBUB image.