[Touch-packages] [Bug 1934286] Re: Update the ModemManager to 1.16.6-2 to support some modems in Focal and Hirsute releases.

[Kent Lin]

Test pass with Dell DW5821e [413C:81D7] on hirsute

* The version of the packages tested:
   ModemManager: 1.16.6
   libmbim: 1.24.8
   libqmi: 1.28.6

** Attachment added: "DW5821e.log"
   
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1934286/+attachment/5520406/+files/DW5821e.log

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to modemmanager in Ubuntu.
https://bugs.launchpad.net/bugs/1934286

Title:
  Update the ModemManager to 1.16.6-2 to support some modems in Focal
  and Hirsute releases.

Status in OEM Priority Project:
  Confirmed
Status in libmbim package in Ubuntu:
  Fix Released
Status in libqmi package in Ubuntu:
  Fix Released
Status in modemmanager package in Ubuntu:
  Fix Released
Status in libmbim source package in Focal:
  Fix Committed
Status in libqmi source package in Focal:
  Fix Committed
Status in modemmanager source package in Focal:
  Fix Committed
Status in libmbim source package in Hirsute:
  Fix Committed
Status in libqmi source package in Hirsute:
  Fix Committed
Status in modemmanager source package in Hirsute:
  Fix Committed

Bug description:
  [Impact]

  Some IOT products use wireless modems which can be working only when
  recent versions of the ModemManager suite are used.

  The following 2 modems need the ModemManager suite to be upgraded:
  * Foxconn SDX55 T99W175 5G sub6 PCIE Modem
  * Quectel SDX24 EM160R-GL 4G LTE CAT16 PCIE Modem

  The main fix requested is to add the FCC unlock mechanism for Foxconn modems.
  * FCC unlock operation for Foxconn modems
  
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/534/commits
  * dms: new 'Foxconn Set FCC authentication' command
  
https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/254/commits

  The minimum versions of the ModemManager suite required to enable the support 
for the above 2 mentioned modems have been verified: (LP: #1928665)
  * ModemManager: 1.16.6
  * libmbim: 1.24.8
  * libqmi : 1.28.6

  The ModemManager suite in the Impish release meets the requirements.

  [Test Plan]

  = How to Reproduce the Bug =

  Execute the following commands to list the modems detected by
  ModemManager in Hirsute and Focal releases:

  $ mmcli --list-modems
  No modems were found

  = Test Procedure =

  1. Install the Ubuntu system on the tested hardware

    The following images will be used to verify the version of the ModemManager 
suite:
    * Impish: 
https://cdimage.ubuntu.com/daily-live/current/impish-desktop-amd64.iso
    * Hirsute: https://releases.ubuntu.com/21.04/ubuntu-21.04-desktop-amd64.iso
    * Focal: 
https://releases.ubuntu.com/focal/ubuntu-20.04.2.0-desktop-amd64.iso

  2. Upgrade the kernel and driver  ( for Foxconn and Quectel modem )

    The kernel needs to get some patches from 5.13 and includes a back ported 
Quectel driver to support these 2 modems.
    We have prepared a kernel packages for testing: 
https://people.canonical.com/~mschiu77/lp1928665/v2/

  3. Install the ModemManager suite ( for Hirsute and Focal releases )

    The ModemManager suite will be installed from the -proposed
  component:

  $ sudo apt update
  $ sudo apt install modemmanager
  $ sudo apt install libqmi-utils

  4. Execute the following commands

  4.1 Get the run-time environment

  $ uname -ar
  $ lsb_release -a
  $ mmcli -V
  $ qmicli -V

  4.2 Check the status of the ModemManager service

  $ sudo systemctl status ModemManager.service

  4.3 List the detected modems

  $ mmcli --list-modems

  4.4 Check the modem’s status

  $ mmcli --modem 0

  4.5 Install and execute Lenovo’s FCC unlock app ( for Quectel modem
  only )

  $ sudo snap install --devmode --dangerous dpr-wwan_1.0-wwan-
  test_amd64.snap

  4.6 Enable the detected modem

  $ sudo mmcli --modem 0 --enable

  4.7 Check the modem’s status

  $ mmcli --modem 0

  = Analyze the Tested Result =

  1. Check if installed packages are working

    The result of test procedure 4.1 and 4.2 can be used to make sure the 
installed packages are working.
    If the Modemmanager.service is active(running), the packages are working.

  2. Check if the supported modem can be detected

    The result of test procedure 4.3 can be used to see if the modem can be 
detected by ModemManager or not.
    The supported modems should be listed.

  3. Check if the modem can be enabled

    If the modem can be enabled, the state of the modem in the test
  procedure 4.7 will be set to be registered.

  = Certification Validation =

  Additionally to the aforementioned test cases, the Certification Team
  will perform some coverage testing across supported devices to make
  sure the other modems still work as expected.

  [Where problems could occur]

  There is a risk that modems supported in the old versions of
  ModemManager suite may not be supported in the newer versions.

  [Other Info]

  We need to upgrade to these 3 packages (in Impish) at the s

[Touch-packages] [Bug 1941030] Re: Screen FLickers

[Daniel van Vugt]

Thanks for the bug report. Please try adding this kernel parameter:

  i915.enable_psr=0

which you can do by editing /etc/default/grub, adding the parameter to
the GRUB_CMDLINE_LINUX_DEFAULT line, and then run:

  sudo update-grub

and reboot.

** Package changed: xorg (Ubuntu) => linux-hwe-5.11 (Ubuntu)

** Summary changed:

- Screen FLickers
+ [Fujitsu Lifebook U7411] Screen Flickers

** Changed in: linux-hwe-5.11 (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1941030

Title:
  [Fujitsu Lifebook U7411] Screen Flickers

Status in linux-hwe-5.11 package in Ubuntu:
  Incomplete

Bug description:
  After the laptop goes to sleep mode, it starts to flicker when i try
  to use the laptop.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.11.0-27.29~20.04.1-generic 5.11.22
  Uname: Linux 5.11.0-27-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Aug 25 10:10:33 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Intel Corporation Device [8086:9a49] (rev 01) (prog-if 00 [VGA controller])
 Subsystem: Fujitsu Client Computing Limited Device [1e26:0050]
  InstallationDate: Installed on 2021-08-18 (6 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  MachineType: FUJITSU CLIENT COMPUTING LIMITED LIFEBOOK U7411
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-27-generic 
root=UUID=2ef2e3af-1c99-45d0-8bdf-5c9bd7e07ab9 ro quiet splash pcie_aspm=off 
vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/28/2021
  dmi.bios.release: 2.21
  dmi.bios.vendor: FUJITSU CLIENT COMPUTING LIMITED
  dmi.bios.version: Version 2.21
  dmi.board.name: FJNB2E7
  dmi.board.vendor: FUJITSU CLIENT COMPUTING LIMITED
  dmi.board.version: A3
  dmi.chassis.type: 10
  dmi.chassis.vendor: FUJITSU CLIENT COMPUTING LIMITED
  dmi.modalias: 
dmi:bvnFUJITSUCLIENTCOMPUTINGLIMITED:bvrVersion2.21:bd06/28/2021:br2.21:svnFUJITSUCLIENTCOMPUTINGLIMITED:pnLIFEBOOKU7411:pvr:rvnFUJITSUCLIENTCOMPUTINGLIMITED:rnFJNB2E7:rvrA3:cvnFUJITSUCLIENTCOMPUTINGLIMITED:ct10:cvr:
  dmi.product.family: LIFEBOOK-FPCA
  dmi.product.name: LIFEBOOK U7411
  dmi.product.sku: SK01
  dmi.sys.vendor: FUJITSU CLIENT COMPUTING LIMITED
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.105-3~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.3~20.04.1
  version.libgl1-mesa-glx: libgl1-mesa-glx 21.0.3-0ubuntu0.3~20.04.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1~20.04.2
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe-5.11/+bug/1941030/+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 1941030] [NEW] Screen FLickers

[Urpan Adhikari]

Public bug reported:

After the laptop goes to sleep mode, it starts to flicker when i try to
use the laptop.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.11.0-27.29~20.04.1-generic 5.11.22
Uname: Linux 5.11.0-27-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Wed Aug 25 10:10:33 2021
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Intel Corporation Device [8086:9a49] (rev 01) (prog-if 00 [VGA controller])
   Subsystem: Fujitsu Client Computing Limited Device [1e26:0050]
InstallationDate: Installed on 2021-08-18 (6 days ago)
InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
MachineType: FUJITSU CLIENT COMPUTING LIMITED LIFEBOOK U7411
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-27-generic 
root=UUID=2ef2e3af-1c99-45d0-8bdf-5c9bd7e07ab9 ro quiet splash pcie_aspm=off 
vt.handoff=7
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/28/2021
dmi.bios.release: 2.21
dmi.bios.vendor: FUJITSU CLIENT COMPUTING LIMITED
dmi.bios.version: Version 2.21
dmi.board.name: FJNB2E7
dmi.board.vendor: FUJITSU CLIENT COMPUTING LIMITED
dmi.board.version: A3
dmi.chassis.type: 10
dmi.chassis.vendor: FUJITSU CLIENT COMPUTING LIMITED
dmi.modalias: 
dmi:bvnFUJITSUCLIENTCOMPUTINGLIMITED:bvrVersion2.21:bd06/28/2021:br2.21:svnFUJITSUCLIENTCOMPUTINGLIMITED:pnLIFEBOOKU7411:pvr:rvnFUJITSUCLIENTCOMPUTINGLIMITED:rnFJNB2E7:rvrA3:cvnFUJITSUCLIENTCOMPUTINGLIMITED:ct10:cvr:
dmi.product.family: LIFEBOOK-FPCA
dmi.product.name: LIFEBOOK U7411
dmi.product.sku: SK01
dmi.sys.vendor: FUJITSU CLIENT COMPUTING LIMITED
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.105-3~20.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.3~20.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx 21.0.3-0ubuntu0.3~20.04.1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1~20.04.2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

** Affects: xorg (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug focal ubuntu

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1941030

Title:
  Screen FLickers

Status in xorg package in Ubuntu:
  New

Bug description:
  After the laptop goes to sleep mode, it starts to flicker when i try
  to use the laptop.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: xorg 1:7.7+19ubuntu14
  ProcVersionSignature: Ubuntu 5.11.0-27.29~20.04.1-generic 5.11.22
  Uname: Linux 5.11.0-27-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: skip
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Aug 25 10:10:33 2021
  DistUpgraded: Fresh install
  DistroCodename: focal
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes, if not too technical
  GraphicsCard:
   Intel Corporation Device [8086:9a49] (rev 01) (prog-if 00 [VGA controller])
 Subsystem: Fujitsu Client Computing Limited Device [1e26:0050]
  InstallationDate: Installed on 2021-08-18 (6 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  MachineType: FUJITSU CLIENT COMPUTING LIMITED LIFEBOOK U7411
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-27-generic 
root=UUID=2ef2e3af-1c99-45d0-8bdf-5c9bd7e07ab9 ro quiet splash pcie_aspm=off 
vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 06/28/2021
  dmi.bios.release: 2.21
  dmi.bios.vendor: FUJITSU CLIENT COMPUTING LIMITED
  dmi.bios.version: Version 2.21
  dmi.board.name: FJNB2E7
  dmi.board.vendor: FUJITSU CLIENT COMPUTING LIMITED
  dmi.board.version: A3
  dmi.chassis.type: 10
  dmi.chassis.vendor: FUJITSU CLIENT COMPUTING LIMITED
  dmi.modalias: 
dmi:bvnFUJITSUCLIENTCOMPUTINGLIMITED:bvrVersion2.21:bd06/28/2021:br2.21:svnFUJITSUCLIENTCOMPUTINGLIMITED:pnLIFEBOOKU7411:pvr:rvnFUJITSUCLIENTCOMPUTINGLIMITED:rnFJNB2E7:rvrA3:cvnFUJITSUCLIENTCOMPUTINGLIMITED:ct10:cvr:
  dmi.product.family: LIFEBOOK-FPCA
  dmi.product.name: LIFEBOOK U7411
  dmi.product.sku: SK01
  dmi.sys.vendor: FUJITSU CLIENT COMPUTING LIMITED
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.105-3~20.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.3~20.04.1
  version.libgl1-mesa-glx: libgl

[Touch-packages] [Bug 1921518] Re: OpenSSL "double free" error

[Dimitri John Ledkov]

The updated openssl package does not change any behaviour w.r.t. config
or engine use. It only has three patches applied to prevent potential
use-after-free errors. It also relies on installing the new PKA engine
with patches from github.

Has the new PKA engine been recompiled and installed correctly?

When installed on my system, the engines configured continued to be
used, and I can observe PKA debug output when using `openssl s_client
-connect` or `curl`.

Note, that `speed` command, by default does not use engines, even when
configured in /etc/ssl/openssl.cnf. One must pass `-engine ID` option to
it to use an engine.

-- 
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/1921518

Title:
  OpenSSL "double free" error

Status in openssl package in Ubuntu:
  Incomplete
Status in openssl source package in Focal:
  Incomplete

Bug description:
  "double free" error is seen when using curl utility. Error is from
  libcrypto.so which is part of the OpenSSL package. This happens only
  when OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  
  OpenSSL can be configured to use a dynamic engine by editing the default 
openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu 
systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids
   
  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1921518/+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 1678187] Re: Removing a linux-image-extra package fails, if /boot is about full

[Hayden Clark]

Thanks for that advice.
I'm a bit in trepidation about removing the default HWE. How do I protect 
myself from having an unbootable system?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1678187

Title:
  Removing a linux-image-extra package fails, if /boot is about full

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  System calls /etc/kernel/postinst.d/initramfs-tools when
  purging/removing a linux-image-extra package. That calls "update-
  initramfs -c" which needs significant amount of additional disk space
  in /boot temporarily. But there is no space left, if /boot is full.

  Likewise /etc/kernel/postinst.d/dkms may call "update-initramfs -u".

  The fix could be to create the new initrg.img file in different partition 
before replacing the old one by it in update-initramfs. So the update-initramfs 
script should be fixed. But there may not be such a partition..
  Anyway the likely case when space runs out is when there is a separate /boot 
partition.

  Alternatively the init scripts should remove the respective 
/boot/initrd.img- file when removing/installing the linux-image-extra 
package. That could also be done by
  update-initramfs -d -k 
  That may be worse way, as then initrd.img file is missing for longer period 
of time and system integrity may suffer in case of e.g. power cut.

  Related question: http://askubuntu.com/q/898499/21005
  The output of 'dpkg --purge' presented there shows that corresponding 
linux-image package may get successfully removed while the linux-image-extra is 
left broken. If the linux-image-extra package will be removed later, the 
post-installation script will create an initrd.img file for a non-installed 
kernel! Same would happen, if removing would be done by apt-get purge.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: initramfs-tools 0.103ubuntu4.7
  ProcVersionSignature: Ubuntu 4.4.0-71.92~14.04.1-generic 4.4.49
  Uname: Linux 4.4.0-71-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.23
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Fri Mar 31 17:42:35 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-09-21 (922 days ago)
  InstallationMedia: Ubuntu-Studio 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.1)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1678187/+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 1940999] Re: FTBFS against glibc 2.34

[Dan Bungert]

** Changed in: grep (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  Confirmed

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1940999] Re: FTBFS against glibc 2.34

[Dan Bungert]

** Attachment added: "grep_3.7-0ubuntu1.dsc"
   
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+attachment/5520321/+files/grep_3.7-0ubuntu1.dsc

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  Confirmed

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1940999] Re: FTBFS against glibc 2.34

