Skip to content
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

CentOS 7 BIOS/UEFI cloud images #169

Open
djuarezg opened this issue Feb 12, 2020 · 6 comments
Open

CentOS 7 BIOS/UEFI cloud images #169

djuarezg opened this issue Feb 12, 2020 · 6 comments

Comments

@djuarezg
Copy link

I see that in https://github.com/CentOS/sig-cloud-instance-build/blob/master/cloudimg/CentOS-8-x86_64-Azure.ks you prepare a C8 compatible image with both UEFI and BIOS. I see this image is being built in a UEFI machine and then you enable the BIOS bootloader .

First of all, are there any plans for doing the same with CentOS 7?

Second, would it be possible to build the image in BIOS and then enable the UEFI bootloader? i.e. do the inverted thing.

@szarkos
Copy link
Contributor

szarkos commented Feb 13, 2020

Hi,

There is an attempt to create a CentOS 7.7 BIOS/UEFI kickstart at 1. I have not verified this config myself yet, I'll need to find time in the coming weeks. If you want to test it yourself then any feedback would be appreciated. Along with UEFI it looks like they are trying to make a transition to cloud-init as well in that kickstart, but aren't quite there yet. I would probably ignore that part.

Currently I have no plan to do the opposite - create a config to build the image in a BIOS boot environment. When we started down this path we followed closely what the Red Hat engineers recommended 2. In that bug report they tested both CentOS 7 and the CentOS 8 kickstart I provided and confirmed this process works well (after some additional tweaks). I'm not sure there is much appetite for testing again in a BIOS environment and dealing with any potential issues as we have a process now that's been well validated. Of course if you want to give it a shot it may be useful for some folks. Is there a reason you need to build in a BIOS env vs. UEFI?

@djuarezg
Copy link
Author

@szarkos Basically we are using https://docs.pagure.org/koji/image_build/#building-disk-images which spawn BIOS VMs. Since there is no simple way for these VMs to spawn in UEFI mode, we wanted to replicate your kickstart in a BIOS environment to ease things.

Our final goal is to produce an Openstack CERN CentOS7 ready image (and 8 afterwards) that boots in both BIOS and UEFI VMs.

I'll take a look at the links you provided.

@djuarezg
Copy link
Author

@szarkos Just one simple question. For this image building it asumes it will always run in UEFI VMs. Are you using Koji for such purpose? If so, do you have any reference on how you are forcing the UEFI boot on the spawned VMs?

@djuarezg
Copy link
Author

OK, feel free to close this ticket once you publish the 7.7 ks. I could verify myself that it uses a working approach. I could be able to build it, but only after forcing UEFI on our spawned VMs for Koji.

Thank you for the references, they were really useful!

@djuarezg
Copy link
Author

djuarezg commented May 6, 2020

@szarkos Sorry to bother you again, but maybe you know why on the following lines:

Even if dealing with BIOS Grub config (/boot/grub2/grub.cfg) it is pointing to a UEFI grubenv: (hd0,gpt15)/efi/centos/grubenv. Is this an attempt to keep a central grubenv for both BIOS and UEFI? This means that the EFI partition is always required on a BIOS node, am I right?

@szarkos
Copy link
Contributor

szarkos commented May 6, 2020

Yes, that pointer to a single grubenv seems to be how the installer wants to set all this up anyway on a rhel/centos 8 system. In a previous iteration of this kickstart I tried copying the grubenv to both locations to maintain them separately, but then that introduced a bug where the kernel upgrade process did not update the default kernel for both uefi and bios grub configs properly. So the grubenv needs to be synced. And yes, the efi partition must always be there for this sort of bios/uefi install.

The folks from Red Hat helped me test and fixup this ks - there's more information in this public bug report starting at comment #26 and onward: https://bugzilla.redhat.com/show_bug.cgi?id=1570991#c26

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants