On one hand, the kernel does not necessarily log its version number. Off my mind, I know this only from kernel bugs which the kernel could identify itself. Otherwise, the kernel only logs errors with regards to “kernel” but not with the version number. This is not necessary because there is always only one kernel running. So if the boot -1
was 6.2.15, you can grep for kernel
to get all errors of the 6.2.15 kernel from during that boot.
However, on the other hand, if I got you right, your disk encryption has to be unlocked immediately after the grub menu, which means before the actual boot of the operating system: if the root partition is itself encrypted, the errors of that moment cannot be logged in journalctl because these are stored in /var/ (even if /var/ is separated, the information which paritition is /var/ is stored on the root partition).
I have currently not much time so that I cannot say if I can keep helping you here until he issue is solved (if anyone has ideas and time, feel free to take over). But the first thing I have in mind is that for some reason, the keyboard has been reset to US. Here I am assuming that you use maybe a different keyboard layout? If so, try to enter your password based upon the US keyboard layout. E.g., what is § on a European keyboard is # on a US keyboard. You can find the keys on the Internet (maybe this is helpful: QWERTY - Wikipedia )
Besides that, once you have chosen the 6.2.15 kernel (try 6.2.15 again for this test), do nothing more. Just wait for the splash password prompt to appear. Then, press ESC to see all information from the terminal. You can now try your password, but if it does not work, you will get more information on that screen and then a new prompt to try again.
This will look like …
[ ok ] some information
[ ok ] some information
Please enter password for 219e9c5c-d189-854f-8c76-d73a53987043:
[error] some error
Please enter password for 219e9c5c-d189-854f-8c76-d73a53987043:
I have written the above off the cuff so do not take it literally. It is just that you have an impression what type of screen we are seeking here.
If you got the related screen and if the actual password does not work, provide a screenshot (maybe with a camera or so) of that screen. Relevant is what is output before the first password prompt appears but also what is output after the failed password attempt and before it is asked for a second try. Maybe that information offers some indication for the next supporter.
Also, if that is ok, feel free to add the logs of a journalctl --boot=-1
- if I assumed your disk encryption right (in terms of the root partition being encrypted), it is likely that this will only output the boots of 6.2.14. However, they could still be indicative. Feel free to anonymize data you consider private (e.g., MAC addresses). IMPORTANT: At the best, you only provide the link to the log file. If you need to paste the logs here for some reason, do always set them in brackets (mark all log text and then click the </> button)
Keeping old kernels too long should be avoided. This is at the best to get some time for fixing and/or to get over a buggy kernel, but not more/longer. Let’s focus on fixing the issue
However, what you elaborate sounds worth a bug report if the mentioned logs/information do not indicate something else and if the issue remains in the 6.3.X kernels.
However, if you know FOR SURE that you have no XFS file system, you can try if 6.3.3 works for you: https://bodhi.fedoraproject.org/updates/FEDORA-2023-514965dd8a - but please try that only if you are 100% sure that you have no XFS file system. If no XFS file system is involved, the 6.3.3 kernel can be considered stable (it has been not pushed to stable only because of an XFS issue that is not yet investigated).