oz
oz copied to clipboard
clalancette
Allow to choose boot_mode for x86_64
We can boot UEFI guests but we allow no option to do so to users. This extra option allows to make this difference
@clalancette @ganto @nullr0ute @tkopecek Could you please take a look at this and see if it could be merged? There are use cases where the boot mode does matter, such as partitioning or configuring the bootloader.
Applying this as a local patch is certainly not ideal.
Can you explain the problem a bit more? I don't understand the problem from your sentence above.
An example on why the boot mode is important can be creating disk images with specific partitioning configurations. BIOS and UEFI modes require different partitioning. For kickstart installations, Anaconda behaves differently depending on which boot mode the machine booted. For reference, CentOS 8 Azure images assume the machine is in UEFI mode.
Without this patch, Oz does only boot x86_64 virtual machines on BIOS mode. This PR allows users to choose which boot mode they boot in.
We have been using this patch in production for already one year without issues.
We have a downstream patch that does this in Fedora: https://src.fedoraproject.org/rpms/oz/blob/master/f/11-make-uefi-configurable.patch
Is there any way that configuration gets to upstream? This is not a Fedora exclusive feature.
Upstream maintenance has mostly stagnated hence why we have a series of patches downstream. I am not an upstream maintainer.
@clalancette could you add some more maintainers? Is there some other way the community could help?
Upstream maintenance has mostly stagnated hence why we have a series of patches downstream. I am not an upstream maintainer.
In short; this is absolutely correct, I have not had time to maintain this repository in recent years.
@clalancette could you add some more maintainers? Is there some other way the community could help?
I could definitely add some people to help with maintenance. I want to make sure that whoever becomes the maintainer is a) going to be more active, and b) not going to insert malware into the repository. I'm not quite sure how to ensure that, but I am willing to hear ideas and nominations.
I could definitely add some people to help with maintenance. I want to make sure that whoever becomes the maintainer is a) going to be more active, and b) not going to insert malware into the repository. I'm not quite sure how to ensure that, but I am willing to hear ideas and nominations.
I could assist, I've been maintaining it to some degree in Fedora and have been active in Fedora from the outset and a Red Hat employee for nearly 9 years. Maybe moving it to another account is an option to.
What about moving to some github org? E.g https://github.com/fedora-infra or https://github.com/release-engineering/ ?
@tkopecek So, I'm reluctant to move the repository to a Fedora-specific organization, since this package isn't really Fedora-specific.
But clearly I haven't had time for it. Here's what I'm going to do. I'm going to add write access to @nullr0ute right now. That will allow somebody access to review and merge PRs. Assuming that works out over the next little while, I'll probably then think about upgrading @nullr0ute to an Admin role.
I'm also willing to give one or two other people write access, so if anyone else wants to help maintain, please let me know. Note that raising your hand doesn't mean I'm going to automatically add you, I'll have to do some research first.
Finally, we can have a separate discussion about moving this to another org. I'm fine with that idea in general, but not with moving it to something fedora-specific.
Hopefully all of this is enough to at least allow some movement on this repository.
@clalancette @nullr0ute so far it doesn't seem to be working out very differently. :(
@nullr0ute https://github.com/clalancette/oz/commit/b7728d5bde9741786d2cd60806411e8462cfb3e5 seems to do something similar to this PR but I cannot seem to understand how that is configurable. Should this PR be adapted? Should your commit be adapted?
https://github.com/clalancette/oz/issues/295 also seems to indicate that b7728d5bde9741786d2cd60806411e8462cfb3e5 wasn't very well tested.