Bug 2090561

I've seen this before with xfs refusing to work when things are mismatched. But I don't think this is something Lorax can (or should) try to do. It seems like dracut in the initramfs is a good candidate for checking this. It handles mounting the root filesystem, and it know what kernel is running, so it should be possible for it to make sure it has the matching modules. Reassigning there for comment.

Yes, dracut was the other possibility, though I wasn't aware that install.img had much at all to do with dracut (outside of being fetched by it).

I guess the question is whether to panic or drop to a dracut shell? I think this combination is undefined and potentially it's bad, so it might be safer to panic.

Please let me bring a bit of insight here. There are two things we need to solve and both are touching Dracut.

First: Kernel mismatch with initrd
In this case the behavior could be fault of any module. Dracut could have this check enabled by default and kill boot with a message that kernel version doesn't match modules in initrd. To avoid people spending time on a unexpected behavior before they realize what is the issue. My noob PoV here would be a simple check of `uname` with kernel module versions directory in initrd.


Second: initrd mismatch with stage2 image (Anaconda installation environment but not only that)
This is definitely more significant issue for Anaconda than with something else but still I think this should be part of the Dracut (feel free to correct me).

To explain how Anaconda works. We will download the stage2 image do some stuff around that (detect repos etc.) and then mount it[1] for Dracut on the given place so Dracut can do a switchroot. Here is a question if this should be handled by Anaconda or Dracut, however, I think Dracut can do a similar check proposed above to check that the kernel modules are match with the current kernel before switchroot. By doing this in Dracut it would help even in cases out of Anaconda where just root= is mismatched with the something else.
Again the behavior should be to kill the boot process and not do a switchroot with a message what was wrong. 

If you want to make it robust, you can add a boot option to disable the check if needed.

[1]: https://github.com/rhinstaller/anaconda/blob/master/dracut/anaconda-lib.sh#L156=

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.