[Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
I have completed most of my regression testing, and things are still looking good. The performance of the block discard is there, and I haven't seen any data corruption. In particular, I have been testing against the testcase for the regression that occurred with the previous revision of the patches, back in December. The testcase is covered in bug 1907262 [1]. [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262 For each of the 5.11, 5.8, 5.4 and 4.15 kernels, the problem does not reproduce, as the values of /sys/block/md0/md/mismatch_cnt are always 0, and mounting each disk in singular and performing a full deep fsck shows no data corruption. Test results for each kernel are below: 5.11.0-16-generic #17+TEST1896578v20210503b1-Ubuntu https://paste.ubuntu.com/p/Dp3sR9mNdY/ 5.8.0-50-generic #56+TEST1896578v20210504b1-Ubuntu https://paste.ubuntu.com/p/tXmtmd5Jys/ 5.4.0-72-generic #80+TEST1896578v20210504b1-Ubuntu https://paste.ubuntu.com/p/VzX2mXcKbF/ 4.15.0-142-generic #146+TEST1896578v20210504b1-Ubuntu https://paste.ubuntu.com/p/HpMcX3N9fD/ I think I will look into some longer running tests as well, more info on that later. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896578 Title: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
If anyone is interested in testing, there are new re-spins of the test kernels available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1896578-test The patches used are the ones I will be submitting for SRU, and are more or less identical to the patches in the previous test kernels I supplied in February. Please go ahead and do some testing, and let me know if you find any problems. Please note this package is NOT SUPPORTED by Canonical, and is for TESTING PURPOSES ONLY. ONLY Install in a dedicated test environment. Instructions to install: 1) sudo add-apt-repository ppa:mruffell/lp1896578-test 2) sudo apt update For 21.04 / Hirsute: 3) sudo apt install linux-image-unsigned-5.11.0-16-generic linux-modules-5.11.0-16-generic \ linux-modules-extra-5.11.0-16-generic linux-headers-5.11.0-16-generic For 20.10 / Groovy: 3) sudo apt install linux-image-unsigned-5.8.0-50-generic linux-modules-5.8.0-50-generic \ linux-modules-extra-5.8.0-50-generic linux-headers-5.8.0-50-generic For 20.04 / Focal: 3) sudo apt install linux-image-unsigned-5.4.0-72-generic linux-modules-5.4.0-72-generic \ linux-modules-extra-5.4.0-72-generic linux-headers-5.4.0-72-generic For 18.04 / Bionic: For the 5.4 Bionic HWE kernel: 3) sudo apt install linux-image-unsigned-5.4.0-72-generic linux-modules-5.4.0-72-generic \ linux-modules-extra-5.4.0-72-generic linux-headers-5.4.0-72-generic For the 4.15 Bionic GA kernel: 3) sudo apt install linux-image-unsigned-4.15.0-142-generic linux-modules-4.15.0-142-generic \ linux-modules-extra-4.15.0-142-generic linux-headers-4.15.0-142-generic 4) sudo reboot 5) uname -rv Make sure the string "+TEST1896578v20210504b1" is present in the uname -rv. You may need to modify your grub configuration to boot the correct kernel. If you need help, read these instructions: https://paste.ubuntu.com/p/XrTzWPPnWJ/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896578 Title: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Description changed: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on Raid 0, takes 4 seconds. The bigger the devices, the longer it takes. The cause is that Raid10 currently uses a 512k chunk size, and uses this for the discard_max_bytes value. If we need to discard 1.9TB, the kernel splits the request into millions of 512k bio requests, even if the underlying device supports larger requests. For example, the NVMe devices on i3.8xlarge support 2.2TB of discard at once: $ cat /sys/block/nvme0n1/queue/discard_max_bytes 2199023255040 $ cat /sys/block/nvme0n1/queue/discard_max_hw_bytes 2199023255040 Where the Raid10 md device only supports 512k: $ cat /sys/block/md0/queue/discard_max_bytes 524288 $ cat /sys/block/md0/queue/discard_max_hw_bytes 524288 If we perform a mkfs.xfs operation on the /dev/md array, it takes over 11 minutes and if we examine the stack, it is stuck in blkdev_issue_discard() $ sudo cat /proc/1626/stack [<0>] wait_barrier+0x14c/0x230 [raid10] [<0>] regular_request_wait+0x39/0x150 [raid10] [<0>] raid10_write_request+0x11e/0x850 [raid10] [<0>] raid10_make_request+0xd7/0x150 [raid10] [<0>] md_handle_request+0x123/0x1a0 [<0>] md_submit_bio+0xda/0x120 [<0>] __submit_bio_noacct+0xde/0x320 [<0>] submit_bio_noacct+0x4d/0x90 [<0>] submit_bio+0x4f/0x1b0 [<0>] __blkdev_issue_discard+0x154/0x290 [<0>] blkdev_issue_discard+0x5d/0xc0 [<0>] blk_ioctl_discard+0xc4/0x110 [<0>] blkdev_common_ioctl+0x56c/0x840 [<0>] blkdev_ioctl+0xeb/0x270 [<0>] block_ioctl+0x3d/0x50 [<0>] __x64_sys_ioctl+0x91/0xc0 [<0>] do_syscall_64+0x38/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Fix] Xiao Ni has developed a patchset which resolves the block discard - performance problems. These commits have now landed in 5.10-rc1. + performance problems. These commits have now landed in 5.13-rc1. commit cf78408f937a67f59f5e90ee8e6cadeed7c128a8 Author: Xiao Ni Date: Thu Feb 4 15:50:43 2021 +0800 Subject: md: add md_submit_discard_bio() for submitting discard bio Link: https://github.com/torvalds/linux/commit/cf78408f937a67f59f5e90ee8e6cadeed7c128a8 commit c2968285925adb97b9aa4ede94c1f1ab61ce0925 Author: Xiao Ni Date: Thu Feb 4 15:50:44 2021 +0800 Subject: md/raid10: extend r10bio devs to raid disks Link: https://github.com/torvalds/linux/commit/c2968285925adb97b9aa4ede94c1f1ab61ce0925 commit f2e7e269a7525317752d472bb48a549780e87d22 Author: Xiao Ni Date: Thu Feb 4 15:50:45 2021 +0800 Subject: md/raid10: pull the code that wait for blocked dev into one function Link: https://github.com/torvalds/linux/commit/f2e7e269a7525317752d472bb48a549780e87d22 commit d30588b2731fb01e1616cf16c3fe79a1443e29aa Author: Xiao Ni Date: Thu Feb 4 15:50:46 2021 +0800 Subject: md/raid10: improve raid10 discard request Link: https://github.com/torvalds/linux/commit/d30588b2731fb01e1616cf16c3fe79a1443e29aa commit 254c271da0712ea8914f187588e0f81f7678ee2f Author: Xiao Ni Date: Thu Feb 4 15:50:47 2021 +0800 Subject: md/raid10: improve discard request for far layout Link: https://github.com/torvalds/linux/commit/254c271da0712ea8914f187588e0f81f7678ee2f There is also an additional commit which is required, and was merged after "md/raid10: improve raid10 discard request" was merged. The - following commits enable Radid10 to use large discards, instead of + following commit enables Radid10 to use large discards, instead of splitting into many bios, since the technical hurdles have now been removed. commit ca4a4e9a55beeb138bb06e3867f5e486da896d44 Author: Mike Snitzer Date: Fri Apr 30 14:38:37 2021 -0400 Subject: dm raid: remove unnecessary discard limits for raid0 and raid10 Link: https://github.com/torvalds/linux/commit/ca4a4e9a55beeb138bb06e3867f5e486da896d44 The commits more or less cherry pick to the 5.11, 5.8, 5.4 and 4.15 kernels, with the following minor backports: 1) submit_bio_noacct() needed to be renamed to generic_make_request() since it was recently changed in: commit ed00aabd5eb9fb44d6aff1173234a2e911b9fead Author: Christoph Hellwig Date: Wed Jul 1 10:59:44 2020 +0200 Subject: block: rename generic_make_request to submit_bio_noacct Link: https://github.com/torvalds/linux/commit/ed00aabd5eb9fb44d6aff1173234a2e911b9fead 2) In the 4.15, 5.4 and 5.8 kernels, trace_block_bio_remap() needs to have its request_queue argument put back in place. It was recently removed in: commit
[Kernel-packages] [Bug 1907262] Re: raid10: discard leads to corrupted file system
Hi Thimo, As promised yesterday, the new re-spins of the test kernels have finished building and are now available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1896578-test The patches used are the ones I will be submitting for SRU, and are more or less identical to the patches in the previous test kernels I supplied in February. Please go ahead and do some testing, and let me know if you find any problems. Please note this package is NOT SUPPORTED by Canonical, and is for TESTING PURPOSES ONLY. ONLY Install in a dedicated test environment. Instructions to install: 1) sudo add-apt-repository ppa:mruffell/lp1896578-test 2) sudo apt update For 21.04 / Hirsute: 3) sudo apt install linux-image-unsigned-5.11.0-16-generic linux-modules-5.11.0-16-generic \ linux-modules-extra-5.11.0-16-generic linux-headers-5.11.0-16-generic For 20.10 / Groovy: 3) sudo apt install linux-image-unsigned-5.8.0-50-generic linux-modules-5.8.0-50-generic \ linux-modules-extra-5.8.0-50-generic linux-headers-5.8.0-50-generic For 20.04 / Focal: 3) sudo apt install linux-image-unsigned-5.4.0-72-generic linux-modules-5.4.0-72-generic \ linux-modules-extra-5.4.0-72-generic linux-headers-5.4.0-72-generic For 18.04 / Bionic: For the 5.4 Bionic HWE kernel: 3) sudo apt install linux-image-unsigned-5.4.0-72-generic linux-modules-5.4.0-72-generic \ linux-modules-extra-5.4.0-72-generic linux-headers-5.4.0-72-generic For the 4.15 Bionic GA kernel: 3) sudo apt install linux-image-unsigned-4.15.0-142-generic linux-modules-4.15.0-142-generic \ linux-modules-extra-4.15.0-142-generic linux-headers-4.15.0-142-generic 4) sudo reboot 5) uname -rv Make sure the string "+TEST1896578v20210504b1" is present in the uname -rv. You may need to modify your grub configuration to boot the correct kernel. If you need help, read these instructions: https://paste.ubuntu.com/p/XrTzWPPnWJ/ I'm still doing final regression testing, but things are looking okay so far. The deadline for patch submission to the next SRU cycle is tomorrow. I'm still planning on submitting the patches for tomorrow, but if I think we need more time for testing, worst case it will slip to the SRU cycle after, which is 3 weeks away. I will write back tomorrow with the results of my regression testing and if I have submitted the patches for SRU. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Invalid Status in linux source package in Xenial: Invalid Status in linux source package in Bionic: Fix Released Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: Fix Released Bug description: Seems to be closely related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578 After updating the Ubuntu 18.04 kernel from 4.15.0-124 to 4.15.0-126 the fstrim command triggered by fstrim.timer causes a severe number of mismatches between two RAID10 component devices. This bug affects several machines in our company with different HW configurations (All using ECC RAM). Both, NVMe and SATA SSDs are affected. How to reproduce: - Create a RAID10 LVM and filesystem on two SSDs mdadm -C -v -l10 -n2 -N "lv-raid" -R /dev/md0 /dev/nvme0n1p2 /dev/nvme1n1p2 pvcreate -ff -y /dev/md0 vgcreate -f -y VolGroup /dev/md0 lvcreate -n root-L 100G -ay -y VolGroup mkfs.ext4 /dev/VolGroup/root mount /dev/VolGroup/root /mnt - Write some data, sync and delete it dd if=/dev/zero of=/mnt/data.raw bs=4K count=1M sync rm /mnt/data.raw - Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (should be 0): cat /sys/block/md0/md/mismatch_cnt - Trigger the bug fstrim /mnt - Re-Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (probably in the range of N*1): cat /sys/block/md0/md/mismatch_cnt After investigating this issue on several machines it *seems* that the first drive does the trim correctly while the second one goes wild. At least the number and severity of errors found by a USB stick live session fsck.ext4 suggests this. To perform the single drive evaluation the RAID10 was started using a single drive at once: mdadm --assemble /dev/md127 /dev/nvme0n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root vgchange -a n /dev/VolGroup mdadm --stop /dev/md127 mdadm --assemble /dev/md127 /dev/nvme1n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root When starting these fscks without -n, on the first device it
[Bug 1907262] Re: raid10: discard leads to corrupted file system
Hi Thimo, As promised yesterday, the new re-spins of the test kernels have finished building and are now available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1896578-test The patches used are the ones I will be submitting for SRU, and are more or less identical to the patches in the previous test kernels I supplied in February. Please go ahead and do some testing, and let me know if you find any problems. Please note this package is NOT SUPPORTED by Canonical, and is for TESTING PURPOSES ONLY. ONLY Install in a dedicated test environment. Instructions to install: 1) sudo add-apt-repository ppa:mruffell/lp1896578-test 2) sudo apt update For 21.04 / Hirsute: 3) sudo apt install linux-image-unsigned-5.11.0-16-generic linux-modules-5.11.0-16-generic \ linux-modules-extra-5.11.0-16-generic linux-headers-5.11.0-16-generic For 20.10 / Groovy: 3) sudo apt install linux-image-unsigned-5.8.0-50-generic linux-modules-5.8.0-50-generic \ linux-modules-extra-5.8.0-50-generic linux-headers-5.8.0-50-generic For 20.04 / Focal: 3) sudo apt install linux-image-unsigned-5.4.0-72-generic linux-modules-5.4.0-72-generic \ linux-modules-extra-5.4.0-72-generic linux-headers-5.4.0-72-generic For 18.04 / Bionic: For the 5.4 Bionic HWE kernel: 3) sudo apt install linux-image-unsigned-5.4.0-72-generic linux-modules-5.4.0-72-generic \ linux-modules-extra-5.4.0-72-generic linux-headers-5.4.0-72-generic For the 4.15 Bionic GA kernel: 3) sudo apt install linux-image-unsigned-4.15.0-142-generic linux-modules-4.15.0-142-generic \ linux-modules-extra-4.15.0-142-generic linux-headers-4.15.0-142-generic 4) sudo reboot 5) uname -rv Make sure the string "+TEST1896578v20210504b1" is present in the uname -rv. You may need to modify your grub configuration to boot the correct kernel. If you need help, read these instructions: https://paste.ubuntu.com/p/XrTzWPPnWJ/ I'm still doing final regression testing, but things are looking okay so far. The deadline for patch submission to the next SRU cycle is tomorrow. I'm still planning on submitting the patches for tomorrow, but if I think we need more time for testing, worst case it will slip to the SRU cycle after, which is 3 weeks away. I will write back tomorrow with the results of my regression testing and if I have submitted the patches for SRU. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
** Description changed: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 + Test builds are available in the following ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/lp1927161-test + [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
** Description changed: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 + Test builds are available in the following ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/lp1927161-test + [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: In Progress Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 Test builds are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1927161-test [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a V2 for hirsute which correctly has d/p/ in the debian/changelog. ** Patch added: "debdiff for openssl on hirsute" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494814/+files/lp1927161_hirsute_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: In Progress Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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
[Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a V2 for hirsute which correctly has d/p/ in the debian/changelog. ** Patch added: "debdiff for openssl on hirsute" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494814/+files/lp1927161_hirsute_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a V2 for impish which correctly has d/p/ in the debian/changelog. ** Patch added: "debdiff for openssl on impish" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494813/+files/lp1927161_impish_v2.debdiff ** Patch removed: "debdiff for openssl on hirsute" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494811/+files/lp1927161_hirsute.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: In Progress Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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
[Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a V2 for impish which correctly has d/p/ in the debian/changelog. ** Patch added: "debdiff for openssl on impish" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494813/+files/lp1927161_impish_v2.debdiff ** Patch removed: "debdiff for openssl on hirsute" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494811/+files/lp1927161_hirsute.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a debdiff for openssl on groovy, which fixes this issue, and also bug 1926254 ** Patch added: "debdiff for openssl on groovy" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494812/+files/lp1926254_lp1927161_groovy.debdiff ** Patch removed: "debdiff for openssl on impish" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494810/+files/lp1927161_impish.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: In Progress Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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
[Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a debdiff for openssl on hirsute which fixes this problem. ** Patch added: "debdiff for openssl on hirsute" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494811/+files/lp1927161_hirsute.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a debdiff for openssl on groovy, which fixes this issue, and also bug 1926254 ** Patch added: "debdiff for openssl on groovy" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494812/+files/lp1926254_lp1927161_groovy.debdiff ** Patch removed: "debdiff for openssl on impish" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494810/+files/lp1927161_impish.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a debdiff for openssl on hirsute which fixes this problem. ** Patch added: "debdiff for openssl on hirsute" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494811/+files/lp1927161_hirsute.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: In Progress Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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
[Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a debdiff for impish which fixes this problem. ** Patch added: "debdiff for openssl on impish" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494810/+files/lp1927161_impish.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
Attached is a debdiff for impish which fixes this problem. ** Patch added: "debdiff for openssl on impish" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+attachment/5494810/+files/lp1927161_impish.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: In Progress Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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
[Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
I split 'pr12272.patch' into one file per commit, and I did a diff to ensure that there is no changes to the code: https://paste.ubuntu.com/p/zDqqXmsM8c/ When using these split up patches "dpkg-buildpackage -d -S" completes successfully. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
I split 'pr12272.patch' into one file per commit, and I did a diff to ensure that there is no changes to the code: https://paste.ubuntu.com/p/zDqqXmsM8c/ When using these split up patches "dpkg-buildpackage -d -S" completes successfully. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: In Progress Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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
[Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
** Changed in: openssl (Ubuntu Groovy) Status: New => In Progress ** Changed in: openssl (Ubuntu Hirsute) Status: New => In Progress ** Changed in: openssl (Ubuntu Impish) Status: New => In Progress ** Changed in: openssl (Ubuntu Groovy) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Changed in: openssl (Ubuntu Hirsute) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Changed in: openssl (Ubuntu Impish) Assignee: (unassigned) => Matthew Ruffell (mruffell) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
** Changed in: openssl (Ubuntu Groovy) Status: New => In Progress ** Changed in: openssl (Ubuntu Hirsute) Status: New => In Progress ** Changed in: openssl (Ubuntu Impish) Status: New => In Progress ** Changed in: openssl (Ubuntu Groovy) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Changed in: openssl (Ubuntu Hirsute) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Changed in: openssl (Ubuntu Impish) Assignee: (unassigned) => Matthew Ruffell (mruffell) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: In Progress Status in openssl source package in Impish: In Progress Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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
[Kernel-packages] [Bug 1907262] Re: raid10: discard leads to corrupted file system
Hi Thimo, Thanks for writing back, great timing! So, the new revision of the patches that we have been testing since February have just been merged into mainline. The md/raid10 patches got merged on Friday, and the dm/raid patches got merged on Saturday, and will be tagged into 5.13-rc1. There's been a few of us testing them, and we haven't seen any regressions that cause data loss or disk corruption. Things are looking okay. If you are interested, you can see a list of the new commits on bug 1896578. We are still planning to SRU the new revision into the Ubuntu kernels, and I have spent the day backporting the official mainline commits to the Ubuntu 5.11, 5.8, 5.4 and 4.15 kernels. I'm currently building re-spins of the test kernels, based on more recently released Ubuntu kernels, with these official mainline patches, instead of the patches I got from the development mailing list I used in my previous set of test kernels. I'm expecting these kernels to finish building overnight, and I will make sure to write back tomorrow morning with instructions on how to install these test kernels. It would be great if you could give them a test before they get built into the next Ubuntu kernel update. Even when they are built into the next kernel update, I'll let you know how you can test them when they are in -proposed, before they are officially released to -updates. I'll write back tomorrow morning with instructions on how to install the fresh test kernels. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Invalid Status in linux source package in Xenial: Invalid Status in linux source package in Bionic: Fix Released Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: Fix Released Bug description: Seems to be closely related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578 After updating the Ubuntu 18.04 kernel from 4.15.0-124 to 4.15.0-126 the fstrim command triggered by fstrim.timer causes a severe number of mismatches between two RAID10 component devices. This bug affects several machines in our company with different HW configurations (All using ECC RAM). Both, NVMe and SATA SSDs are affected. How to reproduce: - Create a RAID10 LVM and filesystem on two SSDs mdadm -C -v -l10 -n2 -N "lv-raid" -R /dev/md0 /dev/nvme0n1p2 /dev/nvme1n1p2 pvcreate -ff -y /dev/md0 vgcreate -f -y VolGroup /dev/md0 lvcreate -n root-L 100G -ay -y VolGroup mkfs.ext4 /dev/VolGroup/root mount /dev/VolGroup/root /mnt - Write some data, sync and delete it dd if=/dev/zero of=/mnt/data.raw bs=4K count=1M sync rm /mnt/data.raw - Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (should be 0): cat /sys/block/md0/md/mismatch_cnt - Trigger the bug fstrim /mnt - Re-Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (probably in the range of N*1): cat /sys/block/md0/md/mismatch_cnt After investigating this issue on several machines it *seems* that the first drive does the trim correctly while the second one goes wild. At least the number and severity of errors found by a USB stick live session fsck.ext4 suggests this. To perform the single drive evaluation the RAID10 was started using a single drive at once: mdadm --assemble /dev/md127 /dev/nvme0n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root vgchange -a n /dev/VolGroup mdadm --stop /dev/md127 mdadm --assemble /dev/md127 /dev/nvme1n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root When starting these fscks without -n, on the first device it seems the directory structure is OK while on the second device there is only the lost+found folder left. Side-note: Another machine using HWE kernel 5.4.0-56 (after using -53 before) seems to have a quite similar issue. Unfortunately the risk/regression assessment in the aforementioned bug is not complete: the workaround only mitigates the issues during FS creation. This bug on the other hand is triggered by a weekly service (fstrim) causing severe file system corruption. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 1907262] Re: raid10: discard leads to corrupted file system
Hi Thimo, Thanks for writing back, great timing! So, the new revision of the patches that we have been testing since February have just been merged into mainline. The md/raid10 patches got merged on Friday, and the dm/raid patches got merged on Saturday, and will be tagged into 5.13-rc1. There's been a few of us testing them, and we haven't seen any regressions that cause data loss or disk corruption. Things are looking okay. If you are interested, you can see a list of the new commits on bug 1896578. We are still planning to SRU the new revision into the Ubuntu kernels, and I have spent the day backporting the official mainline commits to the Ubuntu 5.11, 5.8, 5.4 and 4.15 kernels. I'm currently building re-spins of the test kernels, based on more recently released Ubuntu kernels, with these official mainline patches, instead of the patches I got from the development mailing list I used in my previous set of test kernels. I'm expecting these kernels to finish building overnight, and I will make sure to write back tomorrow morning with instructions on how to install these test kernels. It would be great if you could give them a test before they get built into the next Ubuntu kernel update. Even when they are built into the next kernel update, I'll let you know how you can test them when they are in -proposed, before they are officially released to -updates. I'll write back tomorrow morning with instructions on how to install the fresh test kernels. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Description changed: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on Raid 0, takes 4 seconds. The bigger the devices, the longer it takes. The cause is that Raid10 currently uses a 512k chunk size, and uses this for the discard_max_bytes value. If we need to discard 1.9TB, the kernel splits the request into millions of 512k bio requests, even if the underlying device supports larger requests. For example, the NVMe devices on i3.8xlarge support 2.2TB of discard at once: $ cat /sys/block/nvme0n1/queue/discard_max_bytes 2199023255040 $ cat /sys/block/nvme0n1/queue/discard_max_hw_bytes 2199023255040 Where the Raid10 md device only supports 512k: $ cat /sys/block/md0/queue/discard_max_bytes 524288 $ cat /sys/block/md0/queue/discard_max_hw_bytes 524288 If we perform a mkfs.xfs operation on the /dev/md array, it takes over 11 minutes and if we examine the stack, it is stuck in blkdev_issue_discard() $ sudo cat /proc/1626/stack [<0>] wait_barrier+0x14c/0x230 [raid10] [<0>] regular_request_wait+0x39/0x150 [raid10] [<0>] raid10_write_request+0x11e/0x850 [raid10] [<0>] raid10_make_request+0xd7/0x150 [raid10] [<0>] md_handle_request+0x123/0x1a0 [<0>] md_submit_bio+0xda/0x120 [<0>] __submit_bio_noacct+0xde/0x320 [<0>] submit_bio_noacct+0x4d/0x90 [<0>] submit_bio+0x4f/0x1b0 [<0>] __blkdev_issue_discard+0x154/0x290 [<0>] blkdev_issue_discard+0x5d/0xc0 [<0>] blk_ioctl_discard+0xc4/0x110 [<0>] blkdev_common_ioctl+0x56c/0x840 [<0>] blkdev_ioctl+0xeb/0x270 [<0>] block_ioctl+0x3d/0x50 [<0>] __x64_sys_ioctl+0x91/0xc0 [<0>] do_syscall_64+0x38/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Fix] Xiao Ni has developed a patchset which resolves the block discard performance problems. These commits have now landed in 5.10-rc1. commit cf78408f937a67f59f5e90ee8e6cadeed7c128a8 Author: Xiao Ni Date: Thu Feb 4 15:50:43 2021 +0800 Subject: md: add md_submit_discard_bio() for submitting discard bio Link: https://github.com/torvalds/linux/commit/cf78408f937a67f59f5e90ee8e6cadeed7c128a8 commit c2968285925adb97b9aa4ede94c1f1ab61ce0925 Author: Xiao Ni Date: Thu Feb 4 15:50:44 2021 +0800 Subject: md/raid10: extend r10bio devs to raid disks Link: https://github.com/torvalds/linux/commit/c2968285925adb97b9aa4ede94c1f1ab61ce0925 commit f2e7e269a7525317752d472bb48a549780e87d22 Author: Xiao Ni Date: Thu Feb 4 15:50:45 2021 +0800 Subject: md/raid10: pull the code that wait for blocked dev into one function Link: https://github.com/torvalds/linux/commit/f2e7e269a7525317752d472bb48a549780e87d22 commit d30588b2731fb01e1616cf16c3fe79a1443e29aa Author: Xiao Ni Date: Thu Feb 4 15:50:46 2021 +0800 Subject: md/raid10: improve raid10 discard request Link: https://github.com/torvalds/linux/commit/d30588b2731fb01e1616cf16c3fe79a1443e29aa commit 254c271da0712ea8914f187588e0f81f7678ee2f Author: Xiao Ni Date: Thu Feb 4 15:50:47 2021 +0800 Subject: md/raid10: improve discard request for far layout Link: https://github.com/torvalds/linux/commit/254c271da0712ea8914f187588e0f81f7678ee2f There is also an additional commit which is required, and was merged after "md/raid10: improve raid10 discard request" was merged. The following commits enable Radid10 to use large discards, instead of splitting into many bios, since the technical hurdles have now been removed. commit ca4a4e9a55beeb138bb06e3867f5e486da896d44 Author: Mike Snitzer Date: Fri Apr 30 14:38:37 2021 -0400 Subject: dm raid: remove unnecessary discard limits for raid0 and raid10 Link: https://github.com/torvalds/linux/commit/ca4a4e9a55beeb138bb06e3867f5e486da896d44 The commits more or less cherry pick to the 5.11, 5.8, 5.4 and 4.15 kernels, with the following minor backports: 1) submit_bio_noacct() needed to be renamed to generic_make_request() since it was recently changed in: commit ed00aabd5eb9fb44d6aff1173234a2e911b9fead Author: Christoph Hellwig Date: Wed Jul 1 10:59:44 2020 +0200 Subject: block: rename generic_make_request to submit_bio_noacct Link: https://github.com/torvalds/linux/commit/ed00aabd5eb9fb44d6aff1173234a2e911b9fead - 2) bio_split(), mempool_alloc(), bio_clone_fast() all needed their + 2) In the 4.15, 5.4 and 5.8 kernels, trace_block_bio_remap() needs to + have its request_queue argument put back in place. It was recently + removed in: + + commit 1c02fca620f7273b597591065d366e2cca948d8f + Author: Christoph Hellwig + Date: Thu
[Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Description changed: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on Raid 0, takes 4 seconds. The bigger the devices, the longer it takes. The cause is that Raid10 currently uses a 512k chunk size, and uses this for the discard_max_bytes value. If we need to discard 1.9TB, the kernel splits the request into millions of 512k bio requests, even if the underlying device supports larger requests. For example, the NVMe devices on i3.8xlarge support 2.2TB of discard at once: $ cat /sys/block/nvme0n1/queue/discard_max_bytes 2199023255040 $ cat /sys/block/nvme0n1/queue/discard_max_hw_bytes 2199023255040 Where the Raid10 md device only supports 512k: $ cat /sys/block/md0/queue/discard_max_bytes 524288 $ cat /sys/block/md0/queue/discard_max_hw_bytes 524288 If we perform a mkfs.xfs operation on the /dev/md array, it takes over 11 minutes and if we examine the stack, it is stuck in blkdev_issue_discard() $ sudo cat /proc/1626/stack [<0>] wait_barrier+0x14c/0x230 [raid10] [<0>] regular_request_wait+0x39/0x150 [raid10] [<0>] raid10_write_request+0x11e/0x850 [raid10] [<0>] raid10_make_request+0xd7/0x150 [raid10] [<0>] md_handle_request+0x123/0x1a0 [<0>] md_submit_bio+0xda/0x120 [<0>] __submit_bio_noacct+0xde/0x320 [<0>] submit_bio_noacct+0x4d/0x90 [<0>] submit_bio+0x4f/0x1b0 [<0>] __blkdev_issue_discard+0x154/0x290 [<0>] blkdev_issue_discard+0x5d/0xc0 [<0>] blk_ioctl_discard+0xc4/0x110 [<0>] blkdev_common_ioctl+0x56c/0x840 [<0>] blkdev_ioctl+0xeb/0x270 [<0>] block_ioctl+0x3d/0x50 [<0>] __x64_sys_ioctl+0x91/0xc0 [<0>] do_syscall_64+0x38/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Fix] Xiao Ni has developed a patchset which resolves the block discard performance problems. These commits have now landed in 5.10-rc1. commit cf78408f937a67f59f5e90ee8e6cadeed7c128a8 Author: Xiao Ni Date: Thu Feb 4 15:50:43 2021 +0800 Subject: md: add md_submit_discard_bio() for submitting discard bio Link: https://github.com/torvalds/linux/commit/cf78408f937a67f59f5e90ee8e6cadeed7c128a8 commit c2968285925adb97b9aa4ede94c1f1ab61ce0925 Author: Xiao Ni Date: Thu Feb 4 15:50:44 2021 +0800 Subject: md/raid10: extend r10bio devs to raid disks Link: https://github.com/torvalds/linux/commit/c2968285925adb97b9aa4ede94c1f1ab61ce0925 commit f2e7e269a7525317752d472bb48a549780e87d22 Author: Xiao Ni Date: Thu Feb 4 15:50:45 2021 +0800 Subject: md/raid10: pull the code that wait for blocked dev into one function Link: https://github.com/torvalds/linux/commit/f2e7e269a7525317752d472bb48a549780e87d22 commit d30588b2731fb01e1616cf16c3fe79a1443e29aa Author: Xiao Ni Date: Thu Feb 4 15:50:46 2021 +0800 Subject: md/raid10: improve raid10 discard request Link: https://github.com/torvalds/linux/commit/d30588b2731fb01e1616cf16c3fe79a1443e29aa commit 254c271da0712ea8914f187588e0f81f7678ee2f Author: Xiao Ni Date: Thu Feb 4 15:50:47 2021 +0800 Subject: md/raid10: improve discard request for far layout Link: https://github.com/torvalds/linux/commit/254c271da0712ea8914f187588e0f81f7678ee2f There is also an additional commit which is required, and was merged after "md/raid10: improve raid10 discard request" was merged. The following commits enable Radid10 to use large discards, instead of splitting into many bios, since the technical hurdles have now been removed. commit ca4a4e9a55beeb138bb06e3867f5e486da896d44 Author: Mike Snitzer Date: Fri Apr 30 14:38:37 2021 -0400 Subject: dm raid: remove unnecessary discard limits for raid0 and raid10 Link: https://github.com/torvalds/linux/commit/ca4a4e9a55beeb138bb06e3867f5e486da896d44 The commits more or less cherry pick to the 5.11, 5.8, 5.4 and 4.15 kernels, with the following minor backports: 1) submit_bio_noacct() needed to be renamed to generic_make_request() since it was recently changed in: commit ed00aabd5eb9fb44d6aff1173234a2e911b9fead Author: Christoph Hellwig Date: Wed Jul 1 10:59:44 2020 +0200 Subject: block: rename generic_make_request to submit_bio_noacct Link: https://github.com/torvalds/linux/commit/ed00aabd5eb9fb44d6aff1173234a2e911b9fead - 2) bio_split(), mempool_alloc(), bio_clone_fast() all needed their + 2) In the 4.15, 5.4 and 5.8 kernels, trace_block_bio_remap() needs to + have its request_queue argument put back in place. It was recently + removed in: + + commit 1c02fca620f7273b597591065d366e2cca948d8f + Author: Christoph Hellwig + Date: Thu
[Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Also affects: linux (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Hirsute) Status: New => In Progress ** Changed in: linux (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Hirsute) Assignee: (unassigned) => Matthew Ruffell (mruffell) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896578 Title: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Also affects: linux (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Hirsute) Status: New => In Progress ** Changed in: linux (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Hirsute) Assignee: (unassigned) => Matthew Ruffell (mruffell) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1896578 Title: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux source package in Hirsute: In Progress Bug description: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on Raid 0, takes 4 seconds. The bigger the devices, the longer it takes. The cause is that Raid10 currently uses a 512k chunk size, and uses this for the discard_max_bytes value. If we need to discard 1.9TB, the kernel splits the request into millions of 512k bio requests, even if the underlying device supports larger requests. For example, the NVMe devices on i3.8xlarge support 2.2TB of discard at once: $ cat /sys/block/nvme0n1/queue/discard_max_bytes 2199023255040 $ cat /sys/block/nvme0n1/queue/discard_max_hw_bytes 2199023255040 Where the Raid10 md device only supports 512k: $ cat /sys/block/md0/queue/discard_max_bytes 524288 $ cat /sys/block/md0/queue/discard_max_hw_bytes 524288 If we perform a mkfs.xfs operation on the /dev/md array, it takes over 11 minutes and if we examine the stack, it is stuck in blkdev_issue_discard() $ sudo cat /proc/1626/stack [<0>] wait_barrier+0x14c/0x230 [raid10] [<0>] regular_request_wait+0x39/0x150 [raid10] [<0>] raid10_write_request+0x11e/0x850 [raid10] [<0>] raid10_make_request+0xd7/0x150 [raid10] [<0>] md_handle_request+0x123/0x1a0 [<0>] md_submit_bio+0xda/0x120 [<0>] __submit_bio_noacct+0xde/0x320 [<0>] submit_bio_noacct+0x4d/0x90 [<0>] submit_bio+0x4f/0x1b0 [<0>] __blkdev_issue_discard+0x154/0x290 [<0>] blkdev_issue_discard+0x5d/0xc0 [<0>] blk_ioctl_discard+0xc4/0x110 [<0>] blkdev_common_ioctl+0x56c/0x840 [<0>] blkdev_ioctl+0xeb/0x270 [<0>] block_ioctl+0x3d/0x50 [<0>] __x64_sys_ioctl+0x91/0xc0 [<0>] do_syscall_64+0x38/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Fix] Xiao Ni has developed a patchset which resolves the block discard performance problems. These commits have now landed in 5.10-rc1. commit cf78408f937a67f59f5e90ee8e6cadeed7c128a8 Author: Xiao Ni Date: Thu Feb 4 15:50:43 2021 +0800 Subject: md: add md_submit_discard_bio() for submitting discard bio Link: https://github.com/torvalds/linux/commit/cf78408f937a67f59f5e90ee8e6cadeed7c128a8 commit c2968285925adb97b9aa4ede94c1f1ab61ce0925 Author: Xiao Ni Date: Thu Feb 4 15:50:44 2021 +0800 Subject: md/raid10: extend r10bio devs to raid disks Link: https://github.com/torvalds/linux/commit/c2968285925adb97b9aa4ede94c1f1ab61ce0925 commit f2e7e269a7525317752d472bb48a549780e87d22 Author: Xiao Ni Date: Thu Feb 4 15:50:45 2021 +0800 Subject: md/raid10: pull the code that wait for blocked dev into one function Link: https://github.com/torvalds/linux/commit/f2e7e269a7525317752d472bb48a549780e87d22 commit d30588b2731fb01e1616cf16c3fe79a1443e29aa Author: Xiao Ni Date: Thu Feb 4 15:50:46 2021 +0800 Subject: md/raid10: improve raid10 discard request Link: https://github.com/torvalds/linux/commit/d30588b2731fb01e1616cf16c3fe79a1443e29aa commit 254c271da0712ea8914f187588e0f81f7678ee2f Author: Xiao Ni Date: Thu Feb 4 15:50:47 2021 +0800 Subject: md/raid10: improve discard request for far layout Link: https://github.com/torvalds/linux/commit/254c271da0712ea8914f187588e0f81f7678ee2f There is also an additional commit which is required, and was merged after "md/raid10: improve raid10 discard request" was merged. The following commits enable Radid10 to use large discards, instead of splitting into many bios, since the technical hurdles have now been removed. commit ca4a4e9a55beeb138bb06e3867f5e486da896d44 Author: Mike Snitzer Date: Fri Apr 30 14:38:37 2021 -0400 Subject: dm raid: remove unnecessary
[Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Description changed: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on Raid 0, takes 4 seconds. The bigger the devices, the longer it takes. The cause is that Raid10 currently uses a 512k chunk size, and uses this for the discard_max_bytes value. If we need to discard 1.9TB, the kernel splits the request into millions of 512k bio requests, even if the underlying device supports larger requests. For example, the NVMe devices on i3.8xlarge support 2.2TB of discard at once: $ cat /sys/block/nvme0n1/queue/discard_max_bytes 2199023255040 $ cat /sys/block/nvme0n1/queue/discard_max_hw_bytes 2199023255040 Where the Raid10 md device only supports 512k: $ cat /sys/block/md0/queue/discard_max_bytes 524288 $ cat /sys/block/md0/queue/discard_max_hw_bytes 524288 If we perform a mkfs.xfs operation on the /dev/md array, it takes over 11 minutes and if we examine the stack, it is stuck in blkdev_issue_discard() $ sudo cat /proc/1626/stack [<0>] wait_barrier+0x14c/0x230 [raid10] [<0>] regular_request_wait+0x39/0x150 [raid10] [<0>] raid10_write_request+0x11e/0x850 [raid10] [<0>] raid10_make_request+0xd7/0x150 [raid10] [<0>] md_handle_request+0x123/0x1a0 [<0>] md_submit_bio+0xda/0x120 [<0>] __submit_bio_noacct+0xde/0x320 [<0>] submit_bio_noacct+0x4d/0x90 [<0>] submit_bio+0x4f/0x1b0 [<0>] __blkdev_issue_discard+0x154/0x290 [<0>] blkdev_issue_discard+0x5d/0xc0 [<0>] blk_ioctl_discard+0xc4/0x110 [<0>] blkdev_common_ioctl+0x56c/0x840 [<0>] blkdev_ioctl+0xeb/0x270 [<0>] block_ioctl+0x3d/0x50 [<0>] __x64_sys_ioctl+0x91/0xc0 [<0>] do_syscall_64+0x38/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Fix] Xiao Ni has developed a patchset which resolves the block discard performance problems. These commits have now landed in 5.10-rc1. - commit 2628089b74d5a64bd0bcb5d247a18f78d7b6f4d0 - Author: Xiao Ni - Date: Tue Aug 25 13:42:59 2020 +0800 + commit cf78408f937a67f59f5e90ee8e6cadeed7c128a8 + Author: Xiao Ni + Date: Thu Feb 4 15:50:43 2021 +0800 Subject: md: add md_submit_discard_bio() for submitting discard bio - Link: https://github.com/torvalds/linux/commit/2628089b74d5a64bd0bcb5d247a18f78d7b6f4d0 - - commit 8650a889017cb1f6ea6813ccf83a2e9f6fa49dd3 - Author: Xiao Ni - Date: Tue Aug 25 13:43:00 2020 +0800 + Link: https://github.com/torvalds/linux/commit/cf78408f937a67f59f5e90ee8e6cadeed7c128a8 + + commit c2968285925adb97b9aa4ede94c1f1ab61ce0925 + Author: Xiao Ni + Date: Thu Feb 4 15:50:44 2021 +0800 Subject: md/raid10: extend r10bio devs to raid disks - Link: https://github.com/torvalds/linux/commit/8650a889017cb1f6ea6813ccf83a2e9f6fa49dd3 - - commit f046f5d0d79cdb968f219ce249e497fd1accf484 - Author: Xiao Ni - Date: Tue Aug 25 13:43:01 2020 +0800 - Subject: md/raid10: pull codes that wait for blocked dev into one function - Link: https://github.com/torvalds/linux/commit/f046f5d0d79cdb968f219ce249e497fd1accf484 - - commit bcc90d280465ebd51ab8688be86e1f00c62dccf9 - Author: Xiao Ni - Date: Wed Sep 2 20:00:22 2020 +0800 + Link: https://github.com/torvalds/linux/commit/c2968285925adb97b9aa4ede94c1f1ab61ce0925 + + commit f2e7e269a7525317752d472bb48a549780e87d22 + Author: Xiao Ni + Date: Thu Feb 4 15:50:45 2021 +0800 + Subject: md/raid10: pull the code that wait for blocked dev into one function + Link: https://github.com/torvalds/linux/commit/f2e7e269a7525317752d472bb48a549780e87d22 + + commit d30588b2731fb01e1616cf16c3fe79a1443e29aa + Author: Xiao Ni + Date: Thu Feb 4 15:50:46 2021 +0800 Subject: md/raid10: improve raid10 discard request - Link: https://github.com/torvalds/linux/commit/bcc90d280465ebd51ab8688be86e1f00c62dccf9 - - commit d3ee2d8415a6256c1c41e1be36e80e640c3e6359 - Author: Xiao Ni - Date: Wed Sep 2 20:00:23 2020 +0800 + Link: https://github.com/torvalds/linux/commit/d30588b2731fb01e1616cf16c3fe79a1443e29aa + + commit 254c271da0712ea8914f187588e0f81f7678ee2f + Author: Xiao Ni + Date: Thu Feb 4 15:50:47 2021 +0800 Subject: md/raid10: improve discard request for far layout - Link: https://github.com/torvalds/linux/commit/d3ee2d8415a6256c1c41e1be36e80e640c3e6359 + Link: https://github.com/torvalds/linux/commit/254c271da0712ea8914f187588e0f81f7678ee2f There is also an additional commit which is required, and was merged after "md/raid10: improve raid10 discard request" was merged. The following commits enable Radid10 to use large discards, instead of splitting into many bios, since the technical hurdles have now been removed. - commit
[Kernel-packages] [Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Description changed: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on Raid 0, takes 4 seconds. The bigger the devices, the longer it takes. The cause is that Raid10 currently uses a 512k chunk size, and uses this for the discard_max_bytes value. If we need to discard 1.9TB, the kernel splits the request into millions of 512k bio requests, even if the underlying device supports larger requests. For example, the NVMe devices on i3.8xlarge support 2.2TB of discard at once: $ cat /sys/block/nvme0n1/queue/discard_max_bytes 2199023255040 $ cat /sys/block/nvme0n1/queue/discard_max_hw_bytes 2199023255040 Where the Raid10 md device only supports 512k: $ cat /sys/block/md0/queue/discard_max_bytes 524288 $ cat /sys/block/md0/queue/discard_max_hw_bytes 524288 If we perform a mkfs.xfs operation on the /dev/md array, it takes over 11 minutes and if we examine the stack, it is stuck in blkdev_issue_discard() $ sudo cat /proc/1626/stack [<0>] wait_barrier+0x14c/0x230 [raid10] [<0>] regular_request_wait+0x39/0x150 [raid10] [<0>] raid10_write_request+0x11e/0x850 [raid10] [<0>] raid10_make_request+0xd7/0x150 [raid10] [<0>] md_handle_request+0x123/0x1a0 [<0>] md_submit_bio+0xda/0x120 [<0>] __submit_bio_noacct+0xde/0x320 [<0>] submit_bio_noacct+0x4d/0x90 [<0>] submit_bio+0x4f/0x1b0 [<0>] __blkdev_issue_discard+0x154/0x290 [<0>] blkdev_issue_discard+0x5d/0xc0 [<0>] blk_ioctl_discard+0xc4/0x110 [<0>] blkdev_common_ioctl+0x56c/0x840 [<0>] blkdev_ioctl+0xeb/0x270 [<0>] block_ioctl+0x3d/0x50 [<0>] __x64_sys_ioctl+0x91/0xc0 [<0>] do_syscall_64+0x38/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Fix] Xiao Ni has developed a patchset which resolves the block discard performance problems. These commits have now landed in 5.10-rc1. - commit 2628089b74d5a64bd0bcb5d247a18f78d7b6f4d0 - Author: Xiao Ni - Date: Tue Aug 25 13:42:59 2020 +0800 + commit cf78408f937a67f59f5e90ee8e6cadeed7c128a8 + Author: Xiao Ni + Date: Thu Feb 4 15:50:43 2021 +0800 Subject: md: add md_submit_discard_bio() for submitting discard bio - Link: https://github.com/torvalds/linux/commit/2628089b74d5a64bd0bcb5d247a18f78d7b6f4d0 - - commit 8650a889017cb1f6ea6813ccf83a2e9f6fa49dd3 - Author: Xiao Ni - Date: Tue Aug 25 13:43:00 2020 +0800 + Link: https://github.com/torvalds/linux/commit/cf78408f937a67f59f5e90ee8e6cadeed7c128a8 + + commit c2968285925adb97b9aa4ede94c1f1ab61ce0925 + Author: Xiao Ni + Date: Thu Feb 4 15:50:44 2021 +0800 Subject: md/raid10: extend r10bio devs to raid disks - Link: https://github.com/torvalds/linux/commit/8650a889017cb1f6ea6813ccf83a2e9f6fa49dd3 - - commit f046f5d0d79cdb968f219ce249e497fd1accf484 - Author: Xiao Ni - Date: Tue Aug 25 13:43:01 2020 +0800 - Subject: md/raid10: pull codes that wait for blocked dev into one function - Link: https://github.com/torvalds/linux/commit/f046f5d0d79cdb968f219ce249e497fd1accf484 - - commit bcc90d280465ebd51ab8688be86e1f00c62dccf9 - Author: Xiao Ni - Date: Wed Sep 2 20:00:22 2020 +0800 + Link: https://github.com/torvalds/linux/commit/c2968285925adb97b9aa4ede94c1f1ab61ce0925 + + commit f2e7e269a7525317752d472bb48a549780e87d22 + Author: Xiao Ni + Date: Thu Feb 4 15:50:45 2021 +0800 + Subject: md/raid10: pull the code that wait for blocked dev into one function + Link: https://github.com/torvalds/linux/commit/f2e7e269a7525317752d472bb48a549780e87d22 + + commit d30588b2731fb01e1616cf16c3fe79a1443e29aa + Author: Xiao Ni + Date: Thu Feb 4 15:50:46 2021 +0800 Subject: md/raid10: improve raid10 discard request - Link: https://github.com/torvalds/linux/commit/bcc90d280465ebd51ab8688be86e1f00c62dccf9 - - commit d3ee2d8415a6256c1c41e1be36e80e640c3e6359 - Author: Xiao Ni - Date: Wed Sep 2 20:00:23 2020 +0800 + Link: https://github.com/torvalds/linux/commit/d30588b2731fb01e1616cf16c3fe79a1443e29aa + + commit 254c271da0712ea8914f187588e0f81f7678ee2f + Author: Xiao Ni + Date: Thu Feb 4 15:50:47 2021 +0800 Subject: md/raid10: improve discard request for far layout - Link: https://github.com/torvalds/linux/commit/d3ee2d8415a6256c1c41e1be36e80e640c3e6359 + Link: https://github.com/torvalds/linux/commit/254c271da0712ea8914f187588e0f81f7678ee2f There is also an additional commit which is required, and was merged after "md/raid10: improve raid10 discard request" was merged. The following commits enable Radid10 to use large discards, instead of splitting into many bios, since the technical hurdles have now been removed. - commit
[Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Hi Seth,
Thanks for the review.
I read the commit you found:
commit 1e41dadfa7b9f792ed0f4714a3d3d36f070cf30e
Author: Dr. David von Oheimb
Date: Sat Jun 27 16:16:12 2020 +0200
Subject: Extend X509 cert checks and error reporting in v3_{purp,crld}.c and
x509_{set,vfy}.c
Link:
https://github.com/openssl/openssl/commit/1e41dadfa7b9f792ed0f4714a3d3d36f070cf30e
Firstly, yes, you are right, this commit does refactor the code I am
suggesting we SRU to focal and groovy, but upon further inspection, this
commit was not backported to the 1.1.1 stable series, as it is missing
from the OpenSSL_1_1_1-stable branch. As you mentioned, it is a fairly
invasive change and modifies a lot of different x509 components, it
isn't suitable to be backported to 1.1.1 stable anyway, and much less be
acceptable for SRU to focal or groovy.
I think we should stick to the small targeted commits I suggested for
this SRU, since they are a part of 1.1.1 stable, and are already in
hirsute onward.
To test that the logic from the suggested commits to SRU matches this
new refactor commit from version 3.0alpha, I went and built the master
branch of openssl, which had commit
d1a770414acd34c774248ce8efbe202fd7a44041 at HEAD.
$ env LD_LIBRARY_PATH="/home/ubuntu/openssl/" ../openssl/apps/openssl version
OpenSSL 3.0.0-alpha16-dev (Library: OpenSSL 3.0.0-alpha16-dev )
$ env LD_LIBRARY_PATH="/home/ubuntu/openssl/" ../openssl/apps/openssl verify
-CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem
user1_cert.pem: OK
The logic matches and the reproducer certificates verify OK. This
confirms we aren't backporting a short lived change, and that this
behaviour is the desired and accepted outcome.
@ddstreet Please go ahead and sponsor the SRU to -updates, thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1926254
Title:
x509 Certificate verification fails when
basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Hi Seth,
Thanks for the review.
I read the commit you found:
commit 1e41dadfa7b9f792ed0f4714a3d3d36f070cf30e
Author: Dr. David von Oheimb
Date: Sat Jun 27 16:16:12 2020 +0200
Subject: Extend X509 cert checks and error reporting in v3_{purp,crld}.c and
x509_{set,vfy}.c
Link:
https://github.com/openssl/openssl/commit/1e41dadfa7b9f792ed0f4714a3d3d36f070cf30e
Firstly, yes, you are right, this commit does refactor the code I am
suggesting we SRU to focal and groovy, but upon further inspection, this
commit was not backported to the 1.1.1 stable series, as it is missing
from the OpenSSL_1_1_1-stable branch. As you mentioned, it is a fairly
invasive change and modifies a lot of different x509 components, it
isn't suitable to be backported to 1.1.1 stable anyway, and much less be
acceptable for SRU to focal or groovy.
I think we should stick to the small targeted commits I suggested for
this SRU, since they are a part of 1.1.1 stable, and are already in
hirsute onward.
To test that the logic from the suggested commits to SRU matches this
new refactor commit from version 3.0alpha, I went and built the master
branch of openssl, which had commit
d1a770414acd34c774248ce8efbe202fd7a44041 at HEAD.
$ env LD_LIBRARY_PATH="/home/ubuntu/openssl/" ../openssl/apps/openssl version
OpenSSL 3.0.0-alpha16-dev (Library: OpenSSL 3.0.0-alpha16-dev )
$ env LD_LIBRARY_PATH="/home/ubuntu/openssl/" ../openssl/apps/openssl verify
-CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem
user1_cert.pem: OK
The logic matches and the reproducer certificates verify OK. This
confirms we aren't backporting a short lived change, and that this
behaviour is the desired and accepted outcome.
@ddstreet Please go ahead and sponsor the SRU to -updates, thanks.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1926254
Title:
x509 Certificate verification fails when
basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Focal:
In Progress
Status in openssl source package in Groovy:
In Progress
Status in openssl source package in Hirsute:
Fix Released
Bug description:
[Impact]
In openssl 1.1.1f, the below commit was merged:
commit ba4356ae4002a04e28642da60c551877eea804f7
Author: Bernd Edlinger
Date: Sat Jan 4 15:54:53 2020 +0100
Subject: Fix error handling in x509v3_cache_extensions and related functions
Link:
https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7
This introduced a regression which caused certificate validation to
fail when certificates violate RFC 5280 [1], namely, when a
certificate has "basicConstraints=CA:FALSE,pathlen:0". This
combination is commonly seen by self-signed leaf certificates with an
intermediate CA before the root CA.
Because of this, openssl 1.1.1f rejects these certificates and they
cannot be used in the system certificate store, and ssl connections
fail when you try to use them to connect to a ssl endpoint.
The error you see when you try verify is:
$ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem
user1_cert.pem
error 20 at 0 depth lookup: unable to get local issuer certificate
error user1_cert.pem: verification failed
The exact same certificates work fine on Xenial, Bionic and Hirsute.
[1] https://tools.ietf.org/html/rfc5280.html
[Testcase]
We will create our own root CA, intermediate CA and leaf server
certificate.
Create necessary directories:
$ mkdir reproducer
$ cd reproducer
$ mkdir CA
Write openssl configuration files to disk for each CA and cert:
$ cat << EOF >> rootCA.cnf
[ req ]
prompt = no
distinguished_name = req_distinguished_name
x509_extensions = usr_cert
[ req_distinguished_name ]
C = DE
O = Test Org
CN = Test RSA PSS Root-CA
[ usr_cert ]
basicConstraints= critical,CA:TRUE
keyUsage= critical,keyCertSign,cRLSign
subjectKeyIdentifier= hash
authorityKeyIdentifier = keyid:always
EOF
$ cat << EOF >> subCA.cnf
[ req ]
prompt = no
distinguished_name = req_distinguished_name
x509_extensions = usr_cert
[ req_distinguished_name ]
C = DE
O = Test Org
CN = Test RSA PSS Sub-CA
[ usr_cert ]
basicConstraints= critical,CA:TRUE,pathlen:0
keyUsage= critical,keyCertSign,cRLSign
subjectKeyIdentifier= hash
authorityKeyIdentifier = keyid:always
EOF
$ cat << EOF >> user.cnf
[ req ]
prompt = no
distinguished_name = req_distinguished_name
x509_extensions = usr_cert
[ req_distinguished_name ]
C = DE
O = Test Org
CN = Test User
[ usr_cert ]
basicConstraints= critical,CA:FALSE,pathlen:0
keyUsage=
Re: [Sts-sponsors] Please Review LP#1926254 openssl x509 Certificate Validation SRU
Hi Dan, I responded to Seth's question about the re-factor commit in openssl 3.0alpha, and it does not need to be backported. I think we are good to go for sponsorship now, thanks! Matthew On Sat, May 1, 2021 at 7:52 AM Dan Streetman wrote: > > On Thu, Apr 29, 2021 at 8:13 PM Matthew Ruffell > wrote: > > > > Hi Security Team, > > > > VISA opened a case, SF308725 - "openssl unable to process the certificate on > > Ubuntu 20.0" [1], about a minor regression in openssl 1.1.1f that affects > > both Focal and Groovy. > > > > [1] > > https://canonical.lightning.force.com/lightning/r/Case/5004K05pGePQAU/view > > > > A commit was merged in 1.1.1f which disallows certificates which set > > "basicConstraints=CA:FALSE,pathlen:0" as it violates the RFC for ssl certs, > > but > > this is a common configuration in certificates in the wild, particularly > > self > > signed certificates. > > > > This was reported upstream and fixed in 1.1.1g, to relax this particular > > scenario only, to allow it to be accepted as a valid certificate. > > > > More information and a full reproducer is available on the Launchpad bug, > > LP #1926254 - "x509 Certificate verification fails when > > basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs" [2]. > > > > [2] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254 > > > > Due to the nature of the package, can you please review the launchpad bug > > and > > debdiffs I have attached to the launchpad bug, and if everything is okay, > > can > > you write an acknowledgement and approval to a comment on the launchpad bug. > > > > After that I will seek sponsorship to get this submitted for SRU. > > > > I am thinking -updates is okay, no need for -security. > > I added ubuntu-security to the bug also, and I'm happy to upload if > there are no objections from security team > > > > > Thanks, > > Matthew > > > > -- > > Mailing list: https://launchpad.net/~sts-sponsors > > Post to : sts-sponsors@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~sts-sponsors > > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[dm-devel] Raid1 and Raid10 Discard Limit Fixups for 5.13 Merge Window
Hi Mike, The Raid10 block discard performance patchset from Xiao Ni has reached mainline this morning in the following commits: 254c271da071 md/raid10: improve discard request for far layout d30588b2731f md/raid10: improve raid10 discard request f2e7e269a752 md/raid10: pull the code that wait for blocked dev into one function c2968285925a md/raid10: extend r10bio devs to raid disks cf78408f937a md: add md_submit_discard_bio() for submitting discard bio I was wondering, are you planning to resubmit your patches to fixup discard limits for raid1 and raid10 this merge cycle? commit e0910c8e4f87bb9f767e61a778b0d9271c4dc512 Author: Mike Snitzer Date: Thu Sep 24 13:14:52 2020 -0400 Subject: dm raid: fix discard limits for raid1 and raid10 Link: https://github.com/torvalds/linux/commit/e0910c8e4f87bb9f767e61a778b0d9271c4dc512 commit f0e90b6c663a7e3b4736cb318c6c7c589f152c28 Author: Mike Snitzer Date: Thu Sep 24 16:40:12 2020 -0400 Subject: dm raid: remove unnecessary discard limits for raid10 Link: https://github.com/torvalds/linux/commit/f0e90b6c663a7e3b4736cb318c6c7c589f152c28 Thanks, Matthew -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
[Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
** Tags added: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926254 Title: x509 Certificate verification fails when basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
** Tags added: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1926254 Title: x509 Certificate verification fails when basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Focal: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: Fix Released Bug description: [Impact] In openssl 1.1.1f, the below commit was merged: commit ba4356ae4002a04e28642da60c551877eea804f7 Author: Bernd Edlinger Date: Sat Jan 4 15:54:53 2020 +0100 Subject: Fix error handling in x509v3_cache_extensions and related functions Link: https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7 This introduced a regression which caused certificate validation to fail when certificates violate RFC 5280 [1], namely, when a certificate has "basicConstraints=CA:FALSE,pathlen:0". This combination is commonly seen by self-signed leaf certificates with an intermediate CA before the root CA. Because of this, openssl 1.1.1f rejects these certificates and they cannot be used in the system certificate store, and ssl connections fail when you try to use them to connect to a ssl endpoint. The error you see when you try verify is: $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed The exact same certificates work fine on Xenial, Bionic and Hirsute. [1] https://tools.ietf.org/html/rfc5280.html [Testcase] We will create our own root CA, intermediate CA and leaf server certificate. Create necessary directories: $ mkdir reproducer $ cd reproducer $ mkdir CA Write openssl configuration files to disk for each CA and cert: $ cat << EOF >> rootCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Root-CA [ usr_cert ] basicConstraints= critical,CA:TRUE keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> subCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Sub-CA [ usr_cert ] basicConstraints= critical,CA:TRUE,pathlen:0 keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> user.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test User [ usr_cert ] basicConstraints= critical,CA:FALSE,pathlen:0 keyUsage= critical,digitalSignature,keyAgreement extendedKeyUsage= clientAuth,serverAuth subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF Then generate the necessary RSA keys and form certificates: $ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config rootCA.cnf -set_serial 01 -new -batch -sha256 -nodes -x509 -days 9125 -out CA/rootCA_cert.pem -key rootCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in subCA_req.pem -CA CA/rootCA_cert.pem -CAkey rootCA_key.pem -out CA/subCA_cert.pem -CAserial rootCA_serial.txt -CAcreateserial -extfile subCA.cnf -extensions usr_cert -days 4380 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ c_rehash CA $ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in user1_req.pem -CA CA/subCA_cert.pem -CAkey subCA_key.pem -out user1_cert.pem -CAserial subCA_serial.txt -CAcreateserial -extfile user.cnf -extensions usr_cert -days 1825 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 Now, let's try verify the generated certificates: $ openssl version OpenSSL 1.1.1f 31 Mar 2020 $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer
[Sts-sponsors] Please Review LP#1926254 openssl x509 Certificate Validation SRU
Hi Security Team, VISA opened a case, SF308725 - "openssl unable to process the certificate on Ubuntu 20.0" [1], about a minor regression in openssl 1.1.1f that affects both Focal and Groovy. [1] https://canonical.lightning.force.com/lightning/r/Case/5004K05pGePQAU/view A commit was merged in 1.1.1f which disallows certificates which set "basicConstraints=CA:FALSE,pathlen:0" as it violates the RFC for ssl certs, but this is a common configuration in certificates in the wild, particularly self signed certificates. This was reported upstream and fixed in 1.1.1g, to relax this particular scenario only, to allow it to be accepted as a valid certificate. More information and a full reproducer is available on the Launchpad bug, LP #1926254 - "x509 Certificate verification fails when basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs" [2]. [2] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254 Due to the nature of the package, can you please review the launchpad bug and debdiffs I have attached to the launchpad bug, and if everything is okay, can you write an acknowledgement and approval to a comment on the launchpad bug. After that I will seek sponsorship to get this submitted for SRU. I am thinking -updates is okay, no need for -security. Thanks, Matthew -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Attached is a debdiff for openssl on Groovy which fixes this bug. ** Patch added: "Debdiff for openssl on Groovy" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254/+attachment/5493443/+files/lp1926254_groovy.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1926254 Title: x509 Certificate verification fails when basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Focal: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: Fix Released Bug description: [Impact] In openssl 1.1.1f, the below commit was merged: commit ba4356ae4002a04e28642da60c551877eea804f7 Author: Bernd Edlinger Date: Sat Jan 4 15:54:53 2020 +0100 Subject: Fix error handling in x509v3_cache_extensions and related functions Link: https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7 This introduced a regression which caused certificate validation to fail when certificates violate RFC 5280 [1], namely, when a certificate has "basicConstraints=CA:FALSE,pathlen:0". This combination is commonly seen by self-signed leaf certificates with an intermediate CA before the root CA. Because of this, openssl 1.1.1f rejects these certificates and they cannot be used in the system certificate store, and ssl connections fail when you try to use them to connect to a ssl endpoint. The error you see when you try verify is: $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed The exact same certificates work fine on Xenial, Bionic and Hirsute. [1] https://tools.ietf.org/html/rfc5280.html [Testcase] We will create our own root CA, intermediate CA and leaf server certificate. Create necessary directories: $ mkdir reproducer $ cd reproducer $ mkdir CA Write openssl configuration files to disk for each CA and cert: $ cat << EOF >> rootCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Root-CA [ usr_cert ] basicConstraints= critical,CA:TRUE keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> subCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Sub-CA [ usr_cert ] basicConstraints= critical,CA:TRUE,pathlen:0 keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> user.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test User [ usr_cert ] basicConstraints= critical,CA:FALSE,pathlen:0 keyUsage= critical,digitalSignature,keyAgreement extendedKeyUsage= clientAuth,serverAuth subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF Then generate the necessary RSA keys and form certificates: $ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config rootCA.cnf -set_serial 01 -new -batch -sha256 -nodes -x509 -days 9125 -out CA/rootCA_cert.pem -key rootCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in subCA_req.pem -CA CA/rootCA_cert.pem -CAkey rootCA_key.pem -out CA/subCA_cert.pem -CAserial rootCA_serial.txt -CAcreateserial -extfile subCA.cnf -extensions usr_cert -days 4380 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ c_rehash CA $ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in user1_req.pem -CA CA/subCA_cert.pem -CAkey subCA_key.pem -out user1_cert.pem -CAserial subCA_serial.txt -CAcreateserial -extfile user.cnf -extensions usr_cert -days 1825 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 Now, let's try verify the generated
[Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Attached is a debdiff for openssl on Groovy which fixes this bug. ** Patch added: "Debdiff for openssl on Groovy" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254/+attachment/5493443/+files/lp1926254_groovy.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926254 Title: x509 Certificate verification fails when basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Attached is a debdiff for openssl on Focal which fixes this bug. ** Patch added: "Debdiff for openssl on focal" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254/+attachment/5493442/+files/lp1926254_focal.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926254 Title: x509 Certificate verification fails when basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Attached is a debdiff for openssl on Focal which fixes this bug. ** Patch added: "Debdiff for openssl on focal" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1926254/+attachment/5493442/+files/lp1926254_focal.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1926254 Title: x509 Certificate verification fails when basicConstraints=CA:FALSE,pathlen:0 on self-signed leaf certs Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Focal: In Progress Status in openssl source package in Groovy: In Progress Status in openssl source package in Hirsute: Fix Released Bug description: [Impact] In openssl 1.1.1f, the below commit was merged: commit ba4356ae4002a04e28642da60c551877eea804f7 Author: Bernd Edlinger Date: Sat Jan 4 15:54:53 2020 +0100 Subject: Fix error handling in x509v3_cache_extensions and related functions Link: https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7 This introduced a regression which caused certificate validation to fail when certificates violate RFC 5280 [1], namely, when a certificate has "basicConstraints=CA:FALSE,pathlen:0". This combination is commonly seen by self-signed leaf certificates with an intermediate CA before the root CA. Because of this, openssl 1.1.1f rejects these certificates and they cannot be used in the system certificate store, and ssl connections fail when you try to use them to connect to a ssl endpoint. The error you see when you try verify is: $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed The exact same certificates work fine on Xenial, Bionic and Hirsute. [1] https://tools.ietf.org/html/rfc5280.html [Testcase] We will create our own root CA, intermediate CA and leaf server certificate. Create necessary directories: $ mkdir reproducer $ cd reproducer $ mkdir CA Write openssl configuration files to disk for each CA and cert: $ cat << EOF >> rootCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Root-CA [ usr_cert ] basicConstraints= critical,CA:TRUE keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> subCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Sub-CA [ usr_cert ] basicConstraints= critical,CA:TRUE,pathlen:0 keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> user.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test User [ usr_cert ] basicConstraints= critical,CA:FALSE,pathlen:0 keyUsage= critical,digitalSignature,keyAgreement extendedKeyUsage= clientAuth,serverAuth subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF Then generate the necessary RSA keys and form certificates: $ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config rootCA.cnf -set_serial 01 -new -batch -sha256 -nodes -x509 -days 9125 -out CA/rootCA_cert.pem -key rootCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in subCA_req.pem -CA CA/rootCA_cert.pem -CAkey rootCA_key.pem -out CA/subCA_cert.pem -CAserial rootCA_serial.txt -CAcreateserial -extfile subCA.cnf -extensions usr_cert -days 4380 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ c_rehash CA $ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in user1_req.pem -CA CA/subCA_cert.pem -CAkey subCA_key.pem -out user1_cert.pem -CAserial subCA_serial.txt -CAcreateserial -extfile user.cnf -extensions usr_cert -days 1825 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 Now, let's try verify the generated
[Kernel-packages] [Bug 1907262] Re: raid10: discard leads to corrupted file system
** Changed in: linux (Ubuntu Groovy) Assignee: Sinclair Willis (yousure1222) => (unassigned) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Invalid Status in linux source package in Xenial: Invalid Status in linux source package in Bionic: Fix Released Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: Fix Released Bug description: Seems to be closely related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578 After updating the Ubuntu 18.04 kernel from 4.15.0-124 to 4.15.0-126 the fstrim command triggered by fstrim.timer causes a severe number of mismatches between two RAID10 component devices. This bug affects several machines in our company with different HW configurations (All using ECC RAM). Both, NVMe and SATA SSDs are affected. How to reproduce: - Create a RAID10 LVM and filesystem on two SSDs mdadm -C -v -l10 -n2 -N "lv-raid" -R /dev/md0 /dev/nvme0n1p2 /dev/nvme1n1p2 pvcreate -ff -y /dev/md0 vgcreate -f -y VolGroup /dev/md0 lvcreate -n root-L 100G -ay -y VolGroup mkfs.ext4 /dev/VolGroup/root mount /dev/VolGroup/root /mnt - Write some data, sync and delete it dd if=/dev/zero of=/mnt/data.raw bs=4K count=1M sync rm /mnt/data.raw - Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (should be 0): cat /sys/block/md0/md/mismatch_cnt - Trigger the bug fstrim /mnt - Re-Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (probably in the range of N*1): cat /sys/block/md0/md/mismatch_cnt After investigating this issue on several machines it *seems* that the first drive does the trim correctly while the second one goes wild. At least the number and severity of errors found by a USB stick live session fsck.ext4 suggests this. To perform the single drive evaluation the RAID10 was started using a single drive at once: mdadm --assemble /dev/md127 /dev/nvme0n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root vgchange -a n /dev/VolGroup mdadm --stop /dev/md127 mdadm --assemble /dev/md127 /dev/nvme1n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root When starting these fscks without -n, on the first device it seems the directory structure is OK while on the second device there is only the lost+found folder left. Side-note: Another machine using HWE kernel 5.4.0-56 (after using -53 before) seems to have a quite similar issue. Unfortunately the risk/regression assessment in the aforementioned bug is not complete: the workaround only mitigates the issues during FS creation. This bug on the other hand is triggered by a weekly service (fstrim) causing severe file system corruption. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 1907262] Re: raid10: discard leads to corrupted file system
** Changed in: linux (Ubuntu Groovy) Assignee: Sinclair Willis (yousure1222) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
** Description changed: [Impact] In openssl 1.1.1f, the below commit was merged: commit ba4356ae4002a04e28642da60c551877eea804f7 Author: Bernd Edlinger Date: Sat Jan 4 15:54:53 2020 +0100 Subject: Fix error handling in x509v3_cache_extensions and related functions Link: https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7 This introduced a regression which caused certificate validation to fail when certificates violate RFC 5280 [1], namely, when a certificate has "basicConstraints=CA:FALSE,pathlen:0". This combination is commonly seen by self-signed leaf certificates with an intermediate CA before the root CA. Because of this, openssl 1.1.1f rejects these certificates and they cannot be used in the system certificate store, and ssl connections fail when you try to use them to connect to a ssl endpoint. The error you see when you try verify is: $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed The exact same certificates work fine on Xenial, Bionic and Hirsute. [1] https://tools.ietf.org/html/rfc5280.html [Testcase] We will create our own root CA, intermediate CA and leaf server certificate. Create necessary directories: $ mkdir reproducer $ cd reproducer $ mkdir CA Write openssl configuration files to disk for each CA and cert: $ cat << EOF >> rootCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Root-CA [ usr_cert ] basicConstraints= critical,CA:TRUE keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> subCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Sub-CA [ usr_cert ] basicConstraints= critical,CA:TRUE,pathlen:0 keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> user.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test User [ usr_cert ] basicConstraints= critical,CA:FALSE,pathlen:0 keyUsage= critical,digitalSignature,keyAgreement extendedKeyUsage= clientAuth,serverAuth subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF Then generate the necessary RSA keys and form certificates: $ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config rootCA.cnf -set_serial 01 -new -batch -sha256 -nodes -x509 -days 9125 -out CA/rootCA_cert.pem -key rootCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in subCA_req.pem -CA CA/rootCA_cert.pem -CAkey rootCA_key.pem -out CA/subCA_cert.pem -CAserial rootCA_serial.txt -CAcreateserial -extfile subCA.cnf -extensions usr_cert -days 4380 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ c_rehash CA $ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in user1_req.pem -CA CA/subCA_cert.pem -CAkey subCA_key.pem -out user1_cert.pem -CAserial subCA_serial.txt -CAcreateserial -extfile user.cnf -extensions usr_cert -days 1825 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 Now, let's try verify the generated certificates: $ openssl version OpenSSL 1.1.1f 31 Mar 2020 $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed There are test packages available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf308725-test If you install these test packages, and attempt to verify, things work as planned. + $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem + user1_cert.pem: OK + [Where problems could occur] If a regression were to occur, it would occur around x509
[Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
** Description changed: [Impact] In openssl 1.1.1f, the below commit was merged: commit ba4356ae4002a04e28642da60c551877eea804f7 Author: Bernd Edlinger Date: Sat Jan 4 15:54:53 2020 +0100 Subject: Fix error handling in x509v3_cache_extensions and related functions Link: https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7 This introduced a regression which caused certificate validation to fail when certificates violate RFC 5280 [1], namely, when a certificate has "basicConstraints=CA:FALSE,pathlen:0". This combination is commonly seen by self-signed leaf certificates with an intermediate CA before the root CA. Because of this, openssl 1.1.1f rejects these certificates and they cannot be used in the system certificate store, and ssl connections fail when you try to use them to connect to a ssl endpoint. The error you see when you try verify is: $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed The exact same certificates work fine on Xenial, Bionic and Hirsute. [1] https://tools.ietf.org/html/rfc5280.html [Testcase] We will create our own root CA, intermediate CA and leaf server certificate. Create necessary directories: $ mkdir reproducer $ cd reproducer $ mkdir CA Write openssl configuration files to disk for each CA and cert: $ cat << EOF >> rootCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Root-CA [ usr_cert ] basicConstraints= critical,CA:TRUE keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> subCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Sub-CA [ usr_cert ] basicConstraints= critical,CA:TRUE,pathlen:0 keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> user.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test User [ usr_cert ] basicConstraints= critical,CA:FALSE,pathlen:0 keyUsage= critical,digitalSignature,keyAgreement extendedKeyUsage= clientAuth,serverAuth subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF Then generate the necessary RSA keys and form certificates: $ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config rootCA.cnf -set_serial 01 -new -batch -sha256 -nodes -x509 -days 9125 -out CA/rootCA_cert.pem -key rootCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in subCA_req.pem -CA CA/rootCA_cert.pem -CAkey rootCA_key.pem -out CA/subCA_cert.pem -CAserial rootCA_serial.txt -CAcreateserial -extfile subCA.cnf -extensions usr_cert -days 4380 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ c_rehash CA $ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt rsa_keygen_bits:2048 $ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 $ openssl x509 -req -sha256 -in user1_req.pem -CA CA/subCA_cert.pem -CAkey subCA_key.pem -out user1_cert.pem -CAserial subCA_serial.txt -CAcreateserial -extfile user.cnf -extensions usr_cert -days 1825 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 Now, let's try verify the generated certificates: $ openssl version OpenSSL 1.1.1f 31 Mar 2020 $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed There are test packages available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf308725-test If you install these test packages, and attempt to verify, things work as planned. + $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem + user1_cert.pem: OK + [Where problems could occur] If a regression were to occur, it would occur around x509
[Bug 1926254] [NEW] x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
view by the security team. One of the commits which fixes the issue adds two testcases to the openssl testsuite, which tests the "CA:FALSE, pathlen:0" certificates with and without -x509_strict, and tests to see if it passes without, and fails with. [Other info] This was reported in the upstream issue #11456 [2]: [2] https://github.com/openssl/openssl/issues/11456 I believe these three commits fix the issue: commit 00a0da2f021e6a0bc9519a6a9e5be66d45e6fc91 Author: Tomas Mraz Date: Thu Apr 2 15:56:12 2020 +0200 Subject: Allow certificates with Basic Constraints CA:false, pathlen:0 Link: https://github.com/openssl/openssl/commit/00a0da2f021e6a0bc9519a6a9e5be66d45e6fc91 commit 29e94f285f7f05b1aec6fa275e320bc5fa37ab1e Author: Tomas Mraz Date: Thu Apr 2 17:31:21 2020 +0200 Subject: Set X509_V_ERR_INVALID_EXTENSION error for invalid basic constraints Link: https://github.com/openssl/openssl/commit/29e94f285f7f05b1aec6fa275e320bc5fa37ab1e commit e78f2a8f269a4dcf820ca994e2b89b77972d79e1 Author: Tomas Mraz Date: Fri Apr 3 10:24:40 2020 +0200 Subject: Add test cases for the non CA certificate with pathlen:0 Link: https://github.com/openssl/openssl/commit/e78f2a8f269a4dcf820ca994e2b89b77972d79e1 These landed in openssl 1.1.1g, and hirsute already has these fixes. ** Affects: openssl (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: openssl (Ubuntu Focal) Importance: Medium Assignee: Matthew Ruffell (mruffell) Status: In Progress ** Affects: openssl (Ubuntu Groovy) Importance: Medium Assignee: Matthew Ruffell (mruffell) Status: In Progress ** Affects: openssl (Ubuntu Hirsute) Importance: Undecided Status: Fix Released ** Tags: focal groovy sts ** Also affects: openssl (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu) Status: New => Fix Released ** Changed in: openssl (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: openssl (Ubuntu Focal) Status: New => In Progress ** Changed in: openssl (Ubuntu Groovy) Status: New => In Progress ** Changed in: openssl (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: openssl (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: openssl (Ubuntu Focal) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Changed in: openssl (Ubuntu Groovy) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Tags added: focal groovy sts ** Description changed: [Impact] In openssl 1.1.1f, the below commit was merged: commit ba4356ae4002a04e28642da60c551877eea804f7 Author: Bernd Edlinger Date: Sat Jan 4 15:54:53 2020 +0100 Subject: Fix error handling in x509v3_cache_extensions and related functions Link: https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7 This introduced a regression which caused certificate validation to fail when certificates violate RFC 5280 [1], namely, when a certificate has "basicConstraints=CA:FALSE,pathlen:0". This combination is commonly seen by self-signed leaf certificates with an intermediate CA before the root CA. Because of this, openssl 1.1.1f rejects these certificates and they cannot be used in the system certificate store, and ssl connections fail when you try to use them to connect to a ssl endpoint. The error you see when you try verify is: $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed The exact same certificates work fine on Xenial, Bionic and Hirsute. [1] https://tools.ietf.org/html/rfc5280.html [Testcase] We will create our own root CA, intermediate CA and leaf server certificate. Create necessary directories: $ mkdir reproducer $ cd reproducer $ mkdir CA Write openssl configuration files to disk for each CA and cert: $ cat << EOF >> rootCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Root-CA [ usr_cert ] basicConstraints= critical,CA:TRUE keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> subCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Sub-CA [ usr_cert ] basicConstraints
[Touch-packages] [Bug 1926254] [NEW] x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
view by the security team. One of the commits which fixes the issue adds two testcases to the openssl testsuite, which tests the "CA:FALSE, pathlen:0" certificates with and without -x509_strict, and tests to see if it passes without, and fails with. [Other info] This was reported in the upstream issue #11456 [2]: [2] https://github.com/openssl/openssl/issues/11456 I believe these three commits fix the issue: commit 00a0da2f021e6a0bc9519a6a9e5be66d45e6fc91 Author: Tomas Mraz Date: Thu Apr 2 15:56:12 2020 +0200 Subject: Allow certificates with Basic Constraints CA:false, pathlen:0 Link: https://github.com/openssl/openssl/commit/00a0da2f021e6a0bc9519a6a9e5be66d45e6fc91 commit 29e94f285f7f05b1aec6fa275e320bc5fa37ab1e Author: Tomas Mraz Date: Thu Apr 2 17:31:21 2020 +0200 Subject: Set X509_V_ERR_INVALID_EXTENSION error for invalid basic constraints Link: https://github.com/openssl/openssl/commit/29e94f285f7f05b1aec6fa275e320bc5fa37ab1e commit e78f2a8f269a4dcf820ca994e2b89b77972d79e1 Author: Tomas Mraz Date: Fri Apr 3 10:24:40 2020 +0200 Subject: Add test cases for the non CA certificate with pathlen:0 Link: https://github.com/openssl/openssl/commit/e78f2a8f269a4dcf820ca994e2b89b77972d79e1 These landed in openssl 1.1.1g, and hirsute already has these fixes. ** Affects: openssl (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: openssl (Ubuntu Focal) Importance: Medium Assignee: Matthew Ruffell (mruffell) Status: In Progress ** Affects: openssl (Ubuntu Groovy) Importance: Medium Assignee: Matthew Ruffell (mruffell) Status: In Progress ** Affects: openssl (Ubuntu Hirsute) Importance: Undecided Status: Fix Released ** Tags: focal groovy sts ** Also affects: openssl (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu) Status: New => Fix Released ** Changed in: openssl (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: openssl (Ubuntu Focal) Status: New => In Progress ** Changed in: openssl (Ubuntu Groovy) Status: New => In Progress ** Changed in: openssl (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: openssl (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: openssl (Ubuntu Focal) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Changed in: openssl (Ubuntu Groovy) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Tags added: focal groovy sts ** Description changed: [Impact] In openssl 1.1.1f, the below commit was merged: commit ba4356ae4002a04e28642da60c551877eea804f7 Author: Bernd Edlinger Date: Sat Jan 4 15:54:53 2020 +0100 Subject: Fix error handling in x509v3_cache_extensions and related functions Link: https://github.com/openssl/openssl/commit/ba4356ae4002a04e28642da60c551877eea804f7 This introduced a regression which caused certificate validation to fail when certificates violate RFC 5280 [1], namely, when a certificate has "basicConstraints=CA:FALSE,pathlen:0". This combination is commonly seen by self-signed leaf certificates with an intermediate CA before the root CA. Because of this, openssl 1.1.1f rejects these certificates and they cannot be used in the system certificate store, and ssl connections fail when you try to use them to connect to a ssl endpoint. The error you see when you try verify is: $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed The exact same certificates work fine on Xenial, Bionic and Hirsute. [1] https://tools.ietf.org/html/rfc5280.html [Testcase] We will create our own root CA, intermediate CA and leaf server certificate. Create necessary directories: $ mkdir reproducer $ cd reproducer $ mkdir CA Write openssl configuration files to disk for each CA and cert: $ cat << EOF >> rootCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Root-CA [ usr_cert ] basicConstraints= critical,CA:TRUE keyUsage= critical,keyCertSign,cRLSign subjectKeyIdentifier= hash authorityKeyIdentifier = keyid:always EOF $ cat << EOF >> subCA.cnf [ req ] prompt = no distinguished_name = req_distinguished_name x509_extensions = usr_cert [ req_distinguished_name ] C = DE O = Test Org CN = Test RSA PSS Sub-CA [ usr_cert ] basicConstraints
[Kernel-packages] [Bug 1856608] Re: [Regression] usb usb2-port2: Cannot enable. Maybe the USB cable is bad?
@dannf: Yes, this bug sure is a tricky one. Most of these reports will be due to failing / faulty / non-spec complaint USB devices or cables, like the original reason for this bug being opened. Although, there have been some reports where user's systems do go back to working when they install my test kernel which reverts "usb: handle warm-reset port requests on hub resume". When we wrote to the USB subsystem maintainer last year about the commit, they were pretty sure the commit worked as intended and that the USB device itself was malfunctioning. The commit is also in all of the upstream -stable kernels, in mainline, with no changes since when it was introduced. Which means that it works for the vast majority of users, and only fails for a very small minority of users. We don't want to deviate from mainline by reverting patches we don't need to. I suppose we could ask affected users for a debug trace of the USB subsystem during a boot, or plugging in a device which causes these messages, and start building a case against "usb: handle warm-reset port requests on hub resume", but at the same time, these errors could be due to failing hardware, and we don't have too many ways of figuring that out, especially if it happens to be a root hub that breaks. It's tricky. We might have to read the USB spec again to see if "usb: handle warm-reset port requests on hub resume" is complaint, but I think it would be since it lasted in mainline this long. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1856608 Title: [Regression] usb usb2-port2: Cannot enable. Maybe the USB cable is bad? Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Status in linux source package in Focal: Confirmed Bug description: This appears to be a regression between 4.15.0-70.79 and 4.15.0-72.81. This bug was fixed by simply reverting the offending change. Bug 1859873 tracks root causing the issue and reapplying the change w/ any necessary fixes. [Impact] USB port unusable and boot time takes ~5 minutes longer to complete. Kernel emits messages like: usb usb2-port2: Cannot enable. Maybe the USB cable is bad? [Test Case] dmesg | grep "Cannot enable" [Fix] [Regression Risk] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856608/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 1856608] Re: [Regression] usb usb2-port2: Cannot enable. Maybe the USB cable is bad?
@dannf: Yes, this bug sure is a tricky one. Most of these reports will be due to failing / faulty / non-spec complaint USB devices or cables, like the original reason for this bug being opened. Although, there have been some reports where user's systems do go back to working when they install my test kernel which reverts "usb: handle warm-reset port requests on hub resume". When we wrote to the USB subsystem maintainer last year about the commit, they were pretty sure the commit worked as intended and that the USB device itself was malfunctioning. The commit is also in all of the upstream -stable kernels, in mainline, with no changes since when it was introduced. Which means that it works for the vast majority of users, and only fails for a very small minority of users. We don't want to deviate from mainline by reverting patches we don't need to. I suppose we could ask affected users for a debug trace of the USB subsystem during a boot, or plugging in a device which causes these messages, and start building a case against "usb: handle warm-reset port requests on hub resume", but at the same time, these errors could be due to failing hardware, and we don't have too many ways of figuring that out, especially if it happens to be a root hub that breaks. It's tricky. We might have to read the USB spec again to see if "usb: handle warm-reset port requests on hub resume" is complaint, but I think it would be since it lasted in mainline this long. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1856608 Title: [Regression] usb usb2-port2: Cannot enable. Maybe the USB cable is bad? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856608/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1924759] Re: accessing cifs DFS mount fails after updating to 5.4.0-71-generic
*** This bug is a duplicate of bug 1923670 *** https://bugs.launchpad.net/bugs/1923670 Hi Kjell, Thanks for reporting the issue! We have been tracking it in bug 1923670. We found the root cause, and we have commit a fix to the source code tree. This will be fixed in the next kernel update hopefully. Thanks, Matthew ** This bug has been marked a duplicate of bug 1923670 CIFS DFS entries not accessible with 5.4.0-71.74-generic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924759 Title: accessing cifs DFS mount fails after updating to 5.4.0-71-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1924759/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 1924759] Re: accessing cifs DFS mount fails after updating to 5.4.0-71-generic
*** This bug is a duplicate of bug 1923670 *** https://bugs.launchpad.net/bugs/1923670 Hi Kjell, Thanks for reporting the issue! We have been tracking it in bug 1923670. We found the root cause, and we have commit a fix to the source code tree. This will be fixed in the next kernel update hopefully. Thanks, Matthew ** This bug has been marked a duplicate of bug 1923670 CIFS DFS entries not accessible with 5.4.0-71.74-generic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1924759 Title: accessing cifs DFS mount fails after updating to 5.4.0-71-generic Status in linux-signed package in Ubuntu: New Bug description: On focal, after updating to 5.4.0-71-generic kernel and modules, I cannot access a CIFS DFS share anymore. # mount -t cifs -o iocharset=utf8,user=username,dom=domain '\\winfs.redacted.corp\WINFS' /mnt # ls -l /mnt/dir/DFS_SHARE/subdir ls: cannot access '/mnt/dir/DFS_SHARE/subdir': No such file or directory The same process reliably works on 5.4.0-70-generic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1924759/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 1923670] Re: CIFS DFS entries not accessible with 5.4.0-71.74-generic
Thanks Tim for building the test kernel, and Hmpf, thanks for testing it and confirming it fixes the problem. Okay, so the problem is: commit a738c93fb1c17e386a09304b517b1c6b2a6a5a8b Author: Shyam Prasad N Date: Thu Feb 11 03:26:54 2021 -0800 Subject: cifs: Set CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath. Link: https://github.com/torvalds/linux/commit/a738c93fb1c17e386a09304b517b1c6b2a6a5a8b Looking at Focal, it seems Tim has submitted the revert and it has been applied for the next kernel update: https://lists.ubuntu.com/archives/kernel-team/2021-April/119241.html https://lists.ubuntu.com/archives/kernel-team/2021-April/119242.html https://lists.ubuntu.com/archives/kernel-team/2021-April/119243.html https://lists.ubuntu.com/archives/kernel-team/2021-April/119244.html https://lists.ubuntu.com/archives/kernel-team/2021-April/119246.html Thanks Tim! As for Bionic, it seems to still be applied to master-next, and hasn't been tagged into a release yet: https://paste.ubuntu.com/p/k9SffBrBMb/ Groovy seems to be in the same situation: https://paste.ubuntu.com/p/wRX79WKpy3/ Tim, are there any plans to get the revert landed in Bionic and Groovy for this cycle? I really don't want cause any regressions if we can avoid it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1923670 Title: CIFS DFS entries not accessible with 5.4.0-71.74-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1923670/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 1923670] Re: CIFS DFS entries not accessible with 5.4.0-71.74-generic
Thanks Tim for building the test kernel, and Hmpf, thanks for testing it and confirming it fixes the problem. Okay, so the problem is: commit a738c93fb1c17e386a09304b517b1c6b2a6a5a8b Author: Shyam Prasad N Date: Thu Feb 11 03:26:54 2021 -0800 Subject: cifs: Set CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath. Link: https://github.com/torvalds/linux/commit/a738c93fb1c17e386a09304b517b1c6b2a6a5a8b Looking at Focal, it seems Tim has submitted the revert and it has been applied for the next kernel update: https://lists.ubuntu.com/archives/kernel-team/2021-April/119241.html https://lists.ubuntu.com/archives/kernel-team/2021-April/119242.html https://lists.ubuntu.com/archives/kernel-team/2021-April/119243.html https://lists.ubuntu.com/archives/kernel-team/2021-April/119244.html https://lists.ubuntu.com/archives/kernel-team/2021-April/119246.html Thanks Tim! As for Bionic, it seems to still be applied to master-next, and hasn't been tagged into a release yet: https://paste.ubuntu.com/p/k9SffBrBMb/ Groovy seems to be in the same situation: https://paste.ubuntu.com/p/wRX79WKpy3/ Tim, are there any plans to get the revert landed in Bionic and Groovy for this cycle? I really don't want cause any regressions if we can avoid it. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1923670 Title: CIFS DFS entries not accessible with 5.4.0-71.74-generic Status in linux package in Ubuntu: Confirmed Status in linux source package in Focal: Fix Committed Bug description: When booting 5.4.0-71-generic I can not access DFS entries anymore, with 5.4.0-70-generic this still works. Some details: fstab entry: //example.com/public /home/user/remotecifs noauto,vers=default,noserverino,users,_netdev,user=remote_user,domain=example.com 00 shell session ~$ mount /home/user/remote Password for remote_user@//example.com/public: ~$ ls /home/user/remote/dfs-folder dfs-subfolder dfs-entry ~$ ls /home/user/remote/dfs-folder/dfs-entry ls: cannot access '/home/user/remote/dfs-folder/dfs-entry': No such file or directory dmesg excerpt [ 1219.568778] CIFS: Attempting to mount //DC01.example.com/Public/dfs-folder/dfs-entry [ 1219.584975] FS-Cache: Duplicate cookie detected [ 1219.584986] FS-Cache: O-cookie c=6e995395 [p=f4725c61 fl=222 nc=0 na=1] [ 1219.584990] FS-Cache: O-cookie d=a11c1428 n=71ab21ba [ 1219.584993] FS-Cache: O-key=[6] '5075626c6963' [ 1219.585001] FS-Cache: N-cookie c=a0608786 [p=f4725c61 fl=2 nc=0 na=1] [ 1219.585004] FS-Cache: N-cookie d=a11c1428 n=901f6a53 [ 1219.585007] FS-Cache: N-key=[6] '5075626c6963' [ 1219.725834] FS-Cache: Duplicate cookie detected [ 1219.725847] FS-Cache: O-cookie c=6e995395 [p=f4725c61 fl=222 nc=0 na=1] [ 1219.725851] FS-Cache: O-cookie d=a11c1428 n=71ab21ba [ 1219.725854] FS-Cache: O-key=[6] '5075626c6963' [ 1219.725864] FS-Cache: N-cookie c=0509709f [p=f4725c61 fl=2 nc=0 na=1] [ 1219.725868] FS-Cache: N-cookie d=a11c1428 n=556f158b [ 1219.725870] FS-Cache: N-key=[6] '5075626c6963' [ 1220.216524] CIFS VFS: cifs_read_super: get root inode failed The dmesg from 5.4.0-70-generic does not have the line CIFS VFS: cifs_read_super: get root inode failed ~$ lsb_release -rd Description:KDE neon User Edition 5.21 Release: ~$ lsb_release -rd Description:KDE neon User Edition 5.21 Release:20.04 20.04 ~$ apt-cache policy linux-image-generic linux-image-generic: Installed: 5.4.0.71.74 Candidate: 5.4.0.71.74 Version table: *** 5.4.0.71.74 500 500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 5.4.0.26.32 500 500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.16 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: dirk 2946 F pulseaudio /dev/snd/controlC1: dirk 2946 F pulseaudio /dev/snd/controlC0: dirk 2946 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: KDE DistroRelease: KDE neon 20.04 InstallationDate: Installed on 2017-07-27 (1356 days ago) InstallationMedia: neon userlts "Xenial" - Build amd64 LIVE Binary 20170614-00:52 MachineType: LENOVO 20HMS00T00 Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-71-generic root=/dev/mapper/vg00-lv_root ro intel_iommu=off ProcVersionSignature: Ubuntu 5.4.0-71.79-generic 5.4.101 RelatedPackageVersions: linux-restricted-modules-5.4.0-71-generic N/A
[Bug 1923670] Re: CIFS DFS entries not accessible with 5.4.0-71.74-generic
Hi @Hmpf,
Thanks for filing a bug report.
I had a look at the changes between 5.4.0-70-generic and
5.4.0-71-generic, and I found three patches for CIFS:
$ git log --grep "cifs" Ubuntu-5.4.0-70.78..Ubuntu-5.4.0-71.79
https://paste.ubuntu.com/p/YgrZcN8B6j/
I had a read of the patches, and I think that this one is causing
problems for you.
commit 21b200d091826a83aafc95d847139b2b0582f6d1
Author: Aurelien Aptel
Date: Fri Feb 5 15:42:48 2021 +0100
Subject: cifs: report error instead of invalid when revalidating a dentry fails
Link:
https://github.com/torvalds/linux/commit/21b200d091826a83aafc95d847139b2b0582f6d1
This was backported to 5.4.0-71-generic through upstream stable in the
below patch:
https://paste.ubuntu.com/p/8FWhRNr8KW/
Now, I think it is that commit due to the error message you are seeing:
CIFS VFS: cifs_read_super: get root inode failed
The commit changes how errors are passed back to the VFS. What it did
before was just return 0 (invalid) on any error at all, when
cifs_revalidate_dentry() failed.
What it does now is send 0 on ENOENT and ESTALE, and the actual error
number on any other error. I think you are getting an "other" error, and
cifs isn't sure what to do with it.
Now, looking at cifs_read_super(), where the error message came from:
150 static int
151 cifs_read_super(struct super_block *sb)
152 {
...
205 rc = super_setup_bdi(sb);
206 if (rc)
207 goto out_no_root;
...
213 inode = cifs_root_iget(sb);
214
215 if (IS_ERR(inode)) {
216 rc = PTR_ERR(inode);
217 goto out_no_root;
218 }
...
225 sb->s_root = d_make_root(inode);
226 if (!sb->s_root) {
227 rc = -ENOMEM;
228 goto out_no_root;
229 }
...
240 out_no_root:
241 cifs_dbg(VFS, "%s: get root inode failed\n", __func__);
242 return rc;
243 }
We see the out_no_root label is really just a catch-all error handler, and
doesn't really tell us what happened, or try to handle the error.
Looking at the code added by the commit, it added a new debug string:
737 static int
738 cifs_d_revalidate(struct dentry *direntry, unsigned int flags)
739 {
...
751 rc = cifs_revalidate_dentry(direntry);
752 if (rc) {
753 cifs_dbg(FYI, "cifs_revalidate_dentry failed with rc=%d", rc);
We can use this string to see what the actual error is, but it is turned
off by default, which is why it doesn't appear in dmesg.
Would you be able to turn on this extra error message so we can keep
helping you to figure out what is happening?
You can turn on extra debugging with instruction from:
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
1) sudo -s
2) echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control
3) echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control
4) echo 7 > /proc/fs/cifs/cifsFYI
5) exit
Then, try your mount command and then try ls on that dentry file.
If you check dmesg, you will get much more logging. What we are
interested in will be a line with "cifs_revalidate_dentry failed with
rc" and then an error number.
We can then look up what the number is, and try go from there.
The easiest way to turn off the extra debug logging is to reboot your
system. Or you can run:
1) sudo -s
2) echo 0 > /proc/fs/cifs/cifsFYI
3) exit
But rebooting is probably easier for you.
Attach your new dmesg to the launchpad bug, and I will have a look. You
might want to remove the URL of your company cifs share and any
usernames before you upload.
Let me know if you have any questions.
Thanks,
Matthew
** Tags added: seg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923670
Title:
CIFS DFS entries not accessible with 5.4.0-71.74-generic
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1923670/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 1923670] Re: CIFS DFS entries not accessible with 5.4.0-71.74-generic
Hi @Hmpf,
Thanks for filing a bug report.
I had a look at the changes between 5.4.0-70-generic and
5.4.0-71-generic, and I found three patches for CIFS:
$ git log --grep "cifs" Ubuntu-5.4.0-70.78..Ubuntu-5.4.0-71.79
https://paste.ubuntu.com/p/YgrZcN8B6j/
I had a read of the patches, and I think that this one is causing
problems for you.
commit 21b200d091826a83aafc95d847139b2b0582f6d1
Author: Aurelien Aptel
Date: Fri Feb 5 15:42:48 2021 +0100
Subject: cifs: report error instead of invalid when revalidating a dentry fails
Link:
https://github.com/torvalds/linux/commit/21b200d091826a83aafc95d847139b2b0582f6d1
This was backported to 5.4.0-71-generic through upstream stable in the
below patch:
https://paste.ubuntu.com/p/8FWhRNr8KW/
Now, I think it is that commit due to the error message you are seeing:
CIFS VFS: cifs_read_super: get root inode failed
The commit changes how errors are passed back to the VFS. What it did
before was just return 0 (invalid) on any error at all, when
cifs_revalidate_dentry() failed.
What it does now is send 0 on ENOENT and ESTALE, and the actual error
number on any other error. I think you are getting an "other" error, and
cifs isn't sure what to do with it.
Now, looking at cifs_read_super(), where the error message came from:
150 static int
151 cifs_read_super(struct super_block *sb)
152 {
...
205 rc = super_setup_bdi(sb);
206 if (rc)
207 goto out_no_root;
...
213 inode = cifs_root_iget(sb);
214
215 if (IS_ERR(inode)) {
216 rc = PTR_ERR(inode);
217 goto out_no_root;
218 }
...
225 sb->s_root = d_make_root(inode);
226 if (!sb->s_root) {
227 rc = -ENOMEM;
228 goto out_no_root;
229 }
...
240 out_no_root:
241 cifs_dbg(VFS, "%s: get root inode failed\n", __func__);
242 return rc;
243 }
We see the out_no_root label is really just a catch-all error handler, and
doesn't really tell us what happened, or try to handle the error.
Looking at the code added by the commit, it added a new debug string:
737 static int
738 cifs_d_revalidate(struct dentry *direntry, unsigned int flags)
739 {
...
751 rc = cifs_revalidate_dentry(direntry);
752 if (rc) {
753 cifs_dbg(FYI, "cifs_revalidate_dentry failed with rc=%d", rc);
We can use this string to see what the actual error is, but it is turned
off by default, which is why it doesn't appear in dmesg.
Would you be able to turn on this extra error message so we can keep
helping you to figure out what is happening?
You can turn on extra debugging with instruction from:
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
1) sudo -s
2) echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control
3) echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control
4) echo 7 > /proc/fs/cifs/cifsFYI
5) exit
Then, try your mount command and then try ls on that dentry file.
If you check dmesg, you will get much more logging. What we are
interested in will be a line with "cifs_revalidate_dentry failed with
rc" and then an error number.
We can then look up what the number is, and try go from there.
The easiest way to turn off the extra debug logging is to reboot your
system. Or you can run:
1) sudo -s
2) echo 0 > /proc/fs/cifs/cifsFYI
3) exit
But rebooting is probably easier for you.
Attach your new dmesg to the launchpad bug, and I will have a look. You
might want to remove the URL of your company cifs share and any
usernames before you upload.
Let me know if you have any questions.
Thanks,
Matthew
** Tags added: seg
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1923670
Title:
CIFS DFS entries not accessible with 5.4.0-71.74-generic
Status in linux package in Ubuntu:
Confirmed
Bug description:
When booting 5.4.0-71-generic I can not access DFS entries anymore,
with 5.4.0-70-generic this still works. Some details:
fstab entry:
//example.com/public /home/user/remotecifs
noauto,vers=default,noserverino,users,_netdev,user=remote_user,domain=example.com
00
shell session
~$ mount /home/user/remote
Password for remote_user@//example.com/public:
~$ ls /home/user/remote/dfs-folder
dfs-subfolder dfs-entry
~$ ls /home/user/remote/dfs-folder/dfs-entry
ls: cannot access '/home/user/remote/dfs-folder/dfs-entry': No such file or
directory
dmesg excerpt
[ 1219.568778] CIFS: Attempting to mount
//DC01.example.com/Public/dfs-folder/dfs-entry
[ 1219.584975] FS-Cache: Duplicate cookie detected
[ 1219.584986] FS-Cache: O-cookie c=6e995395 [p=f4725c61
fl=222 nc=0 na=1]
[ 1219.584990] FS-Cache: O-cookie d=a11c1428 n=71ab21ba
[ 1219.584993] FS-Cache: O-key=[6] '5075626c6963'
[ 1219.585001] FS-Cache: N-cookie c=a0608786 [p=f4725c61 fl=2
nc=0 na=1]
[ 1219.585004] FS-Cache: N-cookie
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Attached is a debdiff for Hirsute which re-applies "screen: Use clean env when creating new tab" and is the same patch in the PPA. ** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? [Testcase] 1. Launch Nautilus to home directory 2. Right click > "Open in Terminal" 3. Run "printenv" to see full list of env variables 4. Click new tab button, or ctrl-shift-t 5. Run "printenv" see the lack of env variables I have a test package available in the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac reverted. If you install this package, environment variables will be set correctly. [Where problems could occur] I think there is some risk with re-instating a commit which has been reverted, and users could run into similar issues as found in the upstream bug. We do have some supporting evidence that the commit isn't too harmful, since it is applied to Groovy currently, things work as intended there, and users haven't complained about the issues in the upstream bug applying to Groovy. If a regression were to occur, then launching a new gnome-terminal or opening a new tab could land the user with a terminal with little to no environment variables set. A workaround will be to launch gnome-terminal from gnome-shell overview. [Other info] - Groovy has the following commit applied: + Focal and Groovy have the following commit applied: commit fd5ac772154426e2da5afd633b336414bca33be9 Author: Christian Persch Date: Mon Mar 23 09:57:56 2020 +0100 Subject: screen: Use clean env when creating new tab Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/fd5ac772154426e2da5afd633b336414bca33be9 This was then reverted in 3.38.1 due to the upstream bug: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 The reverted commit is: commit 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac Author: Christian Persch Date: Thu Sep 17 17:10:47 2020 +0200 Subject: Revert "screen: Use clean env when creating new tab" Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac - This revert seems to have broken Hirsute. If we revert the revert, that is, - apply the commit again, things work as intended. + This revert seems to have broken Hirsute. If we revert the revert, that + is, apply the commit again, things work as intended. To fix this, we need to revert 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac. ** Patch added: "gnome-terminal debdiff for hirsute" https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+attachment/5487098/+files/lp1922839_hirsute.debdiff ** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? [Testcase] 1. Launch Nautilus to home directory 2. Right click > "Open in Terminal" 3. Run "printenv" to see full list of env variables 4. Click new tab button, or ctrl-shift-t 5. Run "printenv" see the lack of env variables I have a test package available in the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac reverted.
[Desktop-packages] [Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Attached is a debdiff for Hirsute which re-applies "screen: Use clean env when creating new tab" and is the same patch in the PPA. ** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? [Testcase] 1. Launch Nautilus to home directory 2. Right click > "Open in Terminal" 3. Run "printenv" to see full list of env variables 4. Click new tab button, or ctrl-shift-t 5. Run "printenv" see the lack of env variables I have a test package available in the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac reverted. If you install this package, environment variables will be set correctly. [Where problems could occur] I think there is some risk with re-instating a commit which has been reverted, and users could run into similar issues as found in the upstream bug. We do have some supporting evidence that the commit isn't too harmful, since it is applied to Groovy currently, things work as intended there, and users haven't complained about the issues in the upstream bug applying to Groovy. If a regression were to occur, then launching a new gnome-terminal or opening a new tab could land the user with a terminal with little to no environment variables set. A workaround will be to launch gnome-terminal from gnome-shell overview. [Other info] - Groovy has the following commit applied: + Focal and Groovy have the following commit applied: commit fd5ac772154426e2da5afd633b336414bca33be9 Author: Christian Persch Date: Mon Mar 23 09:57:56 2020 +0100 Subject: screen: Use clean env when creating new tab Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/fd5ac772154426e2da5afd633b336414bca33be9 This was then reverted in 3.38.1 due to the upstream bug: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 The reverted commit is: commit 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac Author: Christian Persch Date: Thu Sep 17 17:10:47 2020 +0200 Subject: Revert "screen: Use clean env when creating new tab" Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac - This revert seems to have broken Hirsute. If we revert the revert, that is, - apply the commit again, things work as intended. + This revert seems to have broken Hirsute. If we revert the revert, that + is, apply the commit again, things work as intended. To fix this, we need to revert 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac. ** Patch added: "gnome-terminal debdiff for hirsute" https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+attachment/5487098/+files/lp1922839_hirsute.debdiff ** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? [Testcase] 1. Launch Nautilus to home directory 2. Right click > "Open in Terminal" 3. Run "printenv" to see full list of env variables 4. Click new tab button, or ctrl-shift-t 5. Run "printenv" see the lack of env variables I have a test package available in the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac reverted.
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Attached is a debdiff for Hirsute which re-applies "screen: Use clean env when creating new tab" and is the same patch in the PPA. ** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? [Testcase] 1. Launch Nautilus to home directory 2. Right click > "Open in Terminal" 3. Run "printenv" to see full list of env variables 4. Click new tab button, or ctrl-shift-t 5. Run "printenv" see the lack of env variables I have a test package available in the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac reverted. If you install this package, environment variables will be set correctly. [Where problems could occur] I think there is some risk with re-instating a commit which has been reverted, and users could run into similar issues as found in the upstream bug. We do have some supporting evidence that the commit isn't too harmful, since it is applied to Groovy currently, things work as intended there, and users haven't complained about the issues in the upstream bug applying to Groovy. If a regression were to occur, then launching a new gnome-terminal or opening a new tab could land the user with a terminal with little to no environment variables set. A workaround will be to launch gnome-terminal from gnome-shell overview. [Other info] - Groovy has the following commit applied: + Focal and Groovy have the following commit applied: commit fd5ac772154426e2da5afd633b336414bca33be9 Author: Christian Persch Date: Mon Mar 23 09:57:56 2020 +0100 Subject: screen: Use clean env when creating new tab Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/fd5ac772154426e2da5afd633b336414bca33be9 This was then reverted in 3.38.1 due to the upstream bug: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 The reverted commit is: commit 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac Author: Christian Persch Date: Thu Sep 17 17:10:47 2020 +0200 Subject: Revert "screen: Use clean env when creating new tab" Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac - This revert seems to have broken Hirsute. If we revert the revert, that is, - apply the commit again, things work as intended. + This revert seems to have broken Hirsute. If we revert the revert, that + is, apply the commit again, things work as intended. To fix this, we need to revert 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac. ** Patch added: "gnome-terminal debdiff for hirsute" https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+attachment/5487098/+files/lp1922839_hirsute.debdiff ** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? [Testcase] 1. Launch Nautilus to home directory 2. Right click > "Open in Terminal" 3. Run "printenv" to see full list of env variables 4. Click new tab button, or ctrl-shift-t 5. Run "printenv" see the lack of env variables I have a test package available in the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac reverted.
[Desktop-packages] [Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? + + [Testcase] + + 1. Launch Nautilus to home directory + 2. Right click > "Open in Terminal" + 3. Run "printenv" to see full list of env variables + 4. Click new tab button, or ctrl-shift-t + 5. Run "printenv" see the lack of env variables + + I have a test package available in the below ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test + + The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + reverted. + + If you install this package, environment variables will be set + correctly. + + [Where problems could occur] + + I think there is some risk with re-instating a commit which has been + reverted, and users could run into similar issues as found in the + upstream bug. + + We do have some supporting evidence that the commit isn't too harmful, + since it is applied to Groovy currently, things work as intended there, + and users haven't complained about the issues in the upstream bug + applying to Groovy. + + If a regression were to occur, then launching a new gnome-terminal or + opening a new tab could land the user with a terminal with little to no + environment variables set. A workaround will be to launch gnome-terminal + from gnome-shell overview. + + [Other info] + + Groovy has the following commit applied: + + commit fd5ac772154426e2da5afd633b336414bca33be9 + Author: Christian Persch + Date: Mon Mar 23 09:57:56 2020 +0100 + Subject: screen: Use clean env when creating new tab + Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/fd5ac772154426e2da5afd633b336414bca33be9 + + This was then reverted in 3.38.1 due to the upstream bug: + + https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 + + The reverted commit is: + + commit 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + Author: Christian Persch + Date: Thu Sep 17 17:10:47 2020 +0200 + Subject: Revert "screen: Use clean env when creating new tab" + Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + + This revert seems to have broken Hirsute. If we revert the revert, that is, + apply the commit again, things work as intended. + + To fix this, we need to revert 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables Status in gnome-terminal package in Ubuntu: New Status in gnome-terminal source package in Hirsute: New Bug description: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? [Testcase] 1. Launch Nautilus to home directory 2. Right click > "Open in Terminal" 3. Run "printenv" to see full list of env variables 4. Click new tab button, or ctrl-shift-t 5. Run "printenv" see the lack of env variables I have a test package available in the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac reverted. If you install this package, environment variables will be set correctly. [Where problems could occur] I think there is some risk
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? + + [Testcase] + + 1. Launch Nautilus to home directory + 2. Right click > "Open in Terminal" + 3. Run "printenv" to see full list of env variables + 4. Click new tab button, or ctrl-shift-t + 5. Run "printenv" see the lack of env variables + + I have a test package available in the below ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test + + The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + reverted. + + If you install this package, environment variables will be set + correctly. + + [Where problems could occur] + + I think there is some risk with re-instating a commit which has been + reverted, and users could run into similar issues as found in the + upstream bug. + + We do have some supporting evidence that the commit isn't too harmful, + since it is applied to Groovy currently, things work as intended there, + and users haven't complained about the issues in the upstream bug + applying to Groovy. + + If a regression were to occur, then launching a new gnome-terminal or + opening a new tab could land the user with a terminal with little to no + environment variables set. A workaround will be to launch gnome-terminal + from gnome-shell overview. + + [Other info] + + Groovy has the following commit applied: + + commit fd5ac772154426e2da5afd633b336414bca33be9 + Author: Christian Persch + Date: Mon Mar 23 09:57:56 2020 +0100 + Subject: screen: Use clean env when creating new tab + Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/fd5ac772154426e2da5afd633b336414bca33be9 + + This was then reverted in 3.38.1 due to the upstream bug: + + https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 + + The reverted commit is: + + commit 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + Author: Christian Persch + Date: Thu Sep 17 17:10:47 2020 +0200 + Subject: Revert "screen: Use clean env when creating new tab" + Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + + This revert seems to have broken Hirsute. If we revert the revert, that is, + apply the commit again, things work as intended. + + To fix this, we need to revert 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
** Description changed: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? + + [Testcase] + + 1. Launch Nautilus to home directory + 2. Right click > "Open in Terminal" + 3. Run "printenv" to see full list of env variables + 4. Click new tab button, or ctrl-shift-t + 5. Run "printenv" see the lack of env variables + + I have a test package available in the below ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/lp1922839-test + + The build in the ppa has 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + reverted. + + If you install this package, environment variables will be set + correctly. + + [Where problems could occur] + + I think there is some risk with re-instating a commit which has been + reverted, and users could run into similar issues as found in the + upstream bug. + + We do have some supporting evidence that the commit isn't too harmful, + since it is applied to Groovy currently, things work as intended there, + and users haven't complained about the issues in the upstream bug + applying to Groovy. + + If a regression were to occur, then launching a new gnome-terminal or + opening a new tab could land the user with a terminal with little to no + environment variables set. A workaround will be to launch gnome-terminal + from gnome-shell overview. + + [Other info] + + Groovy has the following commit applied: + + commit fd5ac772154426e2da5afd633b336414bca33be9 + Author: Christian Persch + Date: Mon Mar 23 09:57:56 2020 +0100 + Subject: screen: Use clean env when creating new tab + Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/fd5ac772154426e2da5afd633b336414bca33be9 + + This was then reverted in 3.38.1 due to the upstream bug: + + https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 + + The reverted commit is: + + commit 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + Author: Christian Persch + Date: Thu Sep 17 17:10:47 2020 +0200 + Subject: Revert "screen: Use clean env when creating new tab" + Link: https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac + + This revert seems to have broken Hirsute. If we revert the revert, that is, + apply the commit again, things work as intended. + + To fix this, we need to revert 16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Desktop-packages] [Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
It seems the revert for "screen: Use clean env when creating new tab" is already in 3.38.1, and I checked the Ubuntu source package, and the revert is in place. https://gitlab.gnome.org/GNOME/gnome- terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac Interesting. I might try a test build which reverts the revert and see how that goes, since that matches the case on Groovy. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables Status in gnome-terminal package in Ubuntu: New Status in gnome-terminal source package in Hirsute: New Bug description: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
It seems the revert for "screen: Use clean env when creating new tab" is already in 3.38.1, and I checked the Ubuntu source package, and the revert is in place. https://gitlab.gnome.org/GNOME/gnome- terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac Interesting. I might try a test build which reverts the revert and see how that goes, since that matches the case on Groovy. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
It seems the revert for "screen: Use clean env when creating new tab" is already in 3.38.1, and I checked the Ubuntu source package, and the revert is in place. https://gitlab.gnome.org/GNOME/gnome- terminal/-/commit/16bd9f6a4181d37af2769e7ca5a1f9a1211cfaac Interesting. I might try a test build which reverts the revert and see how that goes, since that matches the case on Groovy. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1921104] Re: net/mlx5e: Add missing capability check for uplink follow
** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921104 Title: net/mlx5e: Add missing capability check for uplink follow To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1921104/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 1921104] Re: net/mlx5e: Add missing capability check for uplink follow
** Tags added: sts -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1921104 Title: net/mlx5e: Add missing capability check for uplink follow Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Fix Released Status in linux source package in Focal: Fix Committed Status in linux source package in Groovy: Fix Committed Status in linux source package in Hirsute: Fix Released Bug description: SRU Justification: == [Impact] * Since older firmware may not support the uplink state setting, this can lead to problems. * Now expose firmware indication that it supports setting eswitch uplink state to follow the physical link. * If a kernel without the backport is used on an adapter which does not have the latest adapter firmware, the adapter silently drops outgoing traffic. * This is a regression which was introduced with kernel 5.4.0-48. [Fix] * upstream fix (as in 5.11): 9c9be85f6b59d80efe4705109c0396df18d4e11d 9c9be85f6b59 "net/mlx5e: Add missing capability check for uplink follow" * backport for focal: https://launchpadlibrarian.net/529543695/0001 -Backport-net-mlx5e-Add-missing-capability-check-for-.patch * backport for groovy: https://launchpadlibrarian.net/529775887/0001 -Backport-groovy-net-mlx5e-Add-missing-capability-che.patch [Test Case] * Two IBM Z or LinuxONE systems, installed with Ubuntu Server 20.04 or 20.10 on LPAR, are needed. * Each with RoCE Express 2.x adapters (Mellanox ConnectX4/5) attached and firmware 16.29.1006 or earlier. * Assign an IP address to the adapters on both systems and try to ping one node from the other. * The ping will just fail with the stock Ubuntu kernels (not having the patch), but will succeed with kernels that incl. the patches (like the test builds from the PPA mentioned below). * Due to the lack of hardware this needs to be verified by IBM. [Regression Potential] * Undesired / erroneous behavior in case the modified if condition is assembled in a wrong way. * Again wrong behavior in case the modification of the capability bits in mlx5_ifc_cmd_hca_cap_bits are wrong. * All modification are limited to the mlx5 driver only. * The changes are relatively limited with effectively two lines removed and 4 added (three of them adjustments of the capability bits only). * The modifications were done and tested by IBM and reviewed by Mellanox (see LP comments), based on a PPA test build. [Other] * The above patch/commit was upstream accepted with kernel 5.11. * Hence the patch is not needed for hirsute, just needs to be SRUed for groovy and focal. * The commit couldn't be cleanly cherry-picked, mainly due to changed context, hence the backport(s). __ Expose firmware indication that it supports setting eswitch uplink state to follow (follow the physical link). Condition setting the eswitch uplink admin-state with this capability bit. Older FW may not support the uplink state setting. Available fix with kernel 5.11. https://github.com/torvalds/linux/commit/9c9be85f6b59d80efe4705109c0396df18d4e11d Now required for Ubuntu 20.04 via backport patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1921104/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1838152] Re: gnome-shell freezes on notification arrival (fixed upstream)
Performing verification for Bionic. I want to say straight up, I haven't been able to reproduce the problem, I have tried many mechanisms, but I can not reproduce the 20 second shell hang and crash, as documented in https://github.com/GSConnect /gnome-shell-extension-gsconnect/issues/549#issuecomment-515679156 I first tried to reproduce the problem using gnome-shell 3.28.4-0ubuntu18.04.3 from -updates. I have tried the following in both KVM and on physical hardware of a Lenovo Thinkpad X1 Laptop. I installed the "TeaTime" gnome-shell extension version 28 from https://extensions.gnome.org/extension/604/teatime/ and used it to send multiple notifications that arrive in 5 second delays. The hang never occured. I tried creating a draft email in evolution as suggested in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/470, and ctrl- clicked the link to spawn firefox with a notification. I did this several times, no hangs. I then tried the calendar feature in Evolution to send a notification on a new event in 5 minutes time. I did this multiple times, and never got any hangs. https://bugzilla.redhat.com/show_bug.cgi?id=1575281 I installed the gsconnect gnome-shell extension https://extensions.gnome.org/extension/1319/gsconnect/ and paired it to my android phone running the kdeconnect app. In the settings menu on the android app, there is a "send ping" button. Press that and a notification is spawned in gnome-shell. I clicked this many times, and tried clearing notifications and being in various apps, or trying to race notifications and still could not get a hang. Reading the commits, the gnome-shell hang is caused by fsync() being called from a main thread on persistent gnome-shell state files. I found the gnome-shell pid, and attached strace like so: $ sudo strace -e fsync -p On 3.28.4-0ubuntu18.04.3 each time I pressed "Send Ping" from kdeconnect, a line is printed with: fsync(38) 0 suggesting that fsync is called every time a notification comes in. I then enabled -proposed and installed gnome-shell 3.28.4-0ubuntu18.04.7 I retried all my initial tests, and everything worked and did not hang. When it came to running strace against gnome-shell to view fsync calls, I noticed that fsync was no longer being called each time I pressed "Send Ping", meaning it is no longer happening per notification arrival. I clicked the clock icon to see all notifications, and a large amount of fsync calls appeared in strace output all at once, suggesting that they were put on pause and batched all at once. I can see the behaviour change that 86a00b6 and 19e0840 has had on fsync behaviour, so the commits are doing what they say. In my testing, I did not see any harm caused by these commits, as notifications still arrived as usual. Again, I could not reproduce the original report of a 20 second hang, but the new package in -proposed appears to do no harm from the testing I have undertaken. I talked to Marco about this bug, and we agreed it is okay to mark as verified. So, with some hesitation, I will mark this bug as verified. ** Bug watch added: github.com/GSConnect/gnome-shell-extension-gsconnect/issues #549 https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/549 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-shell/-/issues #470 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/470 ** Bug watch added: Red Hat Bugzilla #1575281 https://bugzilla.redhat.com/show_bug.cgi?id=1575281 ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1838152 Title: gnome-shell freezes on notification arrival (fixed upstream) Status in GNOME Shell: Fix Released Status in gnome-shell package in Ubuntu: Fix Released Status in gnome-shell source package in Bionic: Fix Committed Status in gnome-shell source package in Disco: Fix Released Status in gnome-shell source package in Eoan: Fix Released Bug description: [ Description ] Sometimes certain notifications make the desktop unresponsive for a few seconds and then gnome-shell crashes and all extensions are reloaded. [ Test case ] Install gsconnect extension in gnome-shell: https://extensions.gnome.org/extension/1319/gsconnect/ - Start Up system - first Notification from connected device - Hangs for about 20 sec + This should not happen [ Regression potential ] Persistent state is not kept, although the patch is living upstream for many cycles already, so it's pretty safe. - I have found an upstream bug with a patch, but it's probably not in the Ubuntu's package. I thought of creating an issue in case it is something not known. https://gitlab.gnome.org/GNOME/gnome-shell/issues/470 https://gitlab.gnome.org/GNOME/gnome-
[Bug 1838152] Re: gnome-shell freezes on notification arrival (fixed upstream)
Performing verification for Bionic. I want to say straight up, I haven't been able to reproduce the problem, I have tried many mechanisms, but I can not reproduce the 20 second shell hang and crash, as documented in https://github.com/GSConnect /gnome-shell-extension-gsconnect/issues/549#issuecomment-515679156 I first tried to reproduce the problem using gnome-shell 3.28.4-0ubuntu18.04.3 from -updates. I have tried the following in both KVM and on physical hardware of a Lenovo Thinkpad X1 Laptop. I installed the "TeaTime" gnome-shell extension version 28 from https://extensions.gnome.org/extension/604/teatime/ and used it to send multiple notifications that arrive in 5 second delays. The hang never occured. I tried creating a draft email in evolution as suggested in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/470, and ctrl- clicked the link to spawn firefox with a notification. I did this several times, no hangs. I then tried the calendar feature in Evolution to send a notification on a new event in 5 minutes time. I did this multiple times, and never got any hangs. https://bugzilla.redhat.com/show_bug.cgi?id=1575281 I installed the gsconnect gnome-shell extension https://extensions.gnome.org/extension/1319/gsconnect/ and paired it to my android phone running the kdeconnect app. In the settings menu on the android app, there is a "send ping" button. Press that and a notification is spawned in gnome-shell. I clicked this many times, and tried clearing notifications and being in various apps, or trying to race notifications and still could not get a hang. Reading the commits, the gnome-shell hang is caused by fsync() being called from a main thread on persistent gnome-shell state files. I found the gnome-shell pid, and attached strace like so: $ sudo strace -e fsync -p On 3.28.4-0ubuntu18.04.3 each time I pressed "Send Ping" from kdeconnect, a line is printed with: fsync(38) 0 suggesting that fsync is called every time a notification comes in. I then enabled -proposed and installed gnome-shell 3.28.4-0ubuntu18.04.7 I retried all my initial tests, and everything worked and did not hang. When it came to running strace against gnome-shell to view fsync calls, I noticed that fsync was no longer being called each time I pressed "Send Ping", meaning it is no longer happening per notification arrival. I clicked the clock icon to see all notifications, and a large amount of fsync calls appeared in strace output all at once, suggesting that they were put on pause and batched all at once. I can see the behaviour change that 86a00b6 and 19e0840 has had on fsync behaviour, so the commits are doing what they say. In my testing, I did not see any harm caused by these commits, as notifications still arrived as usual. Again, I could not reproduce the original report of a 20 second hang, but the new package in -proposed appears to do no harm from the testing I have undertaken. I talked to Marco about this bug, and we agreed it is okay to mark as verified. So, with some hesitation, I will mark this bug as verified. ** Bug watch added: github.com/GSConnect/gnome-shell-extension-gsconnect/issues #549 https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/549 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-shell/-/issues #470 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/470 ** Bug watch added: Red Hat Bugzilla #1575281 https://bugzilla.redhat.com/show_bug.cgi?id=1575281 ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1838152 Title: gnome-shell freezes on notification arrival (fixed upstream) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell/+bug/1838152/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1838152] Re: gnome-shell freezes on notification arrival (fixed upstream)
Performing verification for Bionic. I want to say straight up, I haven't been able to reproduce the problem, I have tried many mechanisms, but I can not reproduce the 20 second shell hang and crash, as documented in https://github.com/GSConnect /gnome-shell-extension-gsconnect/issues/549#issuecomment-515679156 I first tried to reproduce the problem using gnome-shell 3.28.4-0ubuntu18.04.3 from -updates. I have tried the following in both KVM and on physical hardware of a Lenovo Thinkpad X1 Laptop. I installed the "TeaTime" gnome-shell extension version 28 from https://extensions.gnome.org/extension/604/teatime/ and used it to send multiple notifications that arrive in 5 second delays. The hang never occured. I tried creating a draft email in evolution as suggested in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/470, and ctrl- clicked the link to spawn firefox with a notification. I did this several times, no hangs. I then tried the calendar feature in Evolution to send a notification on a new event in 5 minutes time. I did this multiple times, and never got any hangs. https://bugzilla.redhat.com/show_bug.cgi?id=1575281 I installed the gsconnect gnome-shell extension https://extensions.gnome.org/extension/1319/gsconnect/ and paired it to my android phone running the kdeconnect app. In the settings menu on the android app, there is a "send ping" button. Press that and a notification is spawned in gnome-shell. I clicked this many times, and tried clearing notifications and being in various apps, or trying to race notifications and still could not get a hang. Reading the commits, the gnome-shell hang is caused by fsync() being called from a main thread on persistent gnome-shell state files. I found the gnome-shell pid, and attached strace like so: $ sudo strace -e fsync -p On 3.28.4-0ubuntu18.04.3 each time I pressed "Send Ping" from kdeconnect, a line is printed with: fsync(38) 0 suggesting that fsync is called every time a notification comes in. I then enabled -proposed and installed gnome-shell 3.28.4-0ubuntu18.04.7 I retried all my initial tests, and everything worked and did not hang. When it came to running strace against gnome-shell to view fsync calls, I noticed that fsync was no longer being called each time I pressed "Send Ping", meaning it is no longer happening per notification arrival. I clicked the clock icon to see all notifications, and a large amount of fsync calls appeared in strace output all at once, suggesting that they were put on pause and batched all at once. I can see the behaviour change that 86a00b6 and 19e0840 has had on fsync behaviour, so the commits are doing what they say. In my testing, I did not see any harm caused by these commits, as notifications still arrived as usual. Again, I could not reproduce the original report of a 20 second hang, but the new package in -proposed appears to do no harm from the testing I have undertaken. I talked to Marco about this bug, and we agreed it is okay to mark as verified. So, with some hesitation, I will mark this bug as verified. ** Bug watch added: github.com/GSConnect/gnome-shell-extension-gsconnect/issues #549 https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/549 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-shell/-/issues #470 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/470 ** Bug watch added: Red Hat Bugzilla #1575281 https://bugzilla.redhat.com/show_bug.cgi?id=1575281 ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1838152 Title: gnome-shell freezes on notification arrival (fixed upstream) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell/+bug/1838152/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1921665] Re: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned
Performing verification for Focal.
I installed qemu 4.2-3ubuntu6.14 from -updates with the usual KVM stack
command:
$ sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients
bridge-utils
$ sudo reboot
>From there I installed and configured a NFS server:
$ sudo -s
$ sudo apt install nfs-kernel-server
$ mkdir -p /export
$ chown libvirt-qemu:kvm /export
$ echo "/export 127.0.0.1(rw,sync,no_subtree_check)" >> /etc/exports
$ systemctl restart nfs-server
Created a disk image:
$ truncate -s 100 /export/reproducer-centos.img
$ chown libvirt-qemu:kvm /export/reproducer-centos.img
$ chmod 666 /export/reproducer-centos.img
and mounted the NFS server:
$ mount 127.0.0.1:/export /mnt -o
bg,noacl,noatime,nolock,proto=udp,vers=3,noauto
I downloaded the CentOS image:
$ wget
https://vault.centos.org/7.2.1511/isos/x86_64/CentOS-7-x86_64-Minimal-1511.iso
and started the VM with the following QEMU command line:
$ sudo qemu-system-x86_64 -cdrom ./CentOS-7-x86_64-Minimal-1511.iso -m
1024 -blockdev '{"driver":"file","filename":"/mnt/reproducer-centos.img
","node-name":"disk0","cache":{"direct":true}}' -device virtio-blk-
pci,drive=disk0 -vnc 0.0.0.0:0 -enable-kvm
On my host I opened Reminna, connected to a VNC connection on :5900.
The CentOS installer eventually showed up, and I followed the steps:
Click Continue at the language/keyboard selection screen.
Click Installation Destination.
Click Done (no changes needed on that screen).
Click Begin Installation.
A few seconds later QEMU crashed with:
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.8001H:ECX.svm [bit 2]
qemu-system-x86_64: /build/qemu-AB62EU/qemu-4.2/block/io.c:1885:
bdrv_co_write_req_prepare: Assertion `end_sector <= bs->total_sectors ||
child->perm & BLK_PERM_RESIZE' failed.
Aborted
I then enabled -proposed, and installed qemu 4.2-3ubuntu6.15
$ sudo apt install qemu-kvm qemu-system-data qemu-system-gui qemu-
system-x86
I then re-started the qemu VM with:
$ sudo qemu-system-x86_64 -cdrom ./CentOS-7-x86_64-Minimal-1511.iso -m
1024 -blockdev '{"driver":"file","filename":"/mnt/reproducer-centos.img
","node-name":"disk0","cache":{"direct":true}}' -device virtio-blk-
pci,drive=disk0 -vnc 0.0.0.0:0 -enable-kvm
This time the VM managed to format the disk, and successfully install
CentOS.
The packages in -proposed fix the issue, and I am happy to mark the bug
as verified.
** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921665
Title:
QEMU hits assertion when virtual disk is stored on NFS server and is
not 4 kib byte aligned
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921665/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921665] Re: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned
Performing verification for Groovy.
I installed qemu 5.0-5ubuntu9.6 from -updates with the usual KVM stack
command:
$ sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients
bridge-utils
$ sudo reboot
>From there I installed and configured a NFS server:
$ sudo -s
$ sudo apt install nfs-kernel-server
$ mkdir -p /export
$ chown libvirt-qemu:kvm /export
$ echo "/export 127.0.0.1(rw,sync,no_subtree_check)" >> /etc/exports
$ systemctl restart nfs-server
Created a disk image:
$ truncate -s 100 /export/reproducer-centos.img
$ chown libvirt-qemu:kvm /export/reproducer-centos.img
$ chmod 666 /export/reproducer-centos.img
and mounted the NFS server:
$ mount 127.0.0.1:/export /mnt -o bg,noacl,noatime,nolock,vers=3,noauto
I downloaded the CentOS image:
$ wget
https://vault.centos.org/7.2.1511/isos/x86_64/CentOS-7-x86_64-Minimal-1511.iso
and started the VM with the following QEMU command line:
$ sudo qemu-system-x86_64 -cdrom ./CentOS-7-x86_64-Minimal-1511.iso -m
1024 -blockdev '{"driver":"file","filename":"/mnt/reproducer-centos.img
","node-name":"disk0","cache":{"direct":true}}' -device virtio-blk-
pci,drive=disk0 -vnc 0.0.0.0:0 -enable-kvm
On my host I opened Reminna, connected to a VNC connection on :5900.
The CentOS installer eventually showed up, and I followed the steps:
Click Continue at the language/keyboard selection screen.
Click Installation Destination.
Click Done (no changes needed on that screen).
Click Begin Installation.
A few seconds later QEMU crashed with:
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.8001H:ECX.svm [bit 2]
qemu-system-x86_64: /build/qemu-RSjBPs/qemu-5.0/block/io.c:1887:
bdrv_co_write_req_prepare: Assertion `end_sector <= bs->total_sectors ||
child->perm & BLK_PERM_RESIZE' failed.
Aborted
I then enabled -proposed, and installed qemu 5.0-5ubuntu9.7
$ sudo apt install qemu-kvm qemu-system-data qemu-system-gui qemu-
system-x86
I then re-started the qemu VM with:
$ sudo qemu-system-x86_64 -cdrom ./CentOS-7-x86_64-Minimal-1511.iso -m
1024 -blockdev '{"driver":"file","filename":"/mnt/reproducer-centos.img
","node-name":"disk0","cache":{"direct":true}}' -device virtio-blk-
pci,drive=disk0 -vnc 0.0.0.0:0 -enable-kvm
This time the VM managed to format the disk, and successfully install
CentOS.
The packages in -proposed fix the issue, and I am happy to mark the bug
as verified.
** Tags removed: verification-needed-groovy
** Tags added: verification-done-groovy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921665
Title:
QEMU hits assertion when virtual disk is stored on NFS server and is
not 4 kib byte aligned
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921665/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Desktop-packages] [Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Might also be related: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/303 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables Status in gnome-terminal package in Ubuntu: New Status in gnome-terminal source package in Hirsute: New Bug description: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Might also be related: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/303 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Might also be related: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/303 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Desktop-packages] [Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Seems this is a long running issue. Upstream bug: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #253 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #303 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/303 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables Status in gnome-terminal package in Ubuntu: New Status in gnome-terminal source package in Hirsute: New Bug description: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Seems this is a long running issue. Upstream bug: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #253 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #303 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/303 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Seems this is a long running issue. Upstream bug: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #253 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-terminal/-/issues #303 https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/303 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Desktop-packages] [Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Version tested in hirsute is 3.38.1-1ubuntu1. I checked Groovy, with 3.38.0-1ubuntu1.1, and the problem does not happen. Both systems using Wayland session. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables Status in gnome-terminal package in Ubuntu: New Status in gnome-terminal source package in Hirsute: New Bug description: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Version tested in hirsute is 3.38.1-1ubuntu1. I checked Groovy, with 3.38.0-1ubuntu1.1, and the problem does not happen. Both systems using Wayland session. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1922839] [NEW] Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Public bug reported: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Affects: gnome-terminal (Ubuntu Hirsute) Importance: Undecided Status: New ** Tags: hirsute ** Also affects: gnome-terminal (Ubuntu Hirsute) Importance: Undecided Status: New ** Tags added: hirsute -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1922839] Re: Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Version tested in hirsute is 3.38.1-1ubuntu1. I checked Groovy, with 3.38.0-1ubuntu1.1, and the problem does not happen. Both systems using Wayland session. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Desktop-packages] [Bug 1922839] [NEW] Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Public bug reported: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Affects: gnome-terminal (Ubuntu Hirsute) Importance: Undecided Status: New ** Tags: hirsute ** Also affects: gnome-terminal (Ubuntu Hirsute) Importance: Undecided Status: New ** Tags added: hirsute -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables Status in gnome-terminal package in Ubuntu: New Status in gnome-terminal source package in Hirsute: New Bug description: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Bug 1922839] [NEW] Opening new tab in gnome-terminal launched from nautilus loses most environment variables
Public bug reported: [Impact] If you launch gnome-terminal by right clicking a directory in Nautilus, selecting "Open in Terminal", you get a fully functional terminal window. If you then press the new tab button, or ctrl-shift-t to open a new terminal tab, you will find that most environment variables have become unset, and you see the text: To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Comparing printenv between: Normal terminal: https://paste.ubuntu.com/p/2hcCY9hbHQ/ Broken new terminal tab: https://paste.ubuntu.com/p/zYsjRHVJH7/ Most commands won't run in the new terminal tab, due to $HOME and $USER not being set. Note, if you launch gnome-terminal from gnome-shell or the dock, and create a new tab, everything works perfectly. Is something wrong with the Nautilus option for "Open in Terminal"? ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Affects: gnome-terminal (Ubuntu Hirsute) Importance: Undecided Status: New ** Tags: hirsute ** Also affects: gnome-terminal (Ubuntu Hirsute) Importance: Undecided Status: New ** Tags added: hirsute -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922839 Title: Opening new tab in gnome-terminal launched from nautilus loses most environment variables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921665] Re: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned
Thanks for the quick work Christian! I'll keep an eye out and be ready to test once builds enter -proposed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921665 Title: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921665/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921665] Re: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned
Attached is a debdiff for Groovy which fixes this bug. ** Patch added: "QEMU debdiff for Groovy" https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921665/+attachment/5481777/+files/lp1921665_groovy.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921665 Title: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921665/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921665] Re: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned
Attached is a debdiff for Focal which fixes this bug. ** Patch added: "QEMU debdiff for focal" https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921665/+attachment/5481776/+files/lp1921665_focal.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921665 Title: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921665/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921665] [NEW] QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned
* Affects: qemu (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: qemu (Ubuntu Focal) Importance: Medium Assignee: Matthew Ruffell (mruffell) Status: In Progress ** Affects: qemu (Ubuntu Groovy) Importance: Medium Assignee: Matthew Ruffell (mruffell) Status: In Progress ** Tags: focal groovy sts ** Also affects: qemu (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: qemu (Ubuntu) Status: New => Fix Released ** Changed in: qemu (Ubuntu Focal) Status: New => In Progress ** Changed in: qemu (Ubuntu Groovy) Status: New => In Progress ** Changed in: qemu (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: qemu (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: qemu (Ubuntu Focal) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Changed in: qemu (Ubuntu Groovy) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Tags added: focal groovy sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921665 Title: QEMU hits assertion when virtual disk is stored on NFS server and is not 4 kib byte aligned To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921665/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Desktop-packages] [Bug 1886592] Re: Add support for VMware Horizon SSO to gnome-shell
Performing verification for gnome-shell in Bionic. During this verification I will explain how VMware Horizon SSO works, and will prove that the gnome-shell in -proposed is equivalent to the custom gnome-shell package distributed by VMware. I will begin by walking through the SSO workflow, based around the custom gnome-shell package distributed by VMware. Firstly, start with a fresh Focal Desktop VM, all up to date. Visit the VMware website, specifically this link: https://my.vmware.com/en/web/vmware/evalcenter?p=horizon-eval-8 Sign up for a VMware account and reach the VMware Horizon 8 evaluation download page. The next step is to locate the "Linux Agent x86_64". The file is named VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz If you have difficulty in obtaining this file and want to reproduce, please message me. Download and copy to the Focal VM. $ scp VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz ubuntu@target:~/ $ ssh ubuntu@target $ tar -xf VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz $ cd VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770 Next, install the VMware Horizon Linux Agent by following the instructions at: https://docs.vmware.com/en/VMware-Horizon-7/7.13/linux-desktops- setup/GUID-B4111821-34F2-465B-B290-FC2070EFCB5A.html $ sudo apt install libpam-pkcs11 $ sudo apt install libnss3-tools $ sudo apt install open-vm-tools $ sudo apt install python python-dbus python-gobject $ sudo ./install_viewagent.sh -T yes Now, this will install a custom patched gnome-shell library, which contains the following patches: https://paste.ubuntu.com/p/q4fkNrqHQT/ You can find this, and more in the VMware-horizonagent-linux- x86_64-2012-8.1.0-17336770/sso directory. Reboot the VM. When it comes back up, run "ps aux". You will see: root 1406 0.0 0.0 4904 2020 ?S15:53 0:00 /bin/sh /usr/lib/vmware/viewagent/bin/GetMachineId.sh root 1447 0.0 0.2 404328 10968 ?Sl 15:53 0:00 /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon root 1449 2.2 0.2 102060 9060 ?Sl 15:53 0:02 /usr/lib/vmware/viewagent/VMwareBlastServer/BlastServer root 1479 0.0 0.1 139968 6528 ?Sl 15:53 0:00 desktopWorker -x /usr/lib/vmware/viewagent/bin/StartXServer.sh -d :100 -s 1 -p 13 root 1488 0.2 1.4 611572 56464 ?Sl 15:53 0:00 /usr/lib/xorg/Xorg :100 -auth /var/vmware/viewagent/xauth/.xauth:100 -once -query 127.0.0.1 -config /usr/lib/vmware/viewagent/resource root 1532 0.0 0.2 258560 8088 ?Sl 15:53 0:00 gdm-session-worker [pam/gdm-launch-environment] gdm 1535 0.0 0.0 25464 1528 ?Ss 15:53 0:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart gdm 1536 0.0 0.1 50244 4528 ?S15:53 0:00 dbus-daemon --nofork --print-address 4 --session gdm 1537 0.0 0.3 551880 13892 ?Sl 15:53 0:00 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart Now, the SSO desktop for the VDI is on xorg display :100, and all of this is launched by /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon. The dbus-run-session runs a bunch of autostart scripts in /usr/share/gdm/greeter/autostart, one of which starts up SsoDBusNotify.py. Now, when /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py runs, it reads in a SSO token generated by desktopDaemon from stdin, and then makes sure the display matches what xorg is running on, and then sends a UserAuthenticated signal to DBUS on '/org/vmware/viewagent/Credentials' and 'org.vmware.viewagent.Credentials'. Lets do this manually, since we are in KVM and not on an actual VMware Horizon cluster. Execute: $ sudo /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py -t sso -d :100 When asked, input the token: "12345DISPLAY:100". The custom gnome-shell distributed by VMware listens on org.vmware.viewagent.Credentials.D100 (yes, that is a per-display dbus address) which then checks to see if the token is any good, and passes it to PAM for processing. PAM then calls the module gdm-vmwcred, which then talks to the SSSD and krb5 PAM modules to authenticate against an AD server. But in our repro environment, this won't work. But the main thing is, if you check: /var/log/auth.log: Mar 22 15:55:51 ubuntu gdm-vmwcred]: pam_vmw_cred(gdm-vmwcred:auth): Failed to acquire user's credentials and /var/log/vmware/pam_vmw_log: 2021:03:22 15:55:51 : Authentication begins 2021:03:22 15:55:51 : SSOChannel_AcquireUserCredentials called. 2021:03:22 15:55:51 : VMWARE Token is invaild. 2021:03:22 15:55:51 : Failed to acquire user's credentials 2021:03:22 15:55:51 : Authentication ends We see gnome-shell does infact call PAM. On vanilla installs of gnome-shell, i.e. gnome-shell 3.28.4-0ubuntu18.04.3 and earlier, if you attempted to do this, gnome- shell would not talk to PAM as it does not understand the per-display dbus logic. Now, on the
[Bug 1886592] Re: Add support for VMware Horizon SSO to gnome-shell
Performing verification for gnome-shell in Bionic. During this verification I will explain how VMware Horizon SSO works, and will prove that the gnome-shell in -proposed is equivalent to the custom gnome-shell package distributed by VMware. I will begin by walking through the SSO workflow, based around the custom gnome-shell package distributed by VMware. Firstly, start with a fresh Focal Desktop VM, all up to date. Visit the VMware website, specifically this link: https://my.vmware.com/en/web/vmware/evalcenter?p=horizon-eval-8 Sign up for a VMware account and reach the VMware Horizon 8 evaluation download page. The next step is to locate the "Linux Agent x86_64". The file is named VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz If you have difficulty in obtaining this file and want to reproduce, please message me. Download and copy to the Focal VM. $ scp VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz ubuntu@target:~/ $ ssh ubuntu@target $ tar -xf VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz $ cd VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770 Next, install the VMware Horizon Linux Agent by following the instructions at: https://docs.vmware.com/en/VMware-Horizon-7/7.13/linux-desktops- setup/GUID-B4111821-34F2-465B-B290-FC2070EFCB5A.html $ sudo apt install libpam-pkcs11 $ sudo apt install libnss3-tools $ sudo apt install open-vm-tools $ sudo apt install python python-dbus python-gobject $ sudo ./install_viewagent.sh -T yes Now, this will install a custom patched gnome-shell library, which contains the following patches: https://paste.ubuntu.com/p/q4fkNrqHQT/ You can find this, and more in the VMware-horizonagent-linux- x86_64-2012-8.1.0-17336770/sso directory. Reboot the VM. When it comes back up, run "ps aux". You will see: root 1406 0.0 0.0 4904 2020 ?S15:53 0:00 /bin/sh /usr/lib/vmware/viewagent/bin/GetMachineId.sh root 1447 0.0 0.2 404328 10968 ?Sl 15:53 0:00 /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon root 1449 2.2 0.2 102060 9060 ?Sl 15:53 0:02 /usr/lib/vmware/viewagent/VMwareBlastServer/BlastServer root 1479 0.0 0.1 139968 6528 ?Sl 15:53 0:00 desktopWorker -x /usr/lib/vmware/viewagent/bin/StartXServer.sh -d :100 -s 1 -p 13 root 1488 0.2 1.4 611572 56464 ?Sl 15:53 0:00 /usr/lib/xorg/Xorg :100 -auth /var/vmware/viewagent/xauth/.xauth:100 -once -query 127.0.0.1 -config /usr/lib/vmware/viewagent/resource root 1532 0.0 0.2 258560 8088 ?Sl 15:53 0:00 gdm-session-worker [pam/gdm-launch-environment] gdm 1535 0.0 0.0 25464 1528 ?Ss 15:53 0:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart gdm 1536 0.0 0.1 50244 4528 ?S15:53 0:00 dbus-daemon --nofork --print-address 4 --session gdm 1537 0.0 0.3 551880 13892 ?Sl 15:53 0:00 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart Now, the SSO desktop for the VDI is on xorg display :100, and all of this is launched by /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon. The dbus-run-session runs a bunch of autostart scripts in /usr/share/gdm/greeter/autostart, one of which starts up SsoDBusNotify.py. Now, when /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py runs, it reads in a SSO token generated by desktopDaemon from stdin, and then makes sure the display matches what xorg is running on, and then sends a UserAuthenticated signal to DBUS on '/org/vmware/viewagent/Credentials' and 'org.vmware.viewagent.Credentials'. Lets do this manually, since we are in KVM and not on an actual VMware Horizon cluster. Execute: $ sudo /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py -t sso -d :100 When asked, input the token: "12345DISPLAY:100". The custom gnome-shell distributed by VMware listens on org.vmware.viewagent.Credentials.D100 (yes, that is a per-display dbus address) which then checks to see if the token is any good, and passes it to PAM for processing. PAM then calls the module gdm-vmwcred, which then talks to the SSSD and krb5 PAM modules to authenticate against an AD server. But in our repro environment, this won't work. But the main thing is, if you check: /var/log/auth.log: Mar 22 15:55:51 ubuntu gdm-vmwcred]: pam_vmw_cred(gdm-vmwcred:auth): Failed to acquire user's credentials and /var/log/vmware/pam_vmw_log: 2021:03:22 15:55:51 : Authentication begins 2021:03:22 15:55:51 : SSOChannel_AcquireUserCredentials called. 2021:03:22 15:55:51 : VMWARE Token is invaild. 2021:03:22 15:55:51 : Failed to acquire user's credentials 2021:03:22 15:55:51 : Authentication ends We see gnome-shell does infact call PAM. On vanilla installs of gnome-shell, i.e. gnome-shell 3.28.4-0ubuntu18.04.3 and earlier, if you attempted to do this, gnome- shell would not talk to PAM as it does not understand the per-display dbus logic. Now, on the
[Bug 1886592] Re: Add support for VMware Horizon SSO to gnome-shell
Performing verification for gnome-shell in Bionic. During this verification I will explain how VMware Horizon SSO works, and will prove that the gnome-shell in -proposed is equivalent to the custom gnome-shell package distributed by VMware. I will begin by walking through the SSO workflow, based around the custom gnome-shell package distributed by VMware. Firstly, start with a fresh Focal Desktop VM, all up to date. Visit the VMware website, specifically this link: https://my.vmware.com/en/web/vmware/evalcenter?p=horizon-eval-8 Sign up for a VMware account and reach the VMware Horizon 8 evaluation download page. The next step is to locate the "Linux Agent x86_64". The file is named VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz If you have difficulty in obtaining this file and want to reproduce, please message me. Download and copy to the Focal VM. $ scp VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz ubuntu@target:~/ $ ssh ubuntu@target $ tar -xf VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz $ cd VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770 Next, install the VMware Horizon Linux Agent by following the instructions at: https://docs.vmware.com/en/VMware-Horizon-7/7.13/linux-desktops- setup/GUID-B4111821-34F2-465B-B290-FC2070EFCB5A.html $ sudo apt install libpam-pkcs11 $ sudo apt install libnss3-tools $ sudo apt install open-vm-tools $ sudo apt install python python-dbus python-gobject $ sudo ./install_viewagent.sh -T yes Now, this will install a custom patched gnome-shell library, which contains the following patches: https://paste.ubuntu.com/p/q4fkNrqHQT/ You can find this, and more in the VMware-horizonagent-linux- x86_64-2012-8.1.0-17336770/sso directory. Reboot the VM. When it comes back up, run "ps aux". You will see: root 1406 0.0 0.0 4904 2020 ?S15:53 0:00 /bin/sh /usr/lib/vmware/viewagent/bin/GetMachineId.sh root 1447 0.0 0.2 404328 10968 ?Sl 15:53 0:00 /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon root 1449 2.2 0.2 102060 9060 ?Sl 15:53 0:02 /usr/lib/vmware/viewagent/VMwareBlastServer/BlastServer root 1479 0.0 0.1 139968 6528 ?Sl 15:53 0:00 desktopWorker -x /usr/lib/vmware/viewagent/bin/StartXServer.sh -d :100 -s 1 -p 13 root 1488 0.2 1.4 611572 56464 ?Sl 15:53 0:00 /usr/lib/xorg/Xorg :100 -auth /var/vmware/viewagent/xauth/.xauth:100 -once -query 127.0.0.1 -config /usr/lib/vmware/viewagent/resource root 1532 0.0 0.2 258560 8088 ?Sl 15:53 0:00 gdm-session-worker [pam/gdm-launch-environment] gdm 1535 0.0 0.0 25464 1528 ?Ss 15:53 0:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart gdm 1536 0.0 0.1 50244 4528 ?S15:53 0:00 dbus-daemon --nofork --print-address 4 --session gdm 1537 0.0 0.3 551880 13892 ?Sl 15:53 0:00 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart Now, the SSO desktop for the VDI is on xorg display :100, and all of this is launched by /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon. The dbus-run-session runs a bunch of autostart scripts in /usr/share/gdm/greeter/autostart, one of which starts up SsoDBusNotify.py. Now, when /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py runs, it reads in a SSO token generated by desktopDaemon from stdin, and then makes sure the display matches what xorg is running on, and then sends a UserAuthenticated signal to DBUS on '/org/vmware/viewagent/Credentials' and 'org.vmware.viewagent.Credentials'. Lets do this manually, since we are in KVM and not on an actual VMware Horizon cluster. Execute: $ sudo /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py -t sso -d :100 When asked, input the token: "12345DISPLAY:100". The custom gnome-shell distributed by VMware listens on org.vmware.viewagent.Credentials.D100 (yes, that is a per-display dbus address) which then checks to see if the token is any good, and passes it to PAM for processing. PAM then calls the module gdm-vmwcred, which then talks to the SSSD and krb5 PAM modules to authenticate against an AD server. But in our repro environment, this won't work. But the main thing is, if you check: /var/log/auth.log: Mar 22 15:55:51 ubuntu gdm-vmwcred]: pam_vmw_cred(gdm-vmwcred:auth): Failed to acquire user's credentials and /var/log/vmware/pam_vmw_log: 2021:03:22 15:55:51 : Authentication begins 2021:03:22 15:55:51 : SSOChannel_AcquireUserCredentials called. 2021:03:22 15:55:51 : VMWARE Token is invaild. 2021:03:22 15:55:51 : Failed to acquire user's credentials 2021:03:22 15:55:51 : Authentication ends We see gnome-shell does infact call PAM. On vanilla installs of gnome-shell, i.e. gnome-shell 3.28.4-0ubuntu18.04.3 and earlier, if you attempted to do this, gnome- shell would not talk to PAM as it does not understand the per-display dbus logic. Now, on the
[Desktop-packages] [Bug 1886592] Re: Add support for VMware Horizon SSO to gnome-shell
Performing verification for gnome-shell in Focal. During this verification I will explain how VMware Horizon SSO works, and will prove that the gnome-shell in -proposed is equivalent to the custom gnome-shell package distributed by VMware. I will begin by walking through the SSO workflow, based around the custom gnome-shell package distributed by VMware. Firstly, start with a fresh Focal Desktop VM, all up to date. Visit the VMware website, specifically this link: https://my.vmware.com/en/web/vmware/evalcenter?p=horizon-eval-8 Sign up for a VMware account and reach the VMware Horizon 8 evaluation download page. The next step is to locate the "Linux Agent x86_64". The file is named VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz If you have difficulty in obtaining this file and want to reproduce, please message me. Download and copy to the Focal VM. $ scp VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz ubuntu@target:~/ $ ssh ubuntu@target $ tar -xf VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz $ cd VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770 Next, install the VMware Horizon Linux Agent by following the instructions at: https://docs.vmware.com/en/VMware-Horizon-7/7.13/linux-desktops- setup/GUID-B4111821-34F2-465B-B290-FC2070EFCB5A.html $ sudo apt install libpam-pkcs11 $ sudo apt install libnss3-tools $ sudo apt install open-vm-tools $ sudo ./install_viewagent.sh -T yes Now, this will install a custom patched gnome-shell library, which contains the following patches: https://paste.ubuntu.com/p/q4fkNrqHQT/ You can find this, and more in the VMware-horizonagent-linux- x86_64-2012-8.1.0-17336770/sso directory. Reboot the VM. When it comes back up, run "ps aux". You will see: oot1410 0.0 0.1 345920 10840 ?Sl 15:09 0:00 /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon root1411 2.1 0.1 77128 9208 ?Sl 15:09 0:00 /usr/lib/vmware/viewagent/VMwareBlastServer/BlastServer root1463 0.0 0.0 107056 6812 ?Sl 15:09 0:00 desktopWorker -x /usr/lib/vmware/viewagent/bin/StartXServer.sh -d :100 -s 1 -p 13 root1477 1.4 0.7 1129928 61244 ? Sl 15:09 0:00 /usr/lib/xorg/Xorg :100 -auth /var/vmware/viewagent/xauth/.xauth:100 -once -query 127.0.0.1 -config /usr/lib/vmware/viewagent/resour root1530 0.0 0.1 177392 9172 ?Sl 15:09 0:00 gdm-session-worker [pam/gdm-launch-environment] gdm 1535 0.0 0.0 5300 1108 ?Ss 15:09 0:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart gdm 1536 0.2 0.0 7556 4672 ?S15:09 0:00 dbus-daemon --nofork --print-address 4 --session gdm 1537 0.3 0.2 568700 16920 ?Sl 15:09 0:00 /usr/libexec/gnome-session-binary --systemd --autostart /usr/share/gdm/greeter/autostart Now, the SSO desktop for the VDI is on xorg display :100, and all of this is launched by /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon. The dbus-run-session runs a bunch of autostart scripts in /usr/share/gdm/greeter/autostart, one of which starts up SsoDBusNotify.py. Now, when /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py runs, it reads in a SSO token generated by desktopDaemon from stdin, and then makes sure the display matches what xorg is running on, and then sends a UserAuthenticated signal to DBUS on '/org/vmware/viewagent/Credentials' and 'org.vmware.viewagent.Credentials'. Lets do this manually, since we are in KVM and not on an actual VMware Horizon cluster. Execute: $ sudo /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py -t sso -d :100 When asked, input the token: "12345DISPLAY:100". The custom gnome-shell distributed by VMware listens on org.vmware.viewagent.Credentials.D100 (yes, that is a per-display dbus address) which then checks to see if the token is any good, and passes it to PAM for processing. PAM then calls the module gdm-vmwcred, which then talks to the SSSD and krb5 PAM modules to authenticate against an AD server. But in our repro environment, this won't work. But the main thing is, if you check: /var/log/auth.log: Mar 22 15:14:45 ubuntu gdm-vmwcred]: pam_vmw_cred(gdm-vmwcred:auth): Failed to acquire user's credentials and /var/log/vmware/pam_vmw_log: 2021:03:22 15:14:45 : Authentication begins 2021:03:22 15:14:45 : SSOChannel_AcquireUserCredentials called. 2021:03:22 15:14:45 : VMWARE Token is invaild. 2021:03:22 15:14:45 : Failed to acquire user's credentials 2021:03:22 15:14:45 : Authentication ends We see gnome-shell does infact call PAM. On vanilla installs of gnome-shell, i.e. gnome-shell 3.36.4-1ubuntu1~20.04.2 and earlier, if you attempted to do this, gnome- shell would not talk to PAM as it does not understand the per-display dbus logic. Now, on the customer environment, SSO works fine with the custom gnome- shell library, as they are correctly configured for SSSD / krb5 to their AD server. Now, let's
[Bug 1886592] Re: Add support for VMware Horizon SSO to gnome-shell
Performing verification for gnome-shell in Focal. During this verification I will explain how VMware Horizon SSO works, and will prove that the gnome-shell in -proposed is equivalent to the custom gnome-shell package distributed by VMware. I will begin by walking through the SSO workflow, based around the custom gnome-shell package distributed by VMware. Firstly, start with a fresh Focal Desktop VM, all up to date. Visit the VMware website, specifically this link: https://my.vmware.com/en/web/vmware/evalcenter?p=horizon-eval-8 Sign up for a VMware account and reach the VMware Horizon 8 evaluation download page. The next step is to locate the "Linux Agent x86_64". The file is named VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz If you have difficulty in obtaining this file and want to reproduce, please message me. Download and copy to the Focal VM. $ scp VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz ubuntu@target:~/ $ ssh ubuntu@target $ tar -xf VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz $ cd VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770 Next, install the VMware Horizon Linux Agent by following the instructions at: https://docs.vmware.com/en/VMware-Horizon-7/7.13/linux-desktops- setup/GUID-B4111821-34F2-465B-B290-FC2070EFCB5A.html $ sudo apt install libpam-pkcs11 $ sudo apt install libnss3-tools $ sudo apt install open-vm-tools $ sudo ./install_viewagent.sh -T yes Now, this will install a custom patched gnome-shell library, which contains the following patches: https://paste.ubuntu.com/p/q4fkNrqHQT/ You can find this, and more in the VMware-horizonagent-linux- x86_64-2012-8.1.0-17336770/sso directory. Reboot the VM. When it comes back up, run "ps aux". You will see: oot1410 0.0 0.1 345920 10840 ?Sl 15:09 0:00 /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon root1411 2.1 0.1 77128 9208 ?Sl 15:09 0:00 /usr/lib/vmware/viewagent/VMwareBlastServer/BlastServer root1463 0.0 0.0 107056 6812 ?Sl 15:09 0:00 desktopWorker -x /usr/lib/vmware/viewagent/bin/StartXServer.sh -d :100 -s 1 -p 13 root1477 1.4 0.7 1129928 61244 ? Sl 15:09 0:00 /usr/lib/xorg/Xorg :100 -auth /var/vmware/viewagent/xauth/.xauth:100 -once -query 127.0.0.1 -config /usr/lib/vmware/viewagent/resour root1530 0.0 0.1 177392 9172 ?Sl 15:09 0:00 gdm-session-worker [pam/gdm-launch-environment] gdm 1535 0.0 0.0 5300 1108 ?Ss 15:09 0:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart gdm 1536 0.2 0.0 7556 4672 ?S15:09 0:00 dbus-daemon --nofork --print-address 4 --session gdm 1537 0.3 0.2 568700 16920 ?Sl 15:09 0:00 /usr/libexec/gnome-session-binary --systemd --autostart /usr/share/gdm/greeter/autostart Now, the SSO desktop for the VDI is on xorg display :100, and all of this is launched by /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon. The dbus-run-session runs a bunch of autostart scripts in /usr/share/gdm/greeter/autostart, one of which starts up SsoDBusNotify.py. Now, when /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py runs, it reads in a SSO token generated by desktopDaemon from stdin, and then makes sure the display matches what xorg is running on, and then sends a UserAuthenticated signal to DBUS on '/org/vmware/viewagent/Credentials' and 'org.vmware.viewagent.Credentials'. Lets do this manually, since we are in KVM and not on an actual VMware Horizon cluster. Execute: $ sudo /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py -t sso -d :100 When asked, input the token: "12345DISPLAY:100". The custom gnome-shell distributed by VMware listens on org.vmware.viewagent.Credentials.D100 (yes, that is a per-display dbus address) which then checks to see if the token is any good, and passes it to PAM for processing. PAM then calls the module gdm-vmwcred, which then talks to the SSSD and krb5 PAM modules to authenticate against an AD server. But in our repro environment, this won't work. But the main thing is, if you check: /var/log/auth.log: Mar 22 15:14:45 ubuntu gdm-vmwcred]: pam_vmw_cred(gdm-vmwcred:auth): Failed to acquire user's credentials and /var/log/vmware/pam_vmw_log: 2021:03:22 15:14:45 : Authentication begins 2021:03:22 15:14:45 : SSOChannel_AcquireUserCredentials called. 2021:03:22 15:14:45 : VMWARE Token is invaild. 2021:03:22 15:14:45 : Failed to acquire user's credentials 2021:03:22 15:14:45 : Authentication ends We see gnome-shell does infact call PAM. On vanilla installs of gnome-shell, i.e. gnome-shell 3.36.4-1ubuntu1~20.04.2 and earlier, if you attempted to do this, gnome- shell would not talk to PAM as it does not understand the per-display dbus logic. Now, on the customer environment, SSO works fine with the custom gnome- shell library, as they are correctly configured for SSSD / krb5 to their AD server. Now, let's
[Bug 1886592] Re: Add support for VMware Horizon SSO to gnome-shell
Performing verification for gnome-shell in Focal. During this verification I will explain how VMware Horizon SSO works, and will prove that the gnome-shell in -proposed is equivalent to the custom gnome-shell package distributed by VMware. I will begin by walking through the SSO workflow, based around the custom gnome-shell package distributed by VMware. Firstly, start with a fresh Focal Desktop VM, all up to date. Visit the VMware website, specifically this link: https://my.vmware.com/en/web/vmware/evalcenter?p=horizon-eval-8 Sign up for a VMware account and reach the VMware Horizon 8 evaluation download page. The next step is to locate the "Linux Agent x86_64". The file is named VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz If you have difficulty in obtaining this file and want to reproduce, please message me. Download and copy to the Focal VM. $ scp VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz ubuntu@target:~/ $ ssh ubuntu@target $ tar -xf VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770.tar.gz $ cd VMware-horizonagent-linux-x86_64-2012-8.1.0-17336770 Next, install the VMware Horizon Linux Agent by following the instructions at: https://docs.vmware.com/en/VMware-Horizon-7/7.13/linux-desktops- setup/GUID-B4111821-34F2-465B-B290-FC2070EFCB5A.html $ sudo apt install libpam-pkcs11 $ sudo apt install libnss3-tools $ sudo apt install open-vm-tools $ sudo ./install_viewagent.sh -T yes Now, this will install a custom patched gnome-shell library, which contains the following patches: https://paste.ubuntu.com/p/q4fkNrqHQT/ You can find this, and more in the VMware-horizonagent-linux- x86_64-2012-8.1.0-17336770/sso directory. Reboot the VM. When it comes back up, run "ps aux". You will see: oot1410 0.0 0.1 345920 10840 ?Sl 15:09 0:00 /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon root1411 2.1 0.1 77128 9208 ?Sl 15:09 0:00 /usr/lib/vmware/viewagent/VMwareBlastServer/BlastServer root1463 0.0 0.0 107056 6812 ?Sl 15:09 0:00 desktopWorker -x /usr/lib/vmware/viewagent/bin/StartXServer.sh -d :100 -s 1 -p 13 root1477 1.4 0.7 1129928 61244 ? Sl 15:09 0:00 /usr/lib/xorg/Xorg :100 -auth /var/vmware/viewagent/xauth/.xauth:100 -once -query 127.0.0.1 -config /usr/lib/vmware/viewagent/resour root1530 0.0 0.1 177392 9172 ?Sl 15:09 0:00 gdm-session-worker [pam/gdm-launch-environment] gdm 1535 0.0 0.0 5300 1108 ?Ss 15:09 0:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart gdm 1536 0.2 0.0 7556 4672 ?S15:09 0:00 dbus-daemon --nofork --print-address 4 --session gdm 1537 0.3 0.2 568700 16920 ?Sl 15:09 0:00 /usr/libexec/gnome-session-binary --systemd --autostart /usr/share/gdm/greeter/autostart Now, the SSO desktop for the VDI is on xorg display :100, and all of this is launched by /usr/lib/vmware/viewagent/DesktopDaemon/desktopDaemon. The dbus-run-session runs a bunch of autostart scripts in /usr/share/gdm/greeter/autostart, one of which starts up SsoDBusNotify.py. Now, when /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py runs, it reads in a SSO token generated by desktopDaemon from stdin, and then makes sure the display matches what xorg is running on, and then sends a UserAuthenticated signal to DBUS on '/org/vmware/viewagent/Credentials' and 'org.vmware.viewagent.Credentials'. Lets do this manually, since we are in KVM and not on an actual VMware Horizon cluster. Execute: $ sudo /usr/lib/vmware/viewagent/bin/SsoDBusNotify.py -t sso -d :100 When asked, input the token: "12345DISPLAY:100". The custom gnome-shell distributed by VMware listens on org.vmware.viewagent.Credentials.D100 (yes, that is a per-display dbus address) which then checks to see if the token is any good, and passes it to PAM for processing. PAM then calls the module gdm-vmwcred, which then talks to the SSSD and krb5 PAM modules to authenticate against an AD server. But in our repro environment, this won't work. But the main thing is, if you check: /var/log/auth.log: Mar 22 15:14:45 ubuntu gdm-vmwcred]: pam_vmw_cred(gdm-vmwcred:auth): Failed to acquire user's credentials and /var/log/vmware/pam_vmw_log: 2021:03:22 15:14:45 : Authentication begins 2021:03:22 15:14:45 : SSOChannel_AcquireUserCredentials called. 2021:03:22 15:14:45 : VMWARE Token is invaild. 2021:03:22 15:14:45 : Failed to acquire user's credentials 2021:03:22 15:14:45 : Authentication ends We see gnome-shell does infact call PAM. On vanilla installs of gnome-shell, i.e. gnome-shell 3.36.4-1ubuntu1~20.04.2 and earlier, if you attempted to do this, gnome- shell would not talk to PAM as it does not understand the per-display dbus logic. Now, on the customer environment, SSO works fine with the custom gnome- shell library, as they are correctly configured for SSSD / krb5 to their AD server. Now, let's
[Bug 1909950] Re: named: TCP connections sometimes never close due to race in socket teardown
Performing verification for Bind9 on Focal.
I first installed 9.16.1-0ubuntu2.6 from -updates to ensure that the
issue is still present.
I checked that I could look up ubuntu.com through the local caching
resolver. From there I started a second VM, and checked I could look up
addresses through the first VM. I then added the 30% packet loss rule
with tc. From there I opened up 11 tabs in gnome-terminal and hit the
first first VM with:
$ for run in {1..1}; do dig +tcp @192.168.122.21 ubuntu.com & done
https://paste.ubuntu.com/p/sF9SXkWpZK/
We can see that the "TCP high-water" mark kept rising until it reached
150, when I then killed the thundering herd from the second VM. I then
did a DNS lookup, and found that named was not listening to TCP, and the
lookup timed out.
This confirms that 9.16.1-0ubuntu2.6 from -updates is affected.
I then enabled -proposed, and installed bind9 9.16.1-0ubuntu2.7 and
rebooted.
>From there, I can checked I could look up ubuntu.com through the local
caching resolver, and again started the second VM. The second VM could
also look up addresses through the first VM. I again added a 30% packet
loss with tc. I then opened up 11 tabs of gnome-terminal and hit the
first vm with the dig for loop of doom.
Except this time, once I reached the TCP high water mark and killed the
second VM, the number of TCP connections fell back down to 1, and did
not get stuck at a higher number. I did a TCP DNS lookup for ubuntu.com
on the server, and the request was successful and did not time out.
named is listening to TCP connections as it is suppose to.
https://paste.ubuntu.com/p/SzJMzz6xbh/
bind9 9.16.1-0ubuntu2.7 fixes the problem. Happy to mark as verified.
I will also write back in a few days time with feedback from a user, who
is testing this fixed package in production.
** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950
Title:
named: TCP connections sometimes never close due to race in socket
teardown
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1909950/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1907262] Re: raid10: discard leads to corrupted file system
Hi Thimo, Recently, Xiao Ni, the original author of the Raid10 block discard patchset, has posted a new revision of the patchset to the linux-raid mailing list for feedback. Xiao has fixed the two bugs that caused the regression. The first was incorrectly calculating the start offset for block discard for the second and extra disks. The second bug was an incorrect stripe size for far layouts. The new patches are: https://www.spinics.net/lists/raid/msg67208.html https://www.spinics.net/lists/raid/msg67212.html https://www.spinics.net/lists/raid/msg67213.html https://www.spinics.net/lists/raid/msg67209.html https://www.spinics.net/lists/raid/msg67210.html https://www.spinics.net/lists/raid/msg67211.html Now, at some point in the future I do want to try and SRU these patches to the Ubuntu kernel, but only when they are ready. I was wondering if you would be interested in helping to test these new patches, since you have a lot of experience with Raid10. If you have some time, and a dedicated spare server, read comment 13 in the below bug which contains instructions to install test kernels I have built. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/comments/13 This is entirely optional, and don't feel that you are obligated to test. We just want to get more eyes on the patches and some wider testing done, and to give feedback back to Xiao, the author, and to Song Liu, the Raid subsystem maintainer about the performance and safety of these patches. I have tested the test kernels with the regression reproducer from this bug, and the mismatch count is always 0, and all fsck -f comes back clean for all disks. If you have some spare time and a spare server, I would really appreciate help testing these kernels. Thanks! Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 1907262] Re: raid10: discard leads to corrupted file system
Hi Thimo, Recently, Xiao Ni, the original author of the Raid10 block discard patchset, has posted a new revision of the patchset to the linux-raid mailing list for feedback. Xiao has fixed the two bugs that caused the regression. The first was incorrectly calculating the start offset for block discard for the second and extra disks. The second bug was an incorrect stripe size for far layouts. The new patches are: https://www.spinics.net/lists/raid/msg67208.html https://www.spinics.net/lists/raid/msg67212.html https://www.spinics.net/lists/raid/msg67213.html https://www.spinics.net/lists/raid/msg67209.html https://www.spinics.net/lists/raid/msg67210.html https://www.spinics.net/lists/raid/msg67211.html Now, at some point in the future I do want to try and SRU these patches to the Ubuntu kernel, but only when they are ready. I was wondering if you would be interested in helping to test these new patches, since you have a lot of experience with Raid10. If you have some time, and a dedicated spare server, read comment 13 in the below bug which contains instructions to install test kernels I have built. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/comments/13 This is entirely optional, and don't feel that you are obligated to test. We just want to get more eyes on the patches and some wider testing done, and to give feedback back to Xiao, the author, and to Song Liu, the Raid subsystem maintainer about the performance and safety of these patches. I have tested the test kernels with the regression reproducer from this bug, and the mismatch count is always 0, and all fsck -f comes back clean for all disks. If you have some spare time and a spare server, I would really appreciate help testing these kernels. Thanks! Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Invalid Status in linux source package in Xenial: Invalid Status in linux source package in Bionic: Fix Released Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: Fix Released Bug description: Seems to be closely related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578 After updating the Ubuntu 18.04 kernel from 4.15.0-124 to 4.15.0-126 the fstrim command triggered by fstrim.timer causes a severe number of mismatches between two RAID10 component devices. This bug affects several machines in our company with different HW configurations (All using ECC RAM). Both, NVMe and SATA SSDs are affected. How to reproduce: - Create a RAID10 LVM and filesystem on two SSDs mdadm -C -v -l10 -n2 -N "lv-raid" -R /dev/md0 /dev/nvme0n1p2 /dev/nvme1n1p2 pvcreate -ff -y /dev/md0 vgcreate -f -y VolGroup /dev/md0 lvcreate -n root-L 100G -ay -y VolGroup mkfs.ext4 /dev/VolGroup/root mount /dev/VolGroup/root /mnt - Write some data, sync and delete it dd if=/dev/zero of=/mnt/data.raw bs=4K count=1M sync rm /mnt/data.raw - Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (should be 0): cat /sys/block/md0/md/mismatch_cnt - Trigger the bug fstrim /mnt - Re-Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (probably in the range of N*1): cat /sys/block/md0/md/mismatch_cnt After investigating this issue on several machines it *seems* that the first drive does the trim correctly while the second one goes wild. At least the number and severity of errors found by a USB stick live session fsck.ext4 suggests this. To perform the single drive evaluation the RAID10 was started using a single drive at once: mdadm --assemble /dev/md127 /dev/nvme0n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root vgchange -a n /dev/VolGroup mdadm --stop /dev/md127 mdadm --assemble /dev/md127 /dev/nvme1n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root When starting these fscks without -n, on the first device it seems the directory structure is OK while on the second device there is only the lost+found folder left. Side-note: Another machine using HWE kernel 5.4.0-56 (after using -53 before) seems to have a quite similar issue. Unfortunately the risk/regression assessment in the aforementioned bug is not complete: the workaround only mitigates the issues during FS creation. This bug on the other hand is triggered by a weekly service (fstrim) causing severe file system corruption. To manage notifications about this bug go to:
[Kernel-packages] [Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
Hi everyone, The original patch author, Xiao Ni, has sent a V2 patchset to the linux- raid mailing list for feedback. This new patchset fixes the problems the previous version had, namely, properly calculating the discard offset for second and onward disks, and correctly calculates the stripe size in far layouts. The patches are: https://www.spinics.net/lists/raid/msg67208.html https://www.spinics.net/lists/raid/msg67212.html https://www.spinics.net/lists/raid/msg67213.html https://www.spinics.net/lists/raid/msg67209.html https://www.spinics.net/lists/raid/msg67210.html https://www.spinics.net/lists/raid/msg67211.html We now need to thoroughly test and provide feedback to Xiao and the Raid subsystem maintainer before these patches can get merged into mainline again. We really need to make sure that these patches don't cause any data corruption. I have backported the patchset to the 4.15, 5.4 and 5.8 kernels. Backports for 5.4 and 5.8 kernels: https://paste.ubuntu.com/p/vPFFPMjhbv/ https://paste.ubuntu.com/p/MCGH8v7Rqk/ https://paste.ubuntu.com/p/rppy39Qgkz/ https://paste.ubuntu.com/p/Dsqy4PQNzJ/ https://paste.ubuntu.com/p/mZ9VDBD8d5/ https://paste.ubuntu.com/p/vJNYZyGTWH/ https://paste.ubuntu.com/p/M4sMwhgWTj/ Backports for the 4.15 kernel: https://paste.ubuntu.com/p/X9rRHT59qf/ https://paste.ubuntu.com/p/VWwW9JbBHy/ https://paste.ubuntu.com/p/pFY3YbBW6t/ https://paste.ubuntu.com/p/JKg4KcHwPB/ https://paste.ubuntu.com/p/C4sf2r9jS4/ I have built test kernels for bionic, bionic HWE, focal and groovy. Performance testing confirms that the testcase for formatting a Raid10 array on NVMe disks drops from 8.5 minutes to about 6 seconds, on AWS i3.8xlarge, due to the speedup in block discard. https://paste.ubuntu.com/p/NNGqP3xdsc/ I have also run through the data corruption regression reproducer from bug 1907262, and throughout the process, the /sys/block/md0/md/mismatch_cnt was always 0, and all deep fsck checks came back clean for individual disks. https://paste.ubuntu.com/p/5DK57TzdFH/ I am happy with these results, and its time to get some wider testing on these patches. If you are interested in helping to test, please use dedicated test servers, and not production systems. These patches have caused data corruption before, so only place data on the Raid10 array that you have copies of elsewhere, and assume that total data loss could happen anytime. Please note, these test kernels are NOT SUPPORTED by Canonical, and are for TEST PURPOSES ONLY. ONLY install in a dedicated test environment. Instructions to Install (on a Bionic or Focal or Groovy system): 1) sudo add-apt-repository ppa:mruffell/lp1896578-test 2) sudo apt update For Bionic: 3) sudo apt install linux-image-unsigned-4.15.0-136-generic linux-modules-4.15.0-136-generic linux-modules-extra-4.15.0-136-generic linux-headers-4.15.0-136-generic For Bionic HWE 5.4 or Focal: 3) sudo apt install linux-image-unsigned-5.4.0-66-generic linux-modules-5.4.0-66-generic linux-modules-extra-5.4.0-66-generic linux-headers-5.4.0-66-generic For Groovy: 3) sudo apt install linux-image-unsigned-5.8.0-44-generic linux-modules-5.8.0-44-generic linux-modules-extra-5.8.0-44-generic linux-headers-5.8.0-44-generic 4) sudo reboot 5) uname -rv Bionic: 4.15.0-136-generic #140+TEST1896578v20210212b1-Ubuntu SMP Fri Feb 12 03:00:17 UTC 2 Bionic HWE: 5.4.0-66-generic #74~18.04.2+TEST1896578v20210212b1-Ubuntu SMP Fri Feb 12 02:55:4 Focal: 5.4.0-66-generic #74+TEST1896578v20210212b1-Ubuntu SMP Fri Feb 12 06:30:51 UTC 20 Groovy: 5.8.0-44-generic #50+TEST1896578v20210212b1-Ubuntu SMP Fri Feb 12 06:19:49 UTC 20 Make sure the uname matches one of the above strings before you start testing and formatting Raid10 arrays. We want to test formatting the arrays with xfs, ext4, and general usage over time with regular consistency checks and fstrims. We want to make sure that mismatch counts are 0, and all fsck -f runs are clean, and no data corruption happens. If you have any problems whatsoever, please let me know. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1896578 Title: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Bug description: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on
[Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
Hi everyone, The original patch author, Xiao Ni, has sent a V2 patchset to the linux- raid mailing list for feedback. This new patchset fixes the problems the previous version had, namely, properly calculating the discard offset for second and onward disks, and correctly calculates the stripe size in far layouts. The patches are: https://www.spinics.net/lists/raid/msg67208.html https://www.spinics.net/lists/raid/msg67212.html https://www.spinics.net/lists/raid/msg67213.html https://www.spinics.net/lists/raid/msg67209.html https://www.spinics.net/lists/raid/msg67210.html https://www.spinics.net/lists/raid/msg67211.html We now need to thoroughly test and provide feedback to Xiao and the Raid subsystem maintainer before these patches can get merged into mainline again. We really need to make sure that these patches don't cause any data corruption. I have backported the patchset to the 4.15, 5.4 and 5.8 kernels. Backports for 5.4 and 5.8 kernels: https://paste.ubuntu.com/p/vPFFPMjhbv/ https://paste.ubuntu.com/p/MCGH8v7Rqk/ https://paste.ubuntu.com/p/rppy39Qgkz/ https://paste.ubuntu.com/p/Dsqy4PQNzJ/ https://paste.ubuntu.com/p/mZ9VDBD8d5/ https://paste.ubuntu.com/p/vJNYZyGTWH/ https://paste.ubuntu.com/p/M4sMwhgWTj/ Backports for the 4.15 kernel: https://paste.ubuntu.com/p/X9rRHT59qf/ https://paste.ubuntu.com/p/VWwW9JbBHy/ https://paste.ubuntu.com/p/pFY3YbBW6t/ https://paste.ubuntu.com/p/JKg4KcHwPB/ https://paste.ubuntu.com/p/C4sf2r9jS4/ I have built test kernels for bionic, bionic HWE, focal and groovy. Performance testing confirms that the testcase for formatting a Raid10 array on NVMe disks drops from 8.5 minutes to about 6 seconds, on AWS i3.8xlarge, due to the speedup in block discard. https://paste.ubuntu.com/p/NNGqP3xdsc/ I have also run through the data corruption regression reproducer from bug 1907262, and throughout the process, the /sys/block/md0/md/mismatch_cnt was always 0, and all deep fsck checks came back clean for individual disks. https://paste.ubuntu.com/p/5DK57TzdFH/ I am happy with these results, and its time to get some wider testing on these patches. If you are interested in helping to test, please use dedicated test servers, and not production systems. These patches have caused data corruption before, so only place data on the Raid10 array that you have copies of elsewhere, and assume that total data loss could happen anytime. Please note, these test kernels are NOT SUPPORTED by Canonical, and are for TEST PURPOSES ONLY. ONLY install in a dedicated test environment. Instructions to Install (on a Bionic or Focal or Groovy system): 1) sudo add-apt-repository ppa:mruffell/lp1896578-test 2) sudo apt update For Bionic: 3) sudo apt install linux-image-unsigned-4.15.0-136-generic linux-modules-4.15.0-136-generic linux-modules-extra-4.15.0-136-generic linux-headers-4.15.0-136-generic For Bionic HWE 5.4 or Focal: 3) sudo apt install linux-image-unsigned-5.4.0-66-generic linux-modules-5.4.0-66-generic linux-modules-extra-5.4.0-66-generic linux-headers-5.4.0-66-generic For Groovy: 3) sudo apt install linux-image-unsigned-5.8.0-44-generic linux-modules-5.8.0-44-generic linux-modules-extra-5.8.0-44-generic linux-headers-5.8.0-44-generic 4) sudo reboot 5) uname -rv Bionic: 4.15.0-136-generic #140+TEST1896578v20210212b1-Ubuntu SMP Fri Feb 12 03:00:17 UTC 2 Bionic HWE: 5.4.0-66-generic #74~18.04.2+TEST1896578v20210212b1-Ubuntu SMP Fri Feb 12 02:55:4 Focal: 5.4.0-66-generic #74+TEST1896578v20210212b1-Ubuntu SMP Fri Feb 12 06:30:51 UTC 20 Groovy: 5.8.0-44-generic #50+TEST1896578v20210212b1-Ubuntu SMP Fri Feb 12 06:19:49 UTC 20 Make sure the uname matches one of the above strings before you start testing and formatting Raid10 arrays. We want to test formatting the arrays with xfs, ext4, and general usage over time with regular consistency checks and fstrims. We want to make sure that mismatch counts are 0, and all fsck -f runs are clean, and no data corruption happens. If you have any problems whatsoever, please let me know. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896578 Title: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Description changed: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on Raid 0, takes 4 seconds. The bigger the devices, the longer it takes. The cause is that Raid10 currently uses a 512k chunk size, and uses this for the discard_max_bytes value. If we need to discard 1.9TB, the kernel splits the request into millions of 512k bio requests, even if the underlying device supports larger requests. For example, the NVMe devices on i3.8xlarge support 2.2TB of discard at once: $ cat /sys/block/nvme0n1/queue/discard_max_bytes 2199023255040 $ cat /sys/block/nvme0n1/queue/discard_max_hw_bytes 2199023255040 Where the Raid10 md device only supports 512k: $ cat /sys/block/md0/queue/discard_max_bytes 524288 $ cat /sys/block/md0/queue/discard_max_hw_bytes 524288 If we perform a mkfs.xfs operation on the /dev/md array, it takes over 11 minutes and if we examine the stack, it is stuck in blkdev_issue_discard() $ sudo cat /proc/1626/stack [<0>] wait_barrier+0x14c/0x230 [raid10] [<0>] regular_request_wait+0x39/0x150 [raid10] [<0>] raid10_write_request+0x11e/0x850 [raid10] [<0>] raid10_make_request+0xd7/0x150 [raid10] [<0>] md_handle_request+0x123/0x1a0 [<0>] md_submit_bio+0xda/0x120 [<0>] __submit_bio_noacct+0xde/0x320 [<0>] submit_bio_noacct+0x4d/0x90 [<0>] submit_bio+0x4f/0x1b0 [<0>] __blkdev_issue_discard+0x154/0x290 [<0>] blkdev_issue_discard+0x5d/0xc0 [<0>] blk_ioctl_discard+0xc4/0x110 [<0>] blkdev_common_ioctl+0x56c/0x840 [<0>] blkdev_ioctl+0xeb/0x270 [<0>] block_ioctl+0x3d/0x50 [<0>] __x64_sys_ioctl+0x91/0xc0 [<0>] do_syscall_64+0x38/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Fix] Xiao Ni has developed a patchset which resolves the block discard performance problems. These commits have now landed in 5.10-rc1. commit 2628089b74d5a64bd0bcb5d247a18f78d7b6f4d0 Author: Xiao Ni Date: Tue Aug 25 13:42:59 2020 +0800 Subject: md: add md_submit_discard_bio() for submitting discard bio Link: https://github.com/torvalds/linux/commit/2628089b74d5a64bd0bcb5d247a18f78d7b6f4d0 commit 8650a889017cb1f6ea6813ccf83a2e9f6fa49dd3 Author: Xiao Ni Date: Tue Aug 25 13:43:00 2020 +0800 Subject: md/raid10: extend r10bio devs to raid disks Link: https://github.com/torvalds/linux/commit/8650a889017cb1f6ea6813ccf83a2e9f6fa49dd3 commit f046f5d0d79cdb968f219ce249e497fd1accf484 Author: Xiao Ni Date: Tue Aug 25 13:43:01 2020 +0800 Subject: md/raid10: pull codes that wait for blocked dev into one function Link: https://github.com/torvalds/linux/commit/f046f5d0d79cdb968f219ce249e497fd1accf484 commit bcc90d280465ebd51ab8688be86e1f00c62dccf9 Author: Xiao Ni Date: Wed Sep 2 20:00:22 2020 +0800 Subject: md/raid10: improve raid10 discard request Link: https://github.com/torvalds/linux/commit/bcc90d280465ebd51ab8688be86e1f00c62dccf9 commit d3ee2d8415a6256c1c41e1be36e80e640c3e6359 Author: Xiao Ni Date: Wed Sep 2 20:00:23 2020 +0800 Subject: md/raid10: improve discard request for far layout Link: https://github.com/torvalds/linux/commit/d3ee2d8415a6256c1c41e1be36e80e640c3e6359 There is also an additional commit which is required, and was merged after "md/raid10: improve raid10 discard request" was merged. The following commits enable Radid10 to use large discards, instead of splitting into many bios, since the technical hurdles have now been removed. commit e0910c8e4f87bb9f767e61a778b0d9271c4dc512 Author: Mike Snitzer Date: Thu Sep 24 13:14:52 2020 -0400 Subject: dm raid: fix discard limits for raid1 and raid10 Link: https://github.com/torvalds/linux/commit/e0910c8e4f87bb9f767e61a778b0d9271c4dc512 commit f0e90b6c663a7e3b4736cb318c6c7c589f152c28 Author: Mike Snitzer Date: Thu Sep 24 16:40:12 2020 -0400 Subject: dm raid: remove unnecessary discard limits for raid10 Link: https://github.com/torvalds/linux/commit/f0e90b6c663a7e3b4736cb318c6c7c589f152c28 All the commits mentioned follow a similar strategy which was implemented in Raid0 in the below commit, which was merged in 4.12-rc2, which fixed block discard performance issues in Raid0: commit 29efc390b9462582ae95eb9a0b8cd17ab956afc0 Author: Shaohua Li Date: Sun May 7 17:36:24 2017 -0700 Subject: md/md0: optimize raid0 discard handling Link: https://github.com/torvalds/linux/commit/29efc390b9462582ae95eb9a0b8cd17ab956afc0 The commits more or less cherry pick to the 5.8, 5.4 and 4.15 kernels, with the following minor fixups: 1)
[Kernel-packages] [Bug 1896578] Re: raid10: Block discard is very slow, causing severe delays for mkfs and fstrim operations
** Description changed: BugLink: https://bugs.launchpad.net/bugs/1896578 [Impact] Block discard is very slow on Raid10, which causes common use cases which invoke block discard, such as mkfs and fstrim operations, to take a very long time. For example, on a i3.8xlarge instance on AWS, which has 4x 1.9TB NVMe devices which support block discard, a mkfs.xfs operation on Raid 10 takes between 8 to 11 minutes, where the same mkfs.xfs operation on Raid 0, takes 4 seconds. The bigger the devices, the longer it takes. The cause is that Raid10 currently uses a 512k chunk size, and uses this for the discard_max_bytes value. If we need to discard 1.9TB, the kernel splits the request into millions of 512k bio requests, even if the underlying device supports larger requests. For example, the NVMe devices on i3.8xlarge support 2.2TB of discard at once: $ cat /sys/block/nvme0n1/queue/discard_max_bytes 2199023255040 $ cat /sys/block/nvme0n1/queue/discard_max_hw_bytes 2199023255040 Where the Raid10 md device only supports 512k: $ cat /sys/block/md0/queue/discard_max_bytes 524288 $ cat /sys/block/md0/queue/discard_max_hw_bytes 524288 If we perform a mkfs.xfs operation on the /dev/md array, it takes over 11 minutes and if we examine the stack, it is stuck in blkdev_issue_discard() $ sudo cat /proc/1626/stack [<0>] wait_barrier+0x14c/0x230 [raid10] [<0>] regular_request_wait+0x39/0x150 [raid10] [<0>] raid10_write_request+0x11e/0x850 [raid10] [<0>] raid10_make_request+0xd7/0x150 [raid10] [<0>] md_handle_request+0x123/0x1a0 [<0>] md_submit_bio+0xda/0x120 [<0>] __submit_bio_noacct+0xde/0x320 [<0>] submit_bio_noacct+0x4d/0x90 [<0>] submit_bio+0x4f/0x1b0 [<0>] __blkdev_issue_discard+0x154/0x290 [<0>] blkdev_issue_discard+0x5d/0xc0 [<0>] blk_ioctl_discard+0xc4/0x110 [<0>] blkdev_common_ioctl+0x56c/0x840 [<0>] blkdev_ioctl+0xeb/0x270 [<0>] block_ioctl+0x3d/0x50 [<0>] __x64_sys_ioctl+0x91/0xc0 [<0>] do_syscall_64+0x38/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Fix] Xiao Ni has developed a patchset which resolves the block discard performance problems. These commits have now landed in 5.10-rc1. commit 2628089b74d5a64bd0bcb5d247a18f78d7b6f4d0 Author: Xiao Ni Date: Tue Aug 25 13:42:59 2020 +0800 Subject: md: add md_submit_discard_bio() for submitting discard bio Link: https://github.com/torvalds/linux/commit/2628089b74d5a64bd0bcb5d247a18f78d7b6f4d0 commit 8650a889017cb1f6ea6813ccf83a2e9f6fa49dd3 Author: Xiao Ni Date: Tue Aug 25 13:43:00 2020 +0800 Subject: md/raid10: extend r10bio devs to raid disks Link: https://github.com/torvalds/linux/commit/8650a889017cb1f6ea6813ccf83a2e9f6fa49dd3 commit f046f5d0d79cdb968f219ce249e497fd1accf484 Author: Xiao Ni Date: Tue Aug 25 13:43:01 2020 +0800 Subject: md/raid10: pull codes that wait for blocked dev into one function Link: https://github.com/torvalds/linux/commit/f046f5d0d79cdb968f219ce249e497fd1accf484 commit bcc90d280465ebd51ab8688be86e1f00c62dccf9 Author: Xiao Ni Date: Wed Sep 2 20:00:22 2020 +0800 Subject: md/raid10: improve raid10 discard request Link: https://github.com/torvalds/linux/commit/bcc90d280465ebd51ab8688be86e1f00c62dccf9 commit d3ee2d8415a6256c1c41e1be36e80e640c3e6359 Author: Xiao Ni Date: Wed Sep 2 20:00:23 2020 +0800 Subject: md/raid10: improve discard request for far layout Link: https://github.com/torvalds/linux/commit/d3ee2d8415a6256c1c41e1be36e80e640c3e6359 There is also an additional commit which is required, and was merged after "md/raid10: improve raid10 discard request" was merged. The following commits enable Radid10 to use large discards, instead of splitting into many bios, since the technical hurdles have now been removed. commit e0910c8e4f87bb9f767e61a778b0d9271c4dc512 Author: Mike Snitzer Date: Thu Sep 24 13:14:52 2020 -0400 Subject: dm raid: fix discard limits for raid1 and raid10 Link: https://github.com/torvalds/linux/commit/e0910c8e4f87bb9f767e61a778b0d9271c4dc512 commit f0e90b6c663a7e3b4736cb318c6c7c589f152c28 Author: Mike Snitzer Date: Thu Sep 24 16:40:12 2020 -0400 Subject: dm raid: remove unnecessary discard limits for raid10 Link: https://github.com/torvalds/linux/commit/f0e90b6c663a7e3b4736cb318c6c7c589f152c28 All the commits mentioned follow a similar strategy which was implemented in Raid0 in the below commit, which was merged in 4.12-rc2, which fixed block discard performance issues in Raid0: commit 29efc390b9462582ae95eb9a0b8cd17ab956afc0 Author: Shaohua Li Date: Sun May 7 17:36:24 2017 -0700 Subject: md/md0: optimize raid0 discard handling Link: https://github.com/torvalds/linux/commit/29efc390b9462582ae95eb9a0b8cd17ab956afc0 The commits more or less cherry pick to the 5.8, 5.4 and 4.15 kernels, with the following minor fixups: 1)
[Bug 1909062] Re: qede: Kubernetes Internal DNS Failure due to QL41xxx NIC not supporting IPIP tx csum offload
Performing verification for Focal. The affected user enabled -proposed and installed 5.4.0-66-generic to the system with a QLogic FastLinQ QL41000 Series 10/25/40/50GbE Controller. They then set all interfaces down, and brought up the QLogic NIC only. # uname -rv 5.4.0-66-generic #74~18.04.2-Ubuntu SMP Fri Feb 5 11:17:31 UTC 2021 # nslookup internal.kubernetes.domain.example 10.1.0.10 Server: 10.1.0.10 Address: 10.1.0.10#53 Name: internal.kubernetes.domain.example Address: 10.48.24.11 # ethtool -k eno1 | grep tx-checksumming tx-checksumming: on # ethtool -k enp94s0f0 | grep tx-checksumming tx-checksumming: on DNS lookup to an internal kubernetes domain with IPIP type DNS lookups work as intended, with tx checksumming enabled. The kernel in -proposed fixes the issue, marking as verified. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909062 Title: qede: Kubernetes Internal DNS Failure due to QL41xxx NIC not supporting IPIP tx csum offload To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1909062/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
