My computer's openSUSE, Leap-15.6, Linux operating system is a "guest" operating system installed in Oracle Corporation VM (Virtual "Machine") VirtualBox, which in turn is an application installed in my "host," 64-bit, Windows 10 Home Edition operating system.

My installed version of Oracle Corporation VM (Virtual "Machine") VirtualBox in this report was 7.0.18 r162988 (Qt5.15.2) in my 64-bit, Windows 10 Home Edition, “host” operating system.

I began reading poster JoaoDerela’s posting on https://superuser.com/questions/1237684/how-to-boot-from-grub-shell on the Internet on how one could start an operating system in a particular Linux kernel using the command line with the GRand Unified Bootloader (GRUB) or GRUB, version 2.  And I discovered that in my Leap-15.6 installation the necessary kernel file vmlinuz-6.0.4-150600.6.21-default was not present in the directory /boot!  The file vmlinuz in the directory /boot was a symbolic link, or symlink to vmlinuz-6.0.4-150600.6.21-default; but the actual file vmlinuz-6.0.4-150600.6.21-default, which according to that symlink needed to be in the directory /boot, was itself not in that directory /boot.  Furthermore it appeared that for some other “vmlinuz….”  files in the directory /boot there was a corresponding file with both “vmlinux” and “.gz” in its full name (Please note the ending letter “x” this time in the name “vmlinux...”.)  And I suppose that the extension “gz” might in a file with “vmlinux….” in its full name represent a gzip-compressed version of a corresponding “vmlinuz...” file.  But there was no corresponding vmlinux-6.4.0-150600.6.21-default.gz file in the directory /boot either!  Now I do not know for certain how the installation of a Linux kernel is supposed to work.  But it might be that the vmlinux....gz file is supposed to be provided to the /boot directory; and after it arrives there it might be decompressed, or “unpacked” to make the corresponding vmlinuz-6.4.0-150600.6.21-default in the directory /boot.  In any case neither one of the files vmlinux-6.4.0-150600.6.21-default.gz nor vmlinuz-6.4.0-150600.6.21-default was in the directory /boot.  Again my previous method of installation of the new Linux kernel-default was via the command 

zypper update –download-in-advance

as a so-called “root” user while my computer was connected to the Internet.

I decided to “force” a reinstallation of kernel-default, version 6.4.0-150600.6.4.21.3.x86_64 via the different installation method of “Start button, System, YaST” (Yet another Software Tool) “Software”.  To do that I first probably performed a search for “kernel-default” or, perhaps less likely, just “kernel”, in YaST Software and then, after it was found, in the right pane clicked on “kernel-default” and selected perhaps eventually “Update unconditionally” (Selecting either “Update unconditionally” or “Update” there results in the same upward-pointing, green-colored symbol of an arrow in a square.  So I wonder if either one of those selections would result in “Update conditionally”, which appears to be equivalent to reinstalling a software package.).  “Accept”ing that change while my computer was connected to the Internet led to the software packages mlterm-sdl2 and kernel-default being installed.  After I “rebooted” my Leap-15.6 installation.  Then at the GRUB2 “bootloader menu” I selected “Advanced options for openSUSE Leap 15.6” and afterward gratefully saw “openSUSE Leap 15.6, with Linux 6.4.0-150600.6.4.21-default” as probably the first choice on that list of kernel versions in which I could “boot” my virtual computer into my Leap-15.6 operating system!

Therefore, sorry, my supposition of the Linux kernel 6.4.0-150600.21-default being missing among the choices of Linux kernels in GRUB 2 due to a problem in the new version of GRUB 2 was incorrect!  That problem was instead probably caused by somehow vmlinuz-6.4.0-150600.21-default not being provided in final form in the directory /boot for GRUB 2; and if the decompression of an imaginable vmlinux-6.4.0-150600.21-default.gz is supposed to occur within the directory /boot, that problem, further back in time, might have been due to vmlinux-6.4.0-150600.21-default.gz not having been provided to the directory /boot.  As for how vmlinuz-6.4.0-150600.21-default or its imaginable predecessor vmlinux-6.4.0-150600.21-default.gz did not end up in the directory /boot, I can imagine four possibilities:

1) a problem in the execution of “zypper update –download-in-advance” as a so-called “root” user,

2) a problem caused by my inclusion of “—download-in-advance” in the command “zypper update –download-in-advance”,

3) that the kernel-default, version-6.4.0-150600.21.3.x86_64-related computer software provided to “zypper ...” had a problem within it, including perhaps being incomplete; or,

4) without me knowing what the software package mlterm-sdl2 has to do with the installation of a Linux kernel, that the execution of the command “zypper update –download-in-advance” as a “root” user somehow might not have resulted in the software package mlterm-sdl2 being installed or updated, assuming that the installation of that software package was necessary for a good final installation of vmlinuz-6.4.0-150600.21-default in the directory /boot.