Bug 1694837

Summary:	lorax-composer fails to build images on EFI host
Product:	Red Hat Enterprise Linux 8	Reporter:	Josh Boyer <jwboyer>
Component:	lorax	Assignee:	Brian Lane <bcl>
Status:	CLOSED NOTABUG	QA Contact:	Release Test Team <release-test-team>
Severity:	unspecified	Docs Contact:	Eliane Ramos Pereira <elpereir>
Priority:	unspecified
Version:	8.0	CC:	abjoshi, elpereir, jcastran, jwboyer, kewhite, klaas, lueberni, mpitt
Target Milestone:	rc
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-10-21 21:19:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Josh Boyer 2019-04-01 20:00:24 UTC

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

Comment 1 Josh Boyer 2019-04-01 20:01:56 UTC

Created attachment 1550732 [details]
composer logs

Comment 2 Josh Boyer 2019-04-01 22:05:27 UTC

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.

Comment 3 Martin Pitt 2019-04-02 09:33:26 UTC

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.

Comment 4 Josh Boyer 2019-04-02 11:48:56 UTC

[jwboyer@zod ~]$ findmnt /boot/efi
TARGET    SOURCE         FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0077,dmask=0077,codepage=437,i
[jwboyer@zod ~]$ 

[jwboyer@zod ~]$ cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Mon Jul 16 09:36:19 2018
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/luks-1ee6def9-3661-4a98-92d1-369f802f7032 /                       xfs     defaults,x-systemd.device-timeout=0 0 0
UUID=64530b76-0cf1-4852-8427-536f46c6297e /boot                   xfs     defaults        0 0
UUID=F4B6-78F7          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=48faf967-c5ff-4929-bd49-493361d7b5f8 swap                    swap    defaults        0 0
[jwboyer@zod ~]$

Comment 5 Brian Lane 2019-04-02 17:10:01 UTC

(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.