[Group.of.nepali.translators] [Bug 1856804] Re: xenial/linux-hwe: 4.15.0-74.83~16.04.1 -proposed tracker
** Changed in: kernel-sru-workflow/regression-testing Status: In Progress => Fix Released ** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. 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: 1856749 packages: main: linux-hwe meta: linux-meta-hwe signed: linux-signed-hwe phase: Testing phase-changed: Thursday, 19. December 2019 15:15 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: automated-testing: Stalled -- testing FAILED - regression-testing: Ongoing -- testing in progress security-signoff: Pending -- waiting for signoff trackers: xenial/linux-deeplens: bug 1854817 variant: debs -- 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/1856804 Title: xenial/linux-hwe: 4.15.0-74.83~16.04.1 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Incomplete 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: In Progress 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 will contain status and test results related to a kernel source (or snap) as stated in the title. 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: 1856749 packages: main: linux-hwe meta: linux-meta-hwe signed: linux-signed-hwe phase: Testing phase-changed: Thursday, 19. December 2019 15:15 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: automated-testing: Stalled -- testing FAILED security-signoff: Pending -- waiting for signoff trackers: xenial/linux-deeplens: bug 1854817 variant: debs To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1856804/+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 1856203] Re: xenial/linux-azure: 4.15.0-1066.71 -proposed tracker
** Changed in: kernel-sru-workflow/stakeholder-signoff Status: Confirmed => Fix Committed ** Changed in: kernel-sru-workflow/stakeholder-signoff 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/1856203 Title: xenial/linux-azure: 4.15.0-1066.71 -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: Invalid 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: In Progress Status in Kernel SRU Workflow stakeholder-signoff series: Fix Released Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux-azure package in Ubuntu: Invalid Status in linux-azure source package in Xenial: Confirmed Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. 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: '1856749' packages: main: linux-azure meta: linux-meta-azure signed: linux-signed-azure phase: Signoff phase-changed: Friday, 20. December 2019 01:13 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: promote-to-updates: Holding -- stakeholder signoff not verified security-signoff: Stalled -- waiting for signoff stakeholder-signoff: Stalled -- waiting for signoff trackers: trusty/linux-azure: bug 1856202 xenial/linux-azure/azure-kernel: bug 1856199 variant: debs To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1856203/+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 1816743] Re: Add systemd's kdump service command-line regardless if user provides or not KDUMP_CMDLINE_APPEND
I'm un-marking this as duplicate - LP #1800566 is being worked only for the reset_devices portion, so I'm decoupling both bugs in order we can work this one soon-ish. Cheers, Guilherme ** This bug is no longer a duplicate of bug 1800566 Make reset_devices parameter default for kdump and decouple kdump systemd service from the KDUMP_CMDLINE_APPEND ** Also affects: makedumpfile (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: makedumpfile (Ubuntu Focal) Importance: Undecided Assignee: Guilherme G. Piccoli (gpiccoli) Status: Confirmed ** Changed in: makedumpfile (Ubuntu Cosmic) Status: Confirmed => Won't Fix ** Changed in: makedumpfile (Ubuntu Disco) Status: Confirmed => Won't Fix ** Changed in: makedumpfile (Ubuntu Eoan) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: makedumpfile (Ubuntu Eoan) Status: New => Confirmed ** Changed in: makedumpfile (Ubuntu Focal) Importance: Undecided => Low ** Changed in: makedumpfile (Ubuntu Eoan) Importance: Undecided => Low ** Changed in: makedumpfile (Ubuntu Disco) Importance: Undecided => Low ** Changed in: makedumpfile (Ubuntu Cosmic) Importance: Undecided => Low ** Changed in: makedumpfile (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: makedumpfile (Ubuntu Xenial) Importance: Undecided => Low -- 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/1816743 Title: Add systemd's kdump service command-line regardless if user provides or not KDUMP_CMDLINE_APPEND Status in makedumpfile package in Ubuntu: Confirmed Status in makedumpfile source package in Xenial: Confirmed Status in makedumpfile source package in Bionic: Confirmed Status in makedumpfile source package in Cosmic: Won't Fix Status in makedumpfile source package in Disco: Won't Fix Status in makedumpfile source package in Eoan: Confirmed Status in makedumpfile source package in Focal: Confirmed Bug description: Since Xenial release, Ubuntu relies on systemd as its init system - there's a kdump service to prevent some other services to unnecessarily start in kdump environment. Problem: if we add something to KDUMP_CMDLINE_APPEND, the entry for kdump service, "systemd.unit=kdump-tools.service" is removed from the command-line. The user manually needs to add that, and this seems highly prone to error. We propose here to decouple the "systemd.unit=kdump-tools.service" parameter from KDUMP_CMDLINE_APPEND, so if user wants really to remove this option, they should used KDUMP_CMDLINE instead. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1816743/+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 1828596] Re: kdump fails when crash is triggered after DLPAR cpu add operation
** Changed in: makedumpfile (Ubuntu Disco) Status: Won't Fix => In Progress -- 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/1828596 Title: kdump fails when crash is triggered after DLPAR cpu add operation Status in The Ubuntu-power-systems project: In Progress Status in makedumpfile package in Ubuntu: In Progress Status in makedumpfile source package in Xenial: In Progress Status in makedumpfile source package in Bionic: In Progress Status in makedumpfile source package in Cosmic: Won't Fix Status in makedumpfile source package in Disco: In Progress Status in makedumpfile source package in Eoan: In Progress Status in makedumpfile source package in Focal: In Progress Bug description: [Impact] After a CPU add/hotplug operation on Power systems, kdump will fail after a crash. The kdump kernel needs to be reloaded after a CPU add/hotplug. [Test case] Do CPU add/hotplug, trigger a crash, and check for a successful kdump. [Regression potential] Multiple reloads caused by multiple sequential CPU adds may cause spurious log results, and systemd may fail to properly reload the kdump kernel. This has been handled by resetting the failure counter when doing such reloads. == Comment: #0 - Hari Krishna Bathini - 2019-05-10 05:55:40 == ---Problem Description--- kdump fails when crash is triggered after CPU add operation. Machine Type = na ---System Hang--- Crashed in early boot process of kdump kernel after crash Had to issue system reset from HMC to reclaim ---Steps to Reproduce--- 1. Configure kdump. 2. Add cpu from HMC. 3. Trigger crash. 4. Machine hangs after crash as below: --- [169250.213166] IPI complete [169250.234331] kexec: Starting switchover sequence. I'm in purgatory --- STRUCK HERE --- ---uname output--- na ---Debugger--- A debugger is not configured == Comment: #1 - Hari Krishna Bathini - 2019-05-10 05:56:46 == The problem is, kexec udev rule to restart kdump-tools service - when a core is added, is not being triggered. The old DT created by kexec (before the core is added) is being used by KDump Kernel. So, when system crashes on a thread from the added core(s), KDump kernel is failing to get the 'boot_cpuid' and eventually failing to boot.. == Comment: #2 - Hari Krishna Bathini - 2019-05-10 06:02:27 == The udev rule when CPU is added is not triggered because ppc64 does not eject add/remove event when a CPU is hot added/removed. It only ejects online/offline event to user space when CPU is hot added/removed. So, the below udev rules are never triggered when needed: SUBSYSTEM=="cpu", ACTION=="add", PROGRAM="/bin/systemctl try-restart kdump-tools.service" SUBSYSTEM=="cpu", ACTION=="remove", PROGRAM="/bin/systemctl try-restart kdump-tools.service" Also, with how CPU hot add & remove are handled in ppc64, a udev trigger to reload kdump after CPU is hot removed is NOT necessary. So, fix the CPU hot add case by updating the udev rule and drop the udev rule meant for CPU hot remove in the kdump udev rules file: SUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl try- restart kdump-tools.service" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1828596/+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 1800566] Re: Make reset_devices parameter default for kdump and decouple kdump systemd service from the KDUMP_CMDLINE_APPEND
** Changed in: makedumpfile (Ubuntu Disco) Status: Won't Fix => In Progress -- 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/1800566 Title: Make reset_devices parameter default for kdump and decouple kdump systemd service from the KDUMP_CMDLINE_APPEND Status in makedumpfile package in Ubuntu: In Progress Status in makedumpfile source package in Trusty: Won't Fix Status in makedumpfile source package in Xenial: In Progress Status in makedumpfile source package in Bionic: In Progress Status in makedumpfile source package in Cosmic: Won't Fix Status in makedumpfile source package in Disco: In Progress Status in makedumpfile source package in Eoan: In Progress Status in makedumpfile source package in Focal: In Progress Bug description: [Impact] * Kdump does not configure by default the crash kernel to perform a device reset by default, by passing the "reset_devices" parameter. Also, the systemd service "kdump-tools-dump" is tightly-coupled with KDUMP_CMDLINE_APPEND and it shouldn't, to prevent user confusion. * Kernel has the "reset_devices" parameter that drivers can opt-in, and perform special activity in case this parameter is parsed from command-line. For example, in kdump kernels it hints the drivers that they are booting from a non-healthy condition and needs to issue some form of reset to the adapter, like clearing DMA mapping in their firmware for example. Users currently (kernel v5.2) are: aacraid, hpsa, ipr, megaraid_sas, mpt3sas, smartpqi, xenbus. This should be enabled by default in the kdump config file to be added in the kdump kernel command-line for all versions. * The systemd service"kdump-tools-dump" is responsible for triggering the execution of the makedumpfile tool ultimately. Kdump from Xenial+ releases rely on systemd as their init system, so this service is the way to trigger the kdump mechanism. Currently it is configured as any other parameter in KDUMP_CMDLINE_APPEND, meaning if user decides to change the line they need to remember adding the systemd service back. It's not really a parameter that should be easily manipulated in kdump line, since there's no use for it except to instruct systemd to load kdump; the only reasonable case for removing it is to debug kdump itself. [Test Case] 1) Deploy a Disco VM e.g. with uvt-kvm 2) Install the kdump-tools package 3) Run `kdump-config test`and check for the 'reset_devices' parameter: $ kdump-config test ... kexec command to be used: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" /var/lib/kdump/vmlinuz Also, by changing the KDUMP_CMDLINE_APPEND we can see "systemd.unit =kdump-tools.service" to be removed. [Regression Potential] The regression potential is low, since it doesn't need any changes in makedumpfile code and we're only adding a parameter on the crash kernel command-line. The risks are related with bad behavior with the kernel when using "reset_devices", like if the driver has bugs in this path. It's considered safer to have the option (and this way prevent problems for booting a unhealthy kernel with potential stuck DMAs in the devices) than not having it. Regarding the other change, about the systemd service, it'll only affect users the are debugging kdump itself and it has no known regression potential. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800566/+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 1811692] Re: udev coldplug will interrupt makedumpfile
** Also affects: makedumpfile (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: makedumpfile (Ubuntu Xenial) Status: New => In Progress -- 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/1811692 Title: udev coldplug will interrupt makedumpfile Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: In Progress Status in makedumpfile source package in Bionic: Fix Released Status in makedumpfile source package in Cosmic: Fix Released Status in makedumpfile source package in Disco: Fix Released Bug description: [Impact] During kdump on i386 systems, udev will restart kdump-tools, which will kill makedumpfile during dump capture, causing the system to reboot without capturing a dump. [Test case] After the fix, a dump could be captured on i386. Other arches were tested and worked just as fine. [Regression potential] Systems could fail to have a dump captured, but it was tested to not be the case. === After introducing the udev rules to restart kdump-tools service when there is memory or cpu hotplug, it will be restarted during coldplug as well. This will cause the dump capture itself to be interrupted after a crash. When it is restarted and tries to dump again, it will find an existing dump file and will fail to dump. My proposed solution is to use a different systemd service for the real capture. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1811692/+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 1800566] Re: Make reset_devices parameter default for kdump and decouple kdump systemd service from the KDUMP_CMDLINE_APPEND
** Changed in: makedumpfile (Ubuntu Disco) Status: Confirmed => Won't Fix ** Changed in: makedumpfile (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: makedumpfile (Ubuntu Eoan) Status: Confirmed => In Progress ** Changed in: makedumpfile (Ubuntu Bionic) Status: Confirmed => In Progress ** Changed in: makedumpfile (Ubuntu Xenial) Status: Confirmed => In Progress -- 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/1800566 Title: Make reset_devices parameter default for kdump and decouple kdump systemd service from the KDUMP_CMDLINE_APPEND Status in makedumpfile package in Ubuntu: In Progress Status in makedumpfile source package in Trusty: Won't Fix Status in makedumpfile source package in Xenial: In Progress Status in makedumpfile source package in Bionic: In Progress Status in makedumpfile source package in Cosmic: Won't Fix Status in makedumpfile source package in Disco: Won't Fix Status in makedumpfile source package in Eoan: In Progress Status in makedumpfile source package in Focal: In Progress Bug description: [Impact] * Kdump does not configure by default the crash kernel to perform a device reset by default, by passing the "reset_devices" parameter. Also, the systemd service "kdump-tools-dump" is tightly-coupled with KDUMP_CMDLINE_APPEND and it shouldn't, to prevent user confusion. * Kernel has the "reset_devices" parameter that drivers can opt-in, and perform special activity in case this parameter is parsed from command-line. For example, in kdump kernels it hints the drivers that they are booting from a non-healthy condition and needs to issue some form of reset to the adapter, like clearing DMA mapping in their firmware for example. Users currently (kernel v5.2) are: aacraid, hpsa, ipr, megaraid_sas, mpt3sas, smartpqi, xenbus. This should be enabled by default in the kdump config file to be added in the kdump kernel command-line for all versions. * The systemd service"kdump-tools-dump" is responsible for triggering the execution of the makedumpfile tool ultimately. Kdump from Xenial+ releases rely on systemd as their init system, so this service is the way to trigger the kdump mechanism. Currently it is configured as any other parameter in KDUMP_CMDLINE_APPEND, meaning if user decides to change the line they need to remember adding the systemd service back. It's not really a parameter that should be easily manipulated in kdump line, since there's no use for it except to instruct systemd to load kdump; the only reasonable case for removing it is to debug kdump itself. [Test Case] 1) Deploy a Disco VM e.g. with uvt-kvm 2) Install the kdump-tools package 3) Run `kdump-config test`and check for the 'reset_devices' parameter: $ kdump-config test ... kexec command to be used: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" /var/lib/kdump/vmlinuz Also, by changing the KDUMP_CMDLINE_APPEND we can see "systemd.unit =kdump-tools.service" to be removed. [Regression Potential] The regression potential is low, since it doesn't need any changes in makedumpfile code and we're only adding a parameter on the crash kernel command-line. The risks are related with bad behavior with the kernel when using "reset_devices", like if the driver has bugs in this path. It's considered safer to have the option (and this way prevent problems for booting a unhealthy kernel with potential stuck DMAs in the devices) than not having it. Regarding the other change, about the systemd service, it'll only affect users the are debugging kdump itself and it has no known regression potential. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800566/+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 1854817] Re: xenial/linux-deeplens: 4.15.0-1014.14 -proposed tracker
** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. 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: 1854818 + kernel-stable-master-bug: '1856804' packages: main: linux-deeplens meta: linux-meta-deeplens phase: Testing phase-changed: Thursday, 05. December 2019 13:21 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: certification-testing: Ongoing -- testing in progress verification-testing: Ongoing -- testing in progress variant: debs ** Changed in: kernel-sru-workflow/verification-testing Status: In Progress => Fix Released ** Description changed: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. 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: '1856804' packages: main: linux-deeplens meta: linux-meta-deeplens - phase: Testing - phase-changed: Thursday, 05. December 2019 13:21 UTC + phase: Holding before Promote to Updates + phase-changed: Friday, 20. December 2019 12:11 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: - certification-testing: Ongoing -- testing in progress - verification-testing: Ongoing -- testing in progress + promote-to-updates: Holding -- cycle not ready to release variant: debs -- 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/1854817 Title: xenial/linux-deeplens: 4.15.0-1014.14 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Invalid 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 promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: Invalid Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Invalid Status in Kernel SRU Workflow security-signoff series: Invalid Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. 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: '1856804' packages: main: linux-deeplens meta: linux-meta-deeplens phase: Holding before Promote to Updates phase-changed: Friday, 20. December 2019 12:11 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: promote-to-updates: Holding -- cycle not ready to release variant: debs To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1854817/+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 1854817] Re: xenial/linux-deeplens: 4.15.0-1014.14 -proposed tracker
Hardware Certification have completed testing this -proposed kernel. No regressions were observed, results are available here: DeepLens: https://certification.canonical.com/hardware/201801-26078/submission/156870/ DeepRacer: https://certification.canonical.com/hardware/201903-26883/submission/156869/ ** 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/1854817 Title: xenial/linux-deeplens: 4.15.0-1014.14 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Invalid 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 promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: Invalid Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Invalid Status in Kernel SRU Workflow security-signoff series: Invalid Status in Kernel SRU Workflow verification-testing series: In Progress Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. 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: '1856804' packages: main: linux-deeplens meta: linux-meta-deeplens phase: Testing phase-changed: Thursday, 05. December 2019 13:21 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: certification-testing: Ongoing -- testing in progress verification-testing: Ongoing -- testing in progress variant: debs To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1854817/+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
