Bug 1368118

Summary: virt-builder fedora-23 fails with --update option
Product: Red Hat Enterprise Linux 7 Reporter: Eric Auger <eric.auger>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.3CC: abologna, drjones, eric.auger, ignatenko, jcm, jsilhan, mluscon, packaging-team-maint, pnemade, ptoscano, rjones, rpm-software-management, vmukhame
Target Milestone: rc   
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-29 20:39:24 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:
Attachments:
Description Flags
virt-builder traces none

Description Eric Auger 2016-08-18 13:18:08 UTC
Created attachment 1191869 [details]
virt-builder traces

Description of problem:

When launching the following command on ARM aarch64 (mustang):

virt-builder fedora-23 -o ./f23 --arch aarch64 --root-password password:123456 --hostname f23guest --update

dnf -y --best upgrade is called and it looks it returns an error that prevents virt-builder from succeeding. As a consequence virt-builder fails creating the guest image:

virt-builder: error: dnf -y --best upgrade: command exited with an error

When launching the same command without --update and doing the "dnf -y --best upgrade" on the guest, the guest gets properly updated (although the same warning exists: Disabling early microcode, because kernel does not support it. CONFIG_MICROCODE_[AMD|INTEL]!=y). So the user experience is different.

The same command with fedora-24 works fine.

Version-Release number of selected component (if applicable):

virt-builder libguestfs-tools:
Version     : 1.32.7
Release     : 1.el7


How reproducible:
100%


Steps to Reproduce:
1. launch virt-builder fedora-23 -o ./f23 --arch aarch64 --root-password password:123456 --hostname f23guest --update -v -x


Actual results:
see attachement below.


Expected results:
Guest image is created and properly updated 


Additional info:

Comment 1 Igor Gnatenko 2016-08-18 13:25:56 UTC
without stdout/stderr of "virt-builder: error: dnf -y --best upgrade: command exited with an error" it's not possible to see what's really going on.

Comment 2 Eric Auger 2016-08-18 13:35:36 UTC
I put the virt-builder traces in the attachment. How can I output more information? Thanks Eric

Comment 3 Igor Gnatenko 2016-08-18 13:41:56 UTC
(In reply to Eric Auger from comment #2)
> I put the virt-builder traces in the attachment. How can I output more
> information? Thanks Eric
this is question to virt-builder developers.

Comment 4 Richard W.M. Jones 2016-08-18 16:54:17 UTC
I was going to say a duplicate of
https://bugzilla.redhat.com/show_bug.cgi?id=1280029

However you're seeing this bug in RHEL 7.3 with 1.32.7,
where the bug *should* be fixed.

Comment 5 Richard W.M. Jones 2016-08-18 16:58:00 UTC
If you look at the logs, you'll see:

No '/dev/log' or 'logger' included for syslog logging
cat: /lib/firmware/amd-ucode/: Is a directory
No '/dev/log' or 'logger' included for syslog logging
Disabling early microcode, because kernel does not support it. CONFIG_MICROCODE_[AMD|INTEL]!=y
1810 blocks

and then dnf doesn't do any "Verify" lines.  This probably
indicates that one of the %post scripts is bailing out, causing
dnf to (quite correctly) return an error.  The error is picked
up by virt-builder because it indicates that the dnf update
command failed.

This is probably caused because of the very different kernels
in RHEL 7.3 (hence the appliance environment) and Fedora 23.

You can replace the --update option with the equivalent dnf
command, ignoring the error code, something like:

  virt-builder --run-command 'dnf -y update ||:'

This is probably not something that we can fix in libguestfs.

It's a side effect of trying to modify a much newer guest using
a much older host kernel, and generally we recommend that you
always try to use a same/newer host when modifying guests, *or*
you explore the --firstboot options.

Comment 6 Eric Auger 2016-08-18 17:20:11 UTC
OK, thank you Richard for your feedbacks. Shall we close the bug then?
Thanks
Eric