[Group.of.nepali.translators] [Bug 1772675] Re: Intel i40e PF reset due to incorrect MDD detection (continues...again...)
[Expired for linux (Ubuntu Bionic) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu Bionic) Status: Incomplete => Expired -- 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/1772675 Title: Intel i40e PF reset due to incorrect MDD detection (continues...again...) Status in linux package in Ubuntu: Expired Status in linux source package in Xenial: Expired Status in linux source package in Bionic: Expired Status in linux source package in Cosmic: Expired Bug description: [impact] The i40e driver sometimes causes a "malicious device" event that the firmware detects, which causes the firmware to reset the nic, causing an interruption in the network connection - which can cause further problems, e.g. if the interface is in a bond; the reset will at least cause a temporary interruption in network traffic. [fix] The fix for this is currently unknown. As the "MDD event" is generated by the i40e firmware, and is completely undocumented, there is no way to tell what the i40e driver did to cause the MDD event. [test case] the bug is unfortunately very difficult to reproduce, but as shown in this (and previous) bug comments, some users of the i40e have traffic that can consistently reproduce the problem (although usually on the order of days, or longer, to reproduce). Reproducing is easily detected, as the nw traffic will be interrupted and the system logs will contain a message like: i40e :02:00.1: TX driver issue detected, PF reset issued [regression potential] unknown since the specific fix is unknown. [original description] This is a continuation from bug 1713553 and then bug 1723127; a patch was added in the first bug and then the second bug, to attempt to fix this, and it may have helped reduce the issue but appears not to have fixed it, based on more reports. See bug 1713553 and bug 1723127 for more details. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1772675/+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 1772675] Re: Intel i40e PF reset due to incorrect MDD detection (continues...again...)
[Expired for linux (Ubuntu Xenial) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu Xenial) Status: Incomplete => Expired -- 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/1772675 Title: Intel i40e PF reset due to incorrect MDD detection (continues...again...) Status in linux package in Ubuntu: Expired Status in linux source package in Xenial: Expired Status in linux source package in Bionic: Expired Status in linux source package in Cosmic: Expired Bug description: [impact] The i40e driver sometimes causes a "malicious device" event that the firmware detects, which causes the firmware to reset the nic, causing an interruption in the network connection - which can cause further problems, e.g. if the interface is in a bond; the reset will at least cause a temporary interruption in network traffic. [fix] The fix for this is currently unknown. As the "MDD event" is generated by the i40e firmware, and is completely undocumented, there is no way to tell what the i40e driver did to cause the MDD event. [test case] the bug is unfortunately very difficult to reproduce, but as shown in this (and previous) bug comments, some users of the i40e have traffic that can consistently reproduce the problem (although usually on the order of days, or longer, to reproduce). Reproducing is easily detected, as the nw traffic will be interrupted and the system logs will contain a message like: i40e :02:00.1: TX driver issue detected, PF reset issued [regression potential] unknown since the specific fix is unknown. [original description] This is a continuation from bug 1713553 and then bug 1723127; a patch was added in the first bug and then the second bug, to attempt to fix this, and it may have helped reduce the issue but appears not to have fixed it, based on more reports. See bug 1713553 and bug 1723127 for more details. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1772675/+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 1772675] Re: Intel i40e PF reset due to incorrect MDD detection (continues...again...)
[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- 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/1772675 Title: Intel i40e PF reset due to incorrect MDD detection (continues...again...) Status in linux package in Ubuntu: Expired Status in linux source package in Xenial: Expired Status in linux source package in Bionic: Expired Status in linux source package in Cosmic: Expired Bug description: [impact] The i40e driver sometimes causes a "malicious device" event that the firmware detects, which causes the firmware to reset the nic, causing an interruption in the network connection - which can cause further problems, e.g. if the interface is in a bond; the reset will at least cause a temporary interruption in network traffic. [fix] The fix for this is currently unknown. As the "MDD event" is generated by the i40e firmware, and is completely undocumented, there is no way to tell what the i40e driver did to cause the MDD event. [test case] the bug is unfortunately very difficult to reproduce, but as shown in this (and previous) bug comments, some users of the i40e have traffic that can consistently reproduce the problem (although usually on the order of days, or longer, to reproduce). Reproducing is easily detected, as the nw traffic will be interrupted and the system logs will contain a message like: i40e :02:00.1: TX driver issue detected, PF reset issued [regression potential] unknown since the specific fix is unknown. [original description] This is a continuation from bug 1713553 and then bug 1723127; a patch was added in the first bug and then the second bug, to attempt to fix this, and it may have helped reduce the issue but appears not to have fixed it, based on more reports. See bug 1713553 and bug 1723127 for more details. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1772675/+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 1772675] Re: Intel i40e PF reset due to incorrect MDD detection (continues...again...)
[Expired for linux (Ubuntu Cosmic) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu Cosmic) Status: Incomplete => Expired -- 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/1772675 Title: Intel i40e PF reset due to incorrect MDD detection (continues...again...) Status in linux package in Ubuntu: Expired Status in linux source package in Xenial: Expired Status in linux source package in Bionic: Expired Status in linux source package in Cosmic: Expired Bug description: [impact] The i40e driver sometimes causes a "malicious device" event that the firmware detects, which causes the firmware to reset the nic, causing an interruption in the network connection - which can cause further problems, e.g. if the interface is in a bond; the reset will at least cause a temporary interruption in network traffic. [fix] The fix for this is currently unknown. As the "MDD event" is generated by the i40e firmware, and is completely undocumented, there is no way to tell what the i40e driver did to cause the MDD event. [test case] the bug is unfortunately very difficult to reproduce, but as shown in this (and previous) bug comments, some users of the i40e have traffic that can consistently reproduce the problem (although usually on the order of days, or longer, to reproduce). Reproducing is easily detected, as the nw traffic will be interrupted and the system logs will contain a message like: i40e :02:00.1: TX driver issue detected, PF reset issued [regression potential] unknown since the specific fix is unknown. [original description] This is a continuation from bug 1713553 and then bug 1723127; a patch was added in the first bug and then the second bug, to attempt to fix this, and it may have helped reduce the issue but appears not to have fixed it, based on more reports. See bug 1713553 and bug 1723127 for more details. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1772675/+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 1799498] Re: New Microsoft Azure Linux Agent
This bug was fixed in the package walinuxagent - 2.2.32-0ubuntu1~18.04.1 --- walinuxagent (2.2.32-0ubuntu1~18.04.1) bionic; urgency=medium * Backport of the disco version. * New upstream release (LP: #1799498). * debian/patches/disable_import_test.patch: refreshed patch. * debian/control: - Add the python3-mock build-dependency. * debian/rules: - Run unit tests but don't fail the build if they fail. Previously, due to a bug in setup.py, those were never being run during build so the failures are not regressions. -- Łukasz 'sil2100' Zemczak Mon, 29 Oct 2018 09:13:23 +0100 ** Changed in: walinuxagent (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: walinuxagent (Ubuntu Xenial) 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/1799498 Title: New Microsoft Azure Linux Agent Status in walinuxagent package in Ubuntu: Fix Released Status in walinuxagent source package in Trusty: Fix Released Status in walinuxagent source package in Xenial: Fix Released Status in walinuxagent source package in Bionic: Fix Released Status in walinuxagent source package in Cosmic: Fix Released Bug description: [Impact] This release contains both bug-fixes and new features and we would like to make sure all of our supported customers have access to these improvements. See the changelog entry below for a full list of changes and bugs. [Test Case] The following development and SRU process was followed: https://wiki.ubuntu.com/walinuxagentUpdates The Microsoft Azure Linux Agent team will execute their testsuite, which includes extension testing , against the walinuxagent that is in -proposed. A successful run will be required before the proposed walinuxagent can be let into -updates. The CPC team will be in charge of attaching a summary of testing to the bug. CPC team members will not mark ‘verification-done’ until this has happened. [Upstream Changelog] * v2.2.32 [#1325] Enable cgroups by default on all distros [#1327, #1347] Allow enforcing of cgroups limits [#1337] Allow configuration for cgroups [#1333] Add support for NSBSD [#1319] Stream extension downloads to disk (do not buffer the download in memory) [#1303] Fix to support custom DNS servers [#1306] Log extension stdout and stderr [#1302] Better of cloud-init configuration during deprovisioning [#1295] Fix to report the correct extension error code [#1289] Allow disabling the agent or extensions [#1290] Use the "ip route" command instead of the "route" comand during network configuration [#1281] Delete JIT accounts [#1234] Fix for reading KVP values from host [#1287] Add UDEV rule in azure disk encryption This release also includes improvements in telemetry and bug fixes. * v2.2.31 [#1196] Health store integration [#1199] CGroups support [#1194] Use host for status reporting [#1188] Fix for sentinel and signal handlers [#1182] Telemetry updates [#1171] Add support for JIT [#1164] Fix for name resolution in Ubuntu 18.04 [#1154] Set connection close header [#1143] Remove extension packages after extraction There are also several other bug fixes and improvements. * v2.2.26 Update Debian specific configuration and setup. * v2.2.25 Revert extension manifest caching to prevent downgrade issues. [Original Description] This is a request to integrate the new version of the Azure Linux Guest Agent version 2.2.32 into the Ubuntu Azure Images . Available here https://github.com/Azure/WALinuxAgent/releases/tag/v2.2.32 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1799498/+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 1791758] Re: ldisc crash on reopened tty
** Changed in: linux (Ubuntu Trusty) Status: Confirmed => Won't Fix ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => High ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => High ** Changed in: linux (Ubuntu Cosmic) Importance: Undecided => High -- 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/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: Won't Fix Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM [Test Case] * Deploy a Trusty KVM instance
[Group.of.nepali.translators] [Bug 1810781] Re: mpt3sas - driver using the wrong register to update a queue index in FW
Xenial has no support for the SAS 3.5 class, so we won't backport the patch - it's only needed in Bionic (4.15 / Xenial HWE) and Cosmic kernel (4.18). ** Changed in: linux (Ubuntu Xenial) Status: Confirmed => Won't Fix ** Changed in: linux (Ubuntu Xenial) Importance: Critical => Medium ** Changed in: linux (Ubuntu Disco) Importance: Critical => Medium ** Changed in: linux (Ubuntu Xenial) Assignee: Guilherme G. Piccoli (gpiccoli) => Mauricio Faria de Oliveira (mfo) ** Changed in: linux (Ubuntu Bionic) Assignee: Guilherme G. Piccoli (gpiccoli) => Mauricio Faria de Oliveira (mfo) ** Changed in: linux (Ubuntu Cosmic) Assignee: Guilherme G. Piccoli (gpiccoli) => Mauricio Faria de Oliveira (mfo) ** Changed in: linux (Ubuntu Disco) Assignee: Guilherme G. Piccoli (gpiccoli) => Mauricio Faria de Oliveira (mfo) -- 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/1810781 Title: mpt3sas - driver using the wrong register to update a queue index in FW Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Won't Fix Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Status in linux source package in Disco: Fix Released Bug description: [Impact] * The mpt3sas driver relies in a FW queue (Reply Post Descriptor Queue) in the I/O completion path; there's a MMIO register that driver uses to flag an empty entry in such queue, called Reply Post Host Index. This value is updated during the driver interrupt routine [in _base_interrupt() function]. * Happens that there are 2 registers representing the Reply Post Host Index according to the type of the adapter. They are differentiated in the driver through the "ioc->combined_reply_queue" check. By the MPI specification (vendor spec), driver should use this combined reply queue according to the number of maximum MSI-X vectors that the adapter exposes and the spec version (SAS 3.0 vs SAS 3.5). * Currently, this is wrong checked for a class of adapters, which was fixed in the upstream kernel commit 2b48be65685a [0]. Without this commit, we can observe spontaneous resets in the driver due to queue overflow (FW is not aware that there are free entries in the Reply Post Descriptor Queue). The dmesg log will show the following output in case of this error: mpt3sas_cm0: fault_state(0x2100)! mpt3sas_cm0: sending diag reset !! mpt3sas_cm0: diag reset: SUCCESS [followed by a lot of driver messages as result of the reset procedure] * During these resets, I/O is stalled so it may affect performance. [Test Case] * It's not trivial to test the problem, but given a machine with an affected device, an I/O benchmark like FIO could be used to exercise the I/O path in a heavy way and trigger the issue. We have reports that the adapter "LSI Logic / Symbios Logic Device [1000:00ac]" is affected by the issue. [Regression Potential] * This is a long-term issue from the mpt3sas driver, affecting only a class of adapters of this vendor. Since it's a clear bug, the fix is necessary. The potential of regressions is unknown, but likely low - it changes the register used for the index updates given some set of characteristics of the adapter (according to the spec.), which restricts even more the scope of this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810781/+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 1810781] Re: mpt3sas - driver using the wrong register to update a queue index in FW
** Changed in: linux (Ubuntu Bionic) Importance: Undecided => Critical ** Changed in: linux (Ubuntu Cosmic) Importance: Undecided => Critical ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => Critical ** Changed in: linux (Ubuntu Xenial) Status: New => Confirmed ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu Cosmic) Status: New => Confirmed ** Changed in: linux (Ubuntu Disco) Status: Confirmed => Fix Released ** Changed in: linux (Ubuntu Cosmic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) -- 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/1810781 Title: mpt3sas - driver using the wrong register to update a queue index in FW Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Status in linux source package in Disco: Fix Released Bug description: [Impact] * The mpt3sas driver relies in a FW queue (Reply Post Descriptor Queue) in the I/O completion path; there's a MMIO register that driver uses to flag an empty entry in such queue, called Reply Post Host Index. This value is updated during the driver interrupt routine [in _base_interrupt() function]. * Happens that there are 2 registers representing the Reply Post Host Index according to the type of the adapter. They are differentiated in the driver through the "ioc->combined_reply_queue" check. By the MPI specification (vendor spec), driver should use this combined reply queue according to the number of maximum MSI-X vectors that the adapter exposes and the spec version (SAS 3.0 vs SAS 3.5). * Currently, this is wrong checked for a class of adapters, which was fixed in the upstream kernel commit 2b48be65685a [0]. Without this commit, we can observe spontaneous resets in the driver due to queue overflow (FW is not aware that there are free entries in the Reply Post Descriptor Queue). The dmesg log will show the following output in case of this error: mpt3sas_cm0: fault_state(0x2100)! mpt3sas_cm0: sending diag reset !! mpt3sas_cm0: diag reset: SUCCESS [followed by a lot of driver messages as result of the reset procedure] * During these resets, I/O is stalled so it may affect performance. [Test Case] * It's not trivial to test the problem, but given a machine with an affected device, an I/O benchmark like FIO could be used to exercise the I/O path in a heavy way and trigger the issue. We have reports that the adapter "LSI Logic / Symbios Logic Device [1000:00ac]" is affected by the issue. [Regression Potential] * This is a long-term issue from the mpt3sas driver, affecting only a class of adapters of this vendor. Since it's a clear bug, the fix is necessary. The potential of regressions is unknown, but likely low - it changes the register used for the index updates given some set of characteristics of the adapter (according to the spec.), which restricts even more the scope of this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810781/+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 1810781] Re: mpt3sas - driver using the wrong register to update a queue index in FW
** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Disco) Importance: Critical Assignee: Guilherme G. Piccoli (gpiccoli) Status: Confirmed ** Also affects: linux (Ubuntu Xenial) 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/1810781 Title: mpt3sas - driver using the wrong register to update a queue index in FW Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Status in linux source package in Disco: Fix Released Bug description: [Impact] * The mpt3sas driver relies in a FW queue (Reply Post Descriptor Queue) in the I/O completion path; there's a MMIO register that driver uses to flag an empty entry in such queue, called Reply Post Host Index. This value is updated during the driver interrupt routine [in _base_interrupt() function]. * Happens that there are 2 registers representing the Reply Post Host Index according to the type of the adapter. They are differentiated in the driver through the "ioc->combined_reply_queue" check. By the MPI specification (vendor spec), driver should use this combined reply queue according to the number of maximum MSI-X vectors that the adapter exposes and the spec version (SAS 3.0 vs SAS 3.5). * Currently, this is wrong checked for a class of adapters, which was fixed in the upstream kernel commit 2b48be65685a [0]. Without this commit, we can observe spontaneous resets in the driver due to queue overflow (FW is not aware that there are free entries in the Reply Post Descriptor Queue). The dmesg log will show the following output in case of this error: mpt3sas_cm0: fault_state(0x2100)! mpt3sas_cm0: sending diag reset !! mpt3sas_cm0: diag reset: SUCCESS [followed by a lot of driver messages as result of the reset procedure] * During these resets, I/O is stalled so it may affect performance. [Test Case] * It's not trivial to test the problem, but given a machine with an affected device, an I/O benchmark like FIO could be used to exercise the I/O path in a heavy way and trigger the issue. We have reports that the adapter "LSI Logic / Symbios Logic Device [1000:00ac]" is affected by the issue. [Regression Potential] * This is a long-term issue from the mpt3sas driver, affecting only a class of adapters of this vendor. Since it's a clear bug, the fix is necessary. The potential of regressions is unknown, but likely low - it changes the register used for the index updates given some set of characteristics of the adapter (according to the spec.), which restricts even more the scope of this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810781/+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:18.0.3-0ubuntu1~cloud0 --- nova (2:18.0.3-0ubuntu1~cloud0) bionic-rocky; urgency=medium . * New update for the Ubuntu Cloud Archive. . 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). ** Changed in: cloud-archive/rocky 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 Released Status in Ubuntu Cloud Archive rocky series: Fix Released 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
[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~cloud0 --- nova (2:17.0.7-0ubuntu1~cloud0) xenial-queens; urgency=medium . * New upstream release for the Ubuntu Cloud Archive. . 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). ** Changed in: cloud-archive/queens 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 Released 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,
[Group.of.nepali.translators] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)
This bug was fixed in the package debian-installer -
20101020ubuntu451.27
---
debian-installer (20101020ubuntu451.27) xenial; urgency=medium
* build/pkg-lists/base: add ca-certificates-udeb to enable HTTPS
without d-i/allow_unauthenticated_ssl in stock initramfs image
as in Debian. (LP: #1807023)
-- Mauricio Faria de Oliveira Mon, 26 Nov 2018
16:49:46 -0200
** Changed in: debian-installer (Ubuntu Xenial)
Status: Fix Committed => Fix Released
** Changed in: ca-certificates (Ubuntu Trusty)
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/1807023
Title:
installer stock images fail to validate any HTTPS certificates (ca-
certificates missing)
Status in debian-installer:
Fix Released
Status in ca-certificates package in Ubuntu:
Invalid
Status in debian-installer package in Ubuntu:
Fix Released
Status in ca-certificates source package in Trusty:
Fix Released
Status in debian-installer source package in Trusty:
Fix Released
Status in ca-certificates source package in Xenial:
Fix Released
Status in debian-installer source package in Xenial:
Fix Released
Status in ca-certificates source package in Bionic:
Invalid
Status in debian-installer source package in Bionic:
Fix Released
Status in ca-certificates source package in Cosmic:
Invalid
Status in debian-installer source package in Cosmic:
Fix Released
Status in ca-certificates source package in Disco:
Invalid
Status in debian-installer source package in Disco:
Fix Released
Status in debian-installer package in Debian:
Fix Released
Bug description:
[Impact]
* The installer stock images fail to validate any HTTPS
certificates because ca-certificates is not available
in the installer environment.
* This causes wget/download errors for preseed files on
HTTPS servers (or HTTP servers that redirect to HTTPS,
which are increasingly common nowadays - e.g., GitHub)
and theoretically any other files that are downloaded
with d-i-utils/fetch-url/wget.
* The fix is to ship ca-certificates-udeb in installer
stock images.
* Debian already ships ca-certificate-udeb in the stock
installer images; the fix is applied since Jan 2017.
(reference: Debian Bug #842040 / d-i commit 2f00c51a [1])
[Test Case]
* In the installer shell:
~ # wget http://github.com # or https://github.com
- FAIL if ca-certificates-udeb is missing:
"ERROR: cannot verify github.com's certificate, <...>'
- PASS if ca-certificates-udeb is available
"Saving to: 'index.html'"
* Test steps with virt-install and netboot images
are provided in the comments, for each release.
[Regression Potential]
* Low. This just adds the ca-certificates files in
/etc/ssl/certs and symlink in /usr/lib/ssl/certs,
so only tools looking for that would be affected.
* Apparently only wget checks for/uses those files,
and the difference in behavior is download errors
no longer occur.
[Notes]
* The ca-certificates-udeb is not currently present
in the Ubuntu 'main' component, but in 'universe',
despite the normal deb being in 'main'.
However, when rebuilding in a PPA it goes into
'main' accordingly, and can be used by default
by debian-installer (otherwise, UDEB_COMPONENTS
has to be modified to include universe/d-i).
* So this fix includes a no-change-rebuild for the
ca-certificates package, in order to publish the
udeb in the archive (at least in PPA for testing).
Hopefully that can be sorted out for this fix
to work out.
* The ca-certificates and debian-installer builds
have been done in a PPA using all architectures,
and testing has been done with the amd64 images.
* This fix is requested for Bionic, Cosmic, Disco
at least.
* The fix for Trusty and Xenial needed a little
bit more work to build/ship the (new) udeb.
(reference: Debian Bug #845456 / ca-certificates commit 3acb3a90 [2])
It would be good to have them too if at all possible.
[1]
https://salsa.debian.org/installer-team/debian-installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6
[2]
https://salsa.debian.org/debian/ca-certificates/commit/3acb3a9042a00307ba35d10052d81cdc206c34a4
[Debugging]
For debugging purposes, one can install strace-udeb in the installer
to verify wget's stat() calls to /usr/lib/ssl/certs.
~ # anna-install strace-udeb
~ # strace -e stat wget -O- https://github.com >/dev/null
...
Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644,
st_size=20, ...}) = 0
140.82.118.3, 140.82.118.4
Connecting to github.com|140.82.118.3|:443... connected.
stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1
[Group.of.nepali.translators] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)
This bug was fixed in the package ca-certificates - 20170717~14.04.2
---
ca-certificates (20170717~14.04.2) trusty; urgency=medium
* Add ca-certificates udeb package (LP: #1807023)
-- Mauricio Faria de Oliveira Thu, 06 Dec 2018
16:20:55 -0200
** Changed in: debian-installer (Ubuntu Trusty)
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/1807023
Title:
installer stock images fail to validate any HTTPS certificates (ca-
certificates missing)
Status in debian-installer:
Fix Released
Status in ca-certificates package in Ubuntu:
Invalid
Status in debian-installer package in Ubuntu:
Fix Released
Status in ca-certificates source package in Trusty:
Fix Released
Status in debian-installer source package in Trusty:
Fix Released
Status in ca-certificates source package in Xenial:
Fix Released
Status in debian-installer source package in Xenial:
Fix Released
Status in ca-certificates source package in Bionic:
Invalid
Status in debian-installer source package in Bionic:
Fix Released
Status in ca-certificates source package in Cosmic:
Invalid
Status in debian-installer source package in Cosmic:
Fix Released
Status in ca-certificates source package in Disco:
Invalid
Status in debian-installer source package in Disco:
Fix Released
Status in debian-installer package in Debian:
Fix Released
Bug description:
[Impact]
* The installer stock images fail to validate any HTTPS
certificates because ca-certificates is not available
in the installer environment.
* This causes wget/download errors for preseed files on
HTTPS servers (or HTTP servers that redirect to HTTPS,
which are increasingly common nowadays - e.g., GitHub)
and theoretically any other files that are downloaded
with d-i-utils/fetch-url/wget.
* The fix is to ship ca-certificates-udeb in installer
stock images.
* Debian already ships ca-certificate-udeb in the stock
installer images; the fix is applied since Jan 2017.
(reference: Debian Bug #842040 / d-i commit 2f00c51a [1])
[Test Case]
* In the installer shell:
~ # wget http://github.com # or https://github.com
- FAIL if ca-certificates-udeb is missing:
"ERROR: cannot verify github.com's certificate, <...>'
- PASS if ca-certificates-udeb is available
"Saving to: 'index.html'"
* Test steps with virt-install and netboot images
are provided in the comments, for each release.
[Regression Potential]
* Low. This just adds the ca-certificates files in
/etc/ssl/certs and symlink in /usr/lib/ssl/certs,
so only tools looking for that would be affected.
* Apparently only wget checks for/uses those files,
and the difference in behavior is download errors
no longer occur.
[Notes]
* The ca-certificates-udeb is not currently present
in the Ubuntu 'main' component, but in 'universe',
despite the normal deb being in 'main'.
However, when rebuilding in a PPA it goes into
'main' accordingly, and can be used by default
by debian-installer (otherwise, UDEB_COMPONENTS
has to be modified to include universe/d-i).
* So this fix includes a no-change-rebuild for the
ca-certificates package, in order to publish the
udeb in the archive (at least in PPA for testing).
Hopefully that can be sorted out for this fix
to work out.
* The ca-certificates and debian-installer builds
have been done in a PPA using all architectures,
and testing has been done with the amd64 images.
* This fix is requested for Bionic, Cosmic, Disco
at least.
* The fix for Trusty and Xenial needed a little
bit more work to build/ship the (new) udeb.
(reference: Debian Bug #845456 / ca-certificates commit 3acb3a90 [2])
It would be good to have them too if at all possible.
[1]
https://salsa.debian.org/installer-team/debian-installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6
[2]
https://salsa.debian.org/debian/ca-certificates/commit/3acb3a9042a00307ba35d10052d81cdc206c34a4
[Debugging]
For debugging purposes, one can install strace-udeb in the installer
to verify wget's stat() calls to /usr/lib/ssl/certs.
~ # anna-install strace-udeb
~ # strace -e stat wget -O- https://github.com >/dev/null
...
Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644,
st_size=20, ...}) = 0
140.82.118.3, 140.82.118.4
Connecting to github.com|140.82.118.3|:443... connected.
stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1 ENOENT (No such
file or directory)
stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such
file or directory)
stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such
file or
[Group.of.nepali.translators] [Bug 1807023] Re: installer stock images fail to validate any HTTPS certificates (ca-certificates missing)
This bug was fixed in the package ca-certificates - 20170717~16.04.2
---
ca-certificates (20170717~16.04.2) xenial; urgency=medium
* Add ca-certificates udeb package (LP: #1807023)
-- Mauricio Faria de Oliveira Thu, 06 Dec 2018
16:20:55 -0200
** Changed in: ca-certificates (Ubuntu Xenial)
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/1807023
Title:
installer stock images fail to validate any HTTPS certificates (ca-
certificates missing)
Status in debian-installer:
Fix Released
Status in ca-certificates package in Ubuntu:
Invalid
Status in debian-installer package in Ubuntu:
Fix Released
Status in ca-certificates source package in Trusty:
Fix Committed
Status in debian-installer source package in Trusty:
Fix Committed
Status in ca-certificates source package in Xenial:
Fix Released
Status in debian-installer source package in Xenial:
Fix Committed
Status in ca-certificates source package in Bionic:
Invalid
Status in debian-installer source package in Bionic:
Fix Released
Status in ca-certificates source package in Cosmic:
Invalid
Status in debian-installer source package in Cosmic:
Fix Released
Status in ca-certificates source package in Disco:
Invalid
Status in debian-installer source package in Disco:
Fix Released
Status in debian-installer package in Debian:
Fix Released
Bug description:
[Impact]
* The installer stock images fail to validate any HTTPS
certificates because ca-certificates is not available
in the installer environment.
* This causes wget/download errors for preseed files on
HTTPS servers (or HTTP servers that redirect to HTTPS,
which are increasingly common nowadays - e.g., GitHub)
and theoretically any other files that are downloaded
with d-i-utils/fetch-url/wget.
* The fix is to ship ca-certificates-udeb in installer
stock images.
* Debian already ships ca-certificate-udeb in the stock
installer images; the fix is applied since Jan 2017.
(reference: Debian Bug #842040 / d-i commit 2f00c51a [1])
[Test Case]
* In the installer shell:
~ # wget http://github.com # or https://github.com
- FAIL if ca-certificates-udeb is missing:
"ERROR: cannot verify github.com's certificate, <...>'
- PASS if ca-certificates-udeb is available
"Saving to: 'index.html'"
* Test steps with virt-install and netboot images
are provided in the comments, for each release.
[Regression Potential]
* Low. This just adds the ca-certificates files in
/etc/ssl/certs and symlink in /usr/lib/ssl/certs,
so only tools looking for that would be affected.
* Apparently only wget checks for/uses those files,
and the difference in behavior is download errors
no longer occur.
[Notes]
* The ca-certificates-udeb is not currently present
in the Ubuntu 'main' component, but in 'universe',
despite the normal deb being in 'main'.
However, when rebuilding in a PPA it goes into
'main' accordingly, and can be used by default
by debian-installer (otherwise, UDEB_COMPONENTS
has to be modified to include universe/d-i).
* So this fix includes a no-change-rebuild for the
ca-certificates package, in order to publish the
udeb in the archive (at least in PPA for testing).
Hopefully that can be sorted out for this fix
to work out.
* The ca-certificates and debian-installer builds
have been done in a PPA using all architectures,
and testing has been done with the amd64 images.
* This fix is requested for Bionic, Cosmic, Disco
at least.
* The fix for Trusty and Xenial needed a little
bit more work to build/ship the (new) udeb.
(reference: Debian Bug #845456 / ca-certificates commit 3acb3a90 [2])
It would be good to have them too if at all possible.
[1]
https://salsa.debian.org/installer-team/debian-installer/commit/2f00c51a7ead982ae1cd71bee06c8416890196b6
[2]
https://salsa.debian.org/debian/ca-certificates/commit/3acb3a9042a00307ba35d10052d81cdc206c34a4
[Debugging]
For debugging purposes, one can install strace-udeb in the installer
to verify wget's stat() calls to /usr/lib/ssl/certs.
~ # anna-install strace-udeb
~ # strace -e stat wget -O- https://github.com >/dev/null
...
Resolving github.com... stat("/etc/resolv.conf", {st_mode=S_IFREG|0644,
st_size=20, ...}) = 0
140.82.118.3, 140.82.118.4
Connecting to github.com|140.82.118.3|:443... connected.
stat("/usr/lib/ssl/certs/45bfefc3.0", 0x7ffdba51b570) = -1 ENOENT (No such
file or directory)
stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such
file or directory)
stat("/usr/lib/ssl/certs/244b5494.0", 0x7ffdba51b570) = -1 ENOENT (No such
file or
[Group.of.nepali.translators] [Bug 1788829] Re: [SRU] Update to new maintenance release
This bug was fixed in the package borgbackup - 1.0.12-0ubuntu1.16.04.1 --- borgbackup (1.0.12-0ubuntu1.16.04.1) xenial; urgency=medium * New upstream release, fixing backup issues (LP: #1788829). -- Gianfranco Costamagna Mon, 17 Dec 2018 17:56:28 +0100 ** Changed in: borgbackup (Ubuntu Xenial) 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/1788829 Title: [SRU] Update to new maintenance release Status in borgbackup package in Ubuntu: Fix Released Status in borgbackup source package in Xenial: Fix Released Bug description: [Impact] The package currently provided in Ubuntu 16.04 LTS has a bug that causes backups to fail: https://github.com/borgbackup/borg/issues/2994 [Test Case] * Try to save and restore a backup with a different timedate [Regression potential] Minimal, borgbackup has a huge testsuite that is ran during build and autopkgtests [Other info] It has been fixed upstream in a new maintenance release: https://github.com/borgbackup/borg/blob/1.0.12/docs/changes.rst#version-1012-2018-04-08 Since it is a maintenance release, it should be safe to update the package. Current version of package: 1.0.11 Request update to version: 1.0.12 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/borgbackup/+bug/1788829/+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 1709877] Re: CPU hotplug fails in the system with empty numa nodes, "Invalid value '0-1, 16-17' for 'cpuset.mems': Invalid argument"
** Changed in: ubuntu-power-systems Status: Fix Released => Confirmed ** Changed in: libvirt (Ubuntu Xenial) Status: Incomplete => Confirmed -- 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/1709877 Title: CPU hotplug fails in the system with empty numa nodes, "Invalid value '0-1,16-17' for 'cpuset.mems': Invalid argument" Status in The Ubuntu-power-systems project: Confirmed Status in libvirt package in Ubuntu: Fix Released Status in libvirt source package in Xenial: Confirmed Bug description: == Comment: #0 - Satheesh Rajendran - 2017-07-19 04:13:18 == CPU hotplug operation fails in the host with empty numa nodes(with no memory) even though VM placement is static and with/without numad is running. .. 32 ... # virsh setvcpus virt-tests-vm1 6 --live error: Invalid value '0-1,16-17' for 'cpuset.mems': Invalid argument # numactl --hardware available: 4 nodes (0-1,16-17) node 0 cpus: 0 8 16 24 32 40 node 0 size: 16188 MB node 0 free: 1119 MB node 1 cpus: 48 56 64 72 80 88 node 1 size: 32630 MB node 1 free: 13233 MB node 16 cpus: 96 104 112 120 128 136 node 16 size: 0 MB node 16 free: 0 MB node 17 cpus: 144 152 160 168 176 184 node 17 size: 0 MB node 17 free: 0 MB node distances: node 0 1 16 17 0: 10 20 40 40 1: 20 10 40 40 16: 40 40 10 20 17: 40 40 20 10 # cat /sys/fs/cgroup/cpuset/cpuset.mems 0-1 Host: #uname -a Linux powerkvm4-lp1 4.10.0-27-generic #30~16.04.2-Ubuntu SMP Thu Jun 29 16:06:52 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux ii libvirt-bin1.3.1-1ubuntu10.11 ii numad 0.5+20150602-4 qemu-kvm 1:2.5+dfsg-5ubuntu10.14 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1709877/+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 1785033] Re: GRUB needs to support 64-bit efi linear frame buffer address
** Changed in: oem-priority Status: Triaged => 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/1785033 Title: GRUB needs to support 64-bit efi linear frame buffer address Status in HWE Next: In Progress Status in OEM Priority Project: Fix Released Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub2 source package in Trusty: New Status in grub2-signed source package in Trusty: New Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in grub2 source package in Bionic: Fix Released Status in grub2-signed source package in Bionic: Fix Released Status in grub2 source package in Cosmic: Fix Released Status in grub2-signed source package in Cosmic: Fix Released Bug description: [Rationale] More firmwares support above 4G mmio configureation and the EFI Graphics Output Protocol can return a 64-bit linear frame buffer address have been implemented in some firmware/BIOS. Grub2 currently only pass 32-bit framebuffer base to kernel. The Linux kernel has already added support to handle 64-bit linear framebuffer address in the efifb driver now. So GRUB2 should support 64-bit EFI linear frame buffer address. [Impact] Some machines block booting with firmware/bios implemented 64-bit EFI linear frame buffer address,due to Grub passing incorrect(only 32-bit) EFI linear frame buffer. [Test cases] Need Bios/Firmware support, 1) Make sure the machine with the Bios implemented 64-bit EFI linear frame buffer address. some machine need to enable above 4G mmio on bios setup menu. 2) Boot up. [Solution] A patch has been committed and accepted by maintainer http://git.savannah.gnu.org/cgit/grub.git/commit/?id=886edba8770ccbc3def0af2a7d6b346d00d0af2f [Regression Potential] Minimal, it's unlikely completing the whole framebuffer address will affect those which hasn't used above 32-bits framebuffer address. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1785033/+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