[Dan Bungert]

** Patch added: "upstream-ChangeLog.diff"
   
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+attachment/5520323/+files/upstream-ChangeLog.diff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  Confirmed

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1940999] Re: FTBFS against glibc 2.34

[Dan Bungert]

This summary file is the differences to the debian directories between
3.6-1 and 3.7

** Attachment added: "changes.summary"
   
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+attachment/5520322/+files/changes.summary

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  Confirmed

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1940999] Re: FTBFS against glibc 2.34

[Dan Bungert]

To address this I propose picking up the new version of grep.

** Attachment added: "grep_3.7-0ubuntu1.debian.tar.xz"
   
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+attachment/5520320/+files/grep_3.7-0ubuntu1.debian.tar.xz

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  Confirmed

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1929345] Re: Pressing calculator key generates infinitely many key-press key-release events

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1929345

Title:
  Pressing calculator key generates infinitely many key-press key-
  release events

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Full description is posted in this AskUbuntu question:
  https://askubuntu.com/q/1336575/625814

  I've got a new notebook HP Omen 15, manufactured in 2020. I has
  Calculator key, this key is actual normal media key.

  Pressing on it launches calculator only once, after the OS is booted.
  No reaction for other presses.

  If I run xev and press Calculator I see infinitely many messages about
  pressing and releasing XF86Calculator key:

  ...
  KeyRelease event, serial 42, synthetic NO, window 0x3e1,
  root 0x29e, subw 0x0, time 52918, (151,-96), root:(151,806),
  state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
  XLookupString gives 0 bytes:
  XFilterEvent returns: False

  KeyPress event, serial 42, synthetic NO, window 0x3e1,
  root 0x29e, subw 0x0, time 52918, (151,-96), root:(151,806),
  state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
  XLookupString gives 0 bytes:
  XmbLookupString gives 0 bytes:
  XFilterEvent returns: False

  KeyRelease event, serial 42, synthetic NO, window 0x3e1,
  root 0x29e, subw 0x0, time 52958, (151,-96), root:(151,806),
  state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
  XLookupString gives 0 bytes:
  XFilterEvent returns: False

  KeyPress event, serial 42, synthetic NO, window 0x3e1,
  root 0x29e, subw 0x0, time 52958, (151,-96), root:(151,806),
  state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
  XLookupString gives 0 bytes:
  XmbLookupString gives 0 bytes:
  XFilterEvent returns: False

  KeyRelease event, serial 42, synthetic NO, window 0x3e1,
  root 0x29e, subw 0x0, time 52999, (151,-96), root:(151,806),
  state 0x14, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
  XLookupString gives 0 bytes:
  XFilterEvent returns: False
  ...

  Then I press Ctrl-C to stop this stream.
  This happens only once after the system is booted, next runs of xev don't 
