-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cloud image in 2.4.1 with EFI missing regexp grub module #1947
Comments
can reproduce locally on a uefi machine but it still boots after hitting enter |
it may be that the regexp is not working and the cmdline defaults are wrong so there is no serial output |
That was my observation as well, after I posted the issue. I think booting will continue just fine, but it may have missed some config depending on the distro. In my original test case, Ubuntu on Azure, I had to set |
Kairos version:
CPU architecture
AMD64
Describe the bug
Used OSBuilder to build a cloud image, intended to run in Azure. This works fine, able to enter recovery mode and reset with kairos-agent. After reboot, grub fail with the error
error: ../../grub-core/script/function.c:119:can't find command 'regexp'
To Reproduce
Expected behavior
Get through Grub without error messages
Analysis and potential cause
The error is fairly clear and is most likely caused by the fact that the regexp module of grub is not copied over into the grub directory of the active image. The kairos-agent debug output has the following few lines:
In #1824 we see the unified bootargs.cfg being introduced, which uses the regexp command. When the image first boots into recovery mode, it will have the
regexp
module in the live grub directory and thus has no problem. But when kairos-agent is resetting the system, if running on an UEFI system it will only copy over a specific list of modules. Source here.If this analysis happens to be correct, we may also need to insmod the regexp module in the grub.cfg in packages?
We managed to take the disk into a local Gen2 HyperV instance and were able to reproduce the same issue as well. When loaded into a Gen1 instance, it will not exhibit this behavior.
The text was updated successfully, but these errors were encountered: