The sbuild autopkgtest failure on the 'unshare' test is indeed fixed w/ sbuild in lunar-proposed; however, now the test 'unshare-qemuwrapper' timed out.
autopkgtest [23:36:43]: @@@@@@@@@@@@@@@@@@@@ summary build-procenv PASS unshare-qemuwrapper FAIL timed out unshare PASS It timed out on the 'guestfish' command, so I enabled `export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1` there, and run autopkgtests against its build in a PPA [1]. Then it finished successfully w/out timing out! x) autopkgtest [16:17:39]: @@@@@@@@@@@@@@@@@@@@ summary build-procenv PASS unshare-qemuwrapper PASS unshare PASS Not a very useful result, but it did show that an step in guestfish took ~25 minutes; 30 mins total: autopkgtest [15:22:52]: test unshare-qemuwrapper: [----------------------- ... + export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 + guestfish <...> ... libguestfs: trace: tar_in "/tmp/.../ubuntu-lunar-host.tar" "/" ... tar -C /sysroot/ -xf - 2> /tmp/tarSfYHJX ... guestfsd: => tar_in (0x45) took 1489.08 secs ... autopkgtest [15:52:27]: test unshare-qemuwrapper: -----------------------] unshare-qemuwrapper PASS So, well, it might have been due to load in the autopkgtest infrastructure at the time tests ran, so just triggered retries on sbuild and sbuild+qemu. Hopefully they will pass and unblock proposed migration for both sbuild & qemu. [1] https://autopkgtest.ubuntu.com/results/autopkgtest-lunar-mfo- build/lunar/amd64/s/sbuild/20221215_161801_a2772@/log.gz -- You received this bug notification because you are a member of SE SRU ("STS") Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1994002 Title: [SRU] migration was active, but no RAM info was set Status in Ubuntu Cloud Archive: New Status in Ubuntu Cloud Archive ussuri series: New Status in qemu package in Ubuntu: In Progress Status in qemu source package in Bionic: In Progress Status in qemu source package in Focal: In Progress Status in qemu source package in Jammy: In Progress Status in qemu source package in Kinetic: In Progress Bug description: [Impact] * While live-migrating many instances concurrently, libvirt sometimes return `internal error: migration was active, but no RAM info was set:` * Effects of this bug are mostly observed in large scale clusters with a lot of live migration activity. * Has second order effects for consumers of migration monitor such as libvirt and openstack. [Test Case] Steps to Reproduce: 1. live evacuate a compute 2. live migration of one or more instances fails with the above error N.B Due to the nature of this bug it is difficult consistently reproduce. In an environment where it has been observed it is estimated to occur approximately 1/1000 migrations. [Where problems could occur] * In the event of a regression the migration monitor may report an inconsistent state. [Original Bug Description] While live-migrating many instances concurrently, libvirt sometimes return internal error: migration was active, but no RAM info was set: ~~~ 2022-03-30 06:08:37.197 7 WARNING nova.virt.libvirt.driver [req-5c3296cf-88ee-4af6-ae6a-ddba99935e23 - - - - -] [instance: af339c99-1182-4489-b15c-21e52f50f724] Error monitoring migration: internal error: migration was active, but no RAM info was set: libvirt.libvirtError: internal error: migration was active, but no RAM info was set ~~~ From upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2074205 [Other Information] Related bug: https://bugs.launchpad.net/nova/+bug/1982284 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1994002/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : [email protected] Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
