[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
** Changed in: oem-priority Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Status in systemd source package in Kinetic: Fix Released Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk In the journal, we can see systemd-shutdown looping repeatedly as it tries and fails to detach all md devices: ... [ 513.416293] systemd-shutdown[1]: Stopping MD /dev/md124p2 (259:5). [ 513.422953] systemd-shutdown[1]: Could not stop MD /dev/md124p2: Device or resource busy [ 513.431227] systemd-shutdown[1]: Stopping MD /dev/md124p1 (259:4). [ 513.437952] systemd-shutdown[1]: Could not stop MD /dev/md124p1: Device or resource busy [ 513.449298] systemd-shutdown[1]: Stopping MD /dev/md124 (9:124). [ 513.456278] systemd-shutdown[1]: Could not stop MD /dev/md124: Device or resource busy [ 513.465323] systemd-shutdown[1]: Not all MD devices stopped, 4 left. [ 513.472564] systemd-shutdown[1]: Couldn't finalize remaining MD devices, trying again. [ 513.485302] systemd-shutdown[1]: Failed to open watchdog device /dev/watchdog: No such file or directory [ 513.496195] systemd-shutdown[1]: Stopping MD devices. [ 513.502176] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 513.513382] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 513.521436] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 513.534810] systemd-shutdown[1]: Stopping MD /dev/md126 (9:126). [ 513.545384] systemd-shutdown[1]: Failed to sync MD block device /dev/md126, ignoring: Input/output error [ 513.557265] md: md126 stopped. [ 513.561451] systemd-shutdown[1]: Stopping MD /dev/md124p2 (259:5). [ 513.576673] systemd-shutdown[1]: Could not stop MD /dev/md124p2: Device or resource busy [ 513.589274] systemd-shutdown[1]: Stopping MD /dev/md124p1 (259:4). [ 513.597976] systemd-shutdown[1]: Could not stop MD /dev/md124p1: Device or resource busy [ 513.607263] systemd-shutdown[1]: Stopping MD /dev/md124 (9:124). [ 513.615067] systemd-shutdown[1]: Could not stop MD /dev/md124: Device or resource busy [ 513.625157] systemd-shutdown[1]: Not all MD devices stopped, 4 left. [ 513.632209] systemd-shutdown[1]: Couldn't finalize remaining MD devices, trying again. [ 513.641474] systemd-shutdown[1]: Failed to open watchdog device /dev/watchdog: No such file or directory [ 513.653660] systemd-shutdown[1]: Stopping MD devices. [ 513.661257] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 513.668833] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 513.677347] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 513.687047] systemd-shutdown[1]: Stopping MD /dev/md126 (9:126). [ 513.697206] systemd-shutdown[1]: Failed to sync MD block device /dev/md126, ignoring: Input/output error [ 513.707193] md: md126 stopped. ... [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] The patch confirmed fixed the reboot issue on the system with two VROC RAIDs but more than two VROC RAIDs and the
[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
** Changed in: oem-priority Status: Fix Released => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Triaged Status in systemd source package in Kinetic: Fix Released Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk In the journal, we can see systemd-shutdown looping repeatedly as it tries and fails to detach all md devices: ... [ 513.416293] systemd-shutdown[1]: Stopping MD /dev/md124p2 (259:5). [ 513.422953] systemd-shutdown[1]: Could not stop MD /dev/md124p2: Device or resource busy [ 513.431227] systemd-shutdown[1]: Stopping MD /dev/md124p1 (259:4). [ 513.437952] systemd-shutdown[1]: Could not stop MD /dev/md124p1: Device or resource busy [ 513.449298] systemd-shutdown[1]: Stopping MD /dev/md124 (9:124). [ 513.456278] systemd-shutdown[1]: Could not stop MD /dev/md124: Device or resource busy [ 513.465323] systemd-shutdown[1]: Not all MD devices stopped, 4 left. [ 513.472564] systemd-shutdown[1]: Couldn't finalize remaining MD devices, trying again. [ 513.485302] systemd-shutdown[1]: Failed to open watchdog device /dev/watchdog: No such file or directory [ 513.496195] systemd-shutdown[1]: Stopping MD devices. [ 513.502176] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 513.513382] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 513.521436] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 513.534810] systemd-shutdown[1]: Stopping MD /dev/md126 (9:126). [ 513.545384] systemd-shutdown[1]: Failed to sync MD block device /dev/md126, ignoring: Input/output error [ 513.557265] md: md126 stopped. [ 513.561451] systemd-shutdown[1]: Stopping MD /dev/md124p2 (259:5). [ 513.576673] systemd-shutdown[1]: Could not stop MD /dev/md124p2: Device or resource busy [ 513.589274] systemd-shutdown[1]: Stopping MD /dev/md124p1 (259:4). [ 513.597976] systemd-shutdown[1]: Could not stop MD /dev/md124p1: Device or resource busy [ 513.607263] systemd-shutdown[1]: Stopping MD /dev/md124 (9:124). [ 513.615067] systemd-shutdown[1]: Could not stop MD /dev/md124: Device or resource busy [ 513.625157] systemd-shutdown[1]: Not all MD devices stopped, 4 left. [ 513.632209] systemd-shutdown[1]: Couldn't finalize remaining MD devices, trying again. [ 513.641474] systemd-shutdown[1]: Failed to open watchdog device /dev/watchdog: No such file or directory [ 513.653660] systemd-shutdown[1]: Stopping MD devices. [ 513.661257] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 513.668833] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 513.677347] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 513.687047] systemd-shutdown[1]: Stopping MD /dev/md126 (9:126). [ 513.697206] systemd-shutdown[1]: Failed to sync MD block device /dev/md126, ignoring: Input/output error [ 513.707193] md: md126 stopped. ... [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] The patch confirmed fixed the reboot issue on the system with two VROC RAIDs but more than two VROC RAIDs and the combinations of
[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
** Changed in: oem-priority Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Status in systemd source package in Kinetic: Fix Released Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk In the journal, we can see systemd-shutdown looping repeatedly as it tries and fails to detach all md devices: ... [ 513.416293] systemd-shutdown[1]: Stopping MD /dev/md124p2 (259:5). [ 513.422953] systemd-shutdown[1]: Could not stop MD /dev/md124p2: Device or resource busy [ 513.431227] systemd-shutdown[1]: Stopping MD /dev/md124p1 (259:4). [ 513.437952] systemd-shutdown[1]: Could not stop MD /dev/md124p1: Device or resource busy [ 513.449298] systemd-shutdown[1]: Stopping MD /dev/md124 (9:124). [ 513.456278] systemd-shutdown[1]: Could not stop MD /dev/md124: Device or resource busy [ 513.465323] systemd-shutdown[1]: Not all MD devices stopped, 4 left. [ 513.472564] systemd-shutdown[1]: Couldn't finalize remaining MD devices, trying again. [ 513.485302] systemd-shutdown[1]: Failed to open watchdog device /dev/watchdog: No such file or directory [ 513.496195] systemd-shutdown[1]: Stopping MD devices. [ 513.502176] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 513.513382] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 513.521436] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 513.534810] systemd-shutdown[1]: Stopping MD /dev/md126 (9:126). [ 513.545384] systemd-shutdown[1]: Failed to sync MD block device /dev/md126, ignoring: Input/output error [ 513.557265] md: md126 stopped. [ 513.561451] systemd-shutdown[1]: Stopping MD /dev/md124p2 (259:5). [ 513.576673] systemd-shutdown[1]: Could not stop MD /dev/md124p2: Device or resource busy [ 513.589274] systemd-shutdown[1]: Stopping MD /dev/md124p1 (259:4). [ 513.597976] systemd-shutdown[1]: Could not stop MD /dev/md124p1: Device or resource busy [ 513.607263] systemd-shutdown[1]: Stopping MD /dev/md124 (9:124). [ 513.615067] systemd-shutdown[1]: Could not stop MD /dev/md124: Device or resource busy [ 513.625157] systemd-shutdown[1]: Not all MD devices stopped, 4 left. [ 513.632209] systemd-shutdown[1]: Couldn't finalize remaining MD devices, trying again. [ 513.641474] systemd-shutdown[1]: Failed to open watchdog device /dev/watchdog: No such file or directory [ 513.653660] systemd-shutdown[1]: Stopping MD devices. [ 513.661257] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 513.668833] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 513.677347] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 513.687047] systemd-shutdown[1]: Stopping MD /dev/md126 (9:126). [ 513.697206] systemd-shutdown[1]: Failed to sync MD block device /dev/md126, ignoring: Input/output error [ 513.707193] md: md126 stopped. ... [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] The patch confirmed fixed the reboot issue on the system with two VROC RAIDs but more than two VROC RAIDs and the
[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
Hi, The issue that pausing this SRU is going to be fixed in the kernel and the section "where problems could occur" updated. Please resume this SRU, Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: New Status in systemd source package in Kinetic: Fix Released Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] The patch confirmed fixed the reboot issue on the system with two VROC RAIDs but more than two VROC RAIDs and the combinations of RAID levels are not all tested. [ Scope ] Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2025563/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
** Description changed: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. - Intel has fixed it in systemd v251 [1]. + Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 - shutdown: get only active md arrays. - - Current md_list_get() implementation filters all block devices, started from - "md*". This is ambiguous because list could contain: - - partitions created upon md device (mdXpY) - - external metadata container- specific type of md array. - - For partitions there is no issue, because they aren't handle STOP_ARRAY - ioctl sent later. It generates misleading errors only. - - Second case is more problematic because containers are not locked in kernel. - They are stopped even if container member array is active. For that reason - reboot or shutdown flow could be blocked because metadata manager cannot be - restarted after switch root on shutdown. - - Add filters to remove partitions and containers from md_list. Partitions - can be excluded by DEVTYPE. Containers are determined by MD_LEVEL - property, we are excluding all with "container" value. - - Signed-off-by: Mariusz Tkaczyk + shutdown: get only active md arrays. + Current md_list_get() implementation filters all block devices, started from + "md*". This is ambiguous because list could contain: + - partitions created upon md device (mdXpY) + - external metadata container- specific type of md array. + + For partitions there is no issue, because they aren't handle STOP_ARRAY + ioctl sent later. It generates misleading errors only. + + Second case is more problematic because containers are not locked in kernel. + They are stopped even if container member array is active. For that reason + reboot or shutdown flow could be blocked because metadata manager cannot be + restarted after switch root on shutdown. + + Add filters to remove partitions and containers from md_list. Partitions + can be excluded by DEVTYPE. Containers are determined by MD_LEVEL + property, we are excluding all with "container" value. + + Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] - Low, upstream fix. + The patch confirmed fixed the reboot issue on the system with two VROC + RAIDs but more than two VROC RAIDs and the combinations of RAID levels + are not all tested. [ Scope ] Jammy ** Changed in: oem-priority Status: Invalid => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: New Status in systemd source package in Kinetic: Fix Released Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update
[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
Hi Athos, Thanks for the review. Please pause this SRU. There are currently issues that need clarification from Intel. I will reopen it and update the "[ Where problems could occur ]" section once the issue is clarified. Thank you. ** Changed in: oem-priority Status: In Progress => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: Invalid Status in systemd package in Ubuntu: Confirmed Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] Low, upstream fix. [ Scope ] Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2025563/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
** Patch added: "systemd_249.11-0ubuntu3.10.debdiff" https://bugs.launchpad.net/oem-priority/+bug/2025563/+attachment/5683483/+files/systemd_249.11-0ubuntu3.10.debdiff ** Changed in: oem-priority Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Confirmed Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] Low, upstream fix. [ Scope ] Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2025563/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
** Tags added: oem-priority -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] Low, upstream fix. [ Scope ] Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2025563/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
** Also affects: oem-priority Importance: Undecided Status: New ** Changed in: oem-priority Status: New => Confirmed ** Changed in: oem-priority Importance: Undecided => Critical ** Changed in: oem-priority Assignee: (unassigned) => Cyrus Lien (cyruslien) ** Tags added: originate-from-2025253 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] Low, upstream fix. [ Scope ] Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2025563/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2025563] [NEW] System can not shutdown if system has multiple VROC RAID arrays
Public bug reported: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] Low, upstream fix. [ Scope ] Jammy ** Affects: oem-priority Importance: Critical Assignee: Cyrus Lien (cyruslien) Status: Confirmed ** Affects: systemd (Ubuntu) Importance: Critical Status: Confirmed ** Tags: originate-from-2025253 ** Changed in: oem-priority Assignee: (unassigned) => Cyrus Lien (cyruslien) ** Changed in: oem-priority Importance: Undecided => Critical ** Changed in: oem-priority Status: New => Confirmed ** Changed in: systemd (Ubuntu) Assignee: Cyrus Lien (cyruslien) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] Low, upstream fix. [ Scope ] Jammy To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2025563/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
According to https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1993541/comments/9, apply the patch to mdadm instead initramfs-tools. ** Changed in: oem-priority Status: In Progress => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: Invalid Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: Fix Released Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
Due to lunar bumped shellcheck to version 0.9.0-1, a lot of shellcheck findings need to be fixed to prevent build failure. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: In Progress Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: Fix Released Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
** Patch added: "initramfs-tools_0.142ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1994936/+attachment/5657520/+files/initramfs-tools_0.142ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: In Progress Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: New Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
Lunar also doesn't fix it yet. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: In Progress Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: New Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
Lunar also doesn't fix it yet. Do we need to send the patch to mdadm instead? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: In Progress Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: New Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
Tried Debian mdadm (4.2+20230223-1) it doesn't fix the issue and the only script mounting efivarfs is mdadm hook scrips. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: In Progress Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: New Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
** Changed in: oem-priority Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: In Progress Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: New Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
** Patch added: "initramfs-tools_0.140ubuntu18.debdiff" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1994936/+attachment/5652807/+files/initramfs-tools_0.140ubuntu18.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: Confirmed Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: New Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
** Patch added: "initramfs-tools_0.140ubuntu13.2.debdiff" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1994936/+attachment/5652806/+files/initramfs-tools_0.140ubuntu13.2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: Confirmed Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: New Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Tags added: originate-from-2000298 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Fix Committed Status in grub2-unsigned package in Ubuntu: Fix Released Status in initramfs-tools package in Ubuntu: Won't Fix Status in linux package in Ubuntu: Confirmed Bug description: [Workaround] Some workarounds have been suggested in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/comments/125 [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory region starvation in <1G addresses: Type StartEnd # Pages Attributes Available -00086FFF 0087 000F BS_Data00087000-00087FFF 0001 000F Available 00088000-0009EFFF 0017 000F Reserved 0009F000-0009 0001 000F Available 0010-00FF 0F00 000F LoaderCode 0100-01021FFF 0022 000F Available 01022000-238A7FFF 00022886 000F BS_Data238A8000-23927FFF 0080 000F Available 23928000-28860FFF 4F39 000F BS_Data28861000-2AB09FFF 22A9 000F LoaderCode 2AB0A000-2ACF8FFF 01EF 000F BS_Data2ACF9000-2B2FAFFF 0602 000F Available 2B2FB000-2B611FFF 0317 000F BS_Data2B612000-2B630FFF 001F 000F Available 2B631000-2B632FFF 0002 000F BS_Data2B633000-2B63CFFF 000A 000F Available 2B63D000-2B649FFF 000D 000F BS_Data2B64A000-2B64EFFF 0005 000F Available 2B64F000-2B666FFF 0018 000F BS_Data2B667000-2D8D5FFF 226F 000F LoaderCode 2D8D6000-2D8E9FFF 0014 000F BS_Data2D8EA000-2D925FFF 003C 000F LoaderCode 2D926000-2D932FFF 000D 000F BS_Data2D933000-2D969FFF 0037 000F BS_Code2D96A000-2D973FFF 000A 000F BS_Data2D974000-2E377FFF 0A04 000F Available 2E378000-2E37AFFF 0003 000F ... Reserved 3C08B000-4192 58A5 000F ACPI_NVS 4193-41B2 0200 000F ACPI_Recl 41B3-41BFEFFF 00CF 000F BS_Data41BFF000-41BF 0001 000F Available 0001-0002AB7F 001AB800 000F Reserved 000A-000F 0060 Reserved 41C0-43FF 2400 Reserved 4400-47FF 4000 000F
[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
** Bug watch added: Debian Bug tracker #1003352 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003352 ** Also affects: initramfs-tools (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003352 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: Confirmed Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: Unknown Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994936] [NEW] initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface
Public bug reported: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 ** Affects: oem-priority Importance: Critical Assignee: Cyrus Lien (cyruslien) Status: Confirmed ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Affects: initramfs-tools (Debian) Importance: Unknown Status: Unknown ** Tags: oem-priority ** Also affects: oem-priority Importance: Undecided Status: New ** Changed in: oem-priority Status: New => Confirmed ** Changed in: oem-priority Importance: Undecided => Critical ** Changed in: oem-priority Assignee: (unassigned) => Cyrus Lien (cyruslien) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1994936 Title: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface Status in OEM Priority Project: Confirmed Status in initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Debian: Unknown Bug description: [ Impact ] kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID, mdadm needs initramfs to mount efivarfs instead. [1] The commit: commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741 Author: Ard Biesheuvel Date: Mon Jun 20 13:34:03 2022 +0200 efi: vars: Remove deprecated 'efivars' sysfs interface [ Test Plan ] 1. Install initramfs-tools 2. update-initramfs -u 3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs 4. Check if boot script 00_mount_efivarfs exists in directory /tmp/extract-initramfs/main/scripts/init-top/ 5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 00_mount_efivarfs will be execute before udev. [ Where problems could occur ] Not sure if there any other tools/utilities also need to mount efivarfs as early as mdadm but the probability of file conflict should be very low. Also, there are no impact mounting efivarfs multiple times. mount: /sys/firmware/efi/efivars: efivarfs already mounted on /sys/firmware/efi/efivars. [ Scope ] Jammy, Kinetic [ Other Info ] The private bug link https://bugs.launchpad.net/somerville/+bug/1990231 debian MR: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1994936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1933828] Re: NTP servers from DHCP are not propagated to timesyncd
** Changed in: oem-priority Assignee: (unassigned) => Cyrus Lien (cyruslien) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1933828 Title: NTP servers from DHCP are not propagated to timesyncd Status in OEM Priority Project: New Status in network-manager package in Ubuntu: New Status in network-manager source package in Focal: New Bug description: Network manager gets NTP servers from DHCP but do not update timesyncd to use it which keeps using ntp.ubuntu.com. This is a problem on private networks which do not have access to public internet. On this type of network the configuration of timesyncd must be updated manually instead of inheriting the conf from the dhcp servers. This can be integrated with a NM dispatcher script such as below: etc/NetworkManager/dispatcher.d/10-update-timesyncd for example: ==8<=8<=8<=8<=8<== #! /usr/bin/bash [ -n "$CONNECTION_UUID" ] || exit INTERFACE=$1 ACTION=$2 case $ACTION in up | dhcp4-change | dhcp6-change) [ -n "$DHCP4_NTP_SERVERS" ] || exit mkdir -p /etc/systemd/timesyncd.conf.d/ cat< /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf [Time] NTP=$DHCP4_NTP_SERVERS RootDistanceMaxSec=15 EOF systemctl restart systemd-timesyncd ;; down) rm -f /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf systemctl restart systemd-timesyncd ;; esac ==8<=8<=8<=8<=8<== ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: network-manager 1.30.0-1ubuntu3 ProcVersionSignature: Ubuntu 5.11.0-18.19+21.10.1-generic 5.11.17 Uname: Linux 5.11.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu67 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Jun 28 14:08:52 2021 InstallationDate: Installed on 2020-05-31 (393 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200527) RebootRequiredPkgs: linux-image-5.11.0-20-generic linux-base SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.30.0 connected started full enabled enabled disabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1933828/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1933828] Re: NTP servers from DHCP are not propagated to timesyncd
** Tags added: oem-priority originate-from-1933586 wenshan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1933828 Title: NTP servers from DHCP are not propagated to timesyncd Status in OEM Priority Project: New Status in network-manager package in Ubuntu: New Status in network-manager source package in Focal: New Bug description: Network manager gets NTP servers from DHCP but do not update timesyncd to use it which keeps using ntp.ubuntu.com. This is a problem on private networks which do not have access to public internet. On this type of network the configuration of timesyncd must be updated manually instead of inheriting the conf from the dhcp servers. This can be integrated with a NM dispatcher script such as below: etc/NetworkManager/dispatcher.d/10-update-timesyncd for example: ==8<=8<=8<=8<=8<== #! /usr/bin/bash [ -n "$CONNECTION_UUID" ] || exit INTERFACE=$1 ACTION=$2 case $ACTION in up | dhcp4-change | dhcp6-change) [ -n "$DHCP4_NTP_SERVERS" ] || exit mkdir -p /etc/systemd/timesyncd.conf.d/ cat< /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf [Time] NTP=$DHCP4_NTP_SERVERS RootDistanceMaxSec=15 EOF systemctl restart systemd-timesyncd ;; down) rm -f /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf systemctl restart systemd-timesyncd ;; esac ==8<=8<=8<=8<=8<== ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: network-manager 1.30.0-1ubuntu3 ProcVersionSignature: Ubuntu 5.11.0-18.19+21.10.1-generic 5.11.17 Uname: Linux 5.11.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu67 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Jun 28 14:08:52 2021 InstallationDate: Installed on 2020-05-31 (393 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200527) RebootRequiredPkgs: linux-image-5.11.0-20-generic linux-base SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.30.0 connected started full enabled enabled disabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1933828/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1918855] Re: Xorg crashed with SIGABRT when under memory pressure
@Daniel @Timo,
I fund the root cause of my X crash issue, which is not same as this bug.
Please ignore my comments and thanks for your response.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1918855
Title:
Xorg crashed with SIGABRT when under memory pressure
Status in OEM Priority Project:
Triaged
Status in mesa package in Ubuntu:
Fix Released
Status in mesa source package in Focal:
Fix Released
Status in mesa source package in Hirsute:
Fix Released
Bug description:
== SRU Justification ==
[Impact]
When the system is under memory pressure, the entire desktop session may
crash.
[Fix]
Commit f9d8d9acbb6a620684fb4dac4affe25816587d92 ("iris: Avoid abort() if
kernel can't allocate memory")
[Test]
Run memory stress and the session crashed in less than 5 minutes.
With the fix applied, run memory stress for 24 hours and the desktop session
is still alive.
[Where problems could occur]
Doing a reset might make the system even more sluggish when under memory
pressure.
== Original bug report ==
I run checkbox job com.canonical.certification::memory/memory_stress_ng on
focal, and the xserver stops unexpectedly with the following stacktrace:
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg
(OsLookupColor+0x13c) [0x5619f3a4d59c]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 1:
/lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6
(gsignal+0xcb) [0x7fae476a418b]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6
(abort+0x12b) [0x7fae47683859]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind
info found [-10]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 4:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 5:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec)
[0x7fae46529c9c]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 6:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
(__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 7:
/usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150)
[0x7fae47007480]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind
info found [-10]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 8:
/usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7fae47040a30]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 9: /usr/lib/xorg/Xorg
(BlockHandler+0xa5) [0x5619f38f0995]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 10: /usr/lib/xorg/Xorg
(WaitForSomething+0x122) [0x5619f3a46c12]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 11: /usr/lib/xorg/Xorg
(SendErrorToClient+0x117) [0x5619f38ebcf7]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 12: /usr/lib/xorg/Xorg
(InitFonts+0x3b4) [0x5619f38effc4]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 13: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xf3) [0x7fae476850b3]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 14: /usr/lib/xorg/Xorg (_start+0x2e)
[0x5619f38d9a2e]
More info:
I searched the Internet and got a bug with the same stacktrace:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3468
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2859
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1918855/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1918855] Re: Xorg crashed with SIGABRT when under memory pressure
I encountered exactly same issue as this bug on bionic so I would like to
leverage iris fix (iris-avoid-abort-if-enomem.diff) but bionic mesa prefer i965
by default over iris.
Do I need to file a new one on mesa/i965 driver?
Aug 3 03:12:39 u-Vostro /usr/lib/gdm3/gdm-x-session[1864]: (EE) glamor0: GL
error: GL_OUT_OF_MEMORY in glTexImage2D
Aug 3 03:12:50 u-Vostro /usr/lib/gdm3/gdm-x-session[1864]: (EE)
Aug 3 03:12:50 u-Vostro /usr/lib/gdm3/gdm-x-session[1864]: (EE) Backtrace:
Aug 3 03:12:54 u-Vostro /usr/lib/gdm3/gdm-x-session[1864]: (EE) 0:
/usr/lib/xorg/Xorg (?+0x0) [0x556430b27080]
Aug 3 03:12:54 u-Vostro /usr/lib/gdm3/gdm-x-session[1864]: (EE) 1:
/lib/x86_64-linux-gnu/libpthread.so.0 (?+0x0) [0x7f7778ae697f]
Aug 3 03:12:56 u-Vostro /usr/lib/gdm3/gdm-x-session[1864]: (EE) 2:
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so (?+0x0) [0x7f7773960a70]
Aug 3 03:12:56 u-Vostro /usr/lib/gdm3/gdm-x-session[1864]: (EE) 3:
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so (?+0x0) [0x7f7773960d10]
Aug 3 03:12:56 u-Vostro /usr/lib/gdm3/gdm-x-session[1864]: (EE) 4:
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so (?+0x0) [0x7f7773960de0]
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1918855
Title:
Xorg crashed with SIGABRT when under memory pressure
Status in OEM Priority Project:
Triaged
Status in mesa package in Ubuntu:
Fix Released
Status in mesa source package in Focal:
Fix Released
Status in mesa source package in Hirsute:
Fix Released
Bug description:
== SRU Justification ==
[Impact]
When the system is under memory pressure, the entire desktop session may
crash.
[Fix]
Commit f9d8d9acbb6a620684fb4dac4affe25816587d92 ("iris: Avoid abort() if
kernel can't allocate memory")
[Test]
Run memory stress and the session crashed in less than 5 minutes.
With the fix applied, run memory stress for 24 hours and the desktop session
is still alive.
[Where problems could occur]
Doing a reset might make the system even more sluggish when under memory
pressure.
== Original bug report ==
I run checkbox job com.canonical.certification::memory/memory_stress_ng on
focal, and the xserver stops unexpectedly with the following stacktrace:
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg
(OsLookupColor+0x13c) [0x5619f3a4d59c]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 1:
/lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6
(gsignal+0xcb) [0x7fae476a418b]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6
(abort+0x12b) [0x7fae47683859]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind
info found [-10]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 4:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 5:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec)
[0x7fae46529c9c]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 6:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
(__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 7:
/usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150)
[0x7fae47007480]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind
info found [-10]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 8:
/usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7fae47040a30]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 9: /usr/lib/xorg/Xorg
(BlockHandler+0xa5) [0x5619f38f0995]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 10: /usr/lib/xorg/Xorg
(WaitForSomething+0x122) [0x5619f3a46c12]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 11: /usr/lib/xorg/Xorg
(SendErrorToClient+0x117) [0x5619f38ebcf7]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 12: /usr/lib/xorg/Xorg
(InitFonts+0x3b4) [0x5619f38effc4]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 13: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xf3) [0x7fae476850b3]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 14: /usr/lib/xorg/Xorg (_start+0x2e)
[0x5619f38d9a2e]
More info:
I searched the Internet and got a bug with the same stacktrace:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3468
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2859
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1918855/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1918855] Re: Xorg crashed with SIGABRT when under memory pressure
@Timo,
In bionic mesa (20.0.8-0ubuntu1~18.04.1) it prefer i965 by default over iris.
rules: confflags_GALLIUM += -Dprefer-iris=false
Is it available to enable iris by default in bionic?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1918855
Title:
Xorg crashed with SIGABRT when under memory pressure
Status in OEM Priority Project:
Triaged
Status in mesa package in Ubuntu:
Fix Released
Status in mesa source package in Focal:
Fix Released
Status in mesa source package in Hirsute:
Fix Released
Bug description:
== SRU Justification ==
[Impact]
When the system is under memory pressure, the entire desktop session may
crash.
[Fix]
Commit f9d8d9acbb6a620684fb4dac4affe25816587d92 ("iris: Avoid abort() if
kernel can't allocate memory")
[Test]
Run memory stress and the session crashed in less than 5 minutes.
With the fix applied, run memory stress for 24 hours and the desktop session
is still alive.
[Where problems could occur]
Doing a reset might make the system even more sluggish when under memory
pressure.
== Original bug report ==
I run checkbox job com.canonical.certification::memory/memory_stress_ng on
focal, and the xserver stops unexpectedly with the following stacktrace:
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg
(OsLookupColor+0x13c) [0x5619f3a4d59c]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 1:
/lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6
(gsignal+0xcb) [0x7fae476a418b]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6
(abort+0x12b) [0x7fae47683859]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind
info found [-10]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 4:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 5:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec)
[0x7fae46529c9c]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 6:
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
(__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 7:
/usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150)
[0x7fae47007480]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind
info found [-10]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 8:
/usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7fae47040a30]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 9: /usr/lib/xorg/Xorg
(BlockHandler+0xa5) [0x5619f38f0995]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 10: /usr/lib/xorg/Xorg
(WaitForSomething+0x122) [0x5619f3a46c12]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 11: /usr/lib/xorg/Xorg
(SendErrorToClient+0x117) [0x5619f38ebcf7]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 12: /usr/lib/xorg/Xorg
(InitFonts+0x3b4) [0x5619f38effc4]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 13: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xf3) [0x7fae476850b3]
/usr/lib/gdm3/gdm-x-session[1425]: (EE) 14: /usr/lib/xorg/Xorg (_start+0x2e)
[0x5619f38d9a2e]
More info:
I searched the Internet and got a bug with the same stacktrace:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3468
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2859
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1918855/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1510570] Re: Bluetooth LE pairing fail
With bluez 5.37-0ubuntu5.2 Designer keyboard still can not connect on 4.13.0-32-generic. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1510570 Title: Bluetooth LE pairing fail Status in OEM Priority Project: Confirmed Status in bluez package in Ubuntu: Fix Released Status in bluez source package in Xenial: Fix Committed Bug description: [Impact] When the Bluetooth adapter is not powered on it is not possible to use it in normal way. We used to have a hack to force powering on by using an udev rule but this doe snot work anymore. Luckily the BlueZ has introduced "AutoEnable" option that makes the stack power on adapters by itself. Backporting this to xenial will improve life of the desktop users and will not require them to hack the solution on their own. The fix itself uses the well known solution to this problem that is floating around there for a while. The upload fixes the bug by enabling the 'AutoEnable' option in the bluetoothd config file. [Original Report] . 15.10 we now have bluez 5 so we can pair BLE devices like the Microsoft Arc Touch Bluetooth Mouse. But this pairing doesn't work very well. Mouse is seen but pairing fail. More information: https://bugzilla.kernel.org/show_bug.cgi?id=104011#c5 This is due to udev rule that use "hcitool" to power on device. Hopefully, bluez 5.35 has a new parameter "AutoEnable" who can be used instead of udev rules. here is a commit with this parameter: http://bazaar.launchpad.net/~guilhem-fr/bluez/autoenable/revision/138 [Test Case] On xenial install from ppa: https://launchpad.net/~bluetooth/+archive/ubuntu/bluez Now reboot the machine. The BT adapter shall be powered on. [Regression Potential] If things go wrong the adapter will not be powered on after the system boots up. Therefore while testing please focus on the adapter state, i.e. powered on or off. [Other Info] This fix is included in the development release, see: http://bazaar.launchpad.net/~bluetooth/bluez/ubuntu-zesty/revision/22 [What to upload] For xenial as in: ) https://launchpad.net/~bluetooth/+archive/ubuntu/bluez ) https://launchpadlibrarian.net/347480725/bluez_5.37-0ubuntu5_5.37-0ubuntu5.2~build1.diff.gz To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1510570/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1510570] Re: Bluetooth LE pairing fail
Designer keyboard still can not connect on 4.13.0-32-generic. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1510570 Title: Bluetooth LE pairing fail Status in OEM Priority Project: Confirmed Status in bluez package in Ubuntu: Fix Released Status in bluez source package in Xenial: Fix Committed Bug description: [Impact] When the Bluetooth adapter is not powered on it is not possible to use it in normal way. We used to have a hack to force powering on by using an udev rule but this doe snot work anymore. Luckily the BlueZ has introduced "AutoEnable" option that makes the stack power on adapters by itself. Backporting this to xenial will improve life of the desktop users and will not require them to hack the solution on their own. The fix itself uses the well known solution to this problem that is floating around there for a while. The upload fixes the bug by enabling the 'AutoEnable' option in the bluetoothd config file. [Original Report] . 15.10 we now have bluez 5 so we can pair BLE devices like the Microsoft Arc Touch Bluetooth Mouse. But this pairing doesn't work very well. Mouse is seen but pairing fail. More information: https://bugzilla.kernel.org/show_bug.cgi?id=104011#c5 This is due to udev rule that use "hcitool" to power on device. Hopefully, bluez 5.35 has a new parameter "AutoEnable" who can be used instead of udev rules. here is a commit with this parameter: http://bazaar.launchpad.net/~guilhem-fr/bluez/autoenable/revision/138 [Test Case] On xenial install from ppa: https://launchpad.net/~bluetooth/+archive/ubuntu/bluez Now reboot the machine. The BT adapter shall be powered on. [Regression Potential] If things go wrong the adapter will not be powered on after the system boots up. Therefore while testing please focus on the adapter state, i.e. powered on or off. [Other Info] This fix is included in the development release, see: http://bazaar.launchpad.net/~bluetooth/bluez/ubuntu-zesty/revision/22 [What to upload] For xenial as in: ) https://launchpad.net/~bluetooth/+archive/ubuntu/bluez ) https://launchpadlibrarian.net/347480725/bluez_5.37-0ubuntu5_5.37-0ubuntu5.2~build1.diff.gz To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1510570/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1510570] Re: Bluetooth LE pairing fail
Verified bluez 5.37-0ubuntu5.2 from -proposed, designer mouse works but designer keyboard failed. To fully support BT LE, looks like we need to upgrade bluez >5.44. (verified bluez 5.46-0ubuntu4~somerville1 which comes form artful can make designer keyboard works) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1510570 Title: Bluetooth LE pairing fail Status in OEM Priority Project: Confirmed Status in bluez package in Ubuntu: Fix Released Status in bluez source package in Xenial: Fix Committed Bug description: [Impact] When the Bluetooth adapter is not powered on it is not possible to use it in normal way. We used to have a hack to force powering on by using an udev rule but this doe snot work anymore. Luckily the BlueZ has introduced "AutoEnable" option that makes the stack power on adapters by itself. Backporting this to xenial will improve life of the desktop users and will not require them to hack the solution on their own. The fix itself uses the well known solution to this problem that is floating around there for a while. The upload fixes the bug by enabling the 'AutoEnable' option in the bluetoothd config file. [Original Report] . 15.10 we now have bluez 5 so we can pair BLE devices like the Microsoft Arc Touch Bluetooth Mouse. But this pairing doesn't work very well. Mouse is seen but pairing fail. More information: https://bugzilla.kernel.org/show_bug.cgi?id=104011#c5 This is due to udev rule that use "hcitool" to power on device. Hopefully, bluez 5.35 has a new parameter "AutoEnable" who can be used instead of udev rules. here is a commit with this parameter: http://bazaar.launchpad.net/~guilhem-fr/bluez/autoenable/revision/138 [Test Case] On xenial install from ppa: https://launchpad.net/~bluetooth/+archive/ubuntu/bluez Now reboot the machine. The BT adapter shall be powered on. [Regression Potential] If things go wrong the adapter will not be powered on after the system boots up. Therefore while testing please focus on the adapter state, i.e. powered on or off. [Other Info] This fix is included in the development release, see: http://bazaar.launchpad.net/~bluetooth/bluez/ubuntu-zesty/revision/22 [What to upload] For xenial as in: ) https://launchpad.net/~bluetooth/+archive/ubuntu/bluez ) https://launchpadlibrarian.net/347480725/bluez_5.37-0ubuntu5_5.37-0ubuntu5.2~build1.diff.gz To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1510570/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1647283] Re: WiFi being detected as ethernet when race condition on renaming for persistent name
** Changed in: oem-priority Status: New => Triaged ** Changed in: oem-priority Assignee: (unassigned) => Alex Tu (alextu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1647283 Title: WiFi being detected as ethernet when race condition on renaming for persistent name Status in HWE Next: New Status in NetworkManager: Fix Released Status in OEM Priority Project: Triaged Status in OEM Priority Project xenial series: New Status in network-manager package in Ubuntu: Triaged Bug description: Forwarded https://bugzilla.gnome.org/show_bug.cgi?id=775613 Version: NetworkManager 1.4.2 This bug happens after power-on with probability about 1/50. That means we need to reboot about 50 times to get into the buggy situation. "nmcli d" shows the device type is ethernet: DEVICE TYPE STATECONNECTION wlp1s0 ethernet unavailable -- lo loopback unmanaged-- The bug starts from a race condition. But it is not the root cause. I've also attach 2 logs. One is in good situation. Another is in bad situation. This log is generated by applying a "log patch" to network-manager 1.4.2 so we can see more stuff. In the bad situation. The bug starts with race condition. But the race condition is not the root cause. The race condition is: * During the renaming from "wlan0" to "wlp1s0". "wlan0" disappeared. * Inside the NM, it is still using "wlan0" in "_linktype_get_type()". * Since /sys/class/net/wlan0/uevent is disappeared. so the type matching failed in _linktype_get_type(). * Also wifi_utils_is_wifi() failed to because /sys/class/net/wlan0 disappeared. * And finally, devtype and kind are both NULL, so it returns NM_LINK_TYPE_ETHERNET for wlan0. Later, wlan0 is renamed to wlp1s0, and it seems to me that the Object inherit the type so it is still type ethernet. But from the log, I saw _linktype_get_type() is called several times later and return the correct type (wifi). But just, "nmcli d" still shows type ethernet. I'm wondering if we are missing to update the type in the Object created after renaming and re-detecting the type. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1647283/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1585863] Re: WiFi malfunction after suspend & resume stress - sudo wpa_cli scan required to fix it.
** Changed in: oem-priority Assignee: (unassigned) => Shih-Yuan Lee (fourdollars) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1585863 Title: WiFi malfunction after suspend & resume stress - sudo wpa_cli scan required to fix it. Status in OEM Priority Project: Confirmed Status in OEM Priority Project xenial series: Confirmed Status in network-manager package in Ubuntu: Confirmed Bug description: HOW TO REPRODUCE: 1. Install fwts by `sudo apt-get install fwts`. 2. Run the suspend & resume stress test. sudo fwts s3 --s3-multiple=30 --s3-min-delay=5 --s3-max-delay=5 --s3-delay-delta=5 RESULT: The WiFi can not connect to any access point and we have to execute `sudo wpa_cli scan` manually to make it work again. WORKAROUND: (http://askubuntu.com/questions/761180/wifi-doesnt-work-after-suspend-after-16-04-upgrade) SYSTEM INFO: Description:Ubuntu Yakkety Yak (development branch) Release:16.10 Packages: libnm-glib-vpn1:amd64 1.2.2-0ubuntu2 libnm-glib4:amd64 1.2.2-0ubuntu2 libnm-util2:amd64 1.2.2-0ubuntu2 libnm0:amd641.2.2-0ubuntu2 network-manager 1.2.2-0ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1585863/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
