kernelstub won't update default kernel to older version (6.0.12 -> 5.19.16)

[mkidson]

I'm having some issues that seem to be related to kernel 6.0.12 and I just want to downgrade to 5.19.16 but kernelstub -k <vmlinuz_path> -i <initrd.img_path> doesn't change the output of kernelstub -p

Distribution (run cat /etc/os-release):

NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

Related Application and/or Package Version (run apt policy $PACKAGE NAME):

Issue/Bug Description:
Running kernelstub -k <vmlinuz_path> -i <initrd.img_path> to revert from kernel 6.0.12 to 5.19.16 does not change the output of kernelstub -p to reflect the new default kernel.

Steps to reproduce (if you know):

sudo kernelstub -k <vmlinuz_path> -i <initrd.img_path>
sudo kernelstub -p

Expected behavior:
Should show old kernel. Even after a restart, 6.0.12 is shown.

Other Notes:
I'm using rEFInd to dualboot Windows and Pop!_OS, on two separate drives. I'm able to use rEFInd to boot into the old kernel, but it seems to only want to use integrated graphics, I can't get it to switch to NVIDIA unless I go to the newer kernel.

[ruineka]

I'm running into issues with this as well after testing 6.2. I'm trying to switch it to test 6.1 but it always boots the newest version.

[isantop]

Those fields represent the kernel being used for the current run of kernelstub; This includes when -p is provided, although -p skips taking any actions. If one ran kernelstub -p -k <vmlinuz> -i <initrd> then it would print them correctly.

I'm not entirely sure what the correct action here is. It may be to rename those fields to better manage user expectations, as kernelstub is not meant to be a utility to check the currently-running kernel (uname is correct for that). I also believe there is value in being able to see what kernel would be installed on the ESP if the auto-detection is allowed to run, without it actually installing (and possibly overwriting) the current kernel. If that's the solution though, then those fields would definitely require better names to reflect what they're actually reporting.