show any events after pressing this key.

  If I run showkey, it always shows scan codes and key codes for that
  key:

  $ sudo showkey -s
  kb mode was ?UNKNOWN?
  [ if you are trying this under X, it might not work
  since the X server is also reading /dev/console ]

  press any key (program terminates 10s after last keypress)...
  0x9c
  0xe0 0x21
  0x1d
  ^Ccaught signal 2, cleaning up...
  0xe0 0x21
  $ sudo showkey -k
  kb mode was ?UNKNOWN?
  [ if you are trying this under X, it might not work
  since the X server is also reading /dev/console ]

  press any key (program terminates 10s after last keypress)...
  keycode  28 release
  keycode 140 press
  keycode  29 press
  ^Ccaught signal 2, cleaning up...

  Debugging with evtest shows that this key doesn't generate any events,
  while some other keys do:

  sudo evtest
  No device specified, trying to scan all of /dev/input/event*
  Available devices:
  /dev/input/event0:  Power Button
  /dev/input/event1:  Lid Switch
  /dev/input/event2:  Power Button
  /dev/input/event3:  AT Translated Set 2 keyboard
  /dev/input/event4:  Video Bus
  /dev/input/event5:  HP WMI hotkeys
  /dev/input/event6:  HDA NVidia HDMI/DP,pcm=3
  /dev/input/event7:  SONiX USB Keyboard
  /dev/input/event8:  SONiX USB Keyboard Consumer Control
  /dev/input/event9:  SONiX USB Keyboard System Control
  /dev/input/event10: PixArt Dell MS116 USB Optical Mouse
  /dev/input/event11: HDA NVidia HDMI/DP,pcm=7
  /dev/input/event12: HDA NVidia HDMI/DP,pcm=8
  /dev/input/event13: HDA NVidia HDMI/DP,pcm=9
  /dev/input/event14: HDA NVidia HDMI/DP,pcm=10
  /dev/input/event15: HDA NVidia HDMI/DP,pcm=11
  /dev/input/event16: SYNA32A5:00 06CB:CE17 Mouse
  /dev/input/event17: SYNA32A5:00 06CB:CE17 Touchpad
  /dev/input/event18: HD-Audio Generic Mic
  /dev/input/event19: HD-Audio Generic Headphone
  /dev/input/event20: HP Wide Vision HD Camera: HP Wi
  /dev/input/event21: WI-XB400 (AVRCP)
  Select the device event number [0-21]: 5
  Input driver version is 1.0.1
  Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
  Input device name: "HP WMI hotkeys"
  Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
  Event code 138 (KEY_HELP)
  Event code 141 (KEY_SETUP)
  Event code 148 (KEY_PROG1)
  Event code 153 (KEY_DIRECTION)
  Event code 184 (KEY_F14)
  Event code 185 (KEY_F15)
  Event code 186 (KEY_F16)
  Event code 187 (KEY_F17)
  Event code 224 (KEY_BRIGHTNESSDOWN)
  Event code 225

[Touch-packages] [Bug 1940996] Re: test failure - test-regex

[Bug Watch Updater]

Launchpad has imported 11 comments from the remote bug at
https://sourceware.org/bugzilla/show_bug.cgi?id=11053.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.


On 2009-12-04T19:35:39+00:00 Paolo Bonzini wrote:

$ echo 87654321 | \
  grep -E -e '^(.?)(.?)(.?)(.?)(.?)(.?)(.?)(.?)(.?).?\9\8\7\6\5\4\3\2\1$' 
Segmentation fault

Will work on a C reproducer soon.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/0


On 2010-04-09T17:46:04+00:00 Paolo Bonzini wrote:

Minimized testcases (same regex):

$ echo 8 | grep -E -e "$regex"
8  # >>> okay
$ echo 87 | grep -E -e "$regex"
Segmentation fault

$ echo 88 | grep -E -e "$regex"
88 # >>> okay
$ echo 887 | grep -E -e "$regex"
Segmentation fault

Also, everything I tried to feed that is of length 9 or higher and should not
match, gives either a false positive or a segfault:

$ echo 987654321 | grep -E -e "$regex"
887654321
$ echo 484635532 | grep -E -e "$regex"
484635532
$ echo 0123454321 | grep -E -e "$regex"
Segmentation fault
$ echo 123454321 | grep -E -e "$regex"
Segmentation fault


Reply at: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/1


On 2014-09-23T02:28:01+00:00 Paul Eggert wrote:

I ran into what appears to be the same bug independently and came up
with a simpler (all-C) reproducer; please see Bug#17356.  I tried to
merge the two bug reports via the web interface, but failed to do so.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/2


On 2014-09-23T07:55:27+00:00 Florian Weimer wrote:

*** Bug 17356 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/3


On 2017-01-17T21:24:04+00:00 Paul Eggert wrote:

This bug causes GNU coreutils Bug#22793 "grep -E assertion failure with
back references"; see . I'm adding comments
to both bug reports so that the connection between the two bugs is
clearer.

Although this bug's current assignee is Paolo Bonzini (the original
reporter), I think Paolo is pretty busy doing other stuff. Is someone
else available to work on regex bugs? I suspect the fix for this bug
will not be trivial.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/4


On 2017-01-17T22:01:52+00:00 Paul Eggert wrote:

Created attachment 9758
C code to reproduce the bug

I attached a slightly-simpler C-language reproducer for the bug, derived
from the attachment in Bug#17356. If I compile and run this program, it
outputs "a.out: regexec.c:1375: pop_fail_stack: Assertion `num >= 0'
failed." and then aborts.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/5


On 2017-12-08T18:32:01+00:00 Paul Eggert wrote:

Created attachment 10674
This test case silently returns the wrong answer

Following up on a 'grep' bug report here:

https://debbugs.gnu.org/29613

attached is a seemingly-related test case which illustrates a bug that
causes 'grep' to quietly return the wrong answer instead of dumping
core. This test case should exit successfully, but because of the bug
regexec returns 0 so the test case exits with status 1. I compiled and
ran it on Fedora 27 x86-64 with "gcc regbug.c; ./a.out".

Reply at:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/6


On 2018-09-22T21:27:12+00:00 Paul Eggert wrote:

Another test case for this bug can be found here:

https://debbugs.gnu.org/32806

Reply at:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/7


On 2019-01-31T03:20:02+00:00 Paul Eggert wrote:

Another test case for this bug can be found here:

https://debbugs.gnu.org/34238

Reply at:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940996/comments/8


On 2019-11-11T11:27:12+00:00 Cvs-commit wrote:

The master branch has been updated by Andreas Schwab
:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fc141ea78ee3d87c67b18488827fe2d89c9343e7

commit fc141ea78ee3d87c67b18488827fe2d89c9343e7
Author: Andreas Schwab 
Date:   Wed Oct 30 10:38:36 2019 +0100

Fix array bounds

[Touch-packages] [Bug 1940860] Re: Mellanox NIC interface names change between 5.4 and 5.8

[Dan Streetman]

> we should be careful to ignore NICs with randomly generated MACs (see
bug 1936972).

ugh nics with LAA?

yeah, it can be hard to 'uniquely' identify a nic, especially since it's
so common to clone macs for bonds, bridges, vlans, and in some cases
even duplicate hw devices with the same nic (e.g. bug 1843381).

> My initial thought is that perhaps subiquity installs should do what
MAAS installs do and configure netplan to always use the install-time
names.

I'm generally not a fan of how MAAS configures netplan to force-rename
interfaces; that sounds to me like it's destined for interface naming
collisions. But I don't have any better immediate suggestion for
'foolproof' matching of all possible nics that might exist across all
kernel driver versions, either.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1940860

Title:
  Mellanox NIC interface names change between 5.4 and 5.8

Status in subiquity:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  I noticed on a couple of systems that my network interface names
  change when upgrading from the focal LTS (5.4) kernel to the focal HWE
  (both 5.8 & 5.11) kernels. Both systems have Mellanox Connect-X 5
  NICs.

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.4.0-81-generic #91-Ubuntu SMP Thu Jul 15 19:10:30 UTC 2021 
aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0  enp1s0f1  enx3e8734bc294f  lo

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.8.0-63-generic #71~20.04.1-Ubuntu SMP Thu Jul 15 17:46:44 UTC 
2021 aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0np0  enp1s0f1np1  enx3e8734bc294f  lo

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 15:58:08 UTC 
2021 aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0np0  enp1s0f1np1  enx3e8734bc294f  lo

  I bisected this down to a kernel change:
  # first bad commit: [c6acd629eec754a9679f922d51f90e44c769b80c] net/mlx5e: Add 
support for devlink-port in non-representors mode

  The impact is that your network can fail to come up after
  transitioning from the LTS kernel to the HWE kernel. Now, this isn't a
  huge problem for MAAS installs because MAAS configures netplan to
  always use the same names as were used at commissioning. It does
  impact subiquity based installs however, which do not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1940860/+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 1940999] [NEW] FTBFS against glibc 2.34

[Dan Bungert]

Public bug reported:

The package grep failed to build in a recent archive rebuild, see
https://people.canonical.com/~doko/ftbfs-report/test-
rebuild-20210805-impish-impish.html#foundations-bugs .

The failure is in automated test, as follows:

stack-overflow: failed test: grep never printed "stack overflow"
FAIL: stack-overflow

** Affects: grep (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940999

Title:
  FTBFS against glibc 2.34

Status in grep package in Ubuntu:
  New

Bug description:
  The package grep failed to build in a recent archive rebuild, see
  https://people.canonical.com/~doko/ftbfs-report/test-
  rebuild-20210805-impish-impish.html#foundations-bugs .

  The failure is in automated test, as follows:

  stack-overflow: failed test: grep never printed "stack overflow"
  FAIL: stack-overflow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1940999/+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 1940996] [NEW] test failure - test-regex

[Dan Bungert]

Public bug reported:

'test-regex' fails when building grep against glibc 2.34.
Per commentary from grep upstream at 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50069, 
the test failure can be attributed to skew between the glibc built-in regex and 
the one that is found in the grep source code.

** Affects: grep
 Importance: Unknown
 Status: Unknown

** Affects: grep (Ubuntu)
 Importance: Undecided
 Status: New

** Bug watch added: Sourceware.org Bugzilla #11053
   https://sourceware.org/bugzilla/show_bug.cgi?id=11053

** Also affects: grep via
   https://sourceware.org/bugzilla/show_bug.cgi?id=11053
   Importance: Unknown
   Status: Unknown

** No longer affects: grep

