LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 04-01-2013, 01:35 AM   #136
aaazen
Member
 
Registered: Dec 2009
Posts: 358

Rep: Reputation: Disabled

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.
 
Old 04-01-2013, 11:21 AM   #137
aaazen
Member
 
Registered: Dec 2009
Posts: 358

Rep: Reputation: Disabled
Quote:
Originally Posted by comet.berkeley View Post
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...
 
Old 04-01-2013, 02:34 PM   #138
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,824

Rep: Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255
Quote:
Originally Posted by comet.berkeley View Post
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...
 
Old 04-01-2013, 09:35 PM   #139
michaelslack
Member
 
Registered: Feb 2013
Location: Sydney
Distribution: slackware
Posts: 110

Rep: Reputation: 36
Post

Quote:
Originally Posted by Dman58 View Post
Has the new version of elilo been able to accomplish dual boot? I don't want to wipe my windows 8 just yet i'de much rather have the option to choose. I have'nt heard anyone hint of that yet, or was I not paying attention. . .

Also I can't figure out for the life of me to get into the UEFI shell in order to tell it to look at rEFInd. Doing that would allow me to dual boot.
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
Code:
prompt
timeout=50
default=slackware

image=/EFI/slackware/vmlinuz-huge-3.8.4
    label=slackware
    root=/dev/sda6     
    read-only
    append=""
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:

Code:
menuentry slackware {
         loader /EFI/ELILO/elilo_x64.efi
}

menuentry windows {
         loader /EFI/Microsoft/Boot/orig-bootmgfw.efi
}
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.

Last edited by michaelslack; 04-02-2013 at 12:14 AM. Reason: added "(again in CSM/legacy mode)" in step 3. also changed refind.efi to refind_x64.efi
 
Old 04-01-2013, 10:46 PM   #140
Dman58
Member
 
Registered: Nov 2010
Location: The Danger Zone
Distribution: Slackware & everything else in a VM
Posts: 294

Rep: Reputation: 31
@ 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.
 
Old 04-02-2013, 12:16 AM   #141
aaazen
Member
 
Registered: Dec 2009
Posts: 358

Rep: Reputation: Disabled
Quote:
Originally Posted by volkerdi View Post
Are they really errors, or does Grub2 try to build with -Werror set? I've seen a lot of that lately...
Here is the last few lines of the first error I encountered:

Quote:
make all-recursive
make[3]: Entering directory `/tmp/SBo/grub-2.00/grub-core/gnulib'
make[4]: Entering directory `/tmp/SBo/grub-2.00/grub-core/gnulib'
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -O2 -MT argp-ba.o -MD -MP -MF .deps/argp-ba.Tpo -c -o argp-ba.o argp-ba.c
mv -f .deps/argp-ba.Tpo .deps/argp-ba.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -O2 -MT argp-eexst.o -MD -MP -MF .deps/argp-eexst.Tpo -c -o argp-eexst.o argp-eexst.c
In file included from argp.h:22:0,
from argp-eexst.c:25:
./stdio.h:456:1: error: 'gets' undeclared here (not in a function)
_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
^
make[4]: *** [argp-eexst.o] Error 1
make[4]: Leaving directory `/tmp/SBo/grub-2.00/grub-core/gnulib'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/SBo/grub-2.00/grub-core/gnulib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/SBo/grub-2.00/grub-core/gnulib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/SBo/grub-2.00'
make: *** [all] Error 2
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
 
Old 04-02-2013, 12:51 AM   #142
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,824

Rep: Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255Reputation: 9255
Quote:
Originally Posted by comet.berkeley View Post
Here is the last few lines of the first error I encountered:

[...]
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.
Old 04-02-2013, 12:23 PM   #143
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-15.0
Posts: 793

Rep: Reputation: 485Reputation: 485Reputation: 485Reputation: 485Reputation: 485
Quote:
Originally Posted by volkerdi View Post
With those changes, I was able to compile grub2 on -current.
DRAT!
Looks like I have to learn how-to grub2 or is it grub.efi
LOL!

john
 
Old 04-02-2013, 01:17 PM   #144
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 821

Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by michaelslack View Post
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).
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.
 
Old 04-02-2013, 01:32 PM   #145
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-15.0
Posts: 793

Rep: Reputation: 485Reputation: 485Reputation: 485Reputation: 485Reputation: 485
Question

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
 
Old 04-02-2013, 02:53 PM   #146
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 821

Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by AlleyTrotter View Post
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.
 
Old 04-02-2013, 03:26 PM   #147
aaazen
Member
 
Registered: Dec 2009
Posts: 358

Rep: Reputation: Disabled
Quote:
Originally Posted by volkerdi View Post
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.
Thanks Patrick! I was able to compile Grub2 for x86_64 efi on Slackware current.
 
Old 04-03-2013, 09:43 AM   #148
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-15.0
Posts: 793

Rep: Reputation: 485Reputation: 485Reputation: 485Reputation: 485Reputation: 485
Quote:
Originally Posted by Erik_FL View Post
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.
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
 
Old 04-10-2013, 12:38 AM   #149
aaazen
Member
 
Registered: Dec 2009
Posts: 358

Rep: Reputation: Disabled
Mixed results

I have mixed results using Grub2 to boot several machines.

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

Click image for larger version

Name:	slack-grub2.jpg
Views:	53
Size:	51.3 KB
ID:	12275

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?

Last edited by aaazen; 04-10-2013 at 12:39 AM. Reason: spelling
 
Old 04-10-2013, 01:54 PM   #150
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 821

Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by comet.berkeley View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware and Grub2 - getting a UEFI mb running linuxbird Slackware 16 12-13-2012 08:40 AM
Slackware on a former UEFI system garpu Slackware - Installation 2 11-23-2012 10:59 PM
Slackware vs. EFI/UEFI kikinovak Slackware 4 10-21-2012 11:31 AM
Help Creating UEFI A MENU For My Bootable (BIOS/UEFI) CDROM ssenuta Linux - Hardware 0 08-27-2012 09:11 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:29 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration