Thank you for the newest 0.12.0 revision.
I'v e installed it on the occassion on some hardware upgrade, which caused some fresh Linux installs and it's how the mess begins :)
I can't make it working with manual stanzas only where linux entries use "old school":
volume
loader
initrd
options
It simply doesn't work (frankly I've made partition images as a backups and after hardware update restored them in the same order, but making changes in UUIDs, configuring&reinstalling grub2 via chroot etc) - after choosing such "old schooled" entry screen becomes black&white (like mono mode turned on) or shows some UEFI message and that's it.
I've managed it somehow to boot via grubx64.efi (boot directly after picking up Linux entry).
And this is a place for correct question and where my issues start,
How to cope with multiple linux installations ? I've got few, and I don't want to really have two boot menus like
1. EFI - pointing to grub2 bootmenu
2. Grub2 text bootmenu
I'd like to have them booted directly from each separate entry (stanza) represented by separate icon at rEFInd boot screen.
What's the main concept to manage multiple linux installations (even the same distros, which implies using the same directory name in \EFI\ directory ) ? I am using UEFI, so have I to make separate subdirectories (like linux1, linux2, linux3) in \EFI directory, or rename grubx64.efi names accordingly, but having all files in one directory, or is it another way ?
Previously (0.11.x) I had completely no issues with multiple linux loaders as I've created another stanzas with volume-loader-initrd-options entries and voila, it worked. But now - it doesn't work (maybe because it's on RAID-0 volume ?), and I'm willing to get some order in UEFI times to have it all compatible - especially you mentioned the new EFI kernel attitude which includes initramfs in one file.
Thank you for anly clues.
Last edit: biuro74 2021-02-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It sounds like your upgrades changed filesystem UUIDs, which most distributions rely upon to mount filesystems. If so, one of the tasks you'll have to undertake is to edit each distribution's /etc/fstab file to point to the new correct filesystem. You'll need to use an emergency boot system (something like an Ubuntu installer in its "try before installing" mode should work), and you'll need to know what you're doing -- the process isn't that hard, but it involves a lot of step-by-step decision-making, which makes it hard to give concise instructions.
As to the general principles, rEFInd is intended to work as the primary (and usually only) boot manager. Given the right filesystem drivers and non-ancient kernels, rEFInd can detect and boot each distribution's kernel automatically. It does rely on either a /boot/refind_linux.conf file to hold boot options or an installation that's done in such a way that rEFInd can correctly guess things like the root (/) filesystem's identity, so you may need to create /boot/refind_linux.conf files for each of your distributions. If rEFInd 0.11.x worked, then rEFInd 0.12.0 should, too. (A caveat: There is a known memory management bug in 0.12.0, which can cause rEFInd to hang before it presents any icons. This bug doesn't seem to affect many computers, though -- none of my dozen or so computers is affected, for instance. Macs seem more susceptible than others, but it's definitely a rEFInd bug, not an Apple EFI bug.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does the RAID volume work in EFI? To work in EFI, there must be an EFI RAID driver which is included in the firmware of the computer or the firmware of the RAID card. In either case, the RAID partitions need to exist in the output of the map command in UEFI Shell.
In your stanzas, is volume a volume name (from the file system), or a UUID, or something else?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
but the only difference is now I use UUIDs (which is a bit confusing due to UUIDs and GUUIDs existence - anyway I use UUID taken from GParted) as you can see, and previously (0.11) I was using volumes names.
Issues start when I try to boot another Fedora, because I've reached my knowledge top, so I need to get updated ;-) how linuxes install multiple instances in EFI system (using standard Grub was easy as I simply used various LOADER files pointing to different kernels): because as you know, Fedora creates \EFI\Fedora subdirectory and puts boot files there: grubx64.efi and similar .efi files. This is a point when I simply don't know: will second Fedora (older revision - 31 let's say) installation overwrite this \EFI\Fedora directory, or create Fedora2 dir, of put grubx64_2.efi file ? I can only presume it will overwrite whole directory, so after this - my first linux installation (Fedora 33) will stop working, because grubx64.efi file will point to the second (F31) installation. I simply cannot use two stanzas with the same grubx64.efi LOADERs and different INITRDs, can I - and I probably need second grubx64.efi file created by F31 installation ? I can skip GRUB2-EFI activity, so it will not overwrite previous Fedora \EFI\Fedora boot files, but question is - how to start the other linux using grubx64.efi file then ? Because LOADER path_to_kernel_in/boot_directory does not work anymore.
Does not work - from what I remember - when I choose proper OS icon, it causes "flash" screen like it changed a graphics mode (maybe this is it indeed) and shows the same rEFInd screen, but in black & white.
As said, I'd like to have all stanzas with efi loaders only (previously all loaders was vmlinuz files from /boot directory, it worked and it was really easy to do with grub2-install). I am a bit worried to use grub2-efi at my F31 (chrooted from 33), because of all the mess it might cause (easy to revert, but when I start to copy files, ammend boot order, do resets, chroots etc - I might miss one thing making Fedora 33 unbootable).
And yes/ /etc/fstab files was first ammendments after installing the distros.
Last edit: biuro74 2021-02-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When installing two or more versions of one distribution (like the multiple Fedoras you mention), typically the most recent one installed overwrites the boot loader files in the ESP created by the first one. This can still work, but it relies upon the GRUB configuration scripts to do the right thing, and you'd use GRUB, not rEFInd, to pick between the different Fedora installations.
If you want to use rEFInd to select between multiple Fedora installations, then the best way is to be sure you've installed EFI filesystem drivers that can read whatever filesystem(s) hold the Linux kernels. In most cases that's the ext4fs driver that ships with rEFInd; however, IIRC Fedora has switched to XFS as the default filesystem, and rEFInd doesn't ship with an XFS driver. If that's the case, you'll need to do one of several things:
Copy your Fedora kernels from /boot to somewhere on your ESP (or some other FAT partition) where rEFInd will scan it. For instance, you could use EFI/fedora-31 and EFI/fedora-33 on your ESP. This is awkward and will require maintenance, though. Also, many ESPs aren't big enough to hold kernels from multiple distributions.
Create separate /boot partitions for each of your Fedora installs using a filesystem that rEFInd can read. FAT is easiest from rEFInd's perspective because it requires no extra filesystem drivers; however, many Linux distributions rely on Unix filesystem features in /boot, making FAT a poor choice. I don't recall offhand if Fedora is among these. Thus, ext4fs may be a better choice. It's usually possible to create ~1GiB partitions for this purpose by shrinking some other partition (FROM THE END) by a small amount.
When installing the OSes, override the default choice of XFS and instead use ext4fs or Btrfs, since rEFInd ships with drivers for both. (ReiserFS may also work if your distribution supports it; but it's pretty old and many distributions have dropped support for it.) Making this change post-installation is possible, but it involves an awkward backup-and-restore operation, and you'll need to tweak various details post-restore to get the system to boot.
Use a third-party XFS driver for EFI, like the one provided in Pete Batard's driver set. I can't promise this will work, though; the last time I checked, some of those drivers just hung my test system. I don't recall if the XFS driver was one of the troublesome ones.
I discourage use of manual boot stanzas in most cases. People tend to get details wrong (which is easy to do; I'm not criticizing here), which creates headaches. If a Linux distribution can be booted from rEFInd, chances are the auto-scanning will get it right. If auto-scanning isn't detecting the kernel, then the problem is likely because of a lack of filesystem support or something else that would also prevent a manual boot stanza from working. The example you presented earlier is loading GRUB, not the Linux kernel, and it contains options that are useless in that context. rEFInd should be auto-detecting that GRUB installation, too, making that entry redundant. That might be true of your Win10_SSD entry, too, although the volume specification makes me think you may be loading that loader from an NTFS volume. If so, and if rEFInd isn't auto-detecting it, then that suggests that the Windows boot loader was erased from the ESP at some point. Restoring it to the ESP would be a better solution than using an NTFS driver to read the Windows boot loader. Copying the directory referenced in the manual boot stanza may do the trick; or you may be better off using Windows tools to re-install the boot loader. (You may want to ask about that on a Windows forum, since I, at least, lack the detailed knowledge to describe how to do this off the top of my head.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fedora didn't switch to XFS, but recommends BTRFS, which made me so many troubles with partition imaging under Windows (BTRFS not supported), so finally I've ended up with old, good ext4 probably on the top of LVM, but without using its features like volume group, so rEFInd should run with no caugh :)
I will try that old-school method with backup & restore files, so will see how that works.
Last edit: biuro74 2021-02-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
rEFInd can't read kernels if they're stored inside an LVM; you need plain-old /boot partition if you're using LVM. At least, if you want rEFInd to load the kernel itself; you can do it without a /boot partition if you use GRUB. (At least, that's my understanding; I've never tried GRUB reading kernels from within an LVM setup.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry, there is so many news which got me during "simple" RAID-0 creation that I have to slow down a bit and find out what is what now :) I have had system completely fine, running what I wanted with no issues. Until this small upgrade. BTRFS (aborted), LVM, EFI boot, new rEFInd, grub2-efi etc = it all appeared suddenly on this occassion
I think LVM is not in use, because I've set up partitions under fdisk during W10 installation - and only formatted some of them to ext4 at Fedora install stage. I never trusted Fedora installer partitioning tool, which personally I find as some joke.
Anyway, I use DVD with rEFInd (some older revision) to boot PC in any rescue situation and it detects W10 and all linux kernels, including my old non-RAID hard drive installations (all vmlinuz-based do kernel panic, however, and only grubx64.efi boots fine). If these kernels were at LVM setup, rEFInd wouldn't detect them, would it ?
I need to burn 0.12 .0 to DVD and see how it works as well as take a look into /boot/refind_linux.conf, and how booting goes with another grubx64.efi starter(backup & restore method) after F31 EFI grub2 reconfiguration - I think I missed proper EFI config (which should've been located in \EFI\Fedora\grub.cfg) and created simple grub2 config (/boot/grub2/grub.cfg) instead.
I need to cool down :) and learn what I have missed within last few years, just updating Fedoras. Thank you for replies again. I'll be back soon ;-)
Last edit: biuro74 2021-02-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If these kernels were at LVM setup, rEFInd wouldn't detect them, would it ?
Correct.
I use DVD with rEFInd (some older revision) to boot PC in any rescue situation and it detects W10 and all linux kernels, including my old non-RAID hard drive installations (all vmlinuz-based do kernel panic, however, and only grubx64.efi boots fine).
Based on this description, I suspect that your on-disk rEFInd installation is lacking a driver for whatever filesystem holds your kernels (presumably ext4fs, if you've used that consistently), but the emergency disk has that driver. See the rEFInd drivers documentation for details. You're probably getting the kernel panic for another reason you mention....
I need to... take a look into /boot/refind_linux.conf
That file holds options that are passed to the kernel. Sometimes rEFInd can guess the correct options to use without that file, but sometimes it can't. It's also possible that you have this file but it holds old, invalid data. Either way, if you can boot via GRUB you can create the file by booting with grub and then running the mkrlconf script that comes with rEFInd. Note that you'll need to do this for each Fedora installation separately.
Thus, you probably need to do at least two things to get rEFInd working well:
Install an EFI filesystem driver for ext4fs (or whatever you're using).
Create a /boot/refind_linux.conf file for each of your distributions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello again, I'm back equipped with some new knowledge and experience ;-)
At this stage I think the best would be using stanzas with "firmware_bootnum" token - frankly, when I've found this option at your Rodbooks website, I knew this was it.
At the same moment - asking Fedora forums - I've found a tip I must have multiple ESP partitions. Fortunately, or not - it's not a point :) but it is doable and meets my requirements :) So every linux partition will have its own ESP partition, this will clean up a mess with same directories and files. I've done two quick Fedora installations on some UEFI-based laptop (with two separate ESPs) and it worked - I mean I had two boot entries in UEFI BIOS.
So it's high time to do the same with my desktop now, which I don't like to treat with unchecked solutions as it might damage the order I've got so far.
First - to underline - is I've got all needed FS drivers in "drivers_x64" directory: ext2, ext4, iso9660 and ntfs. They were there all the time. I cannot see any reason they might be unloadable - refind bootloader is in 64-bit version, so the rest - I presume - uses the same architecture.
Now, I've added few more stanzas into my refind config file:
and none of these works. There are nice icons visible in the bootmenu - so stanzas are active - but choosing any of them shows UEFI-Shell message:
Starting <null string>Using load options ''Error: Not Found while loading <null string>* Hit any key to continue *
Efibootmgr out:
** Warning ** : please recreate these using efibootmgr to remove this warning.BootCurrent: 0000Timeout: 2 secondsBootOrder: 0000,0002,0009,000A,000B,001C,0006,0001Boot0000* rEFInd_SSD_RAIDBoot0001 FEDORA311Boot0002* FedoraBoot0006 UEFI: Built-in EFI ShellBoot0009* Windows Boot ManagerBoot000a* UEFI: TSSTcorp DVDWBD SH-B123LBoot000b* UEFI: SanDiskBoot001C* TOSHIBA
I am able to boot 0002 and 0009 directly from UEFI BIOS bootselector obviously, so what might be wrong here, please ?
P.S. I've done 4 stanzas just in case, because I'm not sure which token is correct: "firmware_bootnum" or "firmware-bootnum" as they both are present in Rodbooks rEFInd manual webpage, but none of them works for me.
Last edit: biuro74 2021-02-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, the firmware_bootnum token, and the ability to reboot to EFI-defined boot loaders, are brand new with rEFInd 0.13.0, which I released on February 15. Your report of what's happening makes me think that you're running an older version of rEFInd, so this feature simply won't work. You'll have to upgrade to 0.13.0 or later to get that particular feature to work.
Second, your example stanzas show duplicates -- two each for Boot0002 and Boot0009. This will simply create two entries for each OS in rEFInd's menu, and they'll behave identically (albeit with two different names). I don't see any point to doing this.
Third, I don't think that's a good way to launch Linux. It can be made to work, but it will be slower than other alternatives and it requires that each Linux distribution have its own properly-configured GRUB. Given a properly-configured GRUB, rEFInd should be able to launch those GRUB instances more quickly and more directly in the "traditional" rEFInd way.
Fourth, you mention having ext2fs, ext4fs, ISO-9660 and NTFS EFI drivers in rEFInd. This is asking for trouble. The main point of rEFInd's filesystem drivers is to enable it to read Linux kernels from Linux-native filesystems. The ISO-9660 and NTFS drivers won't help you do that in most situations, and in fact the NTFS driver is a known trouble-maker -- that's why I dropped the binary version a while back. (Note that it is NOT required to boot Windows.) The ext2fs driver is redundant with the ext4fs driver, so there's no point in having both of them. (The ext4fs driver will read all the filesystems that the ext2fs driver will, plus some that ext2fs won't. Thus, probably the ext4fs driver is the best choice -- but ext2fs can be useful if you want to have separate ext2fs /boot partitions and keep rEFInd from reading other ext4fs partitions.) Having too many drivers will slow rEFInd's startup (maybe imperceptibly, maybe by a lot), and more importantly, it can sometimes introduce bugs, including bugs that can cause system hangs. (The NTFS driver did this a lot.) Furthermore, if you do launch all your Linux distributions via the reboot-to-NVRAM-options method, or even through GRUB, then the filesystem drivers will be useless.
Finally, let's get back to basics here: Manual boot stanzas are a Bad Idea for most people. rEFInd's auto-detection tools work very well in most cases, especially if you create /boot/refind_linux.conf files in each of your Linux distributions and install whatever filesystem driver(s) you need to access the kernels. Manual boot stanzas are finicky; it's easy to misconfigure them because of typos or other problems that are trivial to fix but difficult to detect. (Your use of a 0.13.0 option in an earlier version of rEFInd is an example of this.) GRUB can be a pain on a multi-distribution computer, and creating multiple ESPs, as you say you're trying, is simply the workaround for just one of GRUB's problems. rEFInd handles multiple Linux installations quite well if you let it work as intended.
It sounds to me as if your Linux distributions are damaged -- maybe trivially, or maybe seriously. Somebody with expertise could probably get it booting, or at least ascertain what's not worth fixing, pretty quickly. In the absence of better knowledge, my suggestion is to start fresh:
Back up whatever personal data you can't afford to lose
Wipe the disk clean
Install one distribution
Install rEFInd
Test that rEFInd can boot the first distribution
Install the second distribution
Run mkrlconf and refind-mkdefault from the second distribution (these scripts both come with rEFInd)
Test that rEFInd can boot both distributions
Repeat steps 6-8 for the rest of your distributions
Restore your backed-up data
Alternatively, don't try to multi-boot so many distributions. Instead, rely on virtual machines (VirtualBox, KVM/QEMU, VMWare, or whatever) to install OS images inside one primary OS. If you need two or three OSes to have "raw" hardware access, you can multi-boot them, but then put the rest in virtual machines. Most people who want to run several distributions don't need all their OSes to have "raw" hardware access, though; they want to experiment with different package systems or whatnot, and for that, running inside a virtual machine works fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't noticed that revision changed in the meanwhile, so I've downloaded & updated rEFInd bootloader. Now it firmware_bootnum works indeed. And as you said, it works slow, because it performs a machine reset, but I didn't know that until I've checked it myself. So I will drop that method, however it's very simple and convenient way to create stanzas.
Stanzas show duplicates because of post scriptum to my previous message, which you apparently missed :) This problem is solved - proper token is firmware_bootnum, so please check your webpage: https://www.rodsbooks.com/refind/configfile.html#bootnext Manual boot stanzas paraphaph (simple typo).
(I was not sure which token was correct, hence my doubled stanzas as a method to find it out; now they are corrected to proper entries, but whole idea with firmware_bootnum is being aborted by me right now)
Drivers has been in their directories since first rEFInd install years ago, maybe it's my mistake I didn't check them during last years. Now I keep ext4 only as you suggest - I presume I will be checking "vmlinuz" boot method (kernels are in ext4 partition, no more btrfs, no more LVMs), but I really don't want to, as said, as I'd like to keep booting with efi loaders. I will eventually go back to "vmlinuz" loaders as soon as anything else will fail (however I was using them for years).
Finally, let me have own stanzas as I've checked rEFInd and choosed personalised menu due to few reasons (like simple icons which are different for the same systems, but bootable from various devices; I've got my own icons set and rEFInd is not able to match them to correct OS any way). I'm not in majority of users ;-)
My issues with "old" distros are different story, I didn't want to mix these with rEFInd issues, however I must have told too much in some place and voila :) Distros were imaged by Windows "Macrium Reflect" tool before hardware upgrade, and now some of them are totally damaged (that one with BTRFS), and some of them do kernel panic (F31). I will try to repair them (BTRFS probably no chance without writing a tool), but F31 is bootable - it reads kernel/initramfs, so there's proper access to its partition, but probably something wrong happened with graphic drivers (nouveau vs nVidia).
Before I make use of your further suggestions with mkrlconf, I'd like to finish my way with efi loaders, please (there's one thing left as I'm concerned). This is one thing I don't understand:
This is one of testing entries (it's not final, I know options and initrd tokens are not necessary here, I constantly change this entry during testing further things). Loader from which partition should it boot, please ?
These are my partitions ("p1" is my first partition that contains rEFInd installation, W10 and F33 efi loaders, and "p8" is second ESP with F31 efi loader only):
From what I read, a volume token "Sets the volume that's used for subsequent file accesses (by icon and loader(...)", so it should:
- not show a proper icon as I didn't put any icons to "p8" partition (into rEFInd icons directory)
- boot a loader from "p8" partition
whether it shows an icon and runs loader from" p1" (probably, as I think - rEFInd treats EFI partition as the same EFI partition where it is installed on, and not that one with UUID defined by volume token) partition, because F33 boots up instead of F31.
If I only made it working (to run efi bootloader from "p8" partition), I'd have no further questions :)
Sorry for long elaborate.
Last edit: biuro74 2021-03-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the firmware_bootnum option, wouldn't it be useful to have a direct flag that causes rEFInd to parse the boot option (to extract the description, EFI device path, and parameters) and execute the image at the specified EFI device path with the paremeters directly? It would be faster than the current method that uses BootNext and Reset. The current non-direct method has the benefit of bypassing rEFInd (if someone wanted to do that for some reason).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps, but it wouldn't always work; for instance, a firmware_bootnum entry that points to a built-in EFI shell or a firmware PXE-boot option would not work. (At least, rEFInd can't currently launch these types of features directly. It would likely be possible to extend rEFInd to handle them, but it can't do so at the moment.) Thus, adding such an option would lead to a lot of user confusion because it would sometimes work and sometimes not work.
Also, when it would work, a manual boot stanza that did the same thing could definitely be written, and rEFInd might well auto-detect the boot loader, thus making the feature redundant.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree except for one thing: it might be interesting to add the missing ability to create a manual boot stanza that boots a built-in EFI Shell or a firmware PXE boot option in the case where the option does not exist as a bootnum. The stanza could be a guid or a full EFI device path (it may be simpler to just do guid but rEFInd does have the ability to use a full EFI device path).
For example, on a Mac, there is the Apple Startup Manager and there's the Boot Camp loader. Maybe there's a Target Disk Mode EFI app as well and maybe some other useful or interesting apps? rEFInd already does the legacy Boot Camp option by trying various full EFI device paths (same guid - different firmware volumes) - it could probably be improved by searching all the EFI firmware volume images for just the guid.
I suppose the combination of FvSimpleFileSystemDxe and Fv2OnFvThunk is sufficient for most/all firmware apps on my Mac Pro 2008 but I haven't tried them with rEFInd yet. Then I could add the firmware apps as tools (or OSs if necessary) in the rEFInd menu.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for interrupting this interesting firmware_bootnum sub-thread, but I'm still waiting for any clue why a volume token doesn't work properly (at least for me - regarding to multiple EFI partitions) ?
Last edit: biuro74 2021-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't quite understand what your question is; it's hard to track what's going on with your system across multiple posts with a lot of unrelated details and discussions. That said, I believe you're asking about this menuentry:
From what I read, a volume token "Sets the volume that's used for subsequent file accesses (by icon and loader(...)", so it should:
- not show a proper icon as I didn't put any icons to "p8" partition (into rEFInd icons directory)
Your icon specification came before the volume specification, so the icon will be read from the same volume as rEFInd. The loader, though, should be read off of 225A-B0BF.
whether it shows an icon and runs loader from" p1" (probably, as I think - rEFInd treats EFI partition as the same EFI partition where it is installed on, and not that one with UUID defined by volume token) partition, because F33 boots up instead of F31.
What OS GRUB loads is a GRUB issue; GRUB can load an OS from any volume it can read. Now, if you're certain that the GRUB on 225A-B0BF should be loading Fedora 31, but using this entry is launching Fedora 33, then something is wrong, but I can't be sure what that is. One way to isolate this might be to replace the \EFI\fedora\grubx64.efi file on that volume with something else, just as a test. If the new program runs when you select it from rEFInd, then you know that the problem is not with rEFInd; but if GRUB continues to launch, then something is wrong in rEFInd -- perhaps a misconfiguration on your part, or perhaps a bug.
I'll also point out that the initrd and options lines are useless when launching GRUB; they're useful only when launching a Linux kernel with an EFI stub, or some other loaders.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm quite sure the 225A-B0BF's GRUB is loading F31, because I've got an UEFI BIOS entry done with: efibootmgr -c -d /dev/md126 -p 8 -l \\EFI\\fedora\\grubx64.efi -L FEDORA311
which loads that GRUB and its menu shows few F31 kernels to boot.
So - UEFI BIOS can read that ESP and start F31 GRUB, but rEFInd can't, from some reason.
I'm old school man and all (un)related questions I answer & explain, maybe they look like unrelated, but they all matter at least to me, when I remind this thred after some time :)
Last edit: biuro74 2021-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does that boot loader show up in rEFInd's auto-scan list? If so, does it work as expected? If that works, but your manual boot stanza is not working, then something about that stanza is incorrect -- perhaps it's a typo in the volume specification or filename; or maybe the unnecessary options line is causing GRUB to misbehave. This is, by far, the #1 most common problem with manual boot stanzas.
If rEFInd's auto-scan detects that GRUB but rEFInd refuses to launch it or something goes wrong when you do so, then it might well be a rEFInd bug, but it's hard to know without more information about the details of what's going wrong.
It might be helpful if you'd enable logging (log_level 1 should be adequate) and post a link to the resulting refind.log file, along with a description of what you did, what happened, and what you expected to happen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's not valid, unless the partition or filesystem has a name of 225A-B0BF. That string is a FAT filesystem serial number, which is not something that rEFInd will recognize. When rEFInd fails to parse that, it won't change the active volume, and subsequent options will read the loader from the current volume (presumably the ESP). If you want to read from somewhere else, you must specify, to quote the rEFInd documentation:
You pass this token a filesystem's label, a partition's label, or a partition's GUID.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So - shortly - ESPs are not recognizable for loader token at this moment ?
As far as I know, I can't relabel ESP, and they all have the same (filesystem ?) label "System" by default. Maybe is it any chance to make some workaround in rEFInd code to recognize ESPs - or all FATs in general - at loading all partitions stage and identify them by FAT serial number (because it's all they can be identified by, I'm afraid - or am I wrong ?).
Last edit: biuro74 2021-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So - shortly - ESPs are not recognizable for loader token at this moment ?
That's not correct. The ESP on which rEFInd is installed will be used by default in manual boot stanzas. You can specify another one in any of the three ways noted in the documentation snippet I quoted: A filesystem label, a partition label, or a partition GUID. You can acquire all three of these identifiers from blkid in Linux, among other places. For instance, here's information on the ESP of the computer I'm using now:
$ sudo blkid /dev/nvme0n1p1
/dev/nvme0n1p1: LABEL_FATBOOT="NVME_SSD"LABEL="NVME_SSD"UUID="6CB1-160F"TYPE="vfat"PARTLABEL="EFI system partition"PARTUUID="5f63fbfe-1a11-4ed8-80ff-13f1df6f04c0"
This partition has a filesystem label of "NVME_SSD", a partition label of "EFI system partition", and a partition GUID of "5f63fbfe-1a11-4ed8-80ff-13f1df6f04c0".
As far as I know, I can't relabel ESP, and they all have the same (filesystem ?) label "System" by default.
The fatlabel tool can change the filesystem label of a FAT filesystem; or you can use the GUID or partition label. The GUIDs should be unique for each partition, and can be obtained using blkid, gdisk, or other tools. The partition label might or might not be unique, but it can be changed with gdisk.
BTW, this is an example of what I meant when I wrote that manual boot stanzas are finicky. You used a FAT filesystem serial number instead of any of the valid partition identifiers, and I, the program's author, didn't immediately recognize this error. rEFInd's auto-scanning feature won't make that error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On macOS, the EFI partition is usually labeled EFI. I wouldn't use a label for the EFI partition anyway since all the EFI partitions usually have the same name and it wouldn't look like an EFI partition if it was renamed.
EFI partitions usually exist only on GPT formatted disks. Each GPT partition has a partition UUID. In macOS, diskutil info disk0s1 will get the UUID for the first partition of the first disk which is usually an EFI partition.
It might be nice for rEFInd to be able to use Volume IDs. It would have to read the first blocks of a partition (which it already does) and extract the ID depending on the file system. For HFS+ there's a 64 bit big-endian value in the 3rd block (block 2) at offset 0x68.
I believe GRUB has a simple alternative method so you don't have to give a volume a unique name or know it's partition ID or volume ID. Instead, you can ask GRUB to find a volume by looking for a uniquely named file or folder in the root of a volume. I add an empty folder to all my EFI partitions so I know which one I'm looking at when I have them all mounted at once.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, now it works with that UID given by blkid.
Previously, I was using "UID" given by Gparted and ls -lha /dev/disk/by-uuid. And altough I was aware of few "UID"s (UUID, GUID etc), I was pretty convinced that these tools would give me a correct UID in case of FAT-based partition, but apparently there are too many UIDs - and given by various tools - which leads to nothing but confusion. I am really sorry you have to deal with that mess, because OS makers try to force own solutions instead of present one common standard; I believe all programmers would appreciate it.
Thank you for your thoughts and time. Have a nice beer ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Universally Unique Identifier (UUID) -- This is a 128-bit (16-byte) number that's used to identify Unix filesystems, as database keys, and for various other purposes.
Globally Unique Identifier (GUID) -- This is very similar to a UUID, but this term is generally favored by Microsoft and Intel, and hence is used in EFI documentation.
UUIDs/GUIDs are large enough that, if generated in any of several approved ways, the odds of any two properly-chosen UUIDs being identical are statistically negligible. That is, the UUID of my Linux root filesystem is pretty much guaranteed to not be identical to the UUID of your (or of anybody else's) Linux root filesystem; and the UUID of my Linux root filesystem is pretty much guaranteed to not match my /home filesystem, either (unless I deliberately set them to be identical). This makes UUIDs useful in the context of disk device identification because they can be used in configuration files or whatnot without much concern that they'll accidentally refer to the wrong disk.
By whatever name, a UUID/GUID takes a specific format. Most Linux and macOS filesystems use UUIDs as serial numbers, but not all filesystem serial numbers are UUIDs. FAT and NTFS, in particular, have filesystem serial numbers that are not UUIDs. FAT disks have only 4-byte serial numbers, so although collisions are theoretically uncommon if they were assigned randomly, they can happen, particularly if an imperfect algorithm is used to generate the serial numbers. Such imperfect algorithms have been used in the past, so in fact collisions are pretty common -- or at least, they were some years ago. (I haven't looked into how common this is today.)
The GUID Partition Table (GPT), as the full name implies, relies heavily on GUIDs. GUIDs serve as partition type codes, to uniquely identify partitions, and to uniquely identify the disk. Note that the partition GUID (called the "partition UUID" in Linux) is distinct from the filesystem UUID -- and because not all filesystems use UUIDs, the latter might not technically exist. Some Linux tools, though, like blkid, report (or expect to receive) filesystem UUIDs, and so they typically substitute the filesystem serial numbers, even though they're technically mis-labeled as UUIDs.
Because GUIDs are used by GPT, but not by MBR, you can't really count on a partition GUID being available with 100% certainty -- but the vast majority of EFI-based computers use GPT disks, so GUIDs do exist with high probability, particularly on internal media like hard disks, SSDs, and NVMe devices.
EFI provides a way to learn the filesystem's label, so rEFInd has long used this information to display the name of the filesystem on which a loader resides. Most Linux tools don't bother to set this information, though.
AFAIK, EFI provides no way to learn the partition name, partition GUID, or filesystem UUID. rEFInd has to dig further to do this -- it reads and parses the GPT data structures to get the partition name and GUID, and does some minimal parsing of the raw partition data to extract the filesystem UUID. The partition data, in the case of GPT disks, is quite complete. The filesystem UUID data is less reliable, considered across all filesystem types. In particular, rEFInd extracts this data for NTFS, FAT, ext2/3/4fs, and ReiserFS -- but it's not really a UUID for NTFS and FAT.
rEFInd tracks both the partition GUID and the filesystem UUID when it can determine those values. The partition GUID is more certain to exist. Filesystem UUIDs are trickier, since they might not exist; or rEFInd might not be able to parse them even if they do exist. rEFInd reads the FAT filesystem serial number into the filesystem UUID data structure, but it's used only to identify duplicate filesystems (as in a software RAID array). In principle, rEFInd could parse this further and enable specifying a FAT filesystem's serial number as a volume identifier; or use the real UUIDs in filesystems like ext4fs for this purpose; but there's really very little need for this. GPT is used pretty much universally on EFI-based computers, so partition GUIDs are likely to be more reliable than FAT serial numbers, or even true filesystem UUIDs (which might or might not be extracted by rEFInd, depending on the filesystem), as identifiers. This is why rEFInd does not offer a filesystem UUID or serial number option as a volume specifier -- there are more reliable ways to uniquely identify a volume.
All of these features can be changed by you, if you so desire, as outlined in my earlier messages -- you can change the filesystem's name or UUID/serial number with filesystem-specific tools; or you can change a partition's name or GUID using partitioning software. If you're setting up a manual boot stanza, you may find it convenient to change a partition's name, for instance, by using gdisk or some other disk partitioning tool. Alternatively, you can use the existing GUID value, which will be very un-memorable to a human but very reliable.
When relying on rEFInd's auto-scanning feature, rEFInd keeps track of the partitions internally using EFI device handles, which are generated on the fly by the EFI; you needn't be concerned about them. rEFInd uses a filesystem name or partition name as part of the display of the boot loader information (in the "Boot foo from bar" description -- "bar" in this example is a filesystem or partition name, or a description if neither of those is available). This name is also used as a clue in searching for a tag icon. This is part of why I strongly encourage the use of rEFInd's auto-scanning feature rather than manual boot stanzas -- rEFInd can track volumes internally more reliably than you can by cross-referencing various sources of information.
Concerning the idea of using a file written to the root directory of a filesystem to identify the disk, that also seems like a terribly sub-optimal way to do it. The partition GUID is ugly but reliable. If you're going to the effort to write an identifying file, you might as well set a partition name or filesystem name instead; that will be less obtrusive and less likely to be accidentally deleted.
IMHO, there's little reason to not give each ESP a unique partition name, if your system has multiple ESPs. You can simply include "ESP" in the partition name to identify it as an ESP, while setting something else uniquely -- for instance, "Windows ESP" and "Linux ESP". Utilities that need to identify ESPs as such typically rely on the partition type code, not the partition name, to do this. The name is for human consumption, and so should be treated as such.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Thank you for the newest 0.12.0 revision.
I'v e installed it on the occassion on some hardware upgrade, which caused some fresh Linux installs and it's how the mess begins :)
I can't make it working with manual stanzas only where linux entries use "old school":
volume
loader
initrd
options
It simply doesn't work (frankly I've made partition images as a backups and after hardware update restored them in the same order, but making changes in UUIDs, configuring&reinstalling grub2 via chroot etc) - after choosing such "old schooled" entry screen becomes black&white (like mono mode turned on) or shows some UEFI message and that's it.
I've managed it somehow to boot via grubx64.efi (boot directly after picking up Linux entry).
And this is a place for correct question and where my issues start,
How to cope with multiple linux installations ? I've got few, and I don't want to really have two boot menus like
1. EFI - pointing to grub2 bootmenu
2. Grub2 text bootmenu
I'd like to have them booted directly from each separate entry (stanza) represented by separate icon at rEFInd boot screen.
What's the main concept to manage multiple linux installations (even the same distros, which implies using the same directory name in \EFI\ directory ) ? I am using UEFI, so have I to make separate subdirectories (like linux1, linux2, linux3) in \EFI directory, or rename grubx64.efi names accordingly, but having all files in one directory, or is it another way ?
Previously (0.11.x) I had completely no issues with multiple linux loaders as I've created another stanzas with volume-loader-initrd-options entries and voila, it worked. But now - it doesn't work (maybe because it's on RAID-0 volume ?), and I'm willing to get some order in UEFI times to have it all compatible - especially you mentioned the new EFI kernel attitude which includes initramfs in one file.
Thank you for anly clues.
Last edit: biuro74 2021-02-03
It sounds like your upgrades changed filesystem UUIDs, which most distributions rely upon to mount filesystems. If so, one of the tasks you'll have to undertake is to edit each distribution's
/etc/fstabfile to point to the new correct filesystem. You'll need to use an emergency boot system (something like an Ubuntu installer in its "try before installing" mode should work), and you'll need to know what you're doing -- the process isn't that hard, but it involves a lot of step-by-step decision-making, which makes it hard to give concise instructions.As to the general principles, rEFInd is intended to work as the primary (and usually only) boot manager. Given the right filesystem drivers and non-ancient kernels, rEFInd can detect and boot each distribution's kernel automatically. It does rely on either a
/boot/refind_linux.conffile to hold boot options or an installation that's done in such a way that rEFInd can correctly guess things like the root (/) filesystem's identity, so you may need to create/boot/refind_linux.conffiles for each of your distributions. If rEFInd 0.11.x worked, then rEFInd 0.12.0 should, too. (A caveat: There is a known memory management bug in 0.12.0, which can cause rEFInd to hang before it presents any icons. This bug doesn't seem to affect many computers, though -- none of my dozen or so computers is affected, for instance. Macs seem more susceptible than others, but it's definitely a rEFInd bug, not an Apple EFI bug.)Was 0.11.x working on non-RAID-0 volume?
Does the RAID volume work in EFI? To work in EFI, there must be an EFI RAID driver which is included in the firmware of the computer or the firmware of the RAID card. In either case, the RAID partitions need to exist in the output of the
mapcommand in UEFI Shell.In your stanzas, is
volumea volume name (from the file system), or a UUID, or something else?Hi,
Thank you for replies.
RAID volume works in EFI - I can boot either Windows 10 or Fedora through rEFInd and stanzas:
but the only difference is now I use UUIDs (which is a bit confusing due to UUIDs and GUUIDs existence - anyway I use UUID taken from GParted) as you can see, and previously (0.11) I was using volumes names.
Issues start when I try to boot another Fedora, because I've reached my knowledge top, so I need to get updated ;-) how linuxes install multiple instances in EFI system (using standard Grub was easy as I simply used various LOADER files pointing to different kernels): because as you know, Fedora creates \EFI\Fedora subdirectory and puts boot files there: grubx64.efi and similar .efi files. This is a point when I simply don't know: will second Fedora (older revision - 31 let's say) installation overwrite this \EFI\Fedora directory, or create Fedora2 dir, of put grubx64_2.efi file ? I can only presume it will overwrite whole directory, so after this - my first linux installation (Fedora 33) will stop working, because grubx64.efi file will point to the second (F31) installation. I simply cannot use two stanzas with the same grubx64.efi LOADERs and different INITRDs, can I - and I probably need second grubx64.efi file created by F31 installation ? I can skip GRUB2-EFI activity, so it will not overwrite previous Fedora \EFI\Fedora boot files, but question is - how to start the other linux using grubx64.efi file then ? Because LOADER path_to_kernel_in/boot_directory does not work anymore.
Does not work - from what I remember - when I choose proper OS icon, it causes "flash" screen like it changed a graphics mode (maybe this is it indeed) and shows the same rEFInd screen, but in black & white.
As said, I'd like to have all stanzas with efi loaders only (previously all loaders was vmlinuz files from /boot directory, it worked and it was really easy to do with grub2-install). I am a bit worried to use grub2-efi at my F31 (chrooted from 33), because of all the mess it might cause (easy to revert, but when I start to copy files, ammend boot order, do resets, chroots etc - I might miss one thing making Fedora 33 unbootable).
And yes/ /etc/fstab files was first ammendments after installing the distros.
Last edit: biuro74 2021-02-13
When installing two or more versions of one distribution (like the multiple Fedoras you mention), typically the most recent one installed overwrites the boot loader files in the ESP created by the first one. This can still work, but it relies upon the GRUB configuration scripts to do the right thing, and you'd use GRUB, not rEFInd, to pick between the different Fedora installations.
If you want to use rEFInd to select between multiple Fedora installations, then the best way is to be sure you've installed EFI filesystem drivers that can read whatever filesystem(s) hold the Linux kernels. In most cases that's the ext4fs driver that ships with rEFInd; however, IIRC Fedora has switched to XFS as the default filesystem, and rEFInd doesn't ship with an XFS driver. If that's the case, you'll need to do one of several things:
/bootto somewhere on your ESP (or some other FAT partition) where rEFInd will scan it. For instance, you could useEFI/fedora-31andEFI/fedora-33on your ESP. This is awkward and will require maintenance, though. Also, many ESPs aren't big enough to hold kernels from multiple distributions./bootpartitions for each of your Fedora installs using a filesystem that rEFInd can read. FAT is easiest from rEFInd's perspective because it requires no extra filesystem drivers; however, many Linux distributions rely on Unix filesystem features in/boot, making FAT a poor choice. I don't recall offhand if Fedora is among these. Thus, ext4fs may be a better choice. It's usually possible to create ~1GiB partitions for this purpose by shrinking some other partition (FROM THE END) by a small amount.I discourage use of manual boot stanzas in most cases. People tend to get details wrong (which is easy to do; I'm not criticizing here), which creates headaches. If a Linux distribution can be booted from rEFInd, chances are the auto-scanning will get it right. If auto-scanning isn't detecting the kernel, then the problem is likely because of a lack of filesystem support or something else that would also prevent a manual boot stanza from working. The example you presented earlier is loading GRUB, not the Linux kernel, and it contains options that are useless in that context. rEFInd should be auto-detecting that GRUB installation, too, making that entry redundant. That might be true of your
Win10_SSDentry, too, although thevolumespecification makes me think you may be loading that loader from an NTFS volume. If so, and if rEFInd isn't auto-detecting it, then that suggests that the Windows boot loader was erased from the ESP at some point. Restoring it to the ESP would be a better solution than using an NTFS driver to read the Windows boot loader. Copying the directory referenced in the manual boot stanza may do the trick; or you may be better off using Windows tools to re-install the boot loader. (You may want to ask about that on a Windows forum, since I, at least, lack the detailed knowledge to describe how to do this off the top of my head.)Fedora didn't switch to XFS, but recommends BTRFS, which made me so many troubles with partition imaging under Windows (BTRFS not supported), so finally I've ended up with old, good ext4 probably on the top of LVM, but without using its features like volume group, so rEFInd should run with no caugh :)
I will try that old-school method with backup & restore files, so will see how that works.
Last edit: biuro74 2021-02-13
rEFInd can't read kernels if they're stored inside an LVM; you need plain-old
/bootpartition if you're using LVM. At least, if you want rEFInd to load the kernel itself; you can do it without a/bootpartition if you use GRUB. (At least, that's my understanding; I've never tried GRUB reading kernels from within an LVM setup.)I'm sorry, there is so many news which got me during "simple" RAID-0 creation that I have to slow down a bit and find out what is what now :) I have had system completely fine, running what I wanted with no issues. Until this small upgrade. BTRFS (aborted), LVM, EFI boot, new rEFInd, grub2-efi etc = it all appeared suddenly on this occassion
I think LVM is not in use, because I've set up partitions under fdisk during W10 installation - and only formatted some of them to ext4 at Fedora install stage. I never trusted Fedora installer partitioning tool, which personally I find as some joke.
Anyway, I use DVD with rEFInd (some older revision) to boot PC in any rescue situation and it detects W10 and all linux kernels, including my old non-RAID hard drive installations (all vmlinuz-based do kernel panic, however, and only grubx64.efi boots fine). If these kernels were at LVM setup, rEFInd wouldn't detect them, would it ?
I need to burn 0.12 .0 to DVD and see how it works as well as take a look into /boot/refind_linux.conf, and how booting goes with another grubx64.efi starter(backup & restore method) after F31 EFI grub2 reconfiguration - I think I missed proper EFI config (which should've been located in \EFI\Fedora\grub.cfg) and created simple grub2 config (/boot/grub2/grub.cfg) instead.
I need to cool down :) and learn what I have missed within last few years, just updating Fedoras. Thank you for replies again. I'll be back soon ;-)
Last edit: biuro74 2021-02-14
Correct.
Based on this description, I suspect that your on-disk rEFInd installation is lacking a driver for whatever filesystem holds your kernels (presumably ext4fs, if you've used that consistently), but the emergency disk has that driver. See the rEFInd drivers documentation for details. You're probably getting the kernel panic for another reason you mention....
That file holds options that are passed to the kernel. Sometimes rEFInd can guess the correct options to use without that file, but sometimes it can't. It's also possible that you have this file but it holds old, invalid data. Either way, if you can boot via GRUB you can create the file by booting with grub and then running the
mkrlconfscript that comes with rEFInd. Note that you'll need to do this for each Fedora installation separately.Thus, you probably need to do at least two things to get rEFInd working well:
/boot/refind_linux.conffile for each of your distributions.Hello again, I'm back equipped with some new knowledge and experience ;-)
At this stage I think the best would be using stanzas with "firmware_bootnum" token - frankly, when I've found this option at your Rodbooks website, I knew this was it.
At the same moment - asking Fedora forums - I've found a tip I must have multiple ESP partitions. Fortunately, or not - it's not a point :) but it is doable and meets my requirements :) So every linux partition will have its own ESP partition, this will clean up a mess with same directories and files. I've done two quick Fedora installations on some UEFI-based laptop (with two separate ESPs) and it worked - I mean I had two boot entries in UEFI BIOS.
So it's high time to do the same with my desktop now, which I don't like to treat with unchecked solutions as it might damage the order I've got so far.
First - to underline - is I've got all needed FS drivers in "drivers_x64" directory: ext2, ext4, iso9660 and ntfs. They were there all the time. I cannot see any reason they might be unloadable - refind bootloader is in 64-bit version, so the rest - I presume - uses the same architecture.
Now, I've added few more stanzas into my refind config file:
and none of these works. There are nice icons visible in the bootmenu - so stanzas are active - but choosing any of them shows UEFI-Shell message:
Efibootmgr out:
I am able to boot 0002 and 0009 directly from UEFI BIOS bootselector obviously, so what might be wrong here, please ?
P.S. I've done 4 stanzas just in case, because I'm not sure which token is correct: "firmware_bootnum" or "firmware-bootnum" as they both are present in Rodbooks rEFInd manual webpage, but none of them works for me.
Last edit: biuro74 2021-02-27
First, the
firmware_bootnumtoken, and the ability to reboot to EFI-defined boot loaders, are brand new with rEFInd 0.13.0, which I released on February 15. Your report of what's happening makes me think that you're running an older version of rEFInd, so this feature simply won't work. You'll have to upgrade to 0.13.0 or later to get that particular feature to work.Second, your example stanzas show duplicates -- two each for
Boot0002andBoot0009. This will simply create two entries for each OS in rEFInd's menu, and they'll behave identically (albeit with two different names). I don't see any point to doing this.Third, I don't think that's a good way to launch Linux. It can be made to work, but it will be slower than other alternatives and it requires that each Linux distribution have its own properly-configured GRUB. Given a properly-configured GRUB, rEFInd should be able to launch those GRUB instances more quickly and more directly in the "traditional" rEFInd way.
Fourth, you mention having ext2fs, ext4fs, ISO-9660 and NTFS EFI drivers in rEFInd. This is asking for trouble. The main point of rEFInd's filesystem drivers is to enable it to read Linux kernels from Linux-native filesystems. The ISO-9660 and NTFS drivers won't help you do that in most situations, and in fact the NTFS driver is a known trouble-maker -- that's why I dropped the binary version a while back. (Note that it is NOT required to boot Windows.) The ext2fs driver is redundant with the ext4fs driver, so there's no point in having both of them. (The ext4fs driver will read all the filesystems that the ext2fs driver will, plus some that ext2fs won't. Thus, probably the ext4fs driver is the best choice -- but ext2fs can be useful if you want to have separate ext2fs
/bootpartitions and keep rEFInd from reading other ext4fs partitions.) Having too many drivers will slow rEFInd's startup (maybe imperceptibly, maybe by a lot), and more importantly, it can sometimes introduce bugs, including bugs that can cause system hangs. (The NTFS driver did this a lot.) Furthermore, if you do launch all your Linux distributions via the reboot-to-NVRAM-options method, or even through GRUB, then the filesystem drivers will be useless.Finally, let's get back to basics here: Manual boot stanzas are a Bad Idea for most people. rEFInd's auto-detection tools work very well in most cases, especially if you create
/boot/refind_linux.conffiles in each of your Linux distributions and install whatever filesystem driver(s) you need to access the kernels. Manual boot stanzas are finicky; it's easy to misconfigure them because of typos or other problems that are trivial to fix but difficult to detect. (Your use of a 0.13.0 option in an earlier version of rEFInd is an example of this.) GRUB can be a pain on a multi-distribution computer, and creating multiple ESPs, as you say you're trying, is simply the workaround for just one of GRUB's problems. rEFInd handles multiple Linux installations quite well if you let it work as intended.It sounds to me as if your Linux distributions are damaged -- maybe trivially, or maybe seriously. Somebody with expertise could probably get it booting, or at least ascertain what's not worth fixing, pretty quickly. In the absence of better knowledge, my suggestion is to start fresh:
mkrlconfandrefind-mkdefaultfrom the second distribution (these scripts both come with rEFInd)Alternatively, don't try to multi-boot so many distributions. Instead, rely on virtual machines (VirtualBox, KVM/QEMU, VMWare, or whatever) to install OS images inside one primary OS. If you need two or three OSes to have "raw" hardware access, you can multi-boot them, but then put the rest in virtual machines. Most people who want to run several distributions don't need all their OSes to have "raw" hardware access, though; they want to experiment with different package systems or whatnot, and for that, running inside a virtual machine works fine.
Thank you for reply.
I haven't noticed that revision changed in the meanwhile, so I've downloaded & updated rEFInd bootloader. Now it
firmware_bootnumworks indeed. And as you said, it works slow, because it performs a machine reset, but I didn't know that until I've checked it myself. So I will drop that method, however it's very simple and convenient way to create stanzas.Stanzas show duplicates because of post scriptum to my previous message, which you apparently missed :) This problem is solved - proper token is
firmware_bootnum, so please check your webpage:https://www.rodsbooks.com/refind/configfile.html#bootnext
Manual boot stanzas paraphaph (simple typo).
(I was not sure which token was correct, hence my doubled stanzas as a method to find it out; now they are corrected to proper entries, but whole idea with firmware_bootnum is being aborted by me right now)
Drivers has been in their directories since first rEFInd install years ago, maybe it's my mistake I didn't check them during last years. Now I keep ext4 only as you suggest - I presume I will be checking "vmlinuz" boot method (kernels are in ext4 partition, no more btrfs, no more LVMs), but I really don't want to, as said, as I'd like to keep booting with efi loaders. I will eventually go back to "vmlinuz" loaders as soon as anything else will fail (however I was using them for years).
Finally, let me have own stanzas as I've checked rEFInd and choosed personalised menu due to few reasons (like simple icons which are different for the same systems, but bootable from various devices; I've got my own icons set and rEFInd is not able to match them to correct OS any way). I'm not in majority of users ;-)
My issues with "old" distros are different story, I didn't want to mix these with rEFInd issues, however I must have told too much in some place and voila :) Distros were imaged by Windows "Macrium Reflect" tool before hardware upgrade, and now some of them are totally damaged (that one with BTRFS), and some of them do kernel panic (F31). I will try to repair them (BTRFS probably no chance without writing a tool), but F31 is bootable - it reads kernel/initramfs, so there's proper access to its partition, but probably something wrong happened with graphic drivers (nouveau vs nVidia).
Before I make use of your further suggestions with mkrlconf, I'd like to finish my way with efi loaders, please (there's one thing left as I'm concerned). This is one thing I don't understand:
This is one of testing entries (it's not final, I know options and initrd tokens are not necessary here, I constantly change this entry during testing further things). Loader from which partition should it boot, please ?
These are my partitions ("p1" is my first partition that contains rEFInd installation, W10 and F33 efi loaders, and "p8" is second ESP with F31 efi loader only):
And these are UUIDS:
From what I read, a
volumetoken "Sets the volume that's used for subsequent file accesses (by icon and loader(...)", so it should:- not show a proper icon as I didn't put any icons to "p8" partition (into rEFInd icons directory)
- boot a loader from "p8" partition
whether it shows an icon and runs loader from" p1" (probably, as I think - rEFInd treats EFI partition as the same EFI partition where it is installed on, and not that one with UUID defined by
volumetoken) partition, because F33 boots up instead of F31.If I only made it working (to run efi bootloader from "p8" partition), I'd have no further questions :)
Sorry for long elaborate.
Last edit: biuro74 2021-03-01
For the
firmware_bootnumoption, wouldn't it be useful to have adirectflag that causes rEFInd to parse the boot option (to extract the description, EFI device path, and parameters) and execute the image at the specified EFI device path with the paremeters directly? It would be faster than the current method that usesBootNextand Reset. The current non-direct method has the benefit of bypassing rEFInd (if someone wanted to do that for some reason).Perhaps, but it wouldn't always work; for instance, a
firmware_bootnumentry that points to a built-in EFI shell or a firmware PXE-boot option would not work. (At least, rEFInd can't currently launch these types of features directly. It would likely be possible to extend rEFInd to handle them, but it can't do so at the moment.) Thus, adding such an option would lead to a lot of user confusion because it would sometimes work and sometimes not work.Also, when it would work, a manual boot stanza that did the same thing could definitely be written, and rEFInd might well auto-detect the boot loader, thus making the feature redundant.
I agree except for one thing: it might be interesting to add the missing ability to create a manual boot stanza that boots a built-in EFI Shell or a firmware PXE boot option in the case where the option does not exist as a bootnum. The stanza could be a guid or a full EFI device path (it may be simpler to just do guid but rEFInd does have the ability to use a full EFI device path).
For example, on a Mac, there is the Apple Startup Manager and there's the Boot Camp loader. Maybe there's a Target Disk Mode EFI app as well and maybe some other useful or interesting apps? rEFInd already does the legacy Boot Camp option by trying various full EFI device paths (same guid - different firmware volumes) - it could probably be improved by searching all the EFI firmware volume images for just the guid.
Searching the EFI firmware volume images is done using the firmware volume protocols. A driver can be installed that turns a firmware volume into a file system. See the example at
https://forums.macrumors.com/threads/updating-a-mac-pro-s-cpu-microcode.2114187/post-28964173
I suppose the combination of FvSimpleFileSystemDxe and Fv2OnFvThunk is sufficient for most/all firmware apps on my Mac Pro 2008 but I haven't tried them with rEFInd yet. Then I could add the firmware apps as tools (or OSs if necessary) in the rEFInd menu.
Sorry for interrupting this interesting
firmware_bootnumsub-thread, but I'm still waiting for any clue why avolumetoken doesn't work properly (at least for me - regarding to multiple EFI partitions) ?Last edit: biuro74 2021-03-14
I don't quite understand what your question is; it's hard to track what's going on with your system across multiple posts with a lot of unrelated details and discussions. That said, I believe you're asking about this
menuentry:Concerning this, you wrote:
Your
iconspecification came before thevolumespecification, so the icon will be read from the same volume as rEFInd. The loader, though, should be read off of 225A-B0BF.What OS GRUB loads is a GRUB issue; GRUB can load an OS from any volume it can read. Now, if you're certain that the GRUB on 225A-B0BF should be loading Fedora 31, but using this entry is launching Fedora 33, then something is wrong, but I can't be sure what that is. One way to isolate this might be to replace the
\EFI\fedora\grubx64.efifile on that volume with something else, just as a test. If the new program runs when you select it from rEFInd, then you know that the problem is not with rEFInd; but if GRUB continues to launch, then something is wrong in rEFInd -- perhaps a misconfiguration on your part, or perhaps a bug.I'll also point out that the
initrdandoptionslines are useless when launching GRUB; they're useful only when launching a Linux kernel with an EFI stub, or some other loaders.I'm quite sure the 225A-B0BF's GRUB is loading F31, because I've got an UEFI BIOS entry done with:
efibootmgr -c -d /dev/md126 -p 8 -l \\EFI\\fedora\\grubx64.efi -L FEDORA311which loads that GRUB and its menu shows few F31 kernels to boot.
So - UEFI BIOS can read that ESP and start F31 GRUB, but rEFInd can't, from some reason.
I'm old school man and all (un)related questions I answer & explain, maybe they look like unrelated, but they all matter at least to me, when I remind this thred after some time :)
Last edit: biuro74 2021-03-14
Does that boot loader show up in rEFInd's auto-scan list? If so, does it work as expected? If that works, but your manual boot stanza is not working, then something about that stanza is incorrect -- perhaps it's a typo in the volume specification or filename; or maybe the unnecessary
optionsline is causing GRUB to misbehave. This is, by far, the #1 most common problem with manual boot stanzas.If rEFInd's auto-scan detects that GRUB but rEFInd refuses to launch it or something goes wrong when you do so, then it might well be a rEFInd bug, but it's hard to know without more information about the details of what's going wrong.
It might be helpful if you'd enable logging (
log_level 1should be adequate) and post a link to the resultingrefind.logfile, along with a description of what you did, what happened, and what you expected to happen.I think I know what the problem is:
volume 225A-B0BFThat's not valid, unless the partition or filesystem has a name of 225A-B0BF. That string is a FAT filesystem serial number, which is not something that rEFInd will recognize. When rEFInd fails to parse that, it won't change the active volume, and subsequent options will read the
loaderfrom the current volume (presumably the ESP). If you want to read from somewhere else, you must specify, to quote the rEFInd documentation:So - shortly - ESPs are not recognizable for loader token at this moment ?
As far as I know, I can't relabel ESP, and they all have the same (filesystem ?) label "System" by default. Maybe is it any chance to make some workaround in rEFInd code to recognize ESPs - or all FATs in general - at loading all partitions stage and identify them by FAT serial number (because it's all they can be identified by, I'm afraid - or am I wrong ?).
Last edit: biuro74 2021-03-14
That's not correct. The ESP on which rEFInd is installed will be used by default in manual boot stanzas. You can specify another one in any of the three ways noted in the documentation snippet I quoted: A filesystem label, a partition label, or a partition GUID. You can acquire all three of these identifiers from
blkidin Linux, among other places. For instance, here's information on the ESP of the computer I'm using now:This partition has a filesystem label of "NVME_SSD", a partition label of "EFI system partition", and a partition GUID of "5f63fbfe-1a11-4ed8-80ff-13f1df6f04c0".
The
fatlabeltool can change the filesystem label of a FAT filesystem; or you can use the GUID or partition label. The GUIDs should be unique for each partition, and can be obtained usingblkid,gdisk, or other tools. The partition label might or might not be unique, but it can be changed withgdisk.BTW, this is an example of what I meant when I wrote that manual boot stanzas are finicky. You used a FAT filesystem serial number instead of any of the valid partition identifiers, and I, the program's author, didn't immediately recognize this error. rEFInd's auto-scanning feature won't make that error.
On macOS, the EFI partition is usually labeled
EFI. I wouldn't use a label for the EFI partition anyway since all the EFI partitions usually have the same name and it wouldn't look like an EFI partition if it was renamed.EFI partitions usually exist only on GPT formatted disks. Each GPT partition has a partition UUID. In macOS,
diskutil info disk0s1will get the UUID for the first partition of the first disk which is usually an EFI partition.It might be nice for rEFInd to be able to use Volume IDs. It would have to read the first blocks of a partition (which it already does) and extract the ID depending on the file system. For HFS+ there's a 64 bit big-endian value in the 3rd block (block 2) at offset 0x68.
I believe GRUB has a simple alternative method so you don't have to give a volume a unique name or know it's partition ID or volume ID. Instead, you can ask GRUB to find a volume by looking for a uniquely named file or folder in the root of a volume. I add an empty folder to all my EFI partitions so I know which one I'm looking at when I have them all mounted at once.
OK, now it works with that UID given by
blkid.Previously, I was using "UID" given by Gparted and
ls -lha /dev/disk/by-uuid. And altough I was aware of few "UID"s (UUID, GUID etc), I was pretty convinced that these tools would give me a correct UID in case of FAT-based partition, but apparently there are too many UIDs - and given by various tools - which leads to nothing but confusion. I am really sorry you have to deal with that mess, because OS makers try to force own solutions instead of present one common standard; I believe all programmers would appreciate it.Thank you for your thoughts and time. Have a nice beer ;-)
First, some terminology:
UUIDs/GUIDs are large enough that, if generated in any of several approved ways, the odds of any two properly-chosen UUIDs being identical are statistically negligible. That is, the UUID of my Linux root filesystem is pretty much guaranteed to not be identical to the UUID of your (or of anybody else's) Linux root filesystem; and the UUID of my Linux root filesystem is pretty much guaranteed to not match my
/homefilesystem, either (unless I deliberately set them to be identical). This makes UUIDs useful in the context of disk device identification because they can be used in configuration files or whatnot without much concern that they'll accidentally refer to the wrong disk.By whatever name, a UUID/GUID takes a specific format. Most Linux and macOS filesystems use UUIDs as serial numbers, but not all filesystem serial numbers are UUIDs. FAT and NTFS, in particular, have filesystem serial numbers that are not UUIDs. FAT disks have only 4-byte serial numbers, so although collisions are theoretically uncommon if they were assigned randomly, they can happen, particularly if an imperfect algorithm is used to generate the serial numbers. Such imperfect algorithms have been used in the past, so in fact collisions are pretty common -- or at least, they were some years ago. (I haven't looked into how common this is today.)
The GUID Partition Table (GPT), as the full name implies, relies heavily on GUIDs. GUIDs serve as partition type codes, to uniquely identify partitions, and to uniquely identify the disk. Note that the partition GUID (called the "partition UUID" in Linux) is distinct from the filesystem UUID -- and because not all filesystems use UUIDs, the latter might not technically exist. Some Linux tools, though, like
blkid, report (or expect to receive) filesystem UUIDs, and so they typically substitute the filesystem serial numbers, even though they're technically mis-labeled as UUIDs.Because GUIDs are used by GPT, but not by MBR, you can't really count on a partition GUID being available with 100% certainty -- but the vast majority of EFI-based computers use GPT disks, so GUIDs do exist with high probability, particularly on internal media like hard disks, SSDs, and NVMe devices.
EFI provides a way to learn the filesystem's label, so rEFInd has long used this information to display the name of the filesystem on which a loader resides. Most Linux tools don't bother to set this information, though.
AFAIK, EFI provides no way to learn the partition name, partition GUID, or filesystem UUID. rEFInd has to dig further to do this -- it reads and parses the GPT data structures to get the partition name and GUID, and does some minimal parsing of the raw partition data to extract the filesystem UUID. The partition data, in the case of GPT disks, is quite complete. The filesystem UUID data is less reliable, considered across all filesystem types. In particular, rEFInd extracts this data for NTFS, FAT, ext2/3/4fs, and ReiserFS -- but it's not really a UUID for NTFS and FAT.
rEFInd tracks both the partition GUID and the filesystem UUID when it can determine those values. The partition GUID is more certain to exist. Filesystem UUIDs are trickier, since they might not exist; or rEFInd might not be able to parse them even if they do exist. rEFInd reads the FAT filesystem serial number into the filesystem UUID data structure, but it's used only to identify duplicate filesystems (as in a software RAID array). In principle, rEFInd could parse this further and enable specifying a FAT filesystem's serial number as a
volumeidentifier; or use the real UUIDs in filesystems like ext4fs for this purpose; but there's really very little need for this. GPT is used pretty much universally on EFI-based computers, so partition GUIDs are likely to be more reliable than FAT serial numbers, or even true filesystem UUIDs (which might or might not be extracted by rEFInd, depending on the filesystem), as identifiers. This is why rEFInd does not offer a filesystem UUID or serial number option as avolumespecifier -- there are more reliable ways to uniquely identify a volume.All of these features can be changed by you, if you so desire, as outlined in my earlier messages -- you can change the filesystem's name or UUID/serial number with filesystem-specific tools; or you can change a partition's name or GUID using partitioning software. If you're setting up a manual boot stanza, you may find it convenient to change a partition's name, for instance, by using
gdiskor some other disk partitioning tool. Alternatively, you can use the existing GUID value, which will be very un-memorable to a human but very reliable.When relying on rEFInd's auto-scanning feature, rEFInd keeps track of the partitions internally using EFI device handles, which are generated on the fly by the EFI; you needn't be concerned about them. rEFInd uses a filesystem name or partition name as part of the display of the boot loader information (in the "Boot foo from bar" description -- "bar" in this example is a filesystem or partition name, or a description if neither of those is available). This name is also used as a clue in searching for a tag icon. This is part of why I strongly encourage the use of rEFInd's auto-scanning feature rather than manual boot stanzas -- rEFInd can track volumes internally more reliably than you can by cross-referencing various sources of information.
Concerning the idea of using a file written to the root directory of a filesystem to identify the disk, that also seems like a terribly sub-optimal way to do it. The partition GUID is ugly but reliable. If you're going to the effort to write an identifying file, you might as well set a partition name or filesystem name instead; that will be less obtrusive and less likely to be accidentally deleted.
IMHO, there's little reason to not give each ESP a unique partition name, if your system has multiple ESPs. You can simply include "ESP" in the partition name to identify it as an ESP, while setting something else uniquely -- for instance, "Windows ESP" and "Linux ESP". Utilities that need to identify ESPs as such typically rely on the partition type code, not the partition name, to do this. The name is for human consumption, and so should be treated as such.