[Group.of.nepali.translators] [Bug 1806674] Re: linux-hwe: 4.15.0-43.46~16.04.1 -proposed tracker
Hardware Certification have completed testing this -proposed kernel. No regressions were observed, results are available here: http://people.canonical.com/~hwcert/sru- testing/xenial/4.15.0-43.46~16.04.1/xenial-4.15-proposed-published.html ** Tags added: certification-testing-passed ** Changed in: kernel-sru-workflow/certification-testing Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1806674 Title: linux-hwe: 4.15.0-43.46~16.04.1 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: Fix Released Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Fix Released Status in Kernel SRU Workflow security-signoff series: Fix Released Status in Kernel SRU Workflow upload-to-ppa series: New Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux-hwe package in Ubuntu: Invalid Status in linux-hwe source package in Xenial: Confirmed Bug description: This bug is for tracking the upload package. This bug will contain status and testing results related to that upload. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1806659 phase: Promoted to proposed phase-changed: Saturday, 08. December 2018 13:36 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: certification-testing: Testing in progress To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1806674/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Disco) Importance: Undecided Status: Confirmed ** Also affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: Confirmed Bug description: [Impact] Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. [Test Case] - NFS mount point at /media root@iscsi-bionic:/home/ubuntu# mount | grep media 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) - Test mount point (/test) defined in /etc/fstab: root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test tmpfs /test tmpfs nosuid,nodev 0 0 1. If media.mount is not masked, everything works fine: root@iscsi-bionic:/home/ubuntu# mount | grep test root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago root@iscsi-bionic:/home/ubuntu# systemctl start test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test 2. If media.mount is masked, other mounts are failing: root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount Created symlink /etc/systemd/system/media.mount → /dev/null. root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) [Regression potential] Minimal. Originally, one failing mount point blocked the processing of the rest due to how the return codes were handled for every line in /proc/self/mountinfo. This patch removes this "dependency" and keeps the failure local to the affected mount point, allowing the rest to be processed normally. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10874 Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 [Original Description] netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0
[Group.of.nepali.translators] [Bug 1775195] Re: [sync][sru] Backport of sosreport v3.6
Reopening Trusty as it will be supported in ESM for a while yet. ** Changed in: sosreport (Ubuntu Trusty) Status: Won't Fix => New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1775195 Title: [sync][sru] Backport of sosreport v3.6 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: New Status in sosreport source package in Xenial: Fix Released Status in sosreport source package in Bionic: Fix Released Status in sosreport source package in Cosmic: Fix Released Status in sosreport package in Debian: Fix Released Bug description: [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing] * [minor] juju plugin detection doesn't work if installed as a snap: https://github.com/sosreport/sos/issues/1475 Fix already submitted upstream. This is not a new thing, juju in sosreport have always been made for .deb so far. It's not a regression introduce in 3.6, and IMHO not a blocker for the current SRU. It could be patch later on when the upstream discussion/approval will be done. * [major] Certain plugins may or may not substitute sensible information such as password. Upstream fix found and applied : https://github.com/sosreport/sos/commit/b96bdab - d/p/fix-string-substitution-method.patch * [minor] kernel plugin dont collect some tracing instance files https://github.com/sosreport/sos/commit/d6379b5 LP: #1803735 - d/p/dont-collect-some-tracing-instance-files.patch [Regression Potential] * Regression risk is low, as long as the core functionnality works (Package manager, ...) * autopkgtest reveal no regressions. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1| testing sosreport | 3.6-1| unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release cont
[Group.of.nepali.translators] [Bug 1744079] Re: [SRU] disk over-commit still not correctly calculated during live migration
This bug was fixed in the package nova - 2:18.0.3-0ubuntu1 --- nova (2:18.0.3-0ubuntu1) cosmic; urgency=medium * d/gbp.conf: Create stable/rocky branch. * d/p/disk-size-live-migration-overcommit.patch: Cherry-picked from https://review.openstack.org/#/c/602477 to ensure proper disk calculation during live migration with over-commit (LP: #1744079). * New stable point release for OpenStack Rocky (LP: #1806049). -- Corey Bryant Mon, 03 Dec 2018 12:23:48 -0500 ** Changed in: nova (Ubuntu Cosmic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1744079 Title: [SRU] disk over-commit still not correctly calculated during live migration Status in Ubuntu Cloud Archive: Fix Committed Status in Ubuntu Cloud Archive ocata series: Triaged Status in Ubuntu Cloud Archive pike series: Triaged Status in Ubuntu Cloud Archive queens series: Fix Committed Status in Ubuntu Cloud Archive rocky series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Status in nova package in Ubuntu: Fix Released Status in nova source package in Xenial: Triaged Status in nova source package in Bionic: Fix Committed Status in nova source package in Cosmic: Fix Released Status in nova source package in Disco: Fix Released Bug description: [Impact] nova compares disk space with disk_available_least field, which is possible to be negative, due to overcommit. So the migration may fail because of a "Migration pre-check error: Unable to migrate dfcd087a-5dff-439d-8875-2f702f081539: Disk of instance is too large(available on destination host:-3221225472 < need:22806528)" when trying a migration to another compute that has plenty of free space in his disk. [Test Case] Deploy openstack environment. Make sure there is a negative disk_available_least and a adequate free_disk_gb in one test compute node, then migrate a VM to it with disk-overcommit (openstack server migrate --live --block-migration --disk-overcommit ). You will see above migration pre-check error. This is the formula to compute disk_available_least and free_disk_gb. disk_free_gb = disk_info_dict['free'] disk_over_committed = self._get_disk_over_committed_size_total() available_least = disk_free_gb * units.Gi - disk_over_committed data['disk_available_least'] = available_least / units.Gi The following command can be used to query the value of disk_available_least nova hypervisor-show |grep disk Steps to Reproduce: 1. set disk_allocation_ratio config option > 1.0 2. qemu-img resize cirros-0.3.0-x86_64-disk.img +40G 3. glance image-create --disk-format qcow2 ... 4. boot VMs based on resized image 5. we see disk_available_least becomes negative [Regression Potential] Minimal - we're just changing from the following line: disk_available_gb = dst_compute_info['disk_available_least'] to the following codes: if disk_over_commit: disk_available_gb = dst_compute_info['free_disk_gb'] else: disk_available_gb = dst_compute_info['disk_available_least'] When enabling overcommit, disk_available_least is possible to be negative, so we should use free_disk_gb instead of it by backporting the following two fixes. https://git.openstack.org/cgit/openstack/nova/commit/?id=e097c001c8e0efe8879da57264fcb7bdfdf2 https://git.openstack.org/cgit/openstack/nova/commit/?id=e2cc275063658b23ed88824100919a6dfccb760d This is the code path for check_can_live_migrate_destination: _migrate_live(os-migrateLive API, migrate_server.py) -> migrate_server -> _live_migrate -> _build_live_migrate_task -> _call_livem_checks_on_host -> check_can_live_migrate_destination BTW, redhat also has a same bug - https://bugzilla.redhat.com/show_bug.cgi?id=1477706 [Original Bug Report] Change I8a705114d47384fcd00955d4a4f204072fed57c2 (written by me... sigh) addressed a bug which prevented live migration to a target host with overcommitted disk when made with microversion <2.25. It achieved this, but the fix is still not correct. We now do: if disk_over_commit: disk_available_gb = dst_compute_info['local_gb'] Unfortunately local_gb is *total* disk, not available disk. We actually want free_disk_gb. Fun fact: due to the way we calculate this for filesystems, without taking into account reserved space, this can also be negative. The test we're currently running is: could we fit this guest's allocated disks on the target if the target disk was empty. This is at least better than it was before, as we don't spuriously fail early. In fact, we're effectively disabling a test which is dis
[Group.of.nepali.translators] [Bug 1803735] Re: [kernel] dont collect some tracing instance files
** Also affects: sosreport (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Trusty) Status: New => In Progress ** Changed in: sosreport (Ubuntu Trusty) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Trusty) Assignee: (unassigned) => Eric Desrochers (slashd) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1803735 Title: [kernel] dont collect some tracing instance files Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: In Progress Status in sosreport source package in Xenial: Fix Released Status in sosreport source package in Bionic: Fix Released Status in sosreport source package in Cosmic: Fix Released Status in sosreport source package in Disco: Fix Released Bug description: ** Minor bug found in the current SRU for LP: #1775195 ** [Impact] * When kernel tracing event is in used, sosreport hang at the kernel plugin. [Test Case] * Install rasdaemon $ apt-get install rasdaemon -y * Run sosreport from -proposed (See Bug #1775195) sosreport | 3.6-1ubuntu0.16.04.1 | xenial-proposed sosreport | 3.6-1ubuntu0.18.04.1 | bionic-proposed sosreport | 3.6-1ubuntu0.18.10.1 | cosmic-proposed Only kernel plugin is needed to trigger the hang : $ sosreport -o kernel [Regression Potential] * Regression low. The fix is simply appending files to the the kernel plugin into an existing list of files to be ignored in order to stop hanging when trying to collect them when tracing event is in used. [Other Info] * Upstream fix: https://github.com/sosreport/sos/pull/1445/commits/d6379b5ba0f381ea8ec2403b9985100a946a5866 * Origin : https://github.com/sosreport/sos/pull/1445 [Git bisect log] git bisect start '--term-old' 'broken' '--term-new' 'fixed' # fixed: [848b110f83697814c72ac93b36e786ff9dafc0fc] [powerpc] Add support to collect DLPAR and LPM related logs git bisect fixed 848b110f83697814c72ac93b36e786ff9dafc0fc # broken: [967c015518c1aa135aa6007329972f031ffe12fc] [plugins] Remove unnecessary sizelimits git bisect broken 967c015518c1aa135aa6007329972f031ffe12fc # broken: [e89c7f7744ac4b39956ef3122cdb1489d2676664] [multipath] use -ll for path checker and prio inclusion git bisect broken e89c7f7744ac4b39956ef3122cdb1489d2676664 # broken: [0ea62d1ea57f41c1b75ccb83e69fdda386a7d280] [Plugin] fix exception raise in Plugin._copy_dir() git bisect broken 0ea62d1ea57f41c1b75ccb83e69fdda386a7d280 # broken: [2e3e1479df19aca58d8bd9f80ef3d6e7a9641211] [utilities] use correct comparison-to-None style git bisect broken 2e3e1479df19aca58d8bd9f80ef3d6e7a9641211 # broken: [e108d7c03834446f8dac66ad69f5eade4f2c5fce] [archive] fix and simplify directory destination rewriting git bisect broken e108d7c03834446f8dac66ad69f5eade4f2c5fce # broken: [f8ee9c4b87c6c3b8aa2bda3425f0e53499515363] [openstack_*] relax enabling of OSP RedHat plugins git bisect broken f8ee9c4b87c6c3b8aa2bda3425f0e53499515363 # fixed: [d6379b5ba0f381ea8ec2403b9985100a946a5866] [kernel] dont collect some tracing instance files git bisect fixed d6379b5ba0f381ea8ec2403b9985100a946a5866 # first fixed commit: [d6379b5ba0f381ea8ec2403b9985100a946a5866] [kernel] dont collect some tracing instance files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1803735/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1744079] Re: [SRU] disk over-commit still not correctly calculated during live migration
This bug was fixed in the package nova - 2:17.0.7-0ubuntu1 --- nova (2:17.0.7-0ubuntu1) bionic; urgency=medium * d/p/disk-size-live-migration-overcommit.patch: Cherry-picked from https://review.openstack.org/#/c/602478 to ensure proper disk calculation during live migration with over-commit (LP: #1744079). * New stable point release for OpenStack Queens (LP: #1806043). -- Corey Bryant Fri, 07 Dec 2018 08:27:02 -0500 ** Changed in: nova (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1744079 Title: [SRU] disk over-commit still not correctly calculated during live migration Status in Ubuntu Cloud Archive: Fix Committed Status in Ubuntu Cloud Archive ocata series: Triaged Status in Ubuntu Cloud Archive pike series: Triaged Status in Ubuntu Cloud Archive queens series: Fix Committed Status in Ubuntu Cloud Archive rocky series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Status in nova package in Ubuntu: Fix Released Status in nova source package in Xenial: Triaged Status in nova source package in Bionic: Fix Released Status in nova source package in Cosmic: Fix Released Status in nova source package in Disco: Fix Released Bug description: [Impact] nova compares disk space with disk_available_least field, which is possible to be negative, due to overcommit. So the migration may fail because of a "Migration pre-check error: Unable to migrate dfcd087a-5dff-439d-8875-2f702f081539: Disk of instance is too large(available on destination host:-3221225472 < need:22806528)" when trying a migration to another compute that has plenty of free space in his disk. [Test Case] Deploy openstack environment. Make sure there is a negative disk_available_least and a adequate free_disk_gb in one test compute node, then migrate a VM to it with disk-overcommit (openstack server migrate --live --block-migration --disk-overcommit ). You will see above migration pre-check error. This is the formula to compute disk_available_least and free_disk_gb. disk_free_gb = disk_info_dict['free'] disk_over_committed = self._get_disk_over_committed_size_total() available_least = disk_free_gb * units.Gi - disk_over_committed data['disk_available_least'] = available_least / units.Gi The following command can be used to query the value of disk_available_least nova hypervisor-show |grep disk Steps to Reproduce: 1. set disk_allocation_ratio config option > 1.0 2. qemu-img resize cirros-0.3.0-x86_64-disk.img +40G 3. glance image-create --disk-format qcow2 ... 4. boot VMs based on resized image 5. we see disk_available_least becomes negative [Regression Potential] Minimal - we're just changing from the following line: disk_available_gb = dst_compute_info['disk_available_least'] to the following codes: if disk_over_commit: disk_available_gb = dst_compute_info['free_disk_gb'] else: disk_available_gb = dst_compute_info['disk_available_least'] When enabling overcommit, disk_available_least is possible to be negative, so we should use free_disk_gb instead of it by backporting the following two fixes. https://git.openstack.org/cgit/openstack/nova/commit/?id=e097c001c8e0efe8879da57264fcb7bdfdf2 https://git.openstack.org/cgit/openstack/nova/commit/?id=e2cc275063658b23ed88824100919a6dfccb760d This is the code path for check_can_live_migrate_destination: _migrate_live(os-migrateLive API, migrate_server.py) -> migrate_server -> _live_migrate -> _build_live_migrate_task -> _call_livem_checks_on_host -> check_can_live_migrate_destination BTW, redhat also has a same bug - https://bugzilla.redhat.com/show_bug.cgi?id=1477706 [Original Bug Report] Change I8a705114d47384fcd00955d4a4f204072fed57c2 (written by me... sigh) addressed a bug which prevented live migration to a target host with overcommitted disk when made with microversion <2.25. It achieved this, but the fix is still not correct. We now do: if disk_over_commit: disk_available_gb = dst_compute_info['local_gb'] Unfortunately local_gb is *total* disk, not available disk. We actually want free_disk_gb. Fun fact: due to the way we calculate this for filesystems, without taking into account reserved space, this can also be negative. The test we're currently running is: could we fit this guest's allocated disks on the target if the target disk was empty. This is at least better than it was before, as we don't spuriously fail early. In fact, we're effectively disabling a test which is disabled for microversion >=2.25 anyway. IOW
[Group.of.nepali.translators] [Bug 1571403] Re: lz4 fails to run the tests on s390x (glibc-2.23 related?)
** Changed in: glibc (Ubuntu) Status: New => Invalid ** Changed in: glibc (Ubuntu Xenial) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1571403 Title: lz4 fails to run the tests on s390x (glibc-2.23 related?) Status in glibc package in Ubuntu: Invalid Status in lz4 package in Ubuntu: Fix Released Status in glibc source package in Xenial: Invalid Status in lz4 source package in Xenial: Confirmed Bug description: seen in the test rebuild: https://launchpad.net/ubuntu/+archive/test- rebuild-20160401/+build/9483622 60658 60679 60698 60724 *** Error in `./fuzzer': double free or corruption (!prev): 0x02aa181a4090 *** === Backtrace: = /lib/s390x-linux-gnu/libc.so.6(+0x791ba)[0x3ffaf7791ba] /lib/s390x-linux-gnu/libc.so.6(+0x7f62e)[0x3ffaf77f62e] /lib/s390x-linux-gnu/libc.so.6(+0x80010)[0x3ffaf780010] ./fuzzer(+0xed86)[0x2aa1490ed86] ./fuzzer(main+0x15c)[0x2aa14900e84] /lib/s390x-linux-gnu/libc.so.6(__libc_start_main+0x10e)[0x3ffaf722ece] ./fuzzer(+0x145c)[0x2aa1490145c] === Memory map: 2aa1490-2aa14914000 r-xp fc:00 1443097 /<>/programs/fuzzer 2aa14914000-2aa14915000 r--p 00013000 fc:00 1443097 /<>/programs/fuzzer 2aa14915000-2aa14916000 rw-p 00014000 fc:00 1443097 /<>/programs/fuzzer 2aa1815f000-2aa1820d000 rw-p 00:00 0 [heap] 3ffa800-3ffa8021000 rw-p 00:00 0 3ffa8021000-3ffac00 ---p 00:00 0 3ffaf68-3ffaf69 r-xp fc:00 1180835 /lib/s390x-linux-gnu/libgcc_s.so.1 3ffaf69-3ffaf691000 rw-p f000 fc:00 1180835 /lib/s390x-linux-gnu/libgcc_s.so.1 3ffaf70-3ffaf885000 r-xp fc:00 1183401 /lib/s390x-linux-gnu/libc-2.23.so 3ffaf885000-3ffaf889000 r--p 00184000 fc:00 1183401 /lib/s390x-linux-gnu/libc-2.23.so 3ffaf889000-3ffaf88b000 rw-p 00188000 fc:00 1183401 /lib/s390x-linux-gnu/libc-2.23.so 3ffaf88b000-3ffaf88f000 rw-p 00:00 0 3ffaf98-3ffaf9a4000 r-xp fc:00 1183402 /lib/s390x-linux-gnu/ld-2.23.so 3ffaf9a4000-3ffaf9a5000 r--p 00023000 fc:00 1183402 /lib/s390x-linux-gnu/ld-2.23.so 3ffaf9a5000-3ffaf9a7000 rw-p 00024000 fc:00 1183402 /lib/s390x-linux-gnu/ld-2.23.so 3ffaf9f5000-3ffaf9fe000 rw-p 00:00 0 3ffaf9fe000-3ffafa0 r-xp 00:00 0 [vdso] 3ffefabc000-3ffefb8 rw-p 00:00 0 [stack] All unit tests completed successfully 60747 / 60747 - all tests completed successfully compression ratio: 55.197% HC compression ratio: 51.173% ratio with dict: 44.457% Makefile:277: recipe for target 'test-fuzzer' failed make[3]: *** [test-fuzzer] Aborted make[3]: Leaving directory '/<>/programs' Makefile:98: recipe for target 'test' failed make[2]: *** [test] Error 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1571403/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
