Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Using RC3, I installed cockpit-composer on my machine. I have the machine's repos pointed to the internal RC3 composes. I tried to create a simple "postgresql" image with postgresql and python36 installed. It fails to create an AMI or Azure image with the same error.
Version-Release number of selected component (if applicable):
[root@zod ~]# rpm -q cockpit-composer anaconda-tui lorax-composer
cockpit-composer-0.1.8-1.el8.noarch
anaconda-tui-29.19.0.40-1.el8.x86_64
lorax-composer-28.14.23-1.el8.x86_64
[root@zod ~]#
How reproducible:
Always so far
Steps to Reproduce:
1. Create a blueprint with postgresql and python36
2. Try to create an AMI
3.
Actual results:
Fail
15:30:45,482 ERR ui.tui.spokes.storage: BootLoader setup failed: Failed to find a suitable stage1 device: EFI System Partition cannot be of type xfs.; EFI System Partition must be mounted on one of /boot/efi.; EFI System Partition cannot be of type xfs.; EFI System Partition must be mounted on one of /boot/efi.
Expected results:
AMI
Additional info:
I'll attach the logs of the AMI
OK, so I discussed this with Lars and Brian a bit. It failed because my machine is an EFI host and anaconda uses the host to determine the image type to create. The recommended (supported?) way to run this is in a BIOS VM.
Lars asked that I retitle this bug to reflect what isn't working.
The EFI partition *must* be vfat; it can't be XFS (or ext4 or similar). Usually the installer sets this up in fstab:
UUID=XXXXXX /boot/efi vfat umask=0077,shortname=winnt 0 2
But I suspect what happens on your system is that /boot/efi is simply not mounted at all? What does "findmnt /boot/efi" say?
Either way, this is a lorax/anaconda issue. It should be completely irrelevant how the build host is set up, it's supposed to create a guest image.
(In reply to Martin Pitt from comment #3)
>
> Either way, this is a lorax/anaconda issue. It should be completely
> irrelevant how the build host is set up, it's supposed to create a guest
> image.
To clarify this here for everyone, we are using Anaconda to install the image, and Anaconda can only create an image that matches the type of the host (UEFI or BIOS), so the host's type does actually matter.