[Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Performing verification for Groovy. I went and generated the ssl certificates and attempted to verify them with the openssl version 1.1.1f-1ubuntu4.3 from -updates. ubuntu@deep-mako:~$ sudo apt-cache policy openssl | grep Installed Installed: 1.1.1f-1ubuntu4.3 ubuntu@deep-mako:~$ mkdir reproducer ubuntu@deep-mako:~$ cd reproducer ubuntu@deep-mako:~/reproducer$ mkdir CA ubuntu@deep-mako:~/reproducer$ 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 ubuntu@deep-mako:~/reproducer$ 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 ubuntu@deep-mako:~/reproducer$ 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 ubuntu@deep-mako:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt rsa_keygen_bits:2048 + + ubuntu@deep-mako:~/reproducer$ 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 ubuntu@deep-mako:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt rsa_keygen_bits:2048 ..+ .+ ubuntu@deep-mako:~/reproducer$ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 ubuntu@deep-mako:~/reproducer$ 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 Signature ok subject=C = DE, O = Test Org, CN = Test RSA PSS Sub-CA Getting CA Private Key ubuntu@deep-mako:~/reproducer$ c_rehash CA Doing CA ubuntu@deep-mako:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt rsa_keygen_bits:2048 ...+ .+ ubuntu@deep-mako:~/reproducer$ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 ubuntu@deep-mako:~/reproducer$ 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 Signature ok subject=C = DE, O = Test Org, CN = Test User Getting CA Private Key Now going and verifying the certificates: ubuntu@deep-mako:~/reproducer$ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem C = DE, O = Test Org, CN = Test User error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed We see verification failed, again on CA:FALSE,pathlen:0 basicConstraints. Now if we enable -proposed and install openssl 1.1.1f-1ubuntu4.4. $ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem user1_cert.pem: OK The certificate verifies properly. The problem is fixed. Additionally, if we examine the new unit tests added to openssl's testsuite in the buildlog for Groovy: https://launchpadlibrarian.net/537503607/buildlog_ubuntu-groovy- amd64.openssl_1.1.1f-1ubuntu4.4_BUILDING.txt.gz We see: ../../util/shlib_wrap.sh ../../apps/openssl verify -auth_level 1 -purpose sslserver -trusted ../../../test/certs/root-cert.pem -untrusted ../../../test/certs/ca-cert.pem ../../../test/certs/ee-pathlen.pem => 0 ok 84 - accept non-ca with pathlen:0 by default CN = server.example error 41 at 0 depth lookup: invalid or inconsistent certificate extension error ../../../test/certs/ee-pathlen.pem: verification failed ../../util/shlib_wrap.sh ../../apps/openssl verify -auth_level 1 -purpose sslserver -x509_strict -trusted
[Touch-packages] [Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Performing verification for Focal Generating the ssl certificates, and reproducing the problem with version 1.1.1f-1ubuntu2.3 from -updates. ubuntu@select-lobster:~$ sudo apt-cache policy openssl | grep Installed Installed: 1.1.1f-1ubuntu2.3 ubuntu@select-lobster:~$ mkdir reproducer ubuntu@select-lobster:~$ cd reproducer ubuntu@select-lobster:~/reproducer$ mkdir CA ubuntu@select-lobster:~/reproducer$ 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 ubuntu@select-lobster:~/reproducer$ 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 ubuntu@select-lobster:~/reproducer$ 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 ubuntu@select-lobster:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt rsa_keygen_bits:2048 ..+ + ubuntu@select-lobster:~/reproducer$ 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 ubuntu@select-lobster:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt rsa_keygen_bits:2048 + + ubuntu@select-lobster:~/reproducer$ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 ubuntu@select-lobster:~/reproducer$ 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 Signature ok subject=C = DE, O = Test Org, CN = Test RSA PSS Sub-CA Getting CA Private Key ubuntu@select-lobster:~/reproducer$ c_rehash CA Doing CA ubuntu@select-lobster:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt rsa_keygen_bits:2048 ...+ .+ ubuntu@select-lobster:~/reproducer$ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 ubuntu@select-lobster:~/reproducer$ 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 Signature ok subject=C = DE, O = Test Org, CN = Test User Getting CA Private Key Now, we verify the certificates: ubuntu@select-lobster:~/reproducer$ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem C = DE, O = Test Org, CN = Test User error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed We see verification fail, due to CA:FALSE,pathlen:0 basicConstraints. I then enabled -proposed, and installed openssl and libssl1.1 version 1.1.1f-1ubuntu2.4 If we then repeat the certificate validation: ubuntu@select-lobster:~/reproducer$ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem user1_cert.pem: OK The certificates validate properly. Additionally, if we examine the new unit tests added to openssl's testsuite in the buildlog for focal: https://launchpadlibrarian.net/537505620/buildlog_ubuntu-focal- amd64.openssl_1.1.1f-1ubuntu2.4_BUILDING.txt.gz we see: ../../../test/certs/ee-pathlen.pem: OK ../../util/shlib_wrap.sh ../../apps/openssl verify -auth_level 1 -purpose sslserver -trusted ../../../test/certs/root-cert.pem -untrusted ../../../test/certs/ca-cert.pem ../../../test/certs/ee-pathlen.pem => 0 ok 84 - accept non-ca with pathlen:0 by default CN = server.example error 41 at 0 depth lookup: invalid or inconsistent certificate extension error ../../../test/certs/ee-pathlen.pem: verification failed ../../util/shlib_wrap.sh ../../apps/openssl verify -auth_level
[Bug 1926254] Re: x509 Certificate verification fails when basicConstraints=CA:FALSE, pathlen:0 on self-signed leaf certs
Performing verification for Focal Generating the ssl certificates, and reproducing the problem with version 1.1.1f-1ubuntu2.3 from -updates. ubuntu@select-lobster:~$ sudo apt-cache policy openssl | grep Installed Installed: 1.1.1f-1ubuntu2.3 ubuntu@select-lobster:~$ mkdir reproducer ubuntu@select-lobster:~$ cd reproducer ubuntu@select-lobster:~/reproducer$ mkdir CA ubuntu@select-lobster:~/reproducer$ 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 ubuntu@select-lobster:~/reproducer$ 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 ubuntu@select-lobster:~/reproducer$ 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 ubuntu@select-lobster:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out rootCA_key.pem -pkeyopt rsa_keygen_bits:2048 ..+ + ubuntu@select-lobster:~/reproducer$ 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 ubuntu@select-lobster:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out subCA_key.pem -pkeyopt rsa_keygen_bits:2048 + + ubuntu@select-lobster:~/reproducer$ openssl req -config subCA.cnf -new -out subCA_req.pem -key subCA_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 ubuntu@select-lobster:~/reproducer$ 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 Signature ok subject=C = DE, O = Test Org, CN = Test RSA PSS Sub-CA Getting CA Private Key ubuntu@select-lobster:~/reproducer$ c_rehash CA Doing CA ubuntu@select-lobster:~/reproducer$ openssl genpkey -algorithm RSA-PSS -out user1_key.pem -pkeyopt rsa_keygen_bits:2048 ...+ .+ ubuntu@select-lobster:~/reproducer$ openssl req -config user.cnf -new -out user1_req.pem -key user1_key.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 ubuntu@select-lobster:~/reproducer$ 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 Signature ok subject=C = DE, O = Test Org, CN = Test User Getting CA Private Key Now, we verify the certificates: ubuntu@select-lobster:~/reproducer$ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem C = DE, O = Test Org, CN = Test User error 20 at 0 depth lookup: unable to get local issuer certificate error user1_cert.pem: verification failed We see verification fail, due to CA:FALSE,pathlen:0 basicConstraints. I then enabled -proposed, and installed openssl and libssl1.1 version 1.1.1f-1ubuntu2.4 If we then repeat the certificate validation: ubuntu@select-lobster:~/reproducer$ openssl verify -CAfile CA/rootCA_cert.pem -untrusted CA/subCA_cert.pem user1_cert.pem user1_cert.pem: OK The certificates validate properly. Additionally, if we examine the new unit tests added to openssl's testsuite in the buildlog for focal: https://launchpadlibrarian.net/537505620/buildlog_ubuntu-focal- amd64.openssl_1.1.1f-1ubuntu2.4_BUILDING.txt.gz we see: ../../../test/certs/ee-pathlen.pem: OK ../../util/shlib_wrap.sh ../../apps/openssl verify -auth_level 1 -purpose sslserver -trusted ../../../test/certs/root-cert.pem -untrusted ../../../test/certs/ca-cert.pem ../../../test/certs/ee-pathlen.pem => 0 ok 84 - accept non-ca with pathlen:0 by default CN = server.example error 41 at 0 depth lookup: invalid or inconsistent certificate extension error ../../../test/certs/ee-pathlen.pem: verification failed ../../util/shlib_wrap.sh ../../apps/openssl verify -auth_level
[ubuntu/xenial-proposed] grub2-signed 1.167~16.04.2 (Accepted)
grub2-signed (1.167~16.04.2) xenial; urgency=medium * Remove the line GRUB_DISTRIBUTOR=Debian from /etc/default/grub.d/50-cloudimg-settings.cfg on select cloud images, namely those produced for GCE before 2020-11-11. This ensures that UEFI instances can locate efi executables and grub.cfg in correct directories since grub 2.04 seems to enforce pedantic locations. (LP: #1928040) Date: Tue, 11 May 2021 19:38:29 +1200 Changed-By: Matthew Ruffell Maintainer: Colin Watson Signed-By: Łukasz Zemczak https://launchpad.net/ubuntu/+source/grub2-signed/1.167~16.04.2 Format: 1.8 Date: Tue, 11 May 2021 19:38:29 +1200 Source: grub2-signed Architecture: source Version: 1.167~16.04.2 Distribution: xenial Urgency: medium Maintainer: Colin Watson Changed-By: Matthew Ruffell Launchpad-Bugs-Fixed: 1928040 Changes: grub2-signed (1.167~16.04.2) xenial; urgency=medium . * Remove the line GRUB_DISTRIBUTOR=Debian from /etc/default/grub.d/50-cloudimg-settings.cfg on select cloud images, namely those produced for GCE before 2020-11-11. This ensures that UEFI instances can locate efi executables and grub.cfg in correct directories since grub 2.04 seems to enforce pedantic locations. (LP: #1928040) Checksums-Sha1: 5c7422a29e9f5d6b81967bc7d83afab9d34d37bf 1570 grub2-signed_1.167~16.04.2.dsc ffce063b2dceacc0a62e4ce193161004537ad7d3 9120 grub2-signed_1.167~16.04.2.tar.xz 9fa67638932cf2048c3f03994603e7608fd907d8 8000 grub2-signed_1.167~16.04.2_source.buildinfo Checksums-Sha256: b3bc57fbc07ea0b4f05c25b2b920010500fc4fa4a6650fa1a6452f52624d44b5 1570 grub2-signed_1.167~16.04.2.dsc eb6c1fe8ab116528e3ad3cf92410cb7c7aa06da7dfb2de25acfa9a83ee3633ca 9120 grub2-signed_1.167~16.04.2.tar.xz 7d043ded6893584e0c7d7d4c6ed3c097972cec8b7407a7a5ac6184d2bc8a73fe 8000 grub2-signed_1.167~16.04.2_source.buildinfo Files: aa8129d906dd1d713d2f1903f5eab53c 1570 utils optional grub2-signed_1.167~16.04.2.dsc 25c65304e76ffb921a521fbdfb3cc745 9120 utils optional grub2-signed_1.167~16.04.2.tar.xz d4c977761762dbf77976956144245a9c 8000 utils optional grub2-signed_1.167~16.04.2_source.buildinfo -- Xenial-changes mailing list Xenial-changes@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/xenial-changes
[Bug 1928040] Re: GCE instances drop to a grub prompt when GRUB_DISTRIBUTOR=Debian is set
Attached is a debdiff for grub2-signed which issues a sed to remove the GRUB_DISTRIBUTOR=Debian line from /etc/default/grub.d/50-cloudimg- settings.cfg ** Patch added: "Debdiff for grub2-signed on Xenial" https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1928040/+attachment/5496305/+files/lp1928040_xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928040 Title: GCE instances drop to a grub prompt when GRUB_DISTRIBUTOR=Debian is set To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1928040/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928040] Re: GCE instances drop to a grub prompt when GRUB_DISTRIBUTOR=Debian is set
** Description changed: [Impact] GCE cloud instances started with images released prior to 2020-11-11 will fail to reboot when the newest grub2 2.02~beta2-36ubuntu3.32 packages are installed from -updates. Upon reboot, the instance drops down to a grub prompt, and ceases to boot any further. The output displayed is: BdsDxe: loading Boot0003 "debian" from HD(15,GPT,,0x2800,0x35000)/\EFI\debian\shimx64.efi BdsDxe: starting Boot0003 "debian" from HD(15,GPT,,0x2800,0x35000)/\EFI\debian\shimx64.efi UEFI: Attempting to start image. Description: debian FilePath: HD(15,GPT,36903981-58D9-4718-A4EC-3D3E6CF6AF42,0x2800,0x35000)/\EFI\debian\shimx64.efi OptionNumber: 3. GNU GRUB version 2.04 grub> Now, on GCE cloud images prior to 2020-11-11, /etc/default/grub.d/50 -cloudimg-settings.cfg contained this line: GRUB_DISTRIBUTOR=Debian In images after 2020-11-11, this line was REMOVED from /etc/default/grub.d/50-cloudimg-settings.cfg and instead, images fell back to the below line in /etc/default/grub GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` The above line always returns "Ubuntu". The new grub2 version 2.02~beta2-36ubuntu3.32 now places the EFI executables in the /EFI/Ubuntu directory, while the grub config points to /EFI/Debian, and the grub config cannot be found, and hence we drop to a grub shell. [Testcase] You can start an instance up on Google Cloud with an affected image with the below command: gcloud compute instances create test-xenial-1 --image=ubuntu-1604-xenial-v20200429 --image-project=ubuntu-os-cloud From there: $ sudo apt update $ sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common $ sudo reboot The instance will not come back up, and you will see a grub shell in the logs on GCP. You can also reproduce in KVM. Simply add: GRUB_DISTRIBUTOR=Debian to a file in /etc/default/grub.d/50-cloudimg-settings.cfg then: $ sudo update-grub $ sudo reboot + Test packages are available in the following ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/lp1928040-test + + If you install these test packages, you should be able to upgrade grub + and reboot without issue. + [Where problems could occur] We will be changing the grub configuration for every Google cloud instance started with an image produced before 2020-11-11, and there is risk that we could make a change which prevents instances from booting. We should proceed with caution and make sure to test older and newer images. The fix will be targeted to the /etc/default/grub.d/50-cloudimg- settings.cfg file only, so only cloud instances would get the change, and only if the grub versions match particular versions. [Other info] A workaround is to remove the below line from /etc/default/grub.d/50 -cloudimg-settings.cfg before installing the new grub packages. GRUB_DISTRIBUTOR=Debian -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928040 Title: GCE instances drop to a grub prompt when GRUB_DISTRIBUTOR=Debian is set To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1928040/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Group.of.nepali.translators] [Bug 1928040] [NEW] GCE instances drop to a grub prompt when GRUB_DISTRIBUTOR=Debian is set
Public bug reported: [Impact] GCE cloud instances started with images released prior to 2020-11-11 will fail to reboot when the newest grub2 2.02~beta2-36ubuntu3.32 packages are installed from -updates. Upon reboot, the instance drops down to a grub prompt, and ceases to boot any further. The output displayed is: BdsDxe: loading Boot0003 "debian" from HD(15,GPT,,0x2800,0x35000)/\EFI\debian\shimx64.efi BdsDxe: starting Boot0003 "debian" from HD(15,GPT,,0x2800,0x35000)/\EFI\debian\shimx64.efi UEFI: Attempting to start image. Description: debian FilePath: HD(15,GPT,36903981-58D9-4718-A4EC-3D3E6CF6AF42,0x2800,0x35000)/\EFI\debian\shimx64.efi OptionNumber: 3. GNU GRUB version 2.04 grub> Now, on GCE cloud images prior to 2020-11-11, /etc/default/grub.d/50 -cloudimg-settings.cfg contained this line: GRUB_DISTRIBUTOR=Debian In images after 2020-11-11, this line was REMOVED from /etc/default/grub.d/50-cloudimg-settings.cfg and instead, images fell back to the below line in /etc/default/grub GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` The above line always returns "Ubuntu". The new grub2 version 2.02~beta2-36ubuntu3.32 now places the EFI executables in the /EFI/Ubuntu directory, while the grub config points to /EFI/Debian, and the grub config cannot be found, and hence we drop to a grub shell. [Testcase] You can start an instance up on Google Cloud with an affected image with the below command: gcloud compute instances create test-xenial-1 --image=ubuntu-1604-xenial-v20200429 --image-project=ubuntu-os-cloud >From there: $ sudo apt update $ sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common $ sudo reboot The instance will not come back up, and you will see a grub shell in the logs on GCP. You can also reproduce in KVM. Simply add: GRUB_DISTRIBUTOR=Debian to a file in /etc/default/grub.d/50-cloudimg-settings.cfg then: $ sudo update-grub $ sudo reboot [Where problems could occur] We will be changing the grub configuration for every Google cloud instance started with an image produced before 2020-11-11, and there is risk that we could make a change which prevents instances from booting. We should proceed with caution and make sure to test older and newer images. The fix will be targeted to the /etc/default/grub.d/50-cloudimg- settings.cfg file only, so only cloud instances would get the change, and only if the grub versions match particular versions. [Other info] A workaround is to remove the below line from /etc/default/grub.d/50 -cloudimg-settings.cfg before installing the new grub packages. GRUB_DISTRIBUTOR=Debian ** Affects: grub2 (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: grub2 (Ubuntu Xenial) Importance: Critical Status: In Progress ** Tags: sts xenial ** Also affects: grub2 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: grub2 (Ubuntu) Status: New => Fix Released ** Changed in: grub2 (Ubuntu Xenial) Importance: Undecided => Critical ** Changed in: grub2 (Ubuntu Xenial) Status: New => In Progress ** Tags added: sts xenial -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1928040 Title: GCE instances drop to a grub prompt when GRUB_DISTRIBUTOR=Debian is set Status in grub2 package in Ubuntu: Fix Released Status in grub2 source package in Xenial: In Progress Bug description: [Impact] GCE cloud instances started with images released prior to 2020-11-11 will fail to reboot when the newest grub2 2.02~beta2-36ubuntu3.32 packages are installed from -updates. Upon reboot, the instance drops down to a grub prompt, and ceases to boot any further. The output displayed is: BdsDxe: loading Boot0003 "debian" from HD(15,GPT,,0x2800,0x35000)/\EFI\debian\shimx64.efi BdsDxe: starting Boot0003 "debian" from HD(15,GPT,,0x2800,0x35000)/\EFI\debian\shimx64.efi UEFI: Attempting to start image. Description: debian FilePath: HD(15,GPT,36903981-58D9-4718-A4EC-3D3E6CF6AF42,0x2800,0x35000)/\EFI\debian\shimx64.efi OptionNumber: 3. GNU GRUB version 2.04 grub> Now, on GCE cloud images prior to 2020-11-11, /etc/default/grub.d/50 -cloudimg-settings.cfg contained this line: GRUB_DISTRIBUTOR=Debian In images after 2020-11-11, this line was REMOVED from /etc/default/grub.d/50-cloudimg-settings.cfg and instead, images fell back to the below line in /etc/default/grub GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` The above line always returns "Ubuntu". The new grub2 version 2.02~beta2-36ubuntu3.32 now places the EFI executables in the /EFI/Ubuntu directory, while the grub config points to /EFI/Debian, and the grub config cannot be found, and hence we drop to a grub shell. [Testcase] You
[Bug 1928040] [NEW] GCE instances drop to a grub prompt when GRUB_DISTRIBUTOR=Debian is set
Public bug reported: [Impact] GCE cloud instances started with images released prior to 2020-11-11 will fail to reboot when the newest grub2 2.02~beta2-36ubuntu3.32 packages are installed from -updates. Upon reboot, the instance drops down to a grub prompt, and ceases to boot any further. The output displayed is: BdsDxe: loading Boot0003 "debian" from HD(15,GPT,,0x2800,0x35000)/\EFI\debian\shimx64.efi BdsDxe: starting Boot0003 "debian" from HD(15,GPT,,0x2800,0x35000)/\EFI\debian\shimx64.efi UEFI: Attempting to start image. Description: debian FilePath: HD(15,GPT,36903981-58D9-4718-A4EC-3D3E6CF6AF42,0x2800,0x35000)/\EFI\debian\shimx64.efi OptionNumber: 3. GNU GRUB version 2.04 grub> Now, on GCE cloud images prior to 2020-11-11, /etc/default/grub.d/50 -cloudimg-settings.cfg contained this line: GRUB_DISTRIBUTOR=Debian In images after 2020-11-11, this line was REMOVED from /etc/default/grub.d/50-cloudimg-settings.cfg and instead, images fell back to the below line in /etc/default/grub GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` The above line always returns "Ubuntu". The new grub2 version 2.02~beta2-36ubuntu3.32 now places the EFI executables in the /EFI/Ubuntu directory, while the grub config points to /EFI/Debian, and the grub config cannot be found, and hence we drop to a grub shell. [Testcase] You can start an instance up on Google Cloud with an affected image with the below command: gcloud compute instances create test-xenial-1 --image=ubuntu-1604-xenial-v20200429 --image-project=ubuntu-os-cloud >From there: $ sudo apt update $ sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common $ sudo reboot The instance will not come back up, and you will see a grub shell in the logs on GCP. You can also reproduce in KVM. Simply add: GRUB_DISTRIBUTOR=Debian to a file in /etc/default/grub.d/50-cloudimg-settings.cfg then: $ sudo update-grub $ sudo reboot [Where problems could occur] We will be changing the grub configuration for every Google cloud instance started with an image produced before 2020-11-11, and there is risk that we could make a change which prevents instances from booting. We should proceed with caution and make sure to test older and newer images. The fix will be targeted to the /etc/default/grub.d/50-cloudimg- settings.cfg file only, so only cloud instances would get the change, and only if the grub versions match particular versions. [Other info] A workaround is to remove the below line from /etc/default/grub.d/50 -cloudimg-settings.cfg before installing the new grub packages. GRUB_DISTRIBUTOR=Debian ** Affects: grub2 (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: grub2 (Ubuntu Xenial) Importance: Critical Status: In Progress ** Tags: sts xenial ** Also affects: grub2 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: grub2 (Ubuntu) Status: New => Fix Released ** Changed in: grub2 (Ubuntu Xenial) Importance: Undecided => Critical ** Changed in: grub2 (Ubuntu Xenial) Status: New => In Progress ** Tags added: sts xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928040 Title: GCE instances drop to a grub prompt when GRUB_DISTRIBUTOR=Debian is set To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1928040/+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
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 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.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
[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. + 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 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 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.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
[Kernel-packages] [Bug 1907262] Re: raid10: discard leads to corrupted file system
Hi Thimo, I have been doing quite a bit of regression testing, and so far everything is looking good. The performance of the block discard is there, and I haven't come across any data corruption. I have also spent some time running through the testcase you created for this bug, and I have the results of those tests below. 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'm going to look into some longer running test cases as well, so far I have been focusing on short term (less than six hour) test cases. Otherwise, I have submitted the patches to the Ubuntu kernel mailing list for SRU. Now, these patches will still be subject to review by senior members of the kernel team, and their approval is required before they get applied to the official Ubuntu kernels. I will let you know if they get approval or not. In the meantime, please test the test kernels, and if you find any issues at all with the test kernels, 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/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 :
[Bug 1907262] Re: raid10: discard leads to corrupted file system
Hi Thimo, I have been doing quite a bit of regression testing, and so far everything is looking good. The performance of the block discard is there, and I haven't come across any data corruption. I have also spent some time running through the testcase you created for this bug, and I have the results of those tests below. 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'm going to look into some longer running test cases as well, so far I have been focusing on short term (less than six hour) test cases. Otherwise, I have submitted the patches to the Ubuntu kernel mailing list for SRU. Now, these patches will still be subject to review by senior members of the kernel team, and their approval is required before they get applied to the official Ubuntu kernels. I will let you know if they get approval or not. In the meantime, please test the test kernels, and if you find any issues at all with the test kernels, 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/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 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