** Also affects: grep via
   https://sourceware.org/bugzilla/show_bug.cgi?id=11053
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940996

Title:
  test failure - test-regex

Status in grep:
  Unknown
Status in grep package in Ubuntu:
  New

Bug description:
  'test-regex' fails when building grep against glibc 2.34.
  Per commentary from grep upstream at 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50069, 
  the test failure can be attributed to skew between the glibc built-in regex 
and the one that is found in the grep source code.

To manage notifications about this bug go to:
https://bugs.launchpad.net/grep/+bug/1940996/+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 1934040] Re: openssl s_client's '-ssl2' & '-ssl3' options gone, prematurely!

[Marc Deslauriers]

Thanks for reporting this issue, but we disabled SSLv3 in 2015 in Ubuntu
16.04 LTS. There is absolutely no chance we will be enabling it again.

** Changed in: openssl (Ubuntu)
   Status: New => Won't Fix

-- 
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/1934040

Title:
  openssl s_client's '-ssl2' & '-ssl3' options gone, prematurely!

Status in openssl package in Ubuntu:
  Won't Fix

Bug description:
  SSL2 and SSL3 have been hastily removed, apparently by developers who
  are unaware that these protocols serve purposes other than encryption.
  SSL2/3 is *still used* on onion sites.  Why?  For verification.  An
  onion site has inherent encryption, so it matters not how weak the SSL
  crypto is when the purpose is purely to verify that the server is
  owned by who they say it's owned by.

  Proof that disclosure attacks on ssl2/3 are irrelevant to onion sites:

  https://blog.torproject.org/tls-certificate-for-onion-site
  https://community.torproject.org/onion-services/overview/

  So here is a real world impact case.  Suppose you get your email from
  one of these onion mail servers:

  http://onionmail.info/directory.html

  Some (if not all) use ssl2/3 on top of Tor's inherent onion tunnel.
  They force users to use ssl2/3, so even if a user configures the
  client not to impose TLS, the server imposes it.  And it's reasonable
  because the ssl2/3 vulns are orthoganol to the use case.

  Some users will get lucky and use a mail client that still supports
  ssl2/3.  But there's still a problem: users can no longer use openssl
  to obtain the fingerprint to pin.  e.g.

  $ openssl s_client -proxy 127.0.0.1:8118 -connect xhfheq5i37waj6qb.onion:110 
-showcerts
  CONNECTED(0003)
  140124399195456:error:1408F10B:SSL routines:ssl3_get_record:wrong version 
number:../ssl/record/ssl3_record.c:331:
  ---
  no peer certificate available
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 44 bytes and written 330 bytes
  Verification: OK
  ---
  New, (NONE), Cipher is (NONE)
  Secure Renegotiation IS NOT supported
  Compression: NONE
  Expansion: NONE
  No ALPN negotiated
  Early data was not sent
  Verify return code: 0 (ok)
  ---

  That's openssl version 1.1.1k

  Being denied the ability to pin the SSL cert is actually a
  *degredation* of security.  Cert Pinning is particularly useful with
  self-signed certs, as is often the scenario with onion sites.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1934040/+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 1940860] Re: Mellanox NIC interface names change between 5.4 and 5.8

[dann frazier]

@ddstreet I agree that systemd is behaving as designed. But I'm not sure
what the proper fix for this is, and therefore where changes would be
required.

My initial thought is that perhaps subiquity installs should do what
MAAS installs do and configure netplan to always use the install-time
names. I've added a subiquity for that consideration. Note that if that
is the chosen solution, we should be careful to ignore NICs with
randomly generated MACs (see bug 1936972).

** Also affects: subiquity
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1940860

Title:
  Mellanox NIC interface names change between 5.4 and 5.8

Status in subiquity:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  I noticed on a couple of systems that my network interface names
  change when upgrading from the focal LTS (5.4) kernel to the focal HWE
  (both 5.8 & 5.11) kernels. Both systems have Mellanox Connect-X 5
  NICs.

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.4.0-81-generic #91-Ubuntu SMP Thu Jul 15 19:10:30 UTC 2021 
aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0  enp1s0f1  enx3e8734bc294f  lo

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.8.0-63-generic #71~20.04.1-Ubuntu SMP Thu Jul 15 17:46:44 UTC 
2021 aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0np0  enp1s0f1np1  enx3e8734bc294f  lo

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 15:58:08 UTC 
2021 aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0np0  enp1s0f1np1  enx3e8734bc294f  lo

  I bisected this down to a kernel change:
  # first bad commit: [c6acd629eec754a9679f922d51f90e44c769b80c] net/mlx5e: Add 
support for devlink-port in non-representors mode

  The impact is that your network can fail to come up after
  transitioning from the LTS kernel to the HWE kernel. Now, this isn't a
  huge problem for MAAS installs because MAAS configures netplan to
  always use the same names as were used at commissioning. It does
  impact subiquity based installs however, which do not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1940860/+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 1886653] Re: cups-pki-expired

[amir shkedy]

The same problem with HP DeskJet 3830

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1886653

Title:
  cups-pki-expired

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  The printer always goes to stopped state in Ubuntu 20.04. Print
  properties window has status message saying: "cups-pki-expired". I
  have HP color laserjet m552, which Ubuntu discovers directly from the
  local network and configures automatically.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: cups 2.3.1-9ubuntu1.1
  ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
  Uname: Linux 5.4.0-40-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.3
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jul  7 14:40:00 2020
  InstallationDate: Installed on 2019-11-03 (247 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  Lpstat: device for HP_Color_LaserJet_M552_5F80BF_: 
implicitclass://HP_Color_LaserJet_M552_5F80BF_/
  MachineType: LENOVO 81H1
  Papersize: a4
  PpdFiles: Error: command ['fgrep', '-H', '*NickName', 
'/etc/cups/ppd/HP_Color_LaserJet_M552_5F80BF_.ppd'] failed with exit code 2: 
grep: /etc/cups/ppd/HP_Color_LaserJet_M552_5F80BF_.ppd: Permission denied
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-40-generic 
root=UUID=7f92666a-65f8-485e-b998-046c2c596aa5 ro rootflags=subvol=@ quiet 
splash vt.handoff=7
  SourcePackage: cups
  UpgradeStatus: Upgraded to focal on 2020-03-28 (100 days ago)
  dmi.bios.date: 08/17/2018
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 8PCN45WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40700 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Lenovo ideapad 530S-14ARR
  dmi.modalias: 
dmi:bvnLENOVO:bvr8PCN45WW:bd08/17/2018:svnLENOVO:pn81H1:pvrLenovoideapad530S-14ARR:rvnLENOVO:rnLNVNB161216:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrLenovoideapad530S-14ARR:
  dmi.product.family: ideapad 530S-14ARR
  dmi.product.name: 81H1
  dmi.product.sku: LENOVO_MT_81H1_BU_idea_FM_ideapad 530S-14ARR
  dmi.product.version: Lenovo ideapad 530S-14ARR
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1886653/+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 1939238] Re: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

