retrofit-image action fails if retrofit-series is focal

Bug #1893697 reported by Jason Hobbs on 2020-08-31
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
charm-octavia-diskimage-retrofit
Undecided
Unassigned
snap-octavia-diskimage-retrofit
High
Unassigned

Bug Description

the retrofit-series option fails if the retrofit series is focal. This unit log has several attempts to perform the action with the retrofit-series option set to focal, and then a successful one with it set to bionic:

https://paste.ubuntu.com/p/dQnffSdYBb/

This is the start of the error log: virt-dib: error: libguestfs error: sh: Map install for amphora-agent

The error log finishes unhelpfully, it appears it may be getting truncated:
> Selecting previously unselected package python3-taskflow.
> Preparing to unpack ..

If reporting bugs, run virt-dib with debugging enabled and include the
complete output:

  virt-dib -v -x [...]
"
2020-08-31 20:30:44 DEBUG jujuc server.go:211 running hook tool "juju-log"
2020-08-31 20:30:44 ERROR juju-log action "retrofit-image" failed: "Command '['octavia-diskimage-retrofit', '-u', 'ussuri', '/var/snap/octavia-diskimage-retrofit/common/tmp/tmpilds0hj4', '/var/snap/octavia-diskimage-retrofit/common/tmp/tmpendvv0zy']' returned non-zero exit status 1." "Traceback (most recent call last):

bundle: http://paste.ubuntu.com/p/PMGwRsjJdX/

Jason Hobbs (jason-hobbs) wrote :

sub'd to field high - we have a workaround in using bionic, but focal should work too.

Frode Nordahl (fnordahl) wrote :

Thank you for the bug and thank you for providing logs with debug output.

Focal is supported and we are validating and using focal Amphorae in the Octavia charm gate.

Prompted by your bug report I reran the test just now and I see the same issue here, so I guess there is a change in-distro that offends the process in some way, we'll take a look.

Changed in charm-octavia-diskimage-retrofit:
status: New → Triaged
importance: Undecided → High
Frode Nordahl (fnordahl) wrote :

Running the `octavia-diskimage-retrofit` tool manually on the unit using the QCOW2 image downloaded from glance reveals the following:

> update-initramfs: Generating /boot/initrd.img-5.4.0-45-generic
> W: plymouth module (/usr/lib/x86_64-linux-gnu/plymouth//.so) missing, skipping that theme.
> Processing triggers for linux-image-5.4.0-45-generic (5.4.0-45.49) ...
> /etc/kernel/postinst.d/dkms:
> * dkms: running auto installation service for kernel 5.4.0-45-generic
> ...done.
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-5.4.0-45-generic
> W: plymouth module (/usr/lib/x86_64-linux-gnu/plymouth//.so) missing, skipping that theme.
> Error 24 : Write error : cannot write compressed block
> E: mkinitramfs failure cpio 141 lz4 -9 -l 24

The script in the snap does already grow the root filesystem to accommodate for upgraded packages:
https://github.com/openstack-charmers/octavia-diskimage-retrofit/blob/25cbc42fdefa50dc5cef0a55c1bd50dbcc74e0da/src/retrofit/retrofit.sh#L83

We may need to increase the headroom a bit.

Frode Nordahl (fnordahl) wrote :

I guess it is worth noting that a workaround would be to configure glance-simplestreams-sync to download the daily image stream as opposed to the released one. That will have more of the updates included in the source image and avoid the problem of overrunning the image disk space in the retrofit process.

Frode Nordahl (fnordahl) wrote :

Setting to invalid for charm as this was an issue with the snap.

Changed in snap-octavia-diskimage-retrofit:
status: New → Fix Committed
importance: Undecided → High
Changed in charm-octavia-diskimage-retrofit:
status: Triaged → Invalid
importance: High → Undecided
Changed in snap-octavia-diskimage-retrofit:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers