the joys of EFI and reFind

Didier Spaier · 08-21-2015, 06:21 PM

First draft. You'll need to copy/paste this script inside the running installer and run it with sh if you feel adventurous as I didn't have time to put it in an initrd. Feedback appreciated. Completely untested. Instructions inside.

EDIT: there are several mistakes in the script, so don't try it as is. I will correct it, test it in a VM and provide a new version later. Not posting unchecked/untested stuff not to wait one more day is a lesson that I am not able to learn alas, sorry for that.

EDIT2: attachment removed, see next post instead.

Didier Spaier · 08-22-2015, 03:56 PM

Now tested in a VirtualBox' virtual machine.

It worked, despite warnings about changing permissions.

One thing is weird: in the attached pic you see that rEFInd's boot menu includes three entries for Slackware. Only the rightmost one (highlighted in the pic and that corresponds to the settings done by refindconfig) works.
I don't know why it's so but it looks like that, in this case at least, rEFInd registers "guessed" menu entries in its menu.

Feed back is welcome, instructions for use are on the top of the script.

Integration to Slackware could be done this way:

ship rEFInd in Slackware.
ship the script refindconfig either in the initrd or in /var/log/setup alongside the other setup scripts.
allow to run it in a similar fashion as liloconfig or eliloconfig.
what do do exactly, i.e. just run refindconfig or also run rEFInd's install.sh should depend whether we are installing in a Mac or not, but I don't know how this can be tested.

However this post is _not_ a request to our BDFL

Other than that, rEFInd is obviously well thought and well implemented, congrats Roderick W. Smith!

polaris96 · 08-22-2015, 04:09 PM

Quote:

Originally Posted by sombragris

I'd like to know how can I add a Slackware kernel to the rEFInd menu, booting directly from rEFInd and bypassing ELILO. I tried doing that after reading the docs but all I got was a kernel panic. In my experience, documentation for EFI boot managers (ELILO, rEFInd, GRUB2) is either absent or abstruse.

Sorry, sombragris, I was on vacation.

the answer is YUP. It's what I love about rEFInd. it's configurable just like old school grub legacy. Almost identical except your using the DOS style "" instead of "/"

You DO NOT need elilo, although it's fine to use it. I started using elilio and then tweaked until I could safely dump it. I have done so at this point.

Here's how it works, with excerpts from my refind.conf file. I don't use the "automatically created "refind_linux.conf" file. It's powerful and I imagine I WILL use it at some point. At this point, though, I like fine grained control and manually editing refind.conf is easy if you've ever done grub (legacy or 2 .. or lilo, for that matter)

Code:

#scanfor internal,external,optical,manual
#<Polaris>
#Looking to transplant all BIOS devices to EFI/UEFI.  Start Here
#returning to all manual internals because it allows the most fine grained
#control of the display
scanfor optical,manual
#</Polaris>

note the "scanfor *,manual" line.

You need this. it tells refind to use the manual entries cached in refind.conf. don't worry about miograting MBR to EFI those are notes I wrote to myself. The scanfor line is the key.

then:

Code:

menuentry Linux {
	icon EFI/refind/icons/os_linux.png
	volume KERNELS
	loader bzImage-3.3.0-rc7
	initrd initrd-3.3.0.img
	options "ro root=UUID=5f96cafa-e0a7-4057-b18f-fa709db5b837"
	disabled
}

that's one of the canned menuentry blocks. you will have the same codeblock in your refind.conf. C/P it to the bottom of the file
here's what I would change:
1. change the icon to EFI/refind/icons/os_slackware.png
2. Don't worry about the volume line. Unless your system is on a different HDD, delete it. Otherwise, include the partition name for the EFI partition that you're booting from. Remember EFI partitions must be GPT and formatted in FAT32. Other than that they can be anywhere you want. This is the the EFI partition where vmlinuz.efi will reside NOT your root fs partition (don't freak you don't need a FAT32 fs for /.

)
3. move vmlinuz and initrd (if you have one) there. I also copied the systrem map and config files. not sure if you need them but you did in the old world, so...
4. (this is my guess where had issues.) RENAME vmlinuz to vmlinux.efi. The kernel ships with a stub loader and can masquerade as a standard efi loader, but UEFI won't even consider it unless it's got a .efi handle.
5. make sure to remove the "disabled" line at the bottom

