Ubuntu 18.04 Linux Signed Image not recognized

[Justin White]

I recently upgraded an ECS Liva box from 16.04 to 18.04 and noted that rEFInd loaded the previous kernel (4.4.0-122) instead of the new kernel configured in refind.conf (4.15.0-20). Remembering the need for a signed image, I was dismayed when I discovered that the generic Ubuntu image is now signed by default but failed to load.

It appears that rEFInd is only looking for images that end in "efi.signed" or similar, as I was able to duplicate the new vmlinuz file and boot it:

sudo cp /boot/vmlinuz-4.15.0-20-generic /boot/vmlinuz-4.15.0-20-generic.efi.signed
sudo reboot

Upon reboot, I'm now running 4.15.0-20. Hopefully, someone else finds this useful.

[Roderick W. Smith]

By default, rEFInd "folds" multiple kernels into a single entry on its main menu, so as to minimize the clutter that would occur otherwise (and that does occur when using older versions of rEFInd or when you set fold_linux_kernels false in refind.conf). The "folding" algorithm sorts kernels based on their timestamps, because this is easier to parse than filenames -- although parsing Ubuntu's kernel filenames isn't that hard, not every distribution uses the same naming/numbering scheme. The problem with this is that if the timestamps don't match the true age of the kernel releases, an older kernel may appear as the primary entry. The other kernels are accessible by hitting F2, Insert, or Tab, though; and if you want to override what's shown as the primary kernel, you can use the touch command, as in touch /boot/vmlinuz-newer to make vmlinuz-newer the default kernel.

FWIW, this problem likely occurred because of the change from dual kernels (signed plus unsigned) to a single signed kernel. In the past, Ubuntu's signed kernel was created locally by combining the unsigned kernel with a file that contained the signature. The resulting file had a timestamp of whenever you installed the signed kernel package. Both the old unsigned kernel and the new single kernel have a timestamp of whenever the kernel package was created on Canonical's servers. Thus, if you installed the previous kernel after the new kernel was built (but presumably before it was distributed), you'd run into this problem. If so, the problem would have disappeared with the next kernel release, unless your computer's clock was set to some future date when you installed the older kernel.