[Theodore Ts'o]

Your suggested message presupposes that busybox is used on a particular
distribution.   That's not necessarily the case.   Remember, e2fsprogs
is designed for all distributions, not just for Ubuntu.  If Canonical
wants to make a change like that to e2fsprogs, all distributions are
free to make any changes they want to a package.  (At which point they
own any liability if the user is clueless enough that they need that
amount of hand holding, but if that information is just enough to cause
them to attempt to do a file system fixup, but they then lose files
because they fumble the job, that's on Ubuntu, not on me.)

Or perhaps Canonical could put a multiple page, or even a book-length
tutorial in its initramfs scripts that tries to teach all eventualities
of what a user might need to fix when they run e2fsck by hand, if fsck
exits with an error code indicating that the file system needs to be
fixed by hand.   Again, feel free to convince canonical to do something
like that if it's really needed by novice users.   Personally, I think
it's roughly equivalent to trying to teach medicine to a novice as
opposed to telling them to see a doctor, but hey, Ubuntu can try to
break ground by trying to lead users by the hand.   I do predict that
after you tell users to "hit fsck /dev/xx", what will happen next is
users will go to forum.ubuntu-fr.org and ask, how do I answer this
question?  I'm so confused   Where does this end?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1939238

Title:
  UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  Hello
  This problem did not occur on my computer.

  https://nsa40.casimages.com/img/2021/08/07/210807015400327092.png

  It occurs in users who are not competent.
  This week, the French forum collapsed over this incident.

  I think changing the advice phrase might improve understanding of the
  action to be taken.

  Can these lines
  "   ( i.e.. without -a or -p options) 
  fsck existed with status code 4
  The root file system on /dev/ requires a manual fsck"
  become
  "execute this command 'fsck -y /dev/xx' to do a manual fsck on the root 
file system."

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: gnome-terminal 3.38.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Aug  8 15:16:28 2021
  ExecutablePath: /usr/libexec/gnome-terminal-server
  InstallationDate: Installed on 2020-08-02 (370 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  ProcEnviron:
   LANG=fr_FR.UTF-8
   PATH=(custom, user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
  SourcePackage: gnome-terminal
  UpgradeStatus: Upgraded to hirsute on 2021-07-11 (27 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939238/+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 1934147] Re: systemd leaks abandoned session scopes

[Heather Lemon]

** Changed in: systemd (Ubuntu Bionic)
 Assignee: Heather Lemon (hypothetical-lemon) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Focal)
 Assignee: Heather Lemon (hypothetical-lemon) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Hirsute)
 Assignee: Heather Lemon (hypothetical-lemon) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu Impish)
 Assignee: Heather Lemon (hypothetical-lemon) => Dan Streetman (ddstreet)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1934147

Title:
  systemd leaks abandoned session scopes

Status in snapd:
  New
Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Confirmed
Status in systemd source package in Focal:
  In Progress
Status in systemd source package in Groovy:
  Won't Fix
Status in systemd source package in Hirsute:
  In Progress
Status in systemd source package in Impish:
  In Progress

Bug description:
  [impact]

  systemd may leak sessions, leaving empty cgroups around as well as
  abandoned session scopes.

  [test case]

  on a system where the user has a ssh key that allows noninteractive
  login to localhost, and also has noninteractive sudo, run:

  $ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
  done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
  reload; done

  check the sessions to see there have been leaked sessions:

  $ loginctl list-sessions

  SESSION  UID USER   SEAT TTY
1 1000 ubuntu  ttyS0
  350 1000 ubuntu  
  351 1000 ubuntu  
  360 1000 ubuntu  
  ...

  to verify the sessions were leaked, clear them out with:

  $ echo '' | sudo tee
  
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events

  that should result in all the leaked sessions being cleaned up.

  [regression potential]

  issues during systemd pid1 reexec/reload, or issues while cleaning up
  sessions, including leaking sessions/cgroups

  [scope]

  this is needed for all releases

  upstream bug linked above, and upstream PR:
  https://github.com/systemd/systemd/pull/20199

  [original description]

  On a system that is monitored via telegraf I found many abandoned
  systemd session which I believe are created by a potential race where
  systemd is reloading unit files and at the same time a user is
  connecting to the system via ssh or is executing the su command.

  The simple reproducer

  $ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
  daemon-reload & ssh localhost sleep 1 & done

  Wait > 1 second

  $ jobs -p | xargs --verbose --no-run-if-empty kill -KILL

  To clean out STOPPED jobs and

  $ systemctl status --all 2> /dev/null | grep --before-context 3
  abandoned

  will produce something similar to

     │ ├─  175 su - ubuntu
     │ ├─  178 -su
     │ ├─62375 systemctl status --all
     │ └─62376 grep --color=auto --before-context 3 abandoned
  --
  ● session-273.scope - Session 273 of user ubuntu
     Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
  --
  ● session-274.scope - Session 274 of user ubuntu
     Loaded: loaded (/run/systemd/transient/session-274.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
  --
  ● session-30.scope - Session 30 of user ubuntu
     Loaded: loaded (/run/systemd/transient/session-30.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2021-06-30 10:05:56 UTC; 3h 30min ago
  --
  ● session-302.scope - Session 302 of user ubuntu
     Loaded: loaded (/run/systemd/transient/session-302.scope; transient)
  Transient: yes
     Active: active (abandoned) since Wed 2021-06-30 13:32:04 UTC; 4min 6s ago
  --
     │ ├─  175 su - ubuntu
     │ ├─  178 -su
     │ ├─62375 systemctl status --all
     │ └─62376 grep --color=auto --before-context 3 abandoned

  The system in question is running Bionic, systemd-237-3ubuntu10.48

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1934147/+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 1933979] Re: [MIR] busybox package

[Christian Ehrhardt ]

Thank you, options are discussed.
I'll set the bug to incomplete to reflect this isn't blocked on security right 
now.

** Changed in: busybox (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to busybox in Ubuntu.
https://bugs.launchpad.net/bugs/1933979

Title:
   [MIR] busybox package

Status in busybox package in Ubuntu:
  Incomplete

Bug description:
  [Availability]
  ==
  src:busybox was introduced in Dapper (2006) and has been in main since then. 
src:busybox & bin:busybox-static are in main, to be more precise. And this 
request is to promote bin:busybox from src:busybox in main, too. It only 
depends on the libc6 package, which is in main already. The package builds on 
all the architectures; is Arch:any.

  [Rationale]
  ===
  This package is to be included in our partner's cloud images, going back to 
Bionic. As cloud images are to ship only packages from main this request is to 
see that happen.

  [Security]
  ==
  The binary doesn't install services / daemons (/etc/init.d/*, /etc/init/*, 
/lib/systemd/system/*). Just ships the "busybox" binary, its docs, and a man 
page.

  [Dependencies]
  ==
  libc6, which is in main already.

  [Maintenance]
  =
  Server team.

  [Background information]
  
  Tiny utilities for small and embedded systems.

  ---
  Upstream: https://git.busybox.net/busybox/
  Launchpad page: https://launchpad.net/ubuntu/+source/busybox
  Ubuntu bugs: https://bugs.launchpad.net/ubuntu/+source/busybox
  Debian Package Tracker: https://tracker.debian.org/pkg/busybox
  Debian bugs: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=busybox

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1933979/+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 1921518] Re: OpenSSL "double free" error

[Mahantesh Salimath]

The updated OpenSSL package is not behaving as expected, openssl config
file (/etc/ssl/openssl.cnf) has PKA dynamic engine enabled. But
execution of `openssl engine` doesn't show (PKA) engine as one of the
listings. And also, offloading to PKA doesn't happen by default. Ex:
Executing speed test of PKA supported algorithms would by default
offload to PKA engine (openssl speed rsa512), this is not the case now.
Hence it seems updated OpenSSL package just provided a workaround by not
offloading to PKA by default. The fix expected should offload to PKA by
default and have no issues when used with curl and wget.

-- 
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/1921518

Title:
  OpenSSL "double free" error

Status in openssl package in Ubuntu:
  Incomplete
Status in openssl source package in Focal:
  Incomplete

Bug description:
  "double free" error is seen when using curl utility. Error is from
  libcrypto.so which is part of the OpenSSL package. This happens only
  when OpenSSL is configured to use a dynamic engine.

  OpenSSL version is 1.1.1f

  The issue is not encountered if
  http://www.openssl.org/source/openssl-1.1.1f.tar.gz is used instead.

  
  OpenSSL can be configured to use a dynamic engine by editing the default 
openssl config file which is located at '/etc/ssl/openssl.cnf' on Ubuntu 
systems.

  On Bluefield systems, config diff to enable PKA dynamic engine, is as
  below:

  +openssl_conf = conf_section
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file  = $ENV::HOME/.oid
   oid_section= new_oids
   
  +[ conf_section ]
  +engines = engine_section
  +
  +[ engine_section ]
  +bf = bf_section
  +
  +[ bf_section ]
  +engine_id=pka
  +dynamic_path=/usr/lib/aarch64-linux-gnu/engines-1.1/pka.so
  +init=0
  +

  engine_id above refers to dynamic engine name/identifier.
  dynamic_path points to the .so file for the dynamic engine.

  # curl -O https://tpo.pe/pathogen.vim

  double free or corruption (out)

  Aborted (core dumped)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1921518/+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 1940715] Re: systemd-resolved restricts edns0 advertised max size to 512

[Dan Streetman]

** Description changed:

  [impact]
  
  when talking to upstream nameservers, systemd-resolved limits its
  advertised max packet size as 512 in its edns0 opt. However, one of the
  primary benefits of edns0 is to allow using packet sizes larger than
  512, which is the pre-edns0 max packet size.
  
  this results in systemd-resolved failing to handle responses larger than
  512 with udp/edns0, and having to fall back to tcp. This is not optimal
  (since tcp dns imposes significantly higher overhead) and may even cause
  failures, if a firewall allows udp dns but blocks tcp dns traffic.
  
  [test case]
  
- TBD
+ enable debug logging in systemd-resolved, with 'sudo systemctl edit
+ systemd-resolved' and then add:
+ 
+ [Service]
+ Environment=SYSTEMD_LOG_LEVEL=debug
+ 
+ then save that file and restart systemd-resolved (or reboot).
+ 
+ Make sure to flush the cache and reset server features before
+ reproducing:
+ 
+ $ sudo resolvectl flush-caches
+ $ sudo resolvectl reset-server-features
+ 
+ Lookup 'toomany.ddstreet.org' and check systemd-resolved logs to see if
+ it used TCP fallback or not:
+ 
+ ...
+ Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Reply truncated, retrying 
via TCP.
+ ...
+ Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Verified we get a 
response at feature level TCP from DNS server 10.202.51.1.
+ Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Added positive 
unauthenticated cache entry for toomany.ddstreet.org IN A 1799s on 
eth0/INET/10.202.51.1
+ 
+ A correct lookup using larger EDNS0 response size looks like:
+ 
+ ...
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using feature level 
UDP+EDNS0 for transaction 43808.
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using DNS server 
10.202.51.1 for transaction 43808.
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Announcing packet size 
1472 in egress EDNS(0) packet.
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Emitting UDP, link MTU is 
1500, socket MTU is 0, minimal MTU is 40
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Sending query packet with 
id 43808 of size 49.
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing query...
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Received dns UDP packet of 
size 689, ifindex=131, ttl=0, fragsize=0
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing incoming packet 
of size 689 on transaction 43808 (rcode=SUCCESS).
+ Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Added positive 
unauthenticated non-confidential cache entry for toomany.ddstreet.org IN A 
1175s on eth0/INET/10.202.51.1
+ ...
  
  [regression potential]
  
  failure to correctly look up dns records, or other problems while
  performing dns lookups with systemd-resolved
  
  [scope]
  
  this is needed for all releases
  
  this still needs fixing upstream

** Description changed:

  [impact]
  
  when talking to upstream nameservers, systemd-resolved limits its
  advertised max packet size as 512 in its edns0 opt. However, one of the
  primary benefits of edns0 is to allow using packet sizes larger than
  512, which is the pre-edns0 max packet size.
  
  this results in systemd-resolved failing to handle responses larger than
  512 with udp/edns0, and having to fall back to tcp. This is not optimal
  (since tcp dns imposes significantly higher overhead) and may even cause
  failures, if a firewall allows udp dns but blocks tcp dns traffic.
  
  [test case]
  
  enable debug logging in systemd-resolved, with 'sudo systemctl edit
  systemd-resolved' and then add:
  
  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug
  
  then save that file and restart systemd-resolved (or reboot).
  
  Make sure to flush the cache and reset server features before
  reproducing:
  
  $ sudo resolvectl flush-caches
  $ sudo resolvectl reset-server-features
  
  Lookup 'toomany.ddstreet.org' and check systemd-resolved logs to see if
  it used TCP fallback or not:
  
  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Reply truncated, retrying 
via TCP.
  ...
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Verified we get a 
response at feature level TCP from DNS server 10.202.51.1.
  Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Added positive 
unauthenticated cache entry for toomany.ddstreet.org IN A 1799s on 
eth0/INET/10.202.51.1
  
  A correct lookup using larger EDNS0 response size looks like:
  
  ...
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using feature level 
UDP+EDNS0 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using DNS server 
10.202.51.1 for transaction 43808.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Announcing packet size 
1472 in egress EDNS(0) packet.
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Emitting UDP, link MTU is 
1500, socket MTU is 0, minimal MTU is 40
  Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Sending query packet with 
id 43808 of size 49.
  Au

[Touch-packages] [Bug 1940908] Re: resolved: closes listening socket too rapidly and sends Destination port unreachable

[Dan Streetman]

> The server answers and then resolved sends an ICMP Destination Unreachable 
> (Port Unreachable) response!
> This breaks name lookups frequently.

I'm unclear on how/why you are connecting these two statements...can you
explain why it's breaking name lookups?

** Changed in: systemd (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1940908

Title:
  resolved: closes listening socket too rapidly and sends Destination
  port unreachable

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Afffects Ubuntu 18.04 through 21.04 (fixes are in systemd v248)

  With systemd v245 (and v247) and systemd-resolved we're seeing
  frequent problems due to resolved rapidly closing the socket on which
  it sends out a query before the server has answered. The server
  answers and then resolved sends an ICMP Destination Unreachable (Port
  Unreachable) response!

  This breaks name lookups frequently. In our case the DNS server is
  reached via a Wireguard tunnel over a satellite link and latencies can
  vary.

  A typical example captured via tcpdump:

  07:22:03.446919 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338 > 
fddc:7e00:e001:ee00::1.53: 2963+ [1au] ? 
contile-images.services.mozilla.com. (64)
  07:22:03.501089 IP6 fddc:7e00:e001:ee00::1.53 > 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338: 2963 1/0/1  
2a01:7e00:e001:ee64::2278:7366 (92)
  07:22:03.501152 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 > 
fddc:7e00:e001:ee00::1: ICMP6, destination unreachable, unreachable port, 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 udp port 45338, length 148

  The time difference here is only 0.054170 and there is no way to alter
  the timeout in resolved.

  There are recent upstream commits to fix this which ought to be
  cherry-picked. See:

  https://github.com/systemd/systemd/issues/17421

  https://github.com/systemd/systemd/pull/17535

  
https://github.com/systemd/systemd/commit/e03d156f78cb5a0cac85d1e1310d89fdfa4f1b88

  If I am reading the code correctly the timeout is very short:

  src/resolve/resolved-dns-transaction.c:22:#define DNS_TIMEOUT_USEC
  (SD_RESOLVED_QUERY_TIMEOUT_USEC / DNS_TRANSACTION_ATTEMPTS_MAX)

  src/resolve/resolved-def.h:79:#define SD_RESOLVED_QUERY_TIMEOUT_USEC
  (120 * USEC_PER_SEC)

  src/resolve/resolved-dns-transaction.h:212:#define
  DNS_TRANSACTION_ATTEMPTS_MAX 24

  So in micro-seconds that is 120 /24 = 5 per query with, as inferred,
  up to 24 attempts (I don't see multiple duplicate requests on the wire
  so not sure DNS_TRANSACTION_ATTEMPTS_MAX affects this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1940908/+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 1472288] Re: Add additional attributes in /etc/os-release

[Robie Basak]

I'm just driving past the sponsorship queue.

How can we validate that the CPE_NAME you're adding is definitely the
correct one for us to use in Ubuntu?

Your debdiff doesn't include adding BUILD_ID, so maybe this bug needs
renaming to be specific to CPE_NAME? BUILD_ID sounds like something
based on the installer used - like /var/log/installer/media-info or
/etc/cloud/build.info. But that would mean that /etc/os-release could no
longer be a simple conffile and would have to be managed via a postinst
and ucf or something.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1472288

Title:
  Add additional attributes in /etc/os-release

Status in base-files package in Ubuntu:
  Confirmed

Bug description:
  Please add 'CPE_NAME' and 'BUILD_ID' to /etc/os-release.

  More at http://www.freedesktop.org/software/systemd/man/os-
  release.html.

  I'm not sure BUILD_ID should be something like 'vivid' etc, but it
  would be a nice use. Or introduce a new attribute/value pair like

  NICKNAME_ID="vivid"

  No rush. Thanks for adopting this convention so quickly.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: base-files 7.2ubuntu9
  Uname: Linux 4.1.0-rc5carif-7-ga8b253b x86_64
  ApportVersion: 2.17.2-0ubuntu1.1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jul  7 10:26:02 2015
  Dependencies:
   
  InstallationDate: Installed on 2014-11-04 (245 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
  ProcEnviron:
   LANGUAGE=en_US
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: base-files
  UpgradeStatus: Upgraded to vivid on 2015-04-25 (73 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1472288/+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 1940860] Re: Mellanox NIC interface names change between 5.4 and 5.8

[Dan Streetman]

systemd/udevd appears to be working exactly as advertised, using the
phys_port_name when it's provided by the device's kernel driver; should
this be marked invalid for systemd, or is there actually some change
needed there?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1940860

Title:
  Mellanox NIC interface names change between 5.4 and 5.8

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  I noticed on a couple of systems that my network interface names
  change when upgrading from the focal LTS (5.4) kernel to the focal HWE
  (both 5.8 & 5.11) kernels. Both systems have Mellanox Connect-X 5
  NICs.

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.4.0-81-generic #91-Ubuntu SMP Thu Jul 15 19:10:30 UTC 2021 
aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0  enp1s0f1  enx3e8734bc294f  lo

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.8.0-63-generic #71~20.04.1-Ubuntu SMP Thu Jul 15 17:46:44 UTC 
2021 aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0np0  enp1s0f1np1  enx3e8734bc294f  lo

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 15:58:08 UTC 
2021 aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0np0  enp1s0f1np1  enx3e8734bc294f  lo

  I bisected this down to a kernel change:
  # first bad commit: [c6acd629eec754a9679f922d51f90e44c769b80c] net/mlx5e: Add 
support for devlink-port in non-representors mode

  The impact is that your network can fail to come up after
  transitioning from the LTS kernel to the HWE kernel. Now, this isn't a
  huge problem for MAAS installs because MAAS configures netplan to
  always use the same names as were used at commissioning. It does
  impact subiquity based installs however, which do not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1940860/+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 1939238] Re: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

[geole0]

hello
a completely lost user => https://forum.ubuntu-fr.org/viewtopic.php?id=2066473

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1939238

Title:
  UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  Hello
  This problem did not occur on my computer.

  https://nsa40.casimages.com/img/2021/08/07/210807015400327092.png

  It occurs in users who are not competent.
  This week, the French forum collapsed over this incident.

  I think changing the advice phrase might improve understanding of the
  action to be taken.

  Can these lines
  "   ( i.e.. without -a or -p options) 
  fsck existed with status code 4
  The root file system on /dev/ requires a manual fsck"
  become
  "execute this command 'fsck -y /dev/xx' to do a manual fsck on the root 
file system."

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: gnome-terminal 3.38.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Aug  8 15:16:28 2021
  ExecutablePath: /usr/libexec/gnome-terminal-server
  InstallationDate: Installed on 2020-08-02 (370 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
  ProcEnviron:
   LANG=fr_FR.UTF-8
   PATH=(custom, user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
  SourcePackage: gnome-terminal
  UpgradeStatus: Upgraded to hirsute on 2021-07-11 (27 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939238/+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 1940635] Re: systemd-networkd failing to acquire a DHCP6 lease from dnsmasq on armhf

[Simon Chopin]

Can somebody confirm my assumptions on the architecture of the test ?

First, it sets up a veth with router_eth42 at one end and test_eth42 at
the other (the itf names might be different ?). dnsmasq is bound against
router_eth42 which is configured manually via iproute with both IPv4 and
IPv6 addresses.

networkd is in charge of configuring test_eth42. In this specific case,
it is expected that it sends a DHCPv6 request via test_eth42, and that
we get an answer from dnsmasq with an lease to an address between
2600::10 and 2600::20.

When running tcpdump on test_eth42, I can only see some ICMPv6 router
solicitations (from both ends of the tunnel), with no router
advertisement as answer. This bit is expected AFAIK. However, I do not
see any other traffic, crucially, no DHCPv6 traffic at all.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1940635

Title:
  systemd-networkd failing to acquire a DHCP6 lease from dnsmasq on
  armhf

Status in glibc package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  systemd-networkd is failing to acquire a DCHP6 lease from dnsmasq on
  armhf since glibc 2.34-0ubuntu1, failing systemd (tests-name=networkd-
  test.py) and netplan.io (test-name=ethernets) tests on armhf.

  Reproducer:
  * Setup an armhf container, e.g. via:
  autopkgtest systemd --test-name=networkd-test.py --shell -U 
--apt-pocket=proposed=src:systemd,src:glibc -s -- lxd 
autopkgtest/ubuntu/impish/armhf
  * It will fail and drop you into the shell
  * cd test/ && apt install python3-nose
  * nosetests3 -v -s -m "test_.*_dhcp_ip6" networkd-test.py

  
  This is unrelated to the recent dnsmasq changes (LP: #1894619), as that would 
fail on all architectures, not just armhf.

  It still passes inside an amd64 LXD container, so it is also not related to 
armhf being tested inside a container. But it shows the difference between 
armhf vs amd64 container, that on armhf we're missing the DHCPSOLICIT (and 
therefore DHCPREPLY) messages, as can be seen from the dnsmasq log:
  dnsmasq-dhcp[]: DHCPSOLICIT(router_eth42) 
00:02:00:00:ab:11:57:1e:20:2f:9e:56:5f:34 
  dnsmasq-dhcp[]: DHCPREPLY(router_eth42) 2600::1f 
00:02:00:00:ab:11:57:1e:20:2f:9e:56:5f:34 autopkgtest-lxd-rtypaf

  The issue is most probably the same that causes the currently failing
  netplan.io/ethernets autopkgtest on armhf, if tested against glibc
  2.34-0ubuntu1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1940635/+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 1940908] Re: resolved: closes listening socket too rapidly and sends Destination port unreachable

[TJ]

** Description changed:

  Afffects Ubuntu 18.04 through 21.04 (fixes are in systemd v248)
  
  With systemd v245 (and v247) and systemd-resolved we're seeing frequent
  problems due to resolved rapidly closing the socket on which it sends
  out a query before the server has answered. The server answers and then
  resolved sends an ICMP Destination Unreachable (Port Unreachable)
  response!
  
  This breaks name lookups frequently. In our case the DNS server is
  reached via a Wireguard tunnel over a satellite link and latencies can
  vary.
  
  A typical example captured via tcpdump:
  
  07:22:03.446919 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338 > 
fddc:7e00:e001:ee00::1.53: 2963+ [1au] ? 
contile-images.services.mozilla.com. (64)
  07:22:03.501089 IP6 fddc:7e00:e001:ee00::1.53 > 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338: 2963 1/0/1  
2a01:7e00:e001:ee64::2278:7366 (92)
  07:22:03.501152 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 > 
fddc:7e00:e001:ee00::1: ICMP6, destination unreachable, unreachable port, 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 udp port 45338, length 148
  
  The time difference here is only 0.054170 and there is no way to alter
  the timeout in resolved.
  
  There are recent upstream commits to fix this which ought to be cherry-
  picked. See:
  
  https://github.com/systemd/systemd/issues/17421
  
  https://github.com/systemd/systemd/pull/17535
  
  
https://github.com/systemd/systemd/commit/e03d156f78cb5a0cac85d1e1310d89fdfa4f1b88
+ 
+ If I am reading the code correctly the timeout is very short:
+ 
+ src/resolve/resolved-dns-transaction.c:22:#define DNS_TIMEOUT_USEC
+ (SD_RESOLVED_QUERY_TIMEOUT_USEC / DNS_TRANSACTION_ATTEMPTS_MAX)
+ 
+ src/resolve/resolved-def.h:79:#define SD_RESOLVED_QUERY_TIMEOUT_USEC
+ (120 * USEC_PER_SEC)
+ 
+ src/resolve/resolved-dns-transaction.h:212:#define
+ DNS_TRANSACTION_ATTEMPTS_MAX 24
+ 
+ So in micro-seconds that is 120 /24 = 5 per query with, as inferred, up
+ to 24 attempts (I don't see multiple duplicate requests on the wire so
+ not sure DNS_TRANSACTION_ATTEMPTS_MAX affects this.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1940908

Title:
  resolved: closes listening socket too rapidly and sends Destination
  port unreachable

Status in systemd package in Ubuntu:
  New

Bug description:
  Afffects Ubuntu 18.04 through 21.04 (fixes are in systemd v248)

  With systemd v245 (and v247) and systemd-resolved we're seeing
  frequent problems due to resolved rapidly closing the socket on which
  it sends out a query before the server has answered. The server
  answers and then resolved sends an ICMP Destination Unreachable (Port
  Unreachable) response!

  This breaks name lookups frequently. In our case the DNS server is
  reached via a Wireguard tunnel over a satellite link and latencies can
  vary.

  A typical example captured via tcpdump:

  07:22:03.446919 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338 > 
fddc:7e00:e001:ee00::1.53: 2963+ [1au] ? 
contile-images.services.mozilla.com. (64)
  07:22:03.501089 IP6 fddc:7e00:e001:ee00::1.53 > 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338: 2963 1/0/1  
2a01:7e00:e001:ee64::2278:7366 (92)
  07:22:03.501152 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 > 
fddc:7e00:e001:ee00::1: ICMP6, destination unreachable, unreachable port, 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 udp port 45338, length 148

  The time difference here is only 0.054170 and there is no way to alter
  the timeout in resolved.

  There are recent upstream commits to fix this which ought to be
  cherry-picked. See:

  https://github.com/systemd/systemd/issues/17421

  https://github.com/systemd/systemd/pull/17535

  
https://github.com/systemd/systemd/commit/e03d156f78cb5a0cac85d1e1310d89fdfa4f1b88

  If I am reading the code correctly the timeout is very short:

  src/resolve/resolved-dns-transaction.c:22:#define DNS_TIMEOUT_USEC
  (SD_RESOLVED_QUERY_TIMEOUT_USEC / DNS_TRANSACTION_ATTEMPTS_MAX)

  src/resolve/resolved-def.h:79:#define SD_RESOLVED_QUERY_TIMEOUT_USEC
  (120 * USEC_PER_SEC)

  src/resolve/resolved-dns-transaction.h:212:#define
  DNS_TRANSACTION_ATTEMPTS_MAX 24

  So in micro-seconds that is 120 /24 = 5 per query with, as inferred,
  up to 24 attempts (I don't see multiple duplicate requests on the wire
  so not sure DNS_TRANSACTION_ATTEMPTS_MAX affects this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1940908/+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 1940908] Re: resolved: closes listening socket too rapidly and sends Destination port unreachable

[TJ]

** Description changed:

+ Afffects Ubuntu 18.04 through 21.04 (fixes are in systemd v248)
+ 
  With systemd v245 (and v247) and systemd-resolved we're seeing frequent
  problems due to resolved rapidly closing the socket on which it sends
  out a query before the server has answered. The server answers and then
  resolved sends an ICMP Destination Unreachable (Port Unreachable)
  response!
  
  This breaks name lookups frequently. In our case the DNS server is
  reached via a Wireguard tunnel over a satellite link and latencies can
  vary.
  
  A typical example captured via tcpdump:
  
  07:22:03.446919 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338 > 
fddc:7e00:e001:ee00::1.53: 2963+ [1au] ? 
contile-images.services.mozilla.com. (64)
  07:22:03.501089 IP6 fddc:7e00:e001:ee00::1.53 > 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338: 2963 1/0/1  
2a01:7e00:e001:ee64::2278:7366 (92)
  07:22:03.501152 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 > 
fddc:7e00:e001:ee00::1: ICMP6, destination unreachable, unreachable port, 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 udp port 45338, length 148
  
  The time difference here is only 0.054170 and there is no way to alter
  the timeout in resolved.
  
  There are recent upstream commits to fix this which ought to be cherry-
  picked. See:
  
  https://github.com/systemd/systemd/issues/17421
  
  https://github.com/systemd/systemd/pull/17535
  
  
https://github.com/systemd/systemd/commit/e03d156f78cb5a0cac85d1e1310d89fdfa4f1b88

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1940908

Title:
  resolved: closes listening socket too rapidly and sends Destination
  port unreachable

Status in systemd package in Ubuntu:
  New

Bug description:
  Afffects Ubuntu 18.04 through 21.04 (fixes are in systemd v248)

  With systemd v245 (and v247) and systemd-resolved we're seeing
  frequent problems due to resolved rapidly closing the socket on which
  it sends out a query before the server has answered. The server
  answers and then resolved sends an ICMP Destination Unreachable (Port
  Unreachable) response!

  This breaks name lookups frequently. In our case the DNS server is
  reached via a Wireguard tunnel over a satellite link and latencies can
  vary.

  A typical example captured via tcpdump:

  07:22:03.446919 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338 > 
fddc:7e00:e001:ee00::1.53: 2963+ [1au] ? 
contile-images.services.mozilla.com. (64)
  07:22:03.501089 IP6 fddc:7e00:e001:ee00::1.53 > 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338: 2963 1/0/1  
2a01:7e00:e001:ee64::2278:7366 (92)
  07:22:03.501152 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 > 
fddc:7e00:e001:ee00::1: ICMP6, destination unreachable, unreachable port, 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 udp port 45338, length 148

  The time difference here is only 0.054170 and there is no way to alter
  the timeout in resolved.

  There are recent upstream commits to fix this which ought to be
  cherry-picked. See:

  https://github.com/systemd/systemd/issues/17421

  https://github.com/systemd/systemd/pull/17535

  
https://github.com/systemd/systemd/commit/e03d156f78cb5a0cac85d1e1310d89fdfa4f1b88

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1940908/+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 1940908] [NEW] resolved: closes listening socket too rapidly and sends Destination port unreachable

[TJ]

Public bug reported:

With systemd v245 (and v247) and systemd-resolved we're seeing frequent
problems due to resolved rapidly closing the socket on which it sends
out a query before the server has answered. The server answers and then
resolved sends an ICMP Destination Unreachable (Port Unreachable)
response!

This breaks name lookups frequently. In our case the DNS server is
reached via a Wireguard tunnel over a satellite link and latencies can
vary.

A typical example captured via tcpdump:

07:22:03.446919 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338 > 
fddc:7e00:e001:ee00::1.53: 2963+ [1au] ? 
contile-images.services.mozilla.com. (64)
07:22:03.501089 IP6 fddc:7e00:e001:ee00::1.53 > 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338: 2963 1/0/1  
2a01:7e00:e001:ee64::2278:7366 (92)
07:22:03.501152 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 > 
fddc:7e00:e001:ee00::1: ICMP6, destination unreachable, unreachable port, 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 udp port 45338, length 148

The time difference here is only 0.054170 and there is no way to alter
the timeout in resolved.

There are recent upstream commits to fix this which ought to be cherry-
picked. See:

https://github.com/systemd/systemd/issues/17421

https://github.com/systemd/systemd/pull/17535

https://github.com/systemd/systemd/commit/e03d156f78cb5a0cac85d1e1310d89fdfa4f1b88

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1940908

Title:
  resolved: closes listening socket too rapidly and sends Destination
  port unreachable

Status in systemd package in Ubuntu:
  New

Bug description:
  With systemd v245 (and v247) and systemd-resolved we're seeing
  frequent problems due to resolved rapidly closing the socket on which
  it sends out a query before the server has answered. The server
  answers and then resolved sends an ICMP Destination Unreachable (Port
  Unreachable) response!

  This breaks name lookups frequently. In our case the DNS server is
  reached via a Wireguard tunnel over a satellite link and latencies can
  vary.

  A typical example captured via tcpdump:

  07:22:03.446919 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338 > 
fddc:7e00:e001:ee00::1.53: 2963+ [1au] ? 
contile-images.services.mozilla.com. (64)
  07:22:03.501089 IP6 fddc:7e00:e001:ee00::1.53 > 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4.45338: 2963 1/0/1  
2a01:7e00:e001:ee64::2278:7366 (92)
  07:22:03.501152 IP6 fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 > 
fddc:7e00:e001:ee00::1: ICMP6, destination unreachable, unreachable port, 
fddc:7e00:e001:ee00:fffe:f875:a4f3:42b4 udp port 45338, length 148

  The time difference here is only 0.054170 and there is no way to alter
  the timeout in resolved.

  There are recent upstream commits to fix this which ought to be
  cherry-picked. See:

  https://github.com/systemd/systemd/issues/17421

  https://github.com/systemd/systemd/pull/17535

  
https://github.com/systemd/systemd/commit/e03d156f78cb5a0cac85d1e1310d89fdfa4f1b88

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1940908/+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 1940720] Re: package openssh-server 1:8.4p1-5ubuntu1.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status

[Christian Ehrhardt ]

>From the log:
  Bind to port 22 on 0.0.0.0 failed: Address already in use.

Something on your system already blocks the default SSH port which the
service will try to consume on install/update. You'd want to find what
owns this port and remove/reconfigure that - afterwards the openssh-
server should install/upgrade fine again.

You can find this process via:
  $ sudo ss -pl4 '( sport = :ssh )'

Thank you for your report.

This looks like a local configuration problem, rather than a bug in
Ubuntu.

You can find pointers to get help for this sort of problem here:
http://www.ubuntu.com/support/community

Since we use this bug tracker to track bugs in Ubuntu, rather than
configuration problems, I'm marking this bug as Invalid. This helps us
to focus on fixing bugs in Ubuntu.

If you believe that this is really a bug, then you may find it helpful
to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

** Changed in: openssh (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1940720

Title:
  package openssh-server 1:8.4p1-5ubuntu1.1 failed to install/upgrade:
  installed openssh-server package post-installation script subprocess
  returned error exit status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  not sure it just didn't install

  ProblemType: Package
  DistroRelease: Ubuntu 21.04
  Package: openssh-server 1:8.4p1-5ubuntu1.1
  ProcVersionSignature: Ubuntu 5.11.0-31.33-generic 5.11.22
  Uname: Linux 5.11.0-31-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu65.1
  AptOrdering:
   ncurses-term:amd64: Install
   openssh-sftp-server:amd64: Install
   openssh-server:amd64: Install
   ssh-import-id:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Thu Jul 15 11:05:39 2021
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2021-03-19 (154 days ago)
  InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 
(20210209.1)
  Python3Details: /usr/bin/python3.9, Python 3.9.5, python3-minimal, 3.9.4-1
  PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.18-9
  RelatedPackageVersions:
   dpkg 1.20.9ubuntu1
   apt  2.2.4ubuntu0.1
  SourcePackage: openssh
  Title: package openssh-server 1:8.4p1-5ubuntu1.1 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: Upgraded to hirsute on 2021-05-10 (101 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1940720/+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 1939751] Re: openssh FTBFS with glibc >= 2.34

[Christian Ehrhardt ]

This update includes one of the two changes we have as delta.
Another Fix (group collisions) and the fix for this issue here.

I think despite FF, this could be re-merged to resolve this and the other 
mentioned bugs.
I'll tag it to be more likely to be considered.

But to avoid collisions @William (or @cjatson) are you about to do that
merge already?

** Changed in: openssh (Ubuntu)
   Status: Confirmed => Triaged

** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1939751

Title:
  openssh FTBFS with glibc >= 2.34

Status in openssh package in Ubuntu:
  Triaged
Status in openssh package in Debian:
  Fix Released

Bug description:
  Due to an incompatible function prototype in openbsd-compat tests,
  this package FTBFS with glibc >= 2.34. There is an upstream patch
  already in place to address this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1939751/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1933828] Re: NTP servers from DHCP are not propagated to timesyncd

[Jean-Baptiste Lallement]

** Also affects: network-manager (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: network-manager (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: network-manager (Ubuntu Focal)
 Assignee: (unassigned) => Heather Ellsworth (hellsworth)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1933828

Title:
  NTP servers from DHCP are not propagated to timesyncd

Status in network-manager package in Ubuntu:
  New
Status in network-manager source package in Focal:
  New

Bug description:
  Network manager gets NTP servers from DHCP but do not update timesyncd to use 
it which keeps using ntp.ubuntu.com.
   
  This is a problem on private networks which do not have access to public 
internet. On this type of network the configuration of timesyncd must be 
updated manually instead of inheriting the conf from the dhcp servers.

  This can be integrated with a NM dispatcher script such as below:

  etc/NetworkManager/dispatcher.d/10-update-timesyncd for example:

  ==8<=8<=8<=8<=8<==
  #! /usr/bin/bash

  [ -n "$CONNECTION_UUID" ] || exit

  INTERFACE=$1
  ACTION=$2

  case $ACTION in
  up | dhcp4-change | dhcp6-change)
  [ -n "$DHCP4_NTP_SERVERS" ] || exit
  mkdir -p /etc/systemd/timesyncd.conf.d/
  cat< /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf
  [Time]
  NTP=$DHCP4_NTP_SERVERS
  RootDistanceMaxSec=15
  EOF
  systemctl restart systemd-timesyncd
 ;;
  down)
  rm -f /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf
  systemctl restart systemd-timesyncd
  ;;
  esac
  ==8<=8<=8<=8<=8<==

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: network-manager 1.30.0-1ubuntu3
  ProcVersionSignature: Ubuntu 5.11.0-18.19+21.10.1-generic 5.11.17
  Uname: Linux 5.11.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu67
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Jun 28 14:08:52 2021
  InstallationDate: Installed on 2020-05-31 (393 days ago)
  InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200527)
  RebootRequiredPkgs:
   linux-image-5.11.0-20-generic
   linux-base
  SourcePackage: network-manager
  UpgradeStatus: No upgrade log present (probably fresh install)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI  WWAN-HW  WWAN
   running  1.30.0   connected  started  full  enabled enabled  
disabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1933828/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1938983] Re: missing modules after 5.11.0-25-generic update

[Luca Ferroni]

Bug affects also to me in upgrading to 5.11.0-27

~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.3 LTS
Release:20.04
Codename:   focal

The solution proposed by @MikeR works for me:

I have created a file t.txt with missing modules with the base
LinuxFromScratch URL: https://anduin.linuxfromscratch.org/sources/linux-
firmware/i915/

and then

~$ cd /lib/firmware/i915/
/lib/firmware/i915$ cat ~/tmp/t.txt | while read a; do sudo wget $a; done
/lib/firmware/i915$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.11.0-27-generic
update-initramfs: Generating /boot/initrd.img-5.11.0-25-generic
update-initramfs: Generating /boot/initrd.img-5.8.0-63-generic

Thank you all guys, maybe files should be integrated in `linux-firmware`
package? Can any janitor confirm pls so me or someone of my FSUG can try
to propose a patch for the package itself?

** Attachment added: "My list of "probably missing modules". BEWARE your list 
can be different!"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1938983/+attachment/5520102/+files/t.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1938983

Title:
  missing modules after 5.11.0-25-generic update

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  After updating to kernel 5.11.0-25-generic wireless driver failed to 
recognize WiFi card.
  Possible reasons/symptoms:
  $ sudo update-initramfs -u -k all
  update-initramfs: Generating /boot/initrd.img-5.11.0-25-generic
  W: Possible missing firmware /lib/firmware/i915/skl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/bxt_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/glk_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/kbl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/cml_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/icl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/ehl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/ehl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.5.0.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/tgl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.5.0.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/tgl_guc_49.0.1.bin for module 
i915
  W: Possible missing firmware /lib/firmware/i915/dg1_dmc_ver2_02.bin for 
module i915
  update-initramfs: Generating /boot/initrd.img-5.8.0-63-generic

  $ lsb_release -a
  LSB Version:  core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
  Distributor ID:   Ubuntu
  Description:  July2021
  Release:  20.04
  Codename: focal

  Workaround: connected Ethernet. (Inconvenient)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1938983/+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