Preview of new feature: kernel folding

[Roderick W. Smith]

Hi all!

I'm preparing a new release of rEFInd that includes a new feature that will change the user experience a bit, at least for those who use rEFInd to dual-boot with Linux using the EFI stub loader. I call this feature "kernel folding," and it "folds" multiple Linux kernels into a single entry in the main rEFInd menu. That is, if you've got, say, five kernels in one directory, you'll see one entry on the main rEFInd menu rather than five. (If you're dual-booting two Linux distributions, with their kernels stored in separate directories or partitions, you'll still get two entries, one for each set of kernels.) By default, the most recent kernel will be launched if you hit the Enter key, and to launch another kernel, you hit F2 or Insert, whereupon the other kernels will be listed on the submenu.

This feature is controlled via the new fold_linux_kernels option in refind.conf: Set it to on, true, or 1 to activate it (which is the default, at least in the current test build) or to off, false, or 0 to de-activate it and have rEFInd work the way it has in the past.

In any event, because this marks a fairly significant departure from the way rEFInd used to work, I thought I'd make my test build available before unleashing it through the official downloads. A test binary is available here:

http://www.rodsbooks.com/refind-bin-0.8.7.15.zip

Source code is up on the git repository.

I'd appreciate hearing from anybody who cares to test this new feature. If you have problems, please report them. I'd also appreciate hearing your thoughts on what the default should be. (I'm tentatively setting it to default to "on" because I'm getting a lot of queries from people who want to remove "extra" menu entries.)

I'll probably make a new full release this weekend.

[Chuck Theobald]

I like this feature! Linux kernels get updated with regularity, and having extra entries show up in the main menu following a routine update just would add confusion to my users. I would favour a default "on" setting.

[Roderick W. Smith]

I've released version 0.9.0 of rEFInd, which includes this feature. Unfortunately, Sourceforge's problems mean that it's not yet available in binary form from Sourceforge; but I've put the main binary file up on my own Web site:

http://www.rodsbooks.com/refind/refind-bin-0.9.0.zip

It defaults to an "on" setting for this new feature.

[faginbagin]

I, too, like the new feature. However, when fold_linux_kernels is true, rEFInd won't save an old kernel as the default boot loader in the PreviousBoot NVRAM variable, and will ignore the PreviousBoot variable if it points to an old kernel.

For example, I've got a partition labeled Ubuntu on which I've installed Ubuntu 15.04 vivid that has two kernels currently installed: 3.19.0-22 and 3.19.0-25.

If fold_linux_kernels is true and I boot the old kernel, I find that the PreviousBoot variable contains:
Boot boot\vmlinuz-3.19.0-25-generic.efi.signed from Ubuntu
IOW, it points to the new 3.19.0-25 kernel. If I reboot and take no action before rEFInd times out, it will boot the new kernel.

If I set PreviousBoot to point to the old kernel, 3.19.0-22:
Boot boot\vmlinuz-3.19.0-22-generic.efi.signed from Ubuntu
and reboot, rEFInd will boot into Windows unless I step in and change it.

I would expect the above situation to be similar to what will happen when an upgrade installs a new kernel with a default refind.conf. The PreviousBoot variable will point to the old kernel, but rEFInd will find the new kernel and ignore PreviousBoot. So it will default to the first boot loader, which is likely to be something other than the new kernel. This may not be what the user wants or expects.

When fold_linux_kernels is false and I boot the old kernel, I find that the PreviousBoot variable points to the old kernel:
Boot boot\vmlinuz-3.19.0-22-generic.efi.signed from Ubuntu
and rEFInd will boot that kernel across multiple reboots until I do something to change it.

Regards,
Helen

[Roderick W. Smith]

I realized that the behavior you describe would be the case before I released the feature; however:

• It's unclear what the "correct" behavior is. In some cases, you might want the next boot to default to the most recent kernel even if you override and select the older kernel for one boot.
• Changing the way it works will be complex, because the way the default selection works does not permit specifying a sub-option, and the fold_linux_kernels feature works by turning kernel entries beyond the first one into sub-options.

I've been thinking about ways to alter this behavior, but have yet to code anything. My current thinking is that storing the sub-option selected in NVRAM, much as rEFInd stores the main menu option, and creating a new refind.conf option to set the default sub-option, might be the best way to go. This will still have limitations -- for instance, if the user switches the fold_linux_kernels option on or off, the default selection will seem to change on the next boot (but should act as expected on subsequent boots, assuming no further refind.conf changes). My main qualm with this solution is that it involves adding both a new NVRAM variable and a new refind.conf option, and the extra complexity represented by these additions is undesirable.

In the meantime, if you want to regularly boot an older kernel, there are two workarounds:

• Set fold_linux_kernels false in refind.conf
• In Linux, use touch to set the desired kernel to have the most recent time stamp, as in touch /boot/vmlinuz-whatiwant to make /boot/vmlinuz-whatiwant boot by default.

Note also that, if you want to preserve a default boot to a Linux kernel in the event of a kernel upgrade, the solution is simple: Set your default_selection to include a specification of a generic kernel filename as a second option after +:

default_selection "+,vmlinuz"

This will cause the system to boot the last-booted kernel by default if it's available as a main-menu selection or to try to find any main-menu option that includes the string vmlinuz if the previously-booted option is no longer available.

[faginbagin]

The default_selection option does the job for me. Out of curiosity, I tried setting it to:

default_selection "+,Ubuntu"

where Ubuntu is the disk label of the linux installation I want to fall back on, and it works. Thought I'd mention it, even though the documentation doesn't mention that you can use the volume id. In my case, I've got two linux partitions, one with Ubuntu 15.04, one with Mythbuntu 14.04 and with disk labels Ubuntu and Mythbuntu respectively. Using the disk label is more intuitive than a string like vmlinuz-3.19, which is what I'd have to use to distinguish between the Ubuntu and Mythbuntu installations. I'm glad that volume id works. Perhaps the documentation should mention that's an option?

[Roderick W. Smith]

The ability to use volume labels is explicitly mentioned in the documentation of default_selection at http://www.rodsbooks.com/refind/configfile.html, and it's implicit in the description in refind.conf (which says that a default_selection option may be "any substring that corresponds to a portion of the loader's title"). I've just tweaked the latter to explicitly mention the possibility of using a volume or filesystem title.