please let me know if it doesn't work. I hope this helps

polaris96 · 08-22-2015, 04:21 PM

@ Didier.

NICE scripting, sir. I have to wonder, though...

if

Code:

scanfor usb

were enabled in refind.conf

AND the usb stick was FAT32 ( not a large concern, there, usually, unless it's mine and about to be plugged into a mac, in which case It would be udf and ignored, thank you Steve... )

rEFInd should theoretically discover it on initialization. It certainly found all my external backups, which are attached by USB HDD.

the detection seems robust (overly so. The reason I'm set on manual entries now is that refind keeps giving me choices I don't want - EVERY kernel with EVERY fs)

Didier Spaier · 08-22-2015, 04:51 PM

@ploaris96: thanks for your remarks.

Well, actually most of the scripting is Pat's, not mine... And I see now that it can be shortened as e.g. I don't use the device and partition number of the ESP.

Also, I am a complete newbie wrt rEFInd that I never used myself, I just took dugan's post #29 (that probably I misunderstood, though) as the occasion to have some fun.

I didn't even read all the comments in refind.conf-sample, thus used mostly the defaults settings.

However in these comments I don't see the "usb" value listed for "scanfor". Maybe it was removed from the current (0.9.0) version?

All that been said if someone finds an utility to this exercise I am ready to bring enhancements that could be requested or suggested.

Didier Spaier · 08-22-2015, 05:10 PM

Quote:

Originally Posted by dugan

I'm now intrigued about the possibility of making a slackware-current USB installer that boots with rEFIND...

Now that I re-read your post I think that a way to do that could be to just install rEFInd on your Mac, and edit its configuration file if need be (that is unlikely as it seems that it can genuinely do that) to allow booting off an USB key including an ESP with a properly named EFI image, as is the case for Slackware64-14.1. Then, you'd just have to make a regular installer, if I understand well.

By the way, you could just download an ISO image kindly provided by AlienBOB. I don't know if they are post-processed but it won't hurt to redo it:

Code:

isohybrid -u <ISO image>

then use dd to put it on an USB stick.

EDIT: having had a look to http://taper.alienbase.nl/mirrors/pe...are-current.sh that probably Eric uses (very complete and clean by the way: I am impressed) I assume that the images for 64-current can be dd-ed as is.

polaris96 · 08-22-2015, 09:23 PM

Quote:

Originally Posted by Didier Spaier

However in these comments I don't see the "usb" value listed for "scanfor". Maybe it was removed from the current (0.9.0) version?

All that been said if someone finds an utility to this exercise I am ready to bring enhancements that could be requested or suggested.

Absolutely, I applaud the effort.

You're also correct about no 'usb' token. The correct terminology would be 'scanfor external'

My Bad. Like you, I'm fairly unfamiliar with rEFInd. I do think it would discover a usb stick with

Code:

scanfor $OTHER_PARAMETERS,external

set, so long as the other criteria in my previous post were met by the installer.

I'm also looking to help out. In my own brief experience, rEFInd's intrinsic discovery ability beats Grub2.

Again, I submit to the reader:

***rEFInd***
Easier than Grub Legacy.
More powerful than Grub2.
NOT GNU (yes GNU true believers, bring the torches, I'm a sneering infidel).
Easy and powerful eye candy.

what could be better?

laprjns · 08-23-2015, 10:43 AM

Quote:

Originally Posted by polaris96

what could be better?

Being able to multiboot. This method ignores the ESP partition and therefore any os already installed. By default rEFInd scans the ESP partition for any .efi file and adds boot launch icons for them. Also by default, it scans and creates boot launch icons for all internal hard disk partitions with /boot directories for .efi files and any linux kernels that do not have an .efi extension. I have found that the icons created for the Linux kernels and those in the /boot directory don't usually boot and clutter the menu, so I made appropriate changes in the rrEFInd config file to have then ignored.

My suggestion is that you do not add the scanfo token and allow by default a complete scan of the system, which will include usb attached devices and optical drives. To have it ignore the linux kernels add "scan_all_linux_kernels false" token. To ignore those efi files found on internal hard disk in /boot directories uncomment this line in the config file and remove "boot" from it

Code:

#also_scan_dirs boot,ESP2:EFI/linux/kernels

it should look like this:

Code:

also_scan_dirs ESP2:EFI/linux/kernels

Here's what my rEFInd boot menu screen looks like
http://en.zimagez.com/zimage/screenshot00479.php
All the launch icons with the exception of the one at the far right are auto detected from the ESP partition. The one on the right is a Salix installation usb stick.

Another suggestion is to not create the manual boot stanza in the refind.conf file but rather go with a boot directory in the ESP partition and let the auto detect feature add the boot icon to the rEFInd menu. This way it will be available on the EFI firmware boot menu if needed.
Here's what my ESP partition looks like;

Code:

rich[efi]$ tree -L 3
.
|-- BOOTSECT.BAK
|-- EFI
|   |-- Boot
|   |   |-- Shellx64.xefix
|   |   `-- bootx64.xefix
|   |-- Microsoft
|   |   |-- Boot
|   |   `-- Recovery
|   |-- Salix_mate
|   |   |-- elilo.conf
|   |   |-- elilo.efi
|   |   |-- elilo.png
|   |   `-- vmlinuz
|   |-- Salix_ob
|   |   |-- elilo.conf
|   |   |-- elilo.efi
|   |   |-- elilo.png
|   |   `-- vmlinuz
|   |-- Salix_xfce
|   |   |-- elilo.conf
|   |   |-- elilo.efi
|   |   |-- elilo.png
|   |   `-- vmlinuz
|   |-- Slackel
|   |   |-- elilo.conf
|   |   |-- elilo.efi
|   |   |-- elilo.png
|   |   |-- grubx64.xefix
|   |   `-- vmlinuz
|   |-- refind
|   |   |-- drivers_x64
|   |   |-- icons
|   |   |-- keys
|   |   |-- refind.conf
|   |   |-- refind_x64.efi
|   |   `-- salix.png
|   `-- tools
|       |-- Shellx64.efi
|       |-- gdisk.efi
|       |-- ipxe.efi
|       |-- ipxe_discovery.efi
|       |-- memtest
|       `-- memtest86-usb.img

Didier Spaier · 08-23-2015, 03:55 PM

Thanks Richard for your information and suggestions, much appreciated. I really need to have a closer look to all the settings. I will make more tests in the coming days.

polaris96 · 09-03-2015, 03:10 PM

Quote:

Originally Posted by laprjns

Being able to multiboot. This method ignores the ESP partition and therefore any os already installed. By default rEFInd scans the ESP partition for any .efi file and adds boot launch icons for them. Also by default, it scans and creates boot launch icons for all internal hard disk partitions with /boot directories for .efi files and any linux kernels that do not have an .efi extension. I have found that the icons created for the Linux kernels and those in the /boot directory don't usually boot and clutter the menu, so I made appropriate changes in the rrEFInd config file to have then ignored.

As I said, if rEFInd is guilty of anything, it's giving too many spurious solutions out of the box. In this way, it resembles (ickk) grub2.

But most of these factor can be edited. The reason your changes weren't effected without disabling scanning were most likely because they were placed in refind.conf.

The author says not to do this.

Instead, a refind_linux_config file should be placed in the directory of each kernel with specific information to pass to the scanning agent.

I do not (yet) use it. Like you, I've moved directly to manual configuration because it's super straight forward and I haven't needed to go further at this time.

Check the author's tutorial, though, if you get a chance. I believe you could effect the changes you're looking for if you follow his directions.