Learn more about these different git repos.
Other Git URLs
The Atomic Host cloud images output by the updates pungi composes (kicked off by bodhi) started producing images that only boot in UEFI mode. This happens if the VM anaconda was run in was started in UEFI mode. Something changed that caused this to start happening.
The images from 20190227.0 are fine while the images from 20190228.0 show the problem. There are no package differences between these images.
The difference is that if you look at the oz logs from the tasks 20190227.0 20190228.0 you can see that one is choosing BIOS boot and one is choosing UEFI boot:
:02:12,338 INFO anaconda:anaconda: bootloader: bootloader GRUB2 on X86 platform
vs
:25:31,273 INFO anaconda:anaconda: bootloader: bootloader EFIGRUB on EFI platform
You can also see in the tdl files the <nvram template="/usr/share/OVMF/OVMF_VARS.fd"/> which is a sign of booting via UEFI.
<nvram template="/usr/share/OVMF/OVMF_VARS.fd"/>
This change is causing breakage for Atomic Host release artifacts and is preventing us from releasing the next two week release of Atomic Host.
A fix ASAP would be nice. Ideally we would be able to release tomorrow.
N/A
No more releases of Atomic Host.
This looks like @pbrobinson 's changes. A new oz version was installed then...
* Thu Feb 28 2019 Peter Robinson <pbrobinson@fedoraproject.org> 0.17.0-0.1 - Upstream git 0.17 snapshot - ARMv7 fixes and support for UEFI - UEFI fixes for x86_64 and aarch64
@pbrobinson What should we do here? Can I downgrade oz to get this working? or is there some other solution here?
left a comment on the upstream pull request: https://github.com/clalancette/oz/pull/269#discussion_r263174795
@kevin reverted oz on the builders we ran a compose which works and then @kevin re-upgraded oz. hopefully we can use the output of this compose to do a release tomorrow and work out to make oz configurable in the next week so we won't have this problem for the next release.
Thanks @dustymabe and @kevin for working on it. Autocloud test looks good with compose Fedora-29-updates-20190306.2
@dustymabe there is really no need to comment everywhere you can damn well find, a single ticket for me to deal with it will be fine. What atomic needs and adding support for a widely deployed piece of functionality are two different problems. I'm not sure why atomic wouldn't want to support secure boot, it's like you don't want a secure OS.
Please don't. IoT, which is a F-30 objective, needs UEFI on x86 too for F-30. This update fixes like 8 problems. I will work with atomic to work out what they need. I feel this has actually exposed an anaconda bug.
Could you pleas be explicit? Exactly what is the breakage here, how do I recreate it?
Of course. There are several that I can think of:
I believe we need to make UEFI vs non-UEFI configurable and probably need to release both types of images for x86_64.
I feel this has actually exposed an anaconda bug.
AFAIK anaconda only queues decides on UEFI vs non-UEFI based on how the VM it is installing into was booted. I don't think there is an option for this. If you find one I'd be very happy to use it!
Could you pleas be explicit? Exactly what is the breakage here, how do I recreate it? Of course. There are several that I can think of: changing the image type in the middle of a release is problematic. We release atomic host every two weeks and will continue to do so for f29 until Fedora 29 EOL a UEFI only cloud image means we won't be in the largest cloud that exists (AWS) UEFI/EFI boot partitions are supported only for Windows boot volumes with VHDX as the image format. Otherwise, a VM's boot volume must use Master Boot Record (MBR) partitions. I believe we need to make UEFI vs non-UEFI configurable and probably need to release both types of images for x86_64. I feel this has actually exposed an anaconda bug. AFAIK anaconda only queues decides on UEFI vs non-UEFI based on how the VM it is installing into was booted. I don't think there is an option for this. If you find one I'd be very happy to use it!
changing the image type in the middle of a release is problematic. We release atomic host every two weeks and will continue to do so for f29 until Fedora 29 EOL a UEFI only cloud image means we won't be in the largest cloud that exists (AWS) UEFI/EFI boot partitions are supported only for Windows boot volumes with VHDX as the image format. Otherwise, a VM's boot volume must use Master Boot Record (MBR) partitions.
The problem is we should be able to use anaconda to create both images without forcing it one way or the other based on the underly (virtual) hardware.
I believe the main problem here is that anaconda forces GUID where AWS only supports msdos for linux, to quote the page above "MBR-partitioned volumes that are formatted using the ext2, ext3, ext4, Btrfs, JFS, or XFS file system. GUID Partition Table (GPT) partitioned volumes are not supported. " and that is a bug in blivet, I'll do a patch, I'll possibly need assistance. For the rest we can do grub2 and grub2-efi side by side to support
and that is a bug in blivet, I'll do a patch, I'll possibly need assistance. For the rest we can do grub2 and grub2-efi side by side to support
👍 - I'm happy to get a fix into anaconda for this. Do you mind opening a bug against anaconda for this so we can make it an FE when the fix is ready?
One thing to note is that if we don't make it optional in oz we'll also have to backport the anaconda bugfix to f29 since we are still using f29 anaconda to build f29 atomic host.
Yes, I can do that, or if you open the bug (it's in blivet) I can deal with FE, upstream PRs etc.
Yes, I realise that, it's about an 8 char bug so would be straight forward.
Ok started to open a bug, but I now realize I don't think I have all of the information I need. Is the desired goal for anaconda to be able to:
Both of the above is regardless of how the anaconda VM was booted?
The only other interpretation I have from what you previously said is that you want anaconda to
So what is the bug we're asking blivet to fix? I think it is hey blivet, can you make an MBR when I ask you to. If you can confirm that I'll open it.
PR created: https://github.com/storaged-project/blivet/pull/763
Against 3.1 release branch, the PR would apply cleanly to all current Fedora releases.
PR created: https://github.com/storaged-project/blivet/pull/763 Against 3.1 release branch, the PR would apply cleanly to all current Fedora releases.
ack
so with that change we should be able to have an image that boots both UEFI and legacy boot? Would it require changes to the kickstart files?
New PR against 3.1-devel https://github.com/storaged-project/blivet/pull/764
@pbrobinson - any chance you could verify that the proposed change gives us a disk image that we can then upload to EC2 and boot? If we could get that data point now then we'll save a bunch of time and process if it doesn't work and we need to change the strategy.
Working on it
❤️
ok i've noticed some new updates for blivet - where do we stand on this? https://bodhi.fedoraproject.org/updates/?packages=python-blivet
Still working on it, will update once I have an update (like always)
I've worked this out in a different way for the moment, still going to deal with the other bits, but later with less stress from people bothering me, a FBR will in inbound shortly
A fix is deployed to production, @dustymabe please test, tomorrow's composes should be back to MBR/BIOS
many thanks @pbrobinson ! @mnguyen - In the morning can you test the latest f29 updates compose and see if AWS and local qcow booting work for you?
@dustymabe Will do!
I couldn't check the AWS because the compose FINISHED_INCOMPLETE and the AMIs were not uploaded. I was able to check the qcow and it works as expected.
Compose Location: https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates-20190315.0/compose/AtomicHost/x86_64/images/
@mnguyen awesome, thanks for checking
Going to close this out, feel free to reopen if it's not fixed.
Metadata Update from @pbrobinson: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
I tested the AMIs generated from the following compose and it is also working as expected.
https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates-20190317.0/
Login to comment on this ticket.