4:26 p.m.
dustymabe reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
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](https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-...
are fine while the images from
[20190228.0](https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-...
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](https://koji.fedoraproject.org/koji/taskinfo?taskID=33075126)
[20190228.0](https://koji.fedoraproject.org/koji/taskinfo?taskID=33107624) 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.
This change is causing breakage for Atomic Host release artifacts and is preventing us
from releasing the next two week release of Atomic Host.
* When do you need this? (YYYY/MM/DD)
A fix ASAP would be nice. Ideally we would be able to release tomorrow.
* When is this no longer needed or useful? (YYYY/MM/DD)
N/A
* If we cannot complete your request, what is the impact?
No more releases of Atomic Host.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
4:49 p.m.
kevin added a new comment to an issue you are following:
``
This looks like @pbrobinson 's changes. A new oz version was installed then...
```
* Thu Feb 28 2019 Peter Robinson <pbrobinson(a)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?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
5:03 p.m.
dustymabe added a new comment to an issue you are following:
``
left a comment on the upstream pull request:
https://github.com/clalancette/oz/pull/269#discussion_r263174795
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
8:45 p.m.
dustymabe added a new comment to an issue you are following:
``
@kevin reverted oz on the builders we ran [a
compose](https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-upd...
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.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
9:30 p.m.
sinnykumari added a new comment to an issue you are following:
``
Thanks @dustymabe and @kevin for working on it. [Autocloud
test](https://apps.fedoraproject.org/autocloud/jobs/6583) looks good with compose
Fedora-29-updates-20190306.2
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
5:07 a.m.
pbrobinson added a new comment to an issue you are following:
``
left a comment on the upstream pull request:
https://github.com/clalancette/oz/pull/269#discussion_r263174795
@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.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
5:09 a.m.
pbrobinson added a new comment to an issue you are following:
``
@pbrobinson What should we do here? Can I downgrade oz to get this
working? or is there some other solution here?
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.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
5:11 a.m.
pbrobinson added a new comment to an issue you are following:
``
This change is causing breakage for Atomic Host release artifacts and
is preventing us from releasing the next two week release of Atomic Host.
Could you pleas be explicit? Exactly what is the breakage here, how do I recreate it?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
8:15 a.m.
dustymabe added a new comment to an issue you are following:
``
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)](https://docs.aws.amazon.com/vm-import/latest/userguide/vmie_prereqs...)
- *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!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
10:20 a.m.
pbrobinson added a new comment to an issue you are following:
``
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!
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
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
11:47 a.m.
dustymabe added a new comment to an issue you are following:
``
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.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
noon
pbrobinson added a new comment to an issue you are following:
``
👍 - 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?
Yes, I can do that, or if you open the bug (it's in blivet) I can deal with FE,
upstream PRs etc.
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 realise that, it's about an 8 char bug so would be straight forward.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
4:03 p.m.
dustymabe added a new comment to an issue you are following:
``
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:
- create a UEFI+GPT disk image (for UEFI booting) based on an input directive
- create a BIOS+MBR disk image (for legacy boot) based on an input directive
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
- create a UEFI+MBR disk image (because AWS requires MBR). I don't know if that even
makes sense but from some light googling I don't think it does. One
[link](https://forums.aws.amazon.com/thread.jspa?threadID=155626) I found.
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.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
5:17 p.m.
pbrobinson added a new comment to an issue you are following:
``
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.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
10:15 p.m.
dustymabe added a new comment to an issue you are following:
``
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?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
4:57 a.m.
pbrobinson added a new comment to an issue you are following:
``
New PR against 3.1-devel https://github.com/storaged-project/blivet/pull/764
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
8:55 a.m.
dustymabe added a new comment to an issue you are following:
``
New PR against 3.1-devel
https://github.com/storaged-project/blivet/pull/764
ack
@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.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
10:03 a.m.
pbrobinson added a new comment to an issue you are following:
``
Working on it
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
8:43 a.m.
dustymabe added a new comment to an issue you are following:
``
Working on it
❤️
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
9:40 a.m.
dustymabe added a new comment to an issue you are following:
``
ok i've noticed some new updates for blivet - where do we stand on this?
https://bodhi.fedoraproject.org/updates/?packages=python-blivet
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
10:22 a.m.
pbrobinson added a new comment to an issue you are following:
``
Still working on it, will update once I have an update (like always)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
8:28 a.m.
pbrobinson added a new comment to an issue you are following:
``
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
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
3:31 p.m.
pbrobinson added a new comment to an issue you are following:
``
A fix is deployed to production, @dustymabe please test, tomorrow's composes should be
back to MBR/BIOS
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
3:46 p.m.
dustymabe added a new comment to an issue you are following:
``
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?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
3:52 p.m.
mnguyen added a new comment to an issue you are following:
``
@dustymabe Will do!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
2:06 p.m.
mnguyen added a new comment to an issue you are following:
``
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-2019...
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
2:20 p.m.
pbrobinson added a new comment to an issue you are following:
``
@mnguyen awesome, thanks for checking
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
2:22 p.m.
The status of the issue: `Atomic Host cloud images switched to being UEFI based` of
project: `releng` has been updated to: Closed as Fixed by pbrobinson.
https://pagure.io/releng/issue/8197
2:22 p.m.
pbrobinson added a new comment to an issue you are following:
``
Going to close this out, feel free to reopen if it's not fixed.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
2:44 p.m.
mnguyen added a new comment to an issue you are following:
``
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-2019...
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8197
1864
days inactive
1876
days old
rel-eng@lists.fedoraproject.org
29 comments
5 participants
participants (5)
-
Dusty Mabe -
Kevin Fenzi
-
Michael Nguyen
-
Peter Robinson
-
Sinny Kumari