problem -- reFind -- booting latest system

[joneall]

I think this is related to my problem of 'apt autoremove' leaving old kernels lying around.

I did a dist-upgrade yesterday which installed vmlinuz-5.11.0-25-generic. (As far as I know, those files in /boot/ are the kernels, but I'm not sure of that.) But when I boot, reFind only finds 5.8.0-63-generic. I can only boot that with grub. Consider this:

$ ll /boot/vml*
lrwxrwxrwx 1 root root       25 ao?t   5 15:11 /boot/vmlinuz -> vmlinuz-5.11.0-25-generic
-rw------- 1 root root 10125664 juil. 13 18:43 /boot/vmlinuz-5.11.0-25-generic
-rw------- 1 root root 11756288 mars  19 13:01 /boot/vmlinuz-5.4.0-70-generic
-rw------- 1 root root 11760384 mars  24 11:29 /boot/vmlinuz-5.4.0-71-generic
-rw------- 1 root root 11768064 juil.  9 18:09 /boot/vmlinuz-5.4.0-80-generic
-rw------- 1 root root  9800288 juil. 15 16:06 /boot/vmlinuz-5.8.0-63-generic
lrwxrwxrwx 1 root root       24 ao?t   5 15:11 /boot/vmlinuz.old -> vmlinuz-5.4.0-80-generic

Before yesterday's upgrade, I was running (through reFind) 5.8.0-63-generic and that's what reFind still points to.

I tried GreyGeek's suggestion in that other post and successfully used muon to delete 5.4.0-71-generic. I suppose I could delete the other 5.4.0 kernels the same say, but, frankly, I'm afraid to delete the system I am using. 'Course, as long as I can boot it by choosing the grub partition...

Is there a way to re-initialize reFind? (Sorry if this is multiple questions.)

Thanks in advance for your suggestions.

[Don B. Cilly]

Try sudo touch /boot/vmlinuz-5.11.0-25-generic
(and reboot)

[GreyGeek]

https://www.linuxuprising.com/2018/1...-order-or.html

https://support.huaweicloud.com/intl...uble_0327.html

Grub-customizer is a GUI used to do those kinds of changes:
https://www.systutorials.com/how-to-...-ubuntu-20-04/
https://www.addictivetips.com/ubuntu...phical-editor/

[claydoh]

Try sudo touch /boot/vmlinuz-5.11.0-25-generic
(and reboot)

What is this doing, to help fix the problem?

https://www.linuxuprising.com/2018/1...-order-or.html

https://support.huaweicloud.com/intl...uble_0327.html

Grub-customizer is a GUI used to do those kinds of changes:
https://www.systutorials.com/how-to-...-ubuntu-20-04/
https://www.addictivetips.com/ubuntu...phical-editor/

These have zero to do with reFind not detecting a new kernel, and it bypasses grub anyway

[GreyGeek]

You're right, Claydoh.
IF the OP is running BTRFS then this might help"

Your problem is caused by Btrfs quirks. Because it supports subvolumes, it's often necessary to specify unusual options to get rEFInd to scan the right subdirectory and to get the kernel to recognize the right location as its root.

To get rEFInd to scan the kernels, you must add the following line to refind.conf:

also_scan_dirs +,@/boot

This assumes that you do not have a separate /boot partition. (My guess is it would be +,@ if you have such a partition, but I've never tried that.) If this doesn't work, you could open an EFI shell and use it to try to find your kernels, then add whatever their location is in a similar way. This might not be necessary in Arch because Arch and Ubuntu might set up their Btrfs volumes in different ways.

With that change in place, rEFInd should detect your kernels, but attempting to boot them will fail. This problem can be overcome by making changes to your /boot/refind_linux.conf file. In particular, you must add the following to the boot options:

rootflags=subvol=@

Be sure to add that in addition to the normal root={whatever} and any other kernel options you use.

Also, be sure that the EFI driver for Btrfs is present in the rEFInd drivers or drivers_x64 subdirectory. I realize you mentioned that drivers are installed, but it wasn't 100% clear that you meant the EFI driver, so I want to make that explicit.

[Don B. Cilly]

What is this doing, to help fix the problem?

It makes the 5.11 kernel "newer" than the 5.8, so rEFInd loads it by default. It's always worked for me.

[joneall]

Try sudo touch /boot/vmlinuz-5.11.0-25-generic
(and reboot)

That worked! Thank you.

BUT, it doesn't explain why I have these old systems (5.4.0-xx) sitting around which apt autoremove will not remove. That was the subject of my other post.

$ ll /boot/vml*
lrwxrwxrwx 1 root root       25 ao?t   5 15:11 /boot/vmlinuz -> vmlinuz-5.11.0-25-generic
-rw------- 1 root root 10125664 ao?t   7 08:59 /boot/vmlinuz-5.11.0-25-generic
-rw------- 1 root root 11756288 mars  19 13:01 /boot/vmlinuz-5.4.0-70-generic
-rw------- 1 root root 11768064 juil.  9 18:09 /boot/vmlinuz-5.4.0-80-generic
-rw------- 1 root root  9800288 juil. 15 16:06 /boot/vmlinuz-5.8.0-63-generic
lrwxrwxrwx 1 root root       24 ao?t   5 15:11 /boot/vmlinuz.old -> vmlinuz-5.4.0-80-generic

Apparently refind ignores the links, as does grub. So what are they for? (Just for curiousity, why vmlinuz instead of vmlinux?)

[Don B. Cilly]

vmlinuz is... like svgz :-) It's compressed.
That rEFInd thing is quite annoying, I agree. But it hasn't been fixed... yet :-/
Still, once you know, it's an easy workaround. I actually have "touch" and "sudo touch" right-clicks in Dolphin.

The touch I use often. I usually sort folders by date, touching a file brings it to the top.
The sudo one I made for rEFInd, basically
You can get them on Pling if you want them.

[AH] I'm not sure why autoremove doesn't remove the old 5.4s - or even if it should.
You can obviously remove them "manually"... I would keep at least one, say 0-80, just in case you want to boot a 5.4 and see if it fixes something. Unlikely, but... for the space it uses...

[jlittle]

/boot/vmlinuz and /boot/initrd.img...
So what are they for?

They're for me! And others that want to write a boot configuration that doesn't have to change when there's a new kernel.

I've used them for about a decade or so. You (by using rEFInd) avoid the cluster kludge (IMO) that is the grub configuration machinery. I avoid it by writing a very simple grub.cfg, using the vmlinuz and initrd.img links. The links allow my grub.cfg to stay unchanged, sometimes for years.

[GreyGeek]

That worked! Thank you.

BUT, it doesn't explain why I have these old systems (5.4.0-xx) sitting around which apt autoremove will not remove. That was the subject of my other post.

From https://help.ubuntu.com/community/RemoveOldKernels

Note: apt-get autoremove will not remove all automatically installed old kernel providing packages as fallback versions are kept; the list of kept kernels is maintained and automatically updated in the file /etc/apt/apt.conf.d/01autoremove-kernels as a list of matching regular expressions.

Apt was released with the 16.04 release and incorporates all that is in apt-get plus some.
https://linoxide.com/apt-and-apt-get-which-one-to-use/

[claydoh]

One of the things with the HWE on LTS releases is that this can end up keeping a minimum set of kernels -- which will usually involve the original 5.4, as well as the HWE - which is 5.11 currently.
So either remove the 5.4 kernel stuff manually, or the meta-package linux-image-generic which is the package that depends on the current original (5.4) kernel , while the meta-package linux-image-generic-hwe-20.04 is what pulls in the latest LTS HWE kernel (5.11, previously 5.8)
If the linux-image-generic is uninstalled, the 5.4 will also be removed, if not immediately then with an autoremove.