[Touch-packages] [Bug 2063221] Re: Drop libglib2.0-0 transitional package

[Mauricio Faria de Oliveira]

The updates look good, thanks!

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

Title:
  Drop libglib2.0-0 transitional package

Status in glib2.0 package in Ubuntu:
  In Progress
Status in glib2.0 source package in Noble:
  Confirmed

Bug description:
  Impact
  --
  apt can struggle with ordering when handling the massive Y2028 time_t 
transition when upgrading to Ubuntu 24.04 LTS.

  It was identified that dropping the libglib2.0-0 transitional package
  can help apt do things in the correct order.

  Technically, Steve Langasek already removed libglib2.0-0 from noble
  release just before release. This upload is necessary to ensure that
  we don't accidentally bring it back.

  Test Case
  -
  1. Is libglib2.0-0 built?

  2. Run rmadison libglib2.0-0
  There should be 0 results for noble, noble-proposed, or noble-updates

  3. Ensure that libglib2.0-0 is removed during the upgrade from Ubuntu
  22.04 LTS to 24.04 LTS. Technically, ubuntu-release-upgrader is
  currently set to disallow upgrades to 24.04 LTS. If this is still the
  case when it is time to verify this SRU, you can manually substitute
  jammy → noble in /etc/apt/sources.list for purposes of testing this
  upgrade, probably in a VM since that's not the supported way to
  upgrade.

  Where Problems Could Occur
  --
  Doing an upload to not build a package that already does not exist in Ubuntu 
24.04 LTS should have no regression potential. The only other change in this 
SRU is bumping the Breaks version to ensure that the transitional libglib2.0-0 
is also removed for people who were using Ubuntu 24.04 LTS early. That also 
should not cause problems since the package was an empty transitional package 
for early Ubuntu 24.04 LTS users.

  Other Info
  --
  This is related to LP: #2061918 for the thunderbird deb to snap upgrade

  There are likely several other Launchpad bugs that can be resolved by
  removing the transitional package and some other workarounds in other
  packages, like in the transitional thunderbird package.

  https://salsa.debian.org/gnome-team/glib/-/merge_requests/34

  We have landed the removal in Debian Unstable and it successfully
  migrated to Debian Testing on April 27 as one of the first t64
  packages to migrate there.

  The removal was recommended by Julian Klode, the apt maintainer for
  Debian and Ubuntu.

  The original transitional package was added by Simon McVittie in hopes
  that it would help apt be able to calculate the upgrade easier. At
  least in the Ubuntu Desktop 22.04 LTS → 24.04 LTS case, it looks like
  it was the opposite. (Although that particular detail was fixed by the
  removal that already happened.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2063221/+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 2063221] Re: Drop libglib2.0-0 transitional package

[Mauricio Faria de Oliveira]

Hi Jeremy,

This looks mostly good, AFAICT.

Could you please complete the SRU bug template by adding the section
'Where problems could occur' / 'Regression potential'? [1]

And although the 'Test Case' is feasible to understand, based on the 'Impact' 
section, it would be nice to have a 'functional' test, if at all 
possible/reasonably doable.
For example, I  tried to reproduce the thunderbird deb2snap issue, but it 
didn't. I realize there might be a more complex package setup/install list to 
trigger it, but maybe there's something simpler that you are aware of.
(Or if it's too complex / not worth it, just clarifying that and mentioning 
what shouldn't change / how to check for no regressions, would be OK too; I 
tried to convey that in comment #1).

Thanks!

[1] https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

** Changed in: glib2.0 (Ubuntu Noble)
   Status: In Progress => Incomplete

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

Title:
  Drop libglib2.0-0 transitional package

Status in glib2.0 package in Ubuntu:
  In Progress
Status in glib2.0 source package in Noble:
  Incomplete

Bug description:
  Impact
  --
  apt can struggle with ordering when handling the massive Y2028 time_t 
transition when upgrading to Ubuntu 24.04 LTS.

  It was identified that dropping the libglib2.0-0 transitional package
  can help apt do things in the correct order.

  Test Case
  -
  Is libglib2.0-0 built?

  Where Problems Could Occur
  --
  We have landed the change from this SRU in Debian Unstable and it 
successfully migrated to Debian Testing on April 27 as one of the first t64 
packages to migrate there.

  This SRU was recommended by Julian Klode, the apt maintainer for
  Debian and Ubuntu.

  The original transitional package was added by Simon McVittie in hopes
  that it would help apt be able to calculate the upgrade easier. At
  least in the Ubuntu Desktop 22.04 LTS → 24.04 LTS case, it looks like
  it was the opposite.

  Hmm, we can't actually drop libglib2.0-0 after release, can we?

  Other Info
  --
  This is related to LP: #2061918 for the thunderbird deb to snap upgrade

  There are likely several other Launchpad bugs that can be resolved by
  this update and some other workarounds in other packages, like in the
  transitional thunderbird package.

  https://salsa.debian.org/gnome-team/glib/-/merge_requests/34

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2063221/+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 2063221] Re: Drop libglib2.0-0 transitional package

[Mauricio Faria de Oliveira]

I tested this with a local package build and local repo in a mantic container,
doing an `apt --dry-run dist-upgrade` without/with that repo (w/ noble apt 
sources list),
and manually download/run noble's release upgrader without/with that repo.

The behavior is the same (ie, no regressions) as expected;
libglib2.0-0 is removed in favor of libglib2.0-0t64 in all cases.

Test 1)

Just Noble:

$ apt-cache show libglib2.0-bin | grep Version:
Version: 2.80.0-6ubuntu1
Version: 2.78.0-2

$ sudo apt --dry-run dist-upgrade 2>&1 | awk '{ print NR ": " $0 }' | 
fgrep libglib2.0
17:   libevent-core-2.1-7 libext2fs2 libgdbm-compat4 libgdbm6 
libglib2.0-0
30:   libgdbm6t64 libglib2.0-0t64 libgnutls30t64 libgpgme11t64
79:   libglib2.0-bin libglib2.0-data libgmp10 libgomp1 libgpg-error-l10n
154: Remv libelf1 [0.189-4] [libglib2.0-bin:amd64 libbpf1:amd64 
iproute2:amd64 ]
156: Inst libglib2.0-bin [2.78.0-2] (2.80.0-6ubuntu1 Ubuntu:24.04/noble 
[amd64]) []
378: Remv libglib2.0-0 [2.78.0-2] [libappstream4:amd64 
open-vm-tools:amd64 libc-dev-bin:amd64 libc-bin:amd64 libc6-dev:amd64 
libnetplan0:amd64 ]
379: Inst libglib2.0-0t64 (2.80.0-6ubuntu1 Ubuntu:24.04/noble [amd64]) 
[open-vm-tools:amd64 libc-dev-bin:amd64 libc-bin:amd64 libc6-dev:amd64 ]
611: Inst libglib2.0-data [2.78.0-2] (2.80.0-6ubuntu1 
Ubuntu:24.04/noble [all])
927: Conf libglib2.0-bin (2.80.0-6ubuntu1 Ubuntu:24.04/noble [amd64])
1070: Conf libglib2.0-0t64 (2.80.0-6ubuntu1 Ubuntu:24.04/noble [amd64])
1201: Conf libglib2.0-data (2.80.0-6ubuntu1 Ubuntu:24.04/noble [all])

Noble and local build/repo:

$ apt-cache show libglib2.0-bin | grep Version:
Version: 2.80.0-6ubuntu3
Version: 2.80.0-6ubuntu1
Version: 2.78.0-2

$ sudo apt --dry-run dist-upgrade 2>&1 | awk '{ print NR ": " $0 }' | 
fgrep libglib2.0
17:   libevent-core-2.1-7 libext2fs2 libgdbm-compat4 libgdbm6 
libglib2.0-0
30:   libgdbm6t64 libglib2.0-0t64 libgnutls30t64 libgpgme11t64
79:   libglib2.0-bin libglib2.0-data libgmp10 libgomp1 libgpg-error-l10n
154: Remv libelf1 [0.189-4] [libglib2.0-bin:amd64 libbpf1:amd64 
iproute2:amd64 ]
156: Inst libglib2.0-bin [2.78.0-2] (2.80.0-6ubuntu3 localhost [amd64]) 
[]
378: Remv libglib2.0-0 [2.78.0-2] [libappstream4:amd64 
open-vm-tools:amd64 libc-dev-bin:amd64 libc-bin:amd64 libc6-dev:amd64 
libnetplan0:amd64 ]
379: Inst libglib2.0-0t64 (2.80.0-6ubuntu3 localhost [amd64]) 
[open-vm-tools:amd64 libc-dev-bin:amd64 libc-bin:amd64 libc6-dev:amd64 ]
611: Inst libglib2.0-data [2.78.0-2] (2.80.0-6ubuntu3 localhost [all])
927: Conf libglib2.0-bin (2.80.0-6ubuntu3 localhost [amd64])
1070: Conf libglib2.0-0t64 (2.80.0-6ubuntu3 localhost [amd64])
1201: Conf libglib2.0-data (2.80.0-6ubuntu3 localhost [all])


Test 2)

Just Noble:

$ dpkg -l | fgrep libglib2.0
rc  libglib2.0-0:amd64  2.78.0-2
amd64GLib library of C routines
ii  libglib2.0-0t64:amd64   2.80.0-6ubuntu1 
amd64GLib library of C routines
ii  libglib2.0-bin  2.80.0-6ubuntu1 
amd64Programs for the GLib library
ii  libglib2.0-data 2.80.0-6ubuntu1 
all  Common files for GLib library

$ dpkg -l | grep thunderbird
ii  thunderbird 2:1snap1-0ubuntu3   
amd64Transitional package - thunderbird -> thunderbird snap

$ snap list thunderbird
Name Version Rev  Tracking   Publisher   Notes
thunderbird  115.10.1-1  470  latest/stable  canonical✓  -

Noble and local build/repo:

$ dpkg -l | fgrep libglib2.0
rc  libglib2.0-0:amd64  2.78.0-2
amd64GLib library of C routines
ii  libglib2.0-0t64:amd64   2.80.0-6ubuntu3 
amd64GLib library of C routines
ii  libglib2.0-bin  2.80.0-6ubuntu3 
amd64Programs for the GLib library
ii  libglib2.0-data 2.80.0-6ubuntu3 
all  Common files for GLib library

$ dpkg -l | grep thunderbird
ii  thunderbird 2:1snap1-0ubuntu3   
amd64Transitional package - thunderbird -> thunderbird snap

$ snap list thunderbird
Name Version Rev  Tracking   Publisher   Notes
thunderbird  115.10.1-1  470  latest/stable  canonical✓  -

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

Title:
  Drop 

[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled

[Mauricio Faria de Oliveira]

Autopkgtests are now clear in update_excuses and pending-sru.

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

Title:
  ls -l triggers mount of autofs shares when --ghost option is present
  or browse_mode is enabled

Status in coreutils package in Ubuntu:
  Fix Released
Status in coreutils source package in Jammy:
  Fix Committed
Status in coreutils package in Fedora:
  Fix Released

Bug description:
  [Impact]

  Issuing a 'ls -l' or a 'stat' on an autofs share when you have set
  --ghost in the auto.master file, or browse_mode=yes in autofs.conf
  will lead to the shares being mounted, when they didn't previously.

  Disks / shares may not be present and the mounts may fail, leading to
  errors in your output.

  This is a behaviour change in autofs 8.32, which occurred in the
  transition to using statx() instead of stat()/lstat() in previous
  releases.

  There doesn't seem to be any workarounds, apart from not running a 'ls
  -l' in your autofs share directory.

  [Testcase]

  Start two Jammy VMs. One will be a NFS server, the other, the client.

  NFS server:

  Server VM:
  $ sudo hostnamectl set-hostname jammy-nfs-server
  $ sudo apt update && sudo apt upgrade -y
  $ sudo apt install nfs-kernel-server
  $ sudo mkdir /export
  $ sudo mkdir /export/users
  $ sudo vi /etc/exports # add the following lines:
  /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync)
  /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
  $ sudo systemctl restart nfs-server.service

  AutoFS Client:
  $ sudo apt update
  $ sudo apt install autofs
  $ sudo vim /etc/autofs.conf
  browse_mode = yes
  $ sudo mkdir /mnt2
  $ sudo vim /etc/auto.master
  /mnt2 /etc/auto.indirect
  $ sudo vim /etc/auto.indirect
  export 192.168.122.18:/export
  export-missing 192.168.122.18:/export-missing
  $ sudo reboot
  $ cd /mnt2
  $ ls -l
  ls: cannot access 'export-missing': No such file or directory
  total 4
  drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
  d? ? ??   ?? export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
  192.168.122.18:/export on /mnt2/export type nfs 
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)

  We see the mount for export occurred, and export-missing was
  attempted, but it was either bogus or the disk was not present,
  leading to a "No such file or directory" error.

  There are test packages available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test

  If you install them, this is what should occur:

  $ ls -l
  total 0
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)

  No mounts happen, and no errors either.

  [Where problems could occur]

  We are changing the behaviour of core utilities, ls and stat, such
  that they no longer attempt to mount autofs shares when --ghost option
  is present or browse_mode is enabled.

  This is the intended behaviour in the first place, and has been this
  way for at least a decade prior, and was changed to return to this
  behaviour shortly after the release of coreutils that introduced
  statx() that caused automounts to occur.

  It is unlikely any system administrators are relying on the behaviour
  found in jammy in any scripts or day to day operations that would be
  adversely affected by the change. The worst case scenario is that a
  user doing an 'ls -l' on an unmounted disk finds the mount doesn't
  automatically occur, and they have to attach the disk and issue the
  mount themselves.

  If a regression were to occur, it would be limited to the ls and stat
  commands, specifically when listing directories linked to autofs
  mountpoints.

  [Other info]

  The automount behaviour change was introduced upstream in version
  8.32, with the introduction of the statx() call. This means only Jammy
  is affected.

  It was quickly reverted back to how it was originally in version 9.1,
  which is already available in Mantic and onward.

  The commits that solve the issue are:

  commit 85c975df2c25bd799370b04bb294e568e001102f
  From: Rohan Sable 
  Date: Mon, 7 Mar 2022 14:14:13 +
  Subject: ls: avoid triggering automounts
  Link: 
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2

  commit 92cb8427c537f37edd43c5cef1909585201372ab 
  From: Pádraig Brady 
  Date: Mon, 7 Mar 2022 23:29:20 +
  Subject: stat: only automount 

[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled

[Mauricio Faria de Oliveira]

For dotnet6 on amd64 and arm64, the errors are unrelated to coreutils
(the same test errors happen against dotnet6 itself and even glibc),
thus triggered a migration-reference/0 run.

[0,3] trigger: coreutils/8.32-4.1ubuntu1.2
dotnet-runtime-json-contains-ubuntu-rids FAIL non-zero exit status 253

[1,4] trigger: dotnet6/6.0.128-0ubuntu1~22.04.1
dotnet-runtime-json-contains-ubuntu-rids FAIL non-zero exit status 253

[2,5] trigger: glibc/2.35-0ubuntu3.6
dotnet-runtime-json-contains-ubuntu-rids FAIL non-zero exit status 253

All fail with error messages:
ERROR: RID (Runtime Identifier) 'ubuntu.24.04{,-arm,-arm64,-x64,-x86}' 
is missing in 
'src/runtime/src/libraries/Microsoft.NETCore.Platforms/src/runtime.json'!


[0] 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/d/dotnet6/20240319_131027_34202@/log.gz
[1] 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/d/dotnet6/20240321_145231_25ae8@/log.gz
[2] 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/d/dotnet6/20240321_154527_e413f@/log.gz

[3] 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/d/dotnet6/20240319_111747_74352@/log.gz
[4] 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/d/dotnet6/20240321_135858_e04d0@/log.gz
[5] 
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/arm64/d/dotnet6/20240321_141049_ff5d1@/log.gz

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

Title:
  ls -l triggers mount of autofs shares when --ghost option is present
  or browse_mode is enabled

Status in coreutils package in Ubuntu:
  Fix Released
Status in coreutils source package in Jammy:
  Fix Committed
Status in coreutils package in Fedora:
  Fix Released

Bug description:
  [Impact]

  Issuing a 'ls -l' or a 'stat' on an autofs share when you have set
  --ghost in the auto.master file, or browse_mode=yes in autofs.conf
  will lead to the shares being mounted, when they didn't previously.

  Disks / shares may not be present and the mounts may fail, leading to
  errors in your output.

  This is a behaviour change in autofs 8.32, which occurred in the
  transition to using statx() instead of stat()/lstat() in previous
  releases.

  There doesn't seem to be any workarounds, apart from not running a 'ls
  -l' in your autofs share directory.

  [Testcase]

  Start two Jammy VMs. One will be a NFS server, the other, the client.

  NFS server:

  Server VM:
  $ sudo hostnamectl set-hostname jammy-nfs-server
  $ sudo apt update && sudo apt upgrade -y
  $ sudo apt install nfs-kernel-server
  $ sudo mkdir /export
  $ sudo mkdir /export/users
  $ sudo vi /etc/exports # add the following lines:
  /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync)
  /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
  $ sudo systemctl restart nfs-server.service

  AutoFS Client:
  $ sudo apt update
  $ sudo apt install autofs
  $ sudo vim /etc/autofs.conf
  browse_mode = yes
  $ sudo mkdir /mnt2
  $ sudo vim /etc/auto.master
  /mnt2 /etc/auto.indirect
  $ sudo vim /etc/auto.indirect
  export 192.168.122.18:/export
  export-missing 192.168.122.18:/export-missing
  $ sudo reboot
  $ cd /mnt2
  $ ls -l
  ls: cannot access 'export-missing': No such file or directory
  total 4
  drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
  d? ? ??   ?? export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
  192.168.122.18:/export on /mnt2/export type nfs 
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)

  We see the mount for export occurred, and export-missing was
  attempted, but it was either bogus or the disk was not present,
  leading to a "No such file or directory" error.

  There are test packages available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test

  If you install them, this is what should occur:

  $ ls -l
  total 0
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)

  No mounts happen, and no errors either.

  [Where problems could occur]

  We are changing the behaviour of core utilities, ls and stat, such
  that they no longer attempt to mount autofs shares when --ghost option
  is present or browse_mode is enabled.

  This is the intended behaviour in the first place, and has been this
  way for at least a decade prior, and was changed to return to this
  

[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled

[Mauricio Faria de Oliveira]

Re: comment #15

> autopkgtest for dotnet6/6.0.128-0ubuntu1~22.04.1: amd64: Regression ♻ , 
> arm64: Regression ♻
> autopkgtest for linux-hwe-5.19/5.19.0-50.50: amd64: Pass, arm64: Regression ♻ 
> , ...
> autopkgtest for linux-hwe-6.5/6.5.0-27.28~22.04.1: arm64: Regression ♻ , ...

dotnet6 amd64

apparently unrelated; rerunning without core-utils as trigger:
- rerun with trigger on dotnet6 (from proposed)
- rerun with trigger on glibc (last passing)

dotnet6 jammy/arm64

likewise

linux-hwe-5.19/arm64
timedout several times
rerun

linux-hwe-6.5/arm64
timeout several times
rerun

linux-gcp-5.19 and -6.2 already cleared due to reruns.

Proposed {linux,linux-*}/{arm64,armhf} to long_tests [1] per [2].

[1] 
https://code.launchpad.net/~mfo/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/462861
[2] https://wiki.ubuntu.com/ProposedMigration#autopkgtests

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

Title:
  ls -l triggers mount of autofs shares when --ghost option is present
  or browse_mode is enabled

Status in coreutils package in Ubuntu:
  Fix Released
Status in coreutils source package in Jammy:
  Fix Committed
Status in coreutils package in Fedora:
  Fix Released

Bug description:
  [Impact]

  Issuing a 'ls -l' or a 'stat' on an autofs share when you have set
  --ghost in the auto.master file, or browse_mode=yes in autofs.conf
  will lead to the shares being mounted, when they didn't previously.

  Disks / shares may not be present and the mounts may fail, leading to
  errors in your output.

  This is a behaviour change in autofs 8.32, which occurred in the
  transition to using statx() instead of stat()/lstat() in previous
  releases.

  There doesn't seem to be any workarounds, apart from not running a 'ls
  -l' in your autofs share directory.

  [Testcase]

  Start two Jammy VMs. One will be a NFS server, the other, the client.

  NFS server:

  Server VM:
  $ sudo hostnamectl set-hostname jammy-nfs-server
  $ sudo apt update && sudo apt upgrade -y
  $ sudo apt install nfs-kernel-server
  $ sudo mkdir /export
  $ sudo mkdir /export/users
  $ sudo vi /etc/exports # add the following lines:
  /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync)
  /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
  $ sudo systemctl restart nfs-server.service

  AutoFS Client:
  $ sudo apt update
  $ sudo apt install autofs
  $ sudo vim /etc/autofs.conf
  browse_mode = yes
  $ sudo mkdir /mnt2
  $ sudo vim /etc/auto.master
  /mnt2 /etc/auto.indirect
  $ sudo vim /etc/auto.indirect
  export 192.168.122.18:/export
  export-missing 192.168.122.18:/export-missing
  $ sudo reboot
  $ cd /mnt2
  $ ls -l
  ls: cannot access 'export-missing': No such file or directory
  total 4
  drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
  d? ? ??   ?? export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
  192.168.122.18:/export on /mnt2/export type nfs 
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)

  We see the mount for export occurred, and export-missing was
  attempted, but it was either bogus or the disk was not present,
  leading to a "No such file or directory" error.

  There are test packages available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test

  If you install them, this is what should occur:

  $ ls -l
  total 0
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)

  No mounts happen, and no errors either.

  [Where problems could occur]

  We are changing the behaviour of core utilities, ls and stat, such
  that they no longer attempt to mount autofs shares when --ghost option
  is present or browse_mode is enabled.

  This is the intended behaviour in the first place, and has been this
  way for at least a decade prior, and was changed to return to this
  behaviour shortly after the release of coreutils that introduced
  statx() that caused automounts to occur.

  It is unlikely any system administrators are relying on the behaviour
  found in jammy in any scripts or day to day operations that would be
  adversely affected by the change. The worst case scenario is that a
  user doing an 'ls -l' on an unmounted disk finds the mount doesn't
  automatically occur, and they have to attach the disk and issue the
  mount themselves.

  If a 

[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2

[Mauricio Faria de Oliveira]

No problem, Mitchell!

Yes, the point pending from comment #44 (.3) is resolved for Jammy per
#48 (so Jammy should be OK, AFAICT), and pending for Focal per #49
(being addressed per #50; thanks!).

Please note that other SRU vanguards may have a different opinion (or
raise other points I may have missed); my shift is  on Mondays, so this
is to be checked by someone else during this week.

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

Title:
  Python extension modules get built using wrong compiler flags with
  python2

Status in python2.7 package in Ubuntu:
  Invalid
Status in python2.7 source package in Bionic:
  Won't Fix
Status in python2.7 source package in Focal:
  Fix Committed
Status in python2.7 source package in Jammy:
  Fix Committed
Status in python2.7 source package in Kinetic:
  Invalid
Status in python2.7 source package in Lunar:
  Invalid
Status in python2.7 source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

  When compiling Python extensions using Python2, CFLAGS optimization
  flags are dropped.

  This behavior has been caused by our update in this patch
  
http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz
  which differs from upstream.

  The fix modifies the portion of code in Lib/distutils/sysconfig.py
  which gets the cflags from the environments, and includes the dropped
  OPT flag from get_config_vars().

  [ Test Plan ]

  There will be 2 separate tests for this bug:
  * Ensuring no-change rebuilds are not changed
  * Ensuring local builds are not changed unless environment variable is set

  Test 1) No-change rebuilds

  To test that no-change rebuilds are not changed, the package python-
  stdlib-extensions will be built against the new python2.7, and confirm
  the compiler flags are not altered. This will be a manual test and
  visual inspection of the build logs.

  Test 2) Functional test

  1. Create test container
  $ lxc launch ubuntu:jammy jammy-2002043
  $ lxc shell jammy-2002043

  2. Install required packages
  For Jammy
  # apt update -y && apt install -y python2 python-pip
  For Focal
  # apt update -y && apt install -y python2 python-setuptools gcc

  3. Create test files
  # mkdir testprog
  # cd testprog
  # cat >setup.py 

[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2

[Mauricio Faria de Oliveira]

Hi Mitchell,

Indeed, there are some autopkgtests results/failures that are not
reported in pending-sru or update_excuses -- this is the case specially
for Focal (Jammy looks good).

I downloaded the autopkgtest.db from autopkgtest.ubuntu.com, and locally 
queried it.
The test results with exitcode != 0 need checking.

Could you please take a look at those?
If you need any tests retried or other assistance, please let us know!
(You know, starting from https://autopkgtest.ubuntu.com/packages/$SRCPKG and 
going from there.)

Thanks!
Mauricio

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

Title:
  Python extension modules get built using wrong compiler flags with
  python2

Status in python2.7 package in Ubuntu:
  Invalid
Status in python2.7 source package in Bionic:
  Won't Fix
Status in python2.7 source package in Focal:
  Fix Committed
Status in python2.7 source package in Jammy:
  Fix Committed
Status in python2.7 source package in Kinetic:
  Invalid
Status in python2.7 source package in Lunar:
  Invalid
Status in python2.7 source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

  When compiling Python extensions using Python2, CFLAGS optimization
  flags are dropped.

  This behavior has been caused by our update in this patch
  
http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz
  which differs from upstream.

  The fix modifies the portion of code in Lib/distutils/sysconfig.py
  which gets the cflags from the environments, and includes the dropped
  OPT flag from get_config_vars().

  [ Test Plan ]

  There will be 2 separate tests for this bug:
  * Ensuring no-change rebuilds are not changed
  * Ensuring local builds are not changed unless environment variable is set

  Test 1) No-change rebuilds

  To test that no-change rebuilds are not changed, the package python-
  stdlib-extensions will be built against the new python2.7, and confirm
  the compiler flags are not altered. This will be a manual test and
  visual inspection of the build logs.

  Test 2) Functional test

  1. Create test container
  $ lxc launch ubuntu:jammy jammy-2002043
  $ lxc shell jammy-2002043

  2. Install required packages
  For Jammy
  # apt update -y && apt install -y python2 python-pip
  For Focal
  # apt update -y && apt install -y python2 python-setuptools gcc

  3. Create test files
  # mkdir testprog
  # cd testprog
  # cat >setup.py 

[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2

[Mauricio Faria de Oliveira]

RELEASE=jammy
TRIGGER=python2.7/2.7.18-13ubuntu1.2

sqlite3 autopkgtest.db -column -header \
"SELECT test.release, test.arch, test.package, "\
"   result.version, result.exitcode, "\
"   result.triggers, result.requester "\
"FROM test, result "\
"WHERE test.id = result.test_id "\
"AND test.release = '${RELEASE}' "\
"AND result.triggers LIKE '%${TRIGGER}%' "\
"ORDER BY test.release, test.package, test.arch"

release  arch package version exitcode  triggers
  requester
---  ---  --  --    
  -
jammyamd64libgnatcoll-python  21.0.0-20 
python2.7/2.7.18-13ubuntu1.2
jammyarm64libgnatcoll-python  21.0.0-20 
python2.7/2.7.18-13ubuntu1.2
jammyarmhflibgnatcoll-python  21.0.0-20 
python2.7/2.7.18-13ubuntu1.2
jammyppc64el  libgnatcoll-python  21.0.0-20 
python2.7/2.7.18-13ubuntu1.2
jammys390xlibgnatcoll-python  21.0.0-20 
python2.7/2.7.18-13ubuntu1.2
jammyamd64python2.7   2.7.18-13ubuntu1.2  0 
python2.7/2.7.18-13ubuntu1.2
jammyarm64python2.7   2.7.18-13ubuntu1.2  0 
python2.7/2.7.18-13ubuntu1.2
jammyarmhfpython2.7   2.7.18-13ubuntu1.2  0 
python2.7/2.7.18-13ubuntu1.2
jammyi386 python2.7   2.7.18-13ubuntu1.2  12
python2.7/2.7.18-13ubuntu1.2
jammyppc64el  python2.7   2.7.18-13ubuntu1.2  0 
python2.7/2.7.18-13ubuntu1.2
jammys390xpython2.7   2.7.18-13ubuntu1.2  0 
python2.7/2.7.18-13ubuntu1.2


jammy/i386/python2.7: not a regression (unrelated failure)

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

Title:
  Python extension modules get built using wrong compiler flags with
  python2

Status in python2.7 package in Ubuntu:
  Invalid
Status in python2.7 source package in Bionic:
  Won't Fix
Status in python2.7 source package in Focal:
  Fix Committed
Status in python2.7 source package in Jammy:
  Fix Committed
Status in python2.7 source package in Kinetic:
  Invalid
Status in python2.7 source package in Lunar:
  Invalid
Status in python2.7 source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

  When compiling Python extensions using Python2, CFLAGS optimization
  flags are dropped.

  This behavior has been caused by our update in this patch
  
http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz
  which differs from upstream.

  The fix modifies the portion of code in Lib/distutils/sysconfig.py
  which gets the cflags from the environments, and includes the dropped
  OPT flag from get_config_vars().

  [ Test Plan ]

  There will be 2 separate tests for this bug:
  * Ensuring no-change rebuilds are not changed
  * Ensuring local builds are not changed unless environment variable is set

  Test 1) No-change rebuilds

  To test that no-change rebuilds are not changed, the package python-
  stdlib-extensions will be built against the new python2.7, and confirm
  the compiler flags are not altered. This will be a manual test and
  visual inspection of the build logs.

  Test 2) Functional test

  1. Create test container
  $ lxc launch ubuntu:jammy jammy-2002043
  $ lxc shell jammy-2002043

  2. Install required packages
  For Jammy
  # apt update -y && apt install -y python2 python-pip
  For Focal
  # apt update -y && apt install -y python2 python-setuptools gcc

  3. Create test files
  # mkdir testprog
  # cd testprog
  # cat >setup.py 

[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2

[Mauricio Faria de Oliveira]

RELEASE=focal
TRIGGER=python2.7/2.7.18-1~20.04.4

sqlite3 autopkgtest.db -column -header \
"SELECT test.release, test.arch, test.package, "\
"   result.version, result.exitcode, "\
"   result.triggers, result.requester "\
"FROM test, result "\
"WHERE test.id = result.test_id "\
"AND test.release = '${RELEASE}' "\
"AND result.triggers LIKE '%${TRIGGER}%' "\
"ORDER BY test.release, test.package, test.arch"

release  arch packageversion   exitcode 
 triggersrequester
---  ---  -     
 --  -
focalamd64dbus-python1.2.16-1build10
 python2.7/2.7.18-1~20.04.4
focalarm64dbus-python1.2.16-1build10
 python2.7/2.7.18-1~20.04.4
focalarmhfdbus-python1.2.16-1build10
 python2.7/2.7.18-1~20.04.4
focali386 dbus-python1.2.16-1build114   
 python2.7/2.7.18-1~20.04.4
focalppc64el  dbus-python1.2.16-1build10
 python2.7/2.7.18-1~20.04.4
focals390xdbus-python1.2.16-1build10
 python2.7/2.7.18-1~20.04.4
focalamd64kodi   2:18.6+dfsg1-2ubuntu1 0
 python2.7/2.7.18-1~20.04.4
focalarm64kodi   2:18.6+dfsg1-2ubuntu1 0
 python2.7/2.7.18-1~20.04.4
focalarmhfkodi   2:18.6+dfsg1-2ubuntu1 0
 python2.7/2.7.18-1~20.04.4
focalppc64el  kodi   2:18.6+dfsg1-2ubuntu1 0
 python2.7/2.7.18-1~20.04.4
focalamd64libapache2-mod-python  3.3.1-11ubuntu5   0
 python2.7/2.7.18-1~20.04.4
focalarm64libapache2-mod-python  3.3.1-11ubuntu5   0
 python2.7/2.7.18-1~20.04.4
focalarmhflibapache2-mod-python  3.3.1-11ubuntu5   0
 python2.7/2.7.18-1~20.04.4
focalppc64el  libapache2-mod-python  3.3.1-11ubuntu5   0
 python2.7/2.7.18-1~20.04.4
focals390xlibapache2-mod-python  3.3.1-11ubuntu5   0
 python2.7/2.7.18-1~20.04.4
focalamd64libgnatcoll-bindings   19-2  0
 python2.7/2.7.18-1~20.04.4
focalarm64libgnatcoll-bindings   19-2  0
 python2.7/2.7.18-1~20.04.4
focalarmhflibgnatcoll-bindings   19-2  0
 python2.7/2.7.18-1~20.04.4
focalppc64el  libgnatcoll-bindings   19-2  0
 python2.7/2.7.18-1~20.04.4
focals390xlibgnatcoll-bindings   19-2  0
 python2.7/2.7.18-1~20.04.4
focalamd64libxml22.9.10+dfsg-5ubuntu0.20.04.6  0
 python2.7/2.7.18-1~20.04.4
focalarm64libxml22.9.10+dfsg-5ubuntu0.20.04.6  0
 python2.7/2.7.18-1~20.04.4
focalarmhflibxml22.9.10+dfsg-5ubuntu0.20.04.6  0
 python2.7/2.7.18-1~20.04.4
focali386 libxml22.9.10+dfsg-5ubuntu0.20.04.6  12   
 python2.7/2.7.18-1~20.04.4
focalppc64el  libxml22.9.10+dfsg-5ubuntu0.20.04.6  0
 python2.7/2.7.18-1~20.04.4
focals390xlibxml22.9.10+dfsg-5ubuntu0.20.04.6  0
 python2.7/2.7.18-1~20.04.4
focalamd64llvm-toolchain-7   1:7.0.1-120
 python2.7/2.7.18-1~20.04.4
focalarm64llvm-toolchain-7   1:7.0.1-124
 python2.7/2.7.18-1~20.04.4
focalarmhfllvm-toolchain-7   1:7.0.1-124
 python2.7/2.7.18-1~20.04.4
focalppc64el  llvm-toolchain-7   1:7.0.1-124
 python2.7/2.7.18-1~20.04.4
focalamd64mercurial  5.3.1-1ubuntu14
 python2.7/2.7.18-1~20.04.4
focalarm64mercurial  5.3.1-1ubuntu14
 python2.7/2.7.18-1~20.04.4
focalarmhfmercurial  5.3.1-1ubuntu14
 python2.7/2.7.18-1~20.04.4
focali386 mercurial  5.3.1-1ubuntu112   
 python2.7/2.7.18-1~20.04.4
focalppc64el  mercurial  5.3.1-1ubuntu14
 python2.7/2.7.18-1~20.04.4
focals390xmercurial  5.3.1-1ubuntu14
 python2.7/2.7.18-1~20.04.4
focalamd64mod-wsgi   4.6.8-1ubuntu3.1  0
 python2.7/2.7.18-1~20.04.4
focalarm64mod-wsgi   4.6.8-1ubuntu3.1  0
 python2.7/2.7.18-1~20.04.4
focalarmhfmod-wsgi   4.6.8-1ubuntu3.1  0
 python2.7/2.7.18-1~20.04.4
focalppc64el  mod-wsgi   4.6.8-1ubuntu3.1  0
 

[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2

[Mauricio Faria de Oliveira]

Hey Mitchell,

No, the autopkgtests re-run for python2.7/focal are done and OK ('they continue 
to fail').
Link: [1] (see the Focal results on diff archs have 'migration-reference/0' and 
'mfo').

The autopkgtests point pending is a clarification on the
database/results, ie, whether we can trust the report pages (pending-
sru, update_excuses).

We'll check that. Thanks!

[1] https://autopkgtest.ubuntu.com/packages/python2.7

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

Title:
  Python extension modules get built using wrong compiler flags with
  python2

Status in python2.7 package in Ubuntu:
  Invalid
Status in python2.7 source package in Bionic:
  Won't Fix
Status in python2.7 source package in Focal:
  Fix Committed
Status in python2.7 source package in Jammy:
  Fix Committed
Status in python2.7 source package in Kinetic:
  Invalid
Status in python2.7 source package in Lunar:
  Invalid
Status in python2.7 source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

  When compiling Python extensions using Python2, CFLAGS optimization
  flags are dropped.

  This behavior has been caused by our update in this patch
  
http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz
  which differs from upstream.

  The fix modifies the portion of code in Lib/distutils/sysconfig.py
  which gets the cflags from the environments, and includes the dropped
  OPT flag from get_config_vars().

  [ Test Plan ]

  There will be 2 separate tests for this bug:
  * Ensuring no-change rebuilds are not changed
  * Ensuring local builds are not changed unless environment variable is set

  Test 1) No-change rebuilds

  To test that no-change rebuilds are not changed, the package python-
  stdlib-extensions will be built against the new python2.7, and confirm
  the compiler flags are not altered. This will be a manual test and
  visual inspection of the build logs.

  Test 2) Functional test

  1. Create test container
  $ lxc launch ubuntu:jammy jammy-2002043
  $ lxc shell jammy-2002043

  2. Install required packages
  For Jammy
  # apt update -y && apt install -y python2 python-pip
  For Focal
  # apt update -y && apt install -y python2 python-setuptools gcc

  3. Create test files
  # mkdir testprog
  # cd testprog
  # cat >setup.py 

[Touch-packages] [Bug 2002043] Re: Python extension modules get built using wrong compiler flags with python2

[Mauricio Faria de Oliveira]

Just a few observations before release.

1) The verification for Jammy apparently has a copy-paste error,
as the banner about the env var is present (step 5) _before_ the
package from -proposed -- which adds it -- is installed (step 6).

To be clear, this is not a problem and should not block the release,
as the _new_ behavior (with -proposed installed) is what matters,
and that looks correct in the output:
- env var undefined/no opt-in = old behavior;
- env var defined/opted-in = new behavior.

The verification for Focal is OK on that regard (does not show the
banner in step 5).

2) The autopkgtests for python2.7/focal failed, but this is not due to these 
changes.
I re-run the tests with the trigger migration-reference/0, and they continue to 
fail.

This is expected, since the changes are opt-in / are not enabled by default.
The only change which _is_ enabled by default is the new banner during build,
but that output is likely not checked for, I'd imagine (ie, it's OK to change).

3) There's been a recent rebuild of the autopkgtest database, and I'd have to
verify the status (ie, finished?) and impact (eg, report pages) at the moment
to make sure this is OK on that regard.

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

Title:
  Python extension modules get built using wrong compiler flags with
  python2

Status in python2.7 package in Ubuntu:
  Invalid
Status in python2.7 source package in Bionic:
  Won't Fix
Status in python2.7 source package in Focal:
  Fix Committed
Status in python2.7 source package in Jammy:
  Fix Committed
Status in python2.7 source package in Kinetic:
  Invalid
Status in python2.7 source package in Lunar:
  Invalid
Status in python2.7 source package in Mantic:
  Invalid

Bug description:
  [ Impact ]

  When compiling Python extensions using Python2, CFLAGS optimization
  flags are dropped.

  This behavior has been caused by our update in this patch
  
http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz
  which differs from upstream.

  The fix modifies the portion of code in Lib/distutils/sysconfig.py
  which gets the cflags from the environments, and includes the dropped
  OPT flag from get_config_vars().

  [ Test Plan ]

  There will be 2 separate tests for this bug:
  * Ensuring no-change rebuilds are not changed
  * Ensuring local builds are not changed unless environment variable is set

  Test 1) No-change rebuilds

  To test that no-change rebuilds are not changed, the package python-
  stdlib-extensions will be built against the new python2.7, and confirm
  the compiler flags are not altered. This will be a manual test and
  visual inspection of the build logs.

  Test 2) Functional test

  1. Create test container
  $ lxc launch ubuntu:jammy jammy-2002043
  $ lxc shell jammy-2002043

  2. Install required packages
  For Jammy
  # apt update -y && apt install -y python2 python-pip
  For Focal
  # apt update -y && apt install -y python2 python-setuptools gcc

  3. Create test files
  # mkdir testprog
  # cd testprog
  # cat >setup.py 

[Touch-packages] [Bug 2054925] Re: Debootstrap fails for Noble with base-files 13ubuntu7

[Mauricio Faria de Oliveira]

> Apologies, I saw the same issue locally fixed it but must have
forgotten to build a new .dsc:/

No worries; thanks for mentioning!

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

Title:
  Debootstrap fails for Noble with base-files 13ubuntu7

Status in base-files package in Ubuntu:
  Won't Fix
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Focal:
  Fix Committed
Status in debootstrap source package in Jammy:
  Fix Released
Status in base-files source package in Mantic:
  New
Status in debootstrap source package in Mantic:
  Fix Released

Bug description:
  [Impact]
  The last couple of days, I have been unable to run a successful debootstrap 
for Noble Numbat.

  Apparently this is caused by the addition of symlinks (/bin, /lib,
  /lib64 and /sbin) in base-files 13ubuntu7. According to
  debootstrap.log, it fails to extract said symlinks because they
  already exist at that point.

  This can be reproduced on build hosts running Jammy Jellyfish against
  any up-to-date Ubuntu public archive mirror as of today.

  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 22.04.4 LTS
  Release:  22.04
  Codename: jammy

  # apt-cache policy debootstrap
  debootstrap:
    Installed: 1.0.126+nmu1ubuntu0.5
    Candidate: 1.0.126+nmu1ubuntu0.5
    Version table:
   *** 1.0.126+nmu1ubuntu0.5 500
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
  100 /var/lib/dpkg/status
   1.0.126+nmu1 500
  500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

  Attached shell output of two runs of debootstrap. First run uses
  mirror archive.ubuntu.com (which as of this report serves base-files
  version 13ubuntu7), and second run uses a local custom mirror (which
  serves base-files 13ubuntu6). First run fails, second run succeeds.

  [Test plan]
  Successfully for each of focal, jammy, mantic, noble
  - debootstrap
  - mk-sbuild
  - pbuilder-dist $release create
  - ubuntu-image, if we can pull debootstrap from proposed for this

  as well as

  - debootstrap noble --merged-usr

  [Where problems could occur]
  We do not anticipate any regressions as we replace the previous *) case for 
usrmerge for post-hirsute with a new jammy|kinetic|lunar|mantic one, and the 
new solution will only impact noble and onward.

  That said, this is a different approach than mantic and newer take,
  and a different approach than Debian takes, where they moved to
  merging post-extraction, even in stable releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2054925/+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 2054925] Please test proposed package

[Mauricio Faria de Oliveira]

Hello Åka, or anyone else affected,

Accepted debootstrap into focal-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/debootstrap/1.0.118ubuntu1.13 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

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

Title:
  Debootstrap fails for Noble with base-files 13ubuntu7

Status in base-files package in Ubuntu:
  Won't Fix
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Focal:
  Fix Committed
Status in debootstrap source package in Jammy:
  Fix Released
Status in base-files source package in Mantic:
  New
Status in debootstrap source package in Mantic:
  Fix Released

Bug description:
  [Impact]
  The last couple of days, I have been unable to run a successful debootstrap 
for Noble Numbat.

  Apparently this is caused by the addition of symlinks (/bin, /lib,
  /lib64 and /sbin) in base-files 13ubuntu7. According to
  debootstrap.log, it fails to extract said symlinks because they
  already exist at that point.

  This can be reproduced on build hosts running Jammy Jellyfish against
  any up-to-date Ubuntu public archive mirror as of today.

  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 22.04.4 LTS
  Release:  22.04
  Codename: jammy

  # apt-cache policy debootstrap
  debootstrap:
    Installed: 1.0.126+nmu1ubuntu0.5
    Candidate: 1.0.126+nmu1ubuntu0.5
    Version table:
   *** 1.0.126+nmu1ubuntu0.5 500
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
  100 /var/lib/dpkg/status
   1.0.126+nmu1 500
  500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

  Attached shell output of two runs of debootstrap. First run uses
  mirror archive.ubuntu.com (which as of this report serves base-files
  version 13ubuntu7), and second run uses a local custom mirror (which
  serves base-files 13ubuntu6). First run fails, second run succeeds.

  [Test plan]
  Successfully for each of focal, jammy, mantic, noble
  - debootstrap
  - mk-sbuild
  - pbuilder-dist $release create
  - ubuntu-image, if we can pull debootstrap from proposed for this

  as well as

  - debootstrap noble --merged-usr

  [Where problems could occur]
  We do not anticipate any regressions as we replace the previous *) case for 
usrmerge for post-hirsute with a new jammy|kinetic|lunar|mantic one, and the 
new solution will only impact noble and onward.

  That said, this is a different approach than mantic and newer take,
  and a different approach than Debian takes, where they moved to
  merging post-extraction, even in stable releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2054925/+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 2054925] Re: Debootstrap fails for Noble with base-files 13ubuntu7

[Mauricio Faria de Oliveira]

The changes for Focal had a syntax error (double ';;' lines, not present
in Jammy) which causes debootstrap to fail early and silently, even for
a previously working series.

Original:

$ sudo debootstrap --variant=minbase focal /tmp/debootstrap.focal 
http://br.archive.ubuntu.com/ubuntu
...
I: Base system installed successfully.
$ echo $?
0

Patched:

$ sudo debootstrap --variant=minbase focal /tmp/debootstrap.focal 
http://br.archive.ubuntu.com/ubuntu
$ echo $?
2

Addressed this issue; verified the diff only changed in that regard; and
re-uploaded.

$ diff -U0 debootstrap_1.0.118ubuntu1.12_1.0.118ubuntu1.13.diff debdiff 
| grep -v '^@@' | sort | uniq -c | sort
  1 +++ debdiff 2024-03-04 21:01:43.500570118 +
  1 --- debootstrap_1.0.118ubuntu1.12_1.0.118ubuntu1.13.diff
2024-02-26 15:24:26.0 +
 32 +@@ -78,7 +78,14 @@
 32 -+  ;;
 32 -@@ -78,7 +78,15 @@

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

Title:
  Debootstrap fails for Noble with base-files 13ubuntu7

Status in base-files package in Ubuntu:
  Won't Fix
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Focal:
  Fix Committed
Status in debootstrap source package in Jammy:
  Fix Released
Status in base-files source package in Mantic:
  New
Status in debootstrap source package in Mantic:
  Fix Released

Bug description:
  [Impact]
  The last couple of days, I have been unable to run a successful debootstrap 
for Noble Numbat.

  Apparently this is caused by the addition of symlinks (/bin, /lib,
  /lib64 and /sbin) in base-files 13ubuntu7. According to
  debootstrap.log, it fails to extract said symlinks because they
  already exist at that point.

  This can be reproduced on build hosts running Jammy Jellyfish against
  any up-to-date Ubuntu public archive mirror as of today.

  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 22.04.4 LTS
  Release:  22.04
  Codename: jammy

  # apt-cache policy debootstrap
  debootstrap:
    Installed: 1.0.126+nmu1ubuntu0.5
    Candidate: 1.0.126+nmu1ubuntu0.5
    Version table:
   *** 1.0.126+nmu1ubuntu0.5 500
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
  100 /var/lib/dpkg/status
   1.0.126+nmu1 500
  500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

  Attached shell output of two runs of debootstrap. First run uses
  mirror archive.ubuntu.com (which as of this report serves base-files
  version 13ubuntu7), and second run uses a local custom mirror (which
  serves base-files 13ubuntu6). First run fails, second run succeeds.

  [Test plan]
  Successfully for each of focal, jammy, mantic, noble
  - debootstrap
  - mk-sbuild
  - pbuilder-dist $release create
  - ubuntu-image, if we can pull debootstrap from proposed for this

  as well as

  - debootstrap noble --merged-usr

  [Where problems could occur]
  We do not anticipate any regressions as we replace the previous *) case for 
usrmerge for post-hirsute with a new jammy|kinetic|lunar|mantic one, and the 
new solution will only impact noble and onward.

  That said, this is a different approach than mantic and newer take,
  and a different approach than Debian takes, where they moved to
  merging post-extraction, even in stable releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2054925/+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 2054925] Re: Debootstrap fails for Noble with base-files 13ubuntu7

[Mauricio Faria de Oliveira]

Testing with the change applied:

$ sudo debootstrap --variant=minbase noble /tmp/debootstrap.noble 
http://br.archive.ubuntu.com/ubuntu
...
I: Base system installed successfully.
$ echo $?
0

$ ls -l /tmp/debootstrap.noble/ | grep usr/
lrwxrwxrwx  1 root root7 Feb 22 14:39 bin -> usr/bin
lrwxrwxrwx  1 root root7 Feb 22 14:39 lib -> usr/lib
lrwxrwxrwx  1 root root9 Feb 22 14:39 lib64 -> usr/lib64
lrwxrwxrwx  1 root root8 Feb 22 14:39 sbin -> usr/sbin

** Changed in: debootstrap (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags removed: verification-done
** Tags added: verification-needed verification-needed-focal

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

Title:
  Debootstrap fails for Noble with base-files 13ubuntu7

Status in base-files package in Ubuntu:
  Won't Fix
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Focal:
  Fix Committed
Status in debootstrap source package in Jammy:
  Fix Released
Status in base-files source package in Mantic:
  New
Status in debootstrap source package in Mantic:
  Fix Released

Bug description:
  [Impact]
  The last couple of days, I have been unable to run a successful debootstrap 
for Noble Numbat.

  Apparently this is caused by the addition of symlinks (/bin, /lib,
  /lib64 and /sbin) in base-files 13ubuntu7. According to
  debootstrap.log, it fails to extract said symlinks because they
  already exist at that point.

  This can be reproduced on build hosts running Jammy Jellyfish against
  any up-to-date Ubuntu public archive mirror as of today.

  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 22.04.4 LTS
  Release:  22.04
  Codename: jammy

  # apt-cache policy debootstrap
  debootstrap:
    Installed: 1.0.126+nmu1ubuntu0.5
    Candidate: 1.0.126+nmu1ubuntu0.5
    Version table:
   *** 1.0.126+nmu1ubuntu0.5 500
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
  100 /var/lib/dpkg/status
   1.0.126+nmu1 500
  500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

  Attached shell output of two runs of debootstrap. First run uses
  mirror archive.ubuntu.com (which as of this report serves base-files
  version 13ubuntu7), and second run uses a local custom mirror (which
  serves base-files 13ubuntu6). First run fails, second run succeeds.

  [Test plan]
  Successfully for each of focal, jammy, mantic, noble
  - debootstrap
  - mk-sbuild
  - pbuilder-dist $release create
  - ubuntu-image, if we can pull debootstrap from proposed for this

  as well as

  - debootstrap noble --merged-usr

  [Where problems could occur]
  We do not anticipate any regressions as we replace the previous *) case for 
usrmerge for post-hirsute with a new jammy|kinetic|lunar|mantic one, and the 
new solution will only impact noble and onward.

  That said, this is a different approach than mantic and newer take,
  and a different approach than Debian takes, where they moved to
  merging post-extraction, even in stable releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2054925/+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 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled

[Mauricio Faria de Oliveira]

Considerations for the SRU team:

I confirmed that the behavior in Jammy is different than
Focal and Mantic, the previous / next supported releases.
(Steps in the next comment.)

So, although this SRU changes behavior in a stable release
(generally not OK in SRUs), it is actually Jammy that changed
behavior _across_ stable releases (and to a buggy one!).

Thus, the SRU is reasonably _restoring_ (arguably, _fixing_)
the _expected_ behavior.  So, this looks OK for SRU, IMHO.

Additionally, I considered two points before sponsoring this.

1) The impact of the code changes to non-autofs/non-automount:

And it seems virtually zero, considering the man pages explain
the flag now used in statx() is used in other related syscalls
(stat, lstat, fstatat), which have it implied since Linux 4.11.
And it indeed only affects automount (note the flag name).

So, even though this change is "new" in Jammy, it's been tested
in older and later releases for a long time (pre-Bionic kernels).

stat(2):

   AT_NO_AUTOMOUNT (since Linux 2.6.38)
  [...]  Since Linux 4.11 this flag is implied.

statx(2):

   AT_NO_AUTOMOUNT
  [...]
  All  of stat(2), lstat(2), and fstatat(2) act as though 
AT_NO_AUTOMOUNT
  was set.

2) Whether users may have started to rely on this behavior

I agree this is unlikely, and think so because of 3 points:

2.1) This behavior did not exist in previous releases,
which reduces the chances it has been 'learned' before.

2.2) The usage of autofs/automount rely on access to be made
_to a particular mountpoint_ in order for it to be _mounted_.

This is reflected in different documentation sources online,
so it is likely that this is the way that has been 'learned'.

2.3) The safe side is, _even if_ an user started to rely on
this behavior to automount the subdirs, the very next thing
they will do (if they actually need that subdir mounted) is
to _access_ that subdir - which can mount it just as before!

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

Title:
  ls -l triggers mount of autofs shares when --ghost option is present
  or browse_mode is enabled

Status in coreutils package in Ubuntu:
  Fix Released
Status in coreutils source package in Jammy:
  In Progress
Status in coreutils package in Fedora:
  Fix Released

Bug description:
  [Impact]

  Issuing a 'ls -l' or a 'stat' on an autofs share when you have set
  --ghost in the auto.master file, or browse_mode=yes in autofs.conf
  will lead to the shares being mounted, when they didn't previously.

  Disks / shares may not be present and the mounts may fail, leading to
  errors in your output.

  This is a behaviour change in autofs 8.32, which occurred in the
  transition to using statx() instead of stat()/lstat() in previous
  releases.

  There doesn't seem to be any workarounds, apart from not running a 'ls
  -l' in your autofs share directory.

  [Testcase]

  Start two Jammy VMs. One will be a NFS server, the other, the client.

  NFS server:

  Server VM:
  $ sudo hostnamectl set-hostname jammy-nfs-server
  $ sudo apt update && sudo apt upgrade -y
  $ sudo apt install nfs-kernel-server
  $ sudo mkdir /export
  $ sudo mkdir /export/users
  $ sudo vi /etc/exports # add the following lines:
  /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync)
  /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
  $ sudo systemctl restart nfs-server.service

  AutoFS Client:
  $ sudo apt update
  $ sudo apt install autofs
  $ sudo vim /etc/autofs.conf
  browse_mode = yes
  $ sudo mkdir /mnt2
  $ sudo vim /etc/auto.master
  /mnt2 /etc/auto.indirect
  $ sudo vim /etc/auto.indirect
  export 192.168.122.18:/export
  export-missing 192.168.122.18:/export-missing
  $ sudo reboot
  $ cd /mnt2
  $ ls -l
  ls: cannot access 'export-missing': No such file or directory
  total 4
  drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
  d? ? ??   ?? export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
  192.168.122.18:/export on /mnt2/export type nfs 
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)

  We see the mount for export occurred, and export-missing was
  attempted, but it was either bogus or the disk was not present,
  leading to a "No such file or directory" error.

  There are test packages available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test

  If you install them, this is what should occur:

  $ ls -l
  total 0
  drwxr-xr-x 2 root root 0 Feb 12 22:01 

[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled

[Mauricio Faria de Oliveira]

Reviewed and sponsored to Jammy; thanks!

Notes:
- Please add test for `stat` as well (bottom of tests comment).
- I just changed the DEP3 Origin tag (commit ID; backport_ed_).

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

Title:
  ls -l triggers mount of autofs shares when --ghost option is present
  or browse_mode is enabled

Status in coreutils package in Ubuntu:
  Fix Released
Status in coreutils source package in Jammy:
  In Progress
Status in coreutils package in Fedora:
  Fix Released

Bug description:
  [Impact]

  Issuing a 'ls -l' or a 'stat' on an autofs share when you have set
  --ghost in the auto.master file, or browse_mode=yes in autofs.conf
  will lead to the shares being mounted, when they didn't previously.

  Disks / shares may not be present and the mounts may fail, leading to
  errors in your output.

  This is a behaviour change in autofs 8.32, which occurred in the
  transition to using statx() instead of stat()/lstat() in previous
  releases.

  There doesn't seem to be any workarounds, apart from not running a 'ls
  -l' in your autofs share directory.

  [Testcase]

  Start two Jammy VMs. One will be a NFS server, the other, the client.

  NFS server:

  Server VM:
  $ sudo hostnamectl set-hostname jammy-nfs-server
  $ sudo apt update && sudo apt upgrade -y
  $ sudo apt install nfs-kernel-server
  $ sudo mkdir /export
  $ sudo mkdir /export/users
  $ sudo vi /etc/exports # add the following lines:
  /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync)
  /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
  $ sudo systemctl restart nfs-server.service

  AutoFS Client:
  $ sudo apt update
  $ sudo apt install autofs
  $ sudo vim /etc/autofs.conf
  browse_mode = yes
  $ sudo mkdir /mnt2
  $ sudo vim /etc/auto.master
  /mnt2 /etc/auto.indirect
  $ sudo vim /etc/auto.indirect
  export 192.168.122.18:/export
  export-missing 192.168.122.18:/export-missing
  $ sudo reboot
  $ cd /mnt2
  $ ls -l
  ls: cannot access 'export-missing': No such file or directory
  total 4
  drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
  d? ? ??   ?? export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
  192.168.122.18:/export on /mnt2/export type nfs 
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)

  We see the mount for export occurred, and export-missing was
  attempted, but it was either bogus or the disk was not present,
  leading to a "No such file or directory" error.

  There are test packages available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test

  If you install them, this is what should occur:

  $ ls -l
  total 0
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)

  No mounts happen, and no errors either.

  [Where problems could occur]

  We are changing the behaviour of core utilities, ls and stat, such
  that they no longer attempt to mount autofs shares when --ghost option
  is present or browse_mode is enabled.

  This is the intended behaviour in the first place, and has been this
  way for at least a decade prior, and was changed to return to this
  behaviour shortly after the release of coreutils that introduced
  statx() that caused automounts to occur.

  It is unlikely any system administrators are relying on the behaviour
  found in jammy in any scripts or day to day operations that would be
  adversely affected by the change. The worst case scenario is that a
  user doing an 'ls -l' on an unmounted disk finds the mount doesn't
  automatically occur, and they have to attach the disk and issue the
  mount themselves.

  If a regression were to occur, it would be limited to the ls and stat
  commands, specifically when listing directories linked to autofs
  mountpoints.

  [Other info]

  The automount behaviour change was introduced upstream in version
  8.32, with the introduction of the statx() call. This means only Jammy
  is affected.

  It was quickly reverted back to how it was originally in version 9.1,
  which is already available in Mantic and onward.

  The commits that solve the issue are:

  commit 85c975df2c25bd799370b04bb294e568e001102f
  From: Rohan Sable 
  Date: Mon, 7 Mar 2022 14:14:13 +
  Subject: ls: avoid triggering automounts
  Link: 
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2

  commit 

[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled

[Mauricio Faria de Oliveira]

Test Steps:

lxc launch --vm ubuntu:$SERIES autofs-$SERIES
lxc shell autofs-$SERIES

# replace linux-kvm with linux-generic for autofs
DEBIAN_FRONTEND=noninteractive apt remove --yes --purge 
'?and(?installed,?or(?source-package(linux-kvm),?source-package(linux-meta-kvm)))'
dpkg -s linux-image-virtual >/dev/null 2>/dev/null || (apt install 
--yes linux-image-virtual && reboot)

apt update && apt install -y autofs
sed '/^browse_mode =/ s/=.*/= yes/' -i /etc/autofs.conf

echo '/test /etc/auto.test' >/etc/auto.master.d/test.autofs

cat >/etc/auto.test 

[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled

[Mauricio Faria de Oliveira]

** Tags removed: sts-sponsor

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

Title:
  ls -l triggers mount of autofs shares when --ghost option is present
  or browse_mode is enabled

Status in coreutils package in Ubuntu:
  Fix Released
Status in coreutils source package in Jammy:
  In Progress
Status in coreutils package in Fedora:
  Fix Released

Bug description:
  [Impact]

  Issuing a 'ls -l' or a 'stat' on an autofs share when you have set
  --ghost in the auto.master file, or browse_mode=yes in autofs.conf
  will lead to the shares being mounted, when they didn't previously.

  Disks / shares may not be present and the mounts may fail, leading to
  errors in your output.

  This is a behaviour change in autofs 8.32, which occurred in the
  transition to using statx() instead of stat()/lstat() in previous
  releases.

  There doesn't seem to be any workarounds, apart from not running a 'ls
  -l' in your autofs share directory.

  [Testcase]

  Start two Jammy VMs. One will be a NFS server, the other, the client.

  NFS server:

  Server VM:
  $ sudo hostnamectl set-hostname jammy-nfs-server
  $ sudo apt update && sudo apt upgrade -y
  $ sudo apt install nfs-kernel-server
  $ sudo mkdir /export
  $ sudo mkdir /export/users
  $ sudo vi /etc/exports # add the following lines:
  /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync)
  /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync)
  $ sudo systemctl restart nfs-server.service

  AutoFS Client:
  $ sudo apt update
  $ sudo apt install autofs
  $ sudo vim /etc/autofs.conf
  browse_mode = yes
  $ sudo mkdir /mnt2
  $ sudo vim /etc/auto.master
  /mnt2 /etc/auto.indirect
  $ sudo vim /etc/auto.indirect
  export 192.168.122.18:/export
  export-missing 192.168.122.18:/export-missing
  $ sudo reboot
  $ cd /mnt2
  $ ls -l
  ls: cannot access 'export-missing': No such file or directory
  total 4
  drwxr-xr-x 3 root root 4096 Feb 12 21:48 export
  d? ? ??   ?? export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561)
  192.168.122.18:/export on /mnt2/export type nfs 
(rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18)

  We see the mount for export occurred, and export-missing was
  attempted, but it was either bogus or the disk was not present,
  leading to a "No such file or directory" error.

  There are test packages available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test

  If you install them, this is what should occur:

  $ ls -l
  total 0
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export
  drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing
  $ mount -l | grep /mnt2
  /etc/auto.indirect on /mnt2 type autofs 
(rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346)

  No mounts happen, and no errors either.

  [Where problems could occur]

  We are changing the behaviour of core utilities, ls and stat, such
  that they no longer attempt to mount autofs shares when --ghost option
  is present or browse_mode is enabled.

  This is the intended behaviour in the first place, and has been this
  way for at least a decade prior, and was changed to return to this
  behaviour shortly after the release of coreutils that introduced
  statx() that caused automounts to occur.

  It is unlikely any system administrators are relying on the behaviour
  found in jammy in any scripts or day to day operations that would be
  adversely affected by the change. The worst case scenario is that a
  user doing an 'ls -l' on an unmounted disk finds the mount doesn't
  automatically occur, and they have to attach the disk and issue the
  mount themselves.

  If a regression were to occur, it would be limited to the ls and stat
  commands, specifically when listing directories linked to autofs
  mountpoints.

  [Other info]

  The automount behaviour change was introduced upstream in version
  8.32, with the introduction of the statx() call. This means only Jammy
  is affected.

  It was quickly reverted back to how it was originally in version 9.1,
  which is already available in Mantic and onward.

  The commits that solve the issue are:

  commit 85c975df2c25bd799370b04bb294e568e001102f
  From: Rohan Sable 
  Date: Mon, 7 Mar 2022 14:14:13 +
  Subject: ls: avoid triggering automounts
  Link: 
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2

  commit 92cb8427c537f37edd43c5cef1909585201372ab 
  From: Pádraig Brady 
  Date: Mon, 7 Mar 2022 23:29:20 +
  Subject: stat: only automount with --cached=never
  Link: 

[Touch-packages] [Bug 2054925] Re: Debootstrap fails for Noble with base-files 13ubuntu7

[Mauricio Faria de Oliveira]

Hello Åka, or anyone else affected,

Accepted debootstrap into jammy-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/debootstrap/1.0.126+nmu1ubuntu0.7
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: debootstrap (Ubuntu Jammy)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-jammy

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

Title:
  Debootstrap fails for Noble with base-files 13ubuntu7

Status in base-files package in Ubuntu:
  Won't Fix
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Focal:
  In Progress
Status in debootstrap source package in Jammy:
  Fix Committed
Status in base-files source package in Mantic:
  New
Status in debootstrap source package in Mantic:
  Fix Released

Bug description:
  [Impact]
  The last couple of days, I have been unable to run a successful debootstrap 
for Noble Numbat.

  Apparently this is caused by the addition of symlinks (/bin, /lib,
  /lib64 and /sbin) in base-files 13ubuntu7. According to
  debootstrap.log, it fails to extract said symlinks because they
  already exist at that point.

  This can be reproduced on build hosts running Jammy Jellyfish against
  any up-to-date Ubuntu public archive mirror as of today.

  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 22.04.4 LTS
  Release:  22.04
  Codename: jammy

  # apt-cache policy debootstrap
  debootstrap:
    Installed: 1.0.126+nmu1ubuntu0.5
    Candidate: 1.0.126+nmu1ubuntu0.5
    Version table:
   *** 1.0.126+nmu1ubuntu0.5 500
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
  100 /var/lib/dpkg/status
   1.0.126+nmu1 500
  500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

  Attached shell output of two runs of debootstrap. First run uses
  mirror archive.ubuntu.com (which as of this report serves base-files
  version 13ubuntu7), and second run uses a local custom mirror (which
  serves base-files 13ubuntu6). First run fails, second run succeeds.

  [Test plan]
  Successfully for each of focal, jammy, mantic, noble
  - debootstrap
  - mksbuild
  - pbuilder whatever chroot management tool it has
  - ubuntu-image, if we can pull debootstrap from proposed for this

  as well as

  - debootstrap noble --merged-usr

  
  [Where problems could occur]
  We do not anticipate any regressions as we replace the previous *) case for 
usrmerge for post-hirsute with a new jammy|kinetic|lunar|mantic one, and the 
new solution will only impact noble and onward.

  That said, this is a different approach than mantic and newer take,
  and a different approach than Debian takes, where they moved to
  merging post-extraction, even in stable releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2054925/+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 2054925] Re: Debootstrap fails for Noble with base-files 13ubuntu7

[Mauricio Faria de Oliveira]

I confirmed that the resulting target dir of debootstrap in Jammy (with
patch/MERGED_USR=no) and Mantic is the same, with a comparison of `ls
-lR` (normalized for Month/Day/Time fields).

...

Test command for Jammy (patched) and Mantic:

# debootstrap --arch=amd64 --variant=minbase --keyring
/usr/share/keyrings/ubuntu-archive-keyring.gpg noble /tmp/nobletest
http://archive.ubuntu.com/ubuntu

Dir listing for Jammy (patched) and Mantic:

deboostrap-jammy # ls -lR /tmp/nobletest/ > list.jammy
deboostrap-mantic # ls -lR /tmp/nobletest/ > list.mantic

Normalization and comparison:

$ sed -i 's/[A-Z][a-z][a-z] .[0-9] [0-9][0-9]:[0-9][0-9]/DATETIME/'
list.jammy list.mantic

$ diff -U0 list.jammy list.mantic
--- list.jammy  2024-02-26 19:39:49.102864808 -0300
+++ list.mantic 2024-02-26 19:39:49.114864569 -0300
@@ -76 +76 @@
--rw-r--r-- 1 root root  18 DATETIME hostname
+-rw-r--r-- 1 root root  19 DATETIME hostname
@@ -7093 +7093 @@
--rw-r--r-- 1 root root 60238 DATETIME bootstrap.log
+-rw-r--r-- 1 root root 60045 DATETIME bootstrap.log

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

Title:
  Debootstrap fails for Noble with base-files 13ubuntu7

Status in base-files package in Ubuntu:
  Won't Fix
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Focal:
  In Progress
Status in debootstrap source package in Jammy:
  In Progress
Status in base-files source package in Mantic:
  New
Status in debootstrap source package in Mantic:
  Fix Released

Bug description:
  [Impact]
  The last couple of days, I have been unable to run a successful debootstrap 
for Noble Numbat.

  Apparently this is caused by the addition of symlinks (/bin, /lib,
  /lib64 and /sbin) in base-files 13ubuntu7. According to
  debootstrap.log, it fails to extract said symlinks because they
  already exist at that point.

  This can be reproduced on build hosts running Jammy Jellyfish against
  any up-to-date Ubuntu public archive mirror as of today.

  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 22.04.4 LTS
  Release:  22.04
  Codename: jammy

  # apt-cache policy debootstrap
  debootstrap:
    Installed: 1.0.126+nmu1ubuntu0.5
    Candidate: 1.0.126+nmu1ubuntu0.5
    Version table:
   *** 1.0.126+nmu1ubuntu0.5 500
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
  100 /var/lib/dpkg/status
   1.0.126+nmu1 500
  500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

  Attached shell output of two runs of debootstrap. First run uses
  mirror archive.ubuntu.com (which as of this report serves base-files
  version 13ubuntu7), and second run uses a local custom mirror (which
  serves base-files 13ubuntu6). First run fails, second run succeeds.

  [Test plan]
  Successfully for each of focal, jammy, mantic, noble
  - debootstrap
  - mksbuild
  - pbuilder whatever chroot management tool it has
  - ubuntu-image, if we can pull debootstrap from proposed for this

  as well as

  - debootstrap noble --merged-usr

  
  [Where problems could occur]
  We do not anticipate any regressions as we replace the previous *) case for 
usrmerge for post-hirsute with a new jammy|kinetic|lunar|mantic one, and the 
new solution will only impact noble and onward.

  That said, this is a different approach than mantic and newer take,
  and a different approach than Debian takes, where they moved to
  merging post-extraction, even in stable releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2054925/+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 2054925] Re: Debootstrap fails for Noble with base-files 13ubuntu7

[Mauricio Faria de Oliveira]

TL;DR: The fix is not needed on Mantic.

This is just to expand a bit on the brief note in '[Where problems could
occur]' ("moved to merging post-extraction"), for clarity.

The code in `scripts/gutsy` (used for noble) is different between Mantic
and Jammy with regards to the order of package extraction and usr-merge
setup, in first_stage_install().

The issue happens in Jammy because usr-merge setup runs _before_
extraction (thus extraction of base-files fails as the
/{bin,lib,lib64,sbin} symlinks already exist):

setup_merged_usr
extract $required

But it doesn't happen in Mantic because usr-merge setup runs _after_
extraction (thus extraction of base-files works as the symlinks don't
yet exist):

extract $required
merge_usr

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

Title:
  Debootstrap fails for Noble with base-files 13ubuntu7

Status in base-files package in Ubuntu:
  Won't Fix
Status in debootstrap package in Ubuntu:
  Fix Released
Status in debootstrap source package in Focal:
  In Progress
Status in debootstrap source package in Jammy:
  In Progress

Bug description:
  [Impact]
  The last couple of days, I have been unable to run a successful debootstrap 
for Noble Numbat.

  Apparently this is caused by the addition of symlinks (/bin, /lib,
  /lib64 and /sbin) in base-files 13ubuntu7. According to
  debootstrap.log, it fails to extract said symlinks because they
  already exist at that point.

  This can be reproduced on build hosts running Jammy Jellyfish against
  any up-to-date Ubuntu public archive mirror as of today.

  # lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 22.04.4 LTS
  Release:  22.04
  Codename: jammy

  # apt-cache policy debootstrap
  debootstrap:
    Installed: 1.0.126+nmu1ubuntu0.5
    Candidate: 1.0.126+nmu1ubuntu0.5
    Version table:
   *** 1.0.126+nmu1ubuntu0.5 500
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
  100 /var/lib/dpkg/status
   1.0.126+nmu1 500
  500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

  Attached shell output of two runs of debootstrap. First run uses
  mirror archive.ubuntu.com (which as of this report serves base-files
  version 13ubuntu7), and second run uses a local custom mirror (which
  serves base-files 13ubuntu6). First run fails, second run succeeds.

  [Test plan]
  Successfully for each of focal, jammy, mantic, noble
  - debootstrap
  - mksbuild
  - pbuilder whatever chroot management tool it has
  - ubuntu-image, if we can pull debootstrap from proposed for this

  as well as

  - debootstrap noble --merged-usr

  
  [Where problems could occur]
  We do not anticipate any regressions as we replace the previous *) case for 
usrmerge for post-hirsute with a new jammy|kinetic|lunar|mantic one, and the 
new solution will only impact noble and onward.

  That said, this is a different approach than mantic and newer take,
  and a different approach than Debian takes, where they moved to
  merging post-extraction, even in stable releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2054925/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

PS: the Jammy verification done in comment 31 used version
2.37.2-4ubuntu3.1 (staged in this bug), and that in comment 39 used
(newer) version 2.37.2-4ubuntu3.2 (also staged, in bug 2048092) -- both
have positive results.

BTW, since the newer upload is still planned for staging, not removing
the block-proposed-jammy tag, IIUIC.

"""
In principle the block-proposed- tag should be removed by an SRU team 
member when accepting a newer upload not planned for further staging. 
But if they overlook this, it's appropriate for whoever notices it (SRU team, 
or uploader) to remove the block-proposed- tag with a suitable comment 
when it no longer applies.
"""
@ https://wiki.ubuntu.com/StableReleaseUpdates#Staging_an_upload

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Jammy:
  Fix Committed
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  Won't Fix
Status in util-linux source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

Jammy verification done in comments 31 (with tag flip) and 39.
Lunar is now Won't Fix (2024-01-17), thus removing lunar tags.

** Tags removed: block-proposed-lunar verification-done-lunar

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Jammy:
  Fix Committed
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  Won't Fix
Status in util-linux source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2046356] Re: Update URL for Support information in MOTD message

[Mauricio Faria de Oliveira]

Notes:
- Added bug task for Lunar (lunar MR is linked/approved; lunar-unapproved has 
an upload).
- Checked that Bionic and Xenial have no conflicting packages/versions in the 
ESM archive.

** Also affects: base-files (Ubuntu Lunar)
   Importance: Undecided
   Status: New

** Changed in: base-files (Ubuntu Lunar)
   Status: New => In Progress

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

Title:
  Update URL for Support information in MOTD message

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  In Progress
Status in base-files source package in Jammy:
  In Progress
Status in base-files source package in Lunar:
  In Progress
Status in base-files source package in Mantic:
  In Progress
Status in base-files source package in Noble:
  Fix Released

Bug description:
  
  [Impact]
  When users see the MOTD message, they are currently seeing an outdated url 
under the support information.
  Even though the outdated url redirects to new Ubuntu Pro webpage, we believe 
the users should still see
  the correct url from the start

  [Test Case]

  - Launch a LXD container for any of the affected releases
  - Install the package with this fix applied
  - Install `update-motd` package
  - Run `update-motd` and confirm the Support url is now the correct one

  [Regression Potential]
  If users are parsing MOTD for some reason, the url change might break that 
logic now. However, parsing MOTD messages is not a supported flow, so we 
believe regression potential is low here.

  [Discussion]
  Since we want users to be aware of what Ubuntu Pro is, we should highlight 
the right product name on any place that is still using the old "advantage" 
name. Updating the support URL here is a step into this direction

  [Original Bug Description]
  On the file 10-help-text, we are printing the following line on MOTD:

  * Support: https://ubuntu.com/advantage

  We should update the url to https://ubuntu.com/pro instead, as this
  will the default url for support information now

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2046356/+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 2039328] Re: Update ubuntu-meta with promotions done between last ubuntu-meta build & release

[Mauricio Faria de Oliveira]

Verification done on mantic-proposed.

On arm64 with ubuntu-desktop-minimal installed,
running do-release-upgrade from lunar to mantic 
(with mantic-proposed enabled and pinning setup)
does install `protection-domain-mapper` and
`qrtr-tools` (`flash-kernel` already installed).


Test Steps:
---

Part 1)
- launch aws arm64 instance with Ubuntu 22.04/jammy

Part 2)
- do-release-upgrade to 22.10/lunar
- install ubuntu-desktop-minimal
- enable lunar-proposed (converted to mantic-proposed in do-release-upgrade 
later)

Part 3)
- set pin priority for mantic-proposed/ubuntu-desktop-minimal
- do-release-upgrade to 23.04/mantic

Details:
---

Start on Jammy:

$ lsb_release -cs
jammy

$ dpkg --print-architecture
arm64

$ uname -m
aarch64

$ sudo apt update && sudo apt -y dist-upgrade && sudo reboot

Upgrade to Lunar:

$ sudo sed -i 's/^Prompt=.*/Prompt=normal/' -i 
/etc/update-manager/release-upgrades
$ do-release-upgrade
Checking for a new Ubuntu release

= Welcome to Ubuntu 23.04 'Lunar Lobster' =
...

$ lsb_release -cs
No LSB modules are available.
lunar

Prepare for testing:

$ sudo apt install -y ubuntu-desktop-minimal

Test/Before: (only 1 out of 3 packages installed)

$ dpkg -s flash-kernel protection-domain-mapper qrtr-tools | grep -e 
Package: -e Version:
dpkg-query: package 'protection-domain-mapper' is not installed and no 
information is available
dpkg-query: package 'qrtr-tools' is not installed and no information is 
available
Use dpkg --info (= dpkg-deb --info) to examine archive files.
Package: flash-kernel
Version: 3.106ubuntu14

Enable -proposed:

$ sudo add-apt-repository -yp proposed

cat 

[Touch-packages] [Bug 2034986] Re: some text became unreadable during a distribution upgrade

[Mauricio Faria de Oliveira]

Verification (synthetic) of the XDG_SESSION_TYPE fix in Mantic:

$ lsb_release -cs
No LSB modules are available.
mantic

The packages are downloaded from Launchpad librarian
since previous versions are not available in archive.

Before the fix (reverted) // 1:23.10.12
---

The XDG_CURRENT_DESKTOP variable IS NOT passed in `pkexec ... --env=`.

$ wget https://launchpad.net/ubuntu/+source/ubuntu-release-
upgrader/1:23.10.12/+build/26929436/+files/{ubuntu-release-
upgrader-{core,gtk},python3-distupgrade}_23.10.12_all.deb

$ sudo apt install -y ./ubuntu-release-upgrader-
core_23.10.12_all.deb ./ubuntu-release-upgrader-gtk_23.10.12_all.deb
./python3-distupgrade_23.10.12_all.deb

$ dpkg -s ubuntu-release-upgrader-core | grep Version:
Version: 1:23.10.12

$ export XDG_CURRENT_DESKTOP=just:testing

$ strace -s 128 do-release-upgrade -d -f DistUpgradeViewGtk3 2>&1 | 
grep '^execve("/usr/bin/pkexec"' | grep -o -- '--env=[^"]\+'

--env=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus,XDG_SESSION_TYPE=tty

After the fix (reapplied) // 1:23.10.13
---

The XDG_CURRENT_DESKTOP variable IS passed in `pkexec ... --env=`.

$ wget https://launchpad.net/ubuntu/+source/ubuntu-release-
upgrader/1:23.10.13/+build/26932072/+files/{ubuntu-release-
upgrader-{core,gtk},python3-distupgrade}_23.10.13_all.deb

$ sudo apt install -y ./ubuntu-release-upgrader-
core_23.10.13_all.deb ./ubuntu-release-upgrader-gtk_23.10.13_all.deb
./python3-distupgrade_23.10.13_all.deb

$ dpkg -s ubuntu-release-upgrader-core | grep Version:
Version: 1:23.10.13

$ export XDG_CURRENT_DESKTOP=just:testing

$ strace -s 128 do-release-upgrade -d -f DistUpgradeViewGtk3 2>&1 | 
grep '^execve("/usr/bin/pkexec"' | grep -o -- '--env=[^"]\+'

--env=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus,XDG_SESSION_TYPE=tty,XDG_CURRENT_DESKTOP=just:testing

Latest version (mantic-proposed) // 1:23.10.14
---

The XDG_CURRENT_DESKTOP variable IS passed in `pkexec ... --env=`.

$ sudo add-apt-repository -yp proposed

$ sudo apt install -y -t mantic-proposed ubuntu-release-
upgrader-core

$ dpkg -s ubuntu-release-upgrader-core | grep Version:
Version: 1:23.10.14

$ strace -s 128 do-release-upgrade -d -f DistUpgradeViewGtk3 2>&1 | 
grep '^execve("/usr/bin/pkexec"' | grep -o -- '--env=[^"]\+'

--env=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus,XDG_SESSION_TYPE=tty,XDG_CURRENT_DESKTOP=just:testing

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

Title:
  some text became unreadable during a distribution upgrade

Status in Cinnamon:
  New
Status in Ubuntu MATE:
  New
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader source package in Jammy:
  Fix Committed
Status in ubuntu-release-upgrader source package in Lunar:
  Fix Released
Status in ubuntu-meta source package in Mantic:
  Fix Released
Status in ubuntu-release-upgrader source package in Mantic:
  Fix Committed

Bug description:
  [ Impact ]

   * On Ubuntu Mate with the Lunar series, when running
     ubuntu-release-upgrader, the displayed font of running
     applications (including the upgrader) becomes very corrupted.

   * This is not just a display problem, it is also a functional one.
     The release upgrader will have text corrupted to the point
     where a dialog asks a decision, and displays two buttons, but the
     text is unreadable and one has to guess which button is the one
     that carries out their desired action.

   * In the early parts of the upgrader tool, users are told in bold:
     "To prevent data loss close all open applications and documents."
     This is just before the "Start Upgrade" button is available.
     But they may not do so.  Many applications may have a corrupted
     font.

   * To address this, an additional environment variable is being
     passed along to pkexec, XDG_CURRENT_DESKTOP, as this is the
     critical criteria for making the Mate version of the fix work.

   * Also in the change are
     * an update to tests
 * from pre-build.sh
       * an update of the mirrors.cfg, adding and removing several
 mirrors
       * a refresh of the po files

  [ Test Plan ]

   * acquire an Ubuntu Mate environment running Ubuntu Lunar on amd64

   * as user, run "update-manager -d"

   * monitor the "Distribution Upgrade" screen.  During the "Installing
     the upgrades" step (and mind that this step will be long), observe
     the text of the "Distribution Upgrade" screen and verify that the
     font does not corrupt.

   * Repeat the above for Ubuntu Desktop

  [ Where problems could occur ]

   * We are changing, at release time, 

[Touch-packages] [Bug 2034986] Re: some text became unreadable during a distribution upgrade

[Mauricio Faria de Oliveira]

Summary for Mantic SRUs.

There are 3 LP bugs combined in mantic-proposed
(list sorted by package version so it's helpful).

1) Bug 2034986, used twice,

1A) First for 1:23.10.9, for 'fix v1':
* Temporary font for Ubuntu MATE (LP: #2034986)

It's released to mantic-updates with 1:23.10.10 (fix for
autopkgtests).

1B) Later for 1:23.10.11, for XDG_CURRENT_DESKTOP:
* do-release-upgrade: pass XDG_CURRENT_DESKTOP env var (LP: #2034986) 

It's reverted in 1:23.10.12:
* Temporarily revert "do-release-upgrade: pass XDG_CURRENT_DESKTOP env var"

and reapplied in 1:23.10.13:
* do-release-upgrade: pass XDG_CURRENT_DESKTOP env var (LP: #2034986)

2) Bug 2039356, used for 'fix v2' in 1:23:10.12:
* Adjustments of unreadable text workaround (LP: #2039356)

3) Bug 2039172, used for an unrelated quirk:
* DistUpgradeQuirks: prevent upgrades on BIOS systems with XFS /boot (LP: 
#2039172)

...

So, for verification, we have to consider 1:23.10.11 up to .14.

.11 doesn't need verification, as it's reverted in .12
.12 is verified (comment #65 / bug 2039356 comment #3)
.13 is not yet verified (comment #65, #66)
.14 is verified, but pending questions (bug 2039172 comment #9)

Thus, it seems what is pending for releasing mantic-proposed
is verification for .13 (that I'm happy to do synthetically),
plus a question for .14 (I'd be be happy to help, if needed).

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

Title:
  some text became unreadable during a distribution upgrade

Status in Cinnamon:
  New
Status in Ubuntu MATE:
  New
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader source package in Jammy:
  Fix Committed
Status in ubuntu-release-upgrader source package in Lunar:
  Fix Released
Status in ubuntu-meta source package in Mantic:
  Fix Released
Status in ubuntu-release-upgrader source package in Mantic:
  Fix Committed

Bug description:
  [ Impact ]

   * On Ubuntu Mate with the Lunar series, when running
     ubuntu-release-upgrader, the displayed font of running
     applications (including the upgrader) becomes very corrupted.

   * This is not just a display problem, it is also a functional one.
     The release upgrader will have text corrupted to the point
     where a dialog asks a decision, and displays two buttons, but the
     text is unreadable and one has to guess which button is the one
     that carries out their desired action.

   * In the early parts of the upgrader tool, users are told in bold:
     "To prevent data loss close all open applications and documents."
     This is just before the "Start Upgrade" button is available.
     But they may not do so.  Many applications may have a corrupted
     font.

   * To address this, an additional environment variable is being
     passed along to pkexec, XDG_CURRENT_DESKTOP, as this is the
     critical criteria for making the Mate version of the fix work.

   * Also in the change are
     * an update to tests
 * from pre-build.sh
       * an update of the mirrors.cfg, adding and removing several
 mirrors
       * a refresh of the po files

  [ Test Plan ]

   * acquire an Ubuntu Mate environment running Ubuntu Lunar on amd64

   * as user, run "update-manager -d"

   * monitor the "Distribution Upgrade" screen.  During the "Installing
     the upgrades" step (and mind that this step will be long), observe
     the text of the "Distribution Upgrade" screen and verify that the
     font does not corrupt.

   * Repeat the above for Ubuntu Desktop

  [ Where problems could occur ]

   * We are changing, at release time, ubuntu-release upgrader.  If we
     are careless, we could regress upgrades for a wider group of users
     than just Ubuntu Mate.  That said, it is believed that passing the
     additional XDG_CURRENT_DESKTOP variable is relatively low risk.

  [ Other Info ]

   * TBD

  ---

  Original description:

  I was upgrading from Lunar to Mantic the other day and left a couple
  of applications open during the upgrade process. During the upgrade
  the text in audacious became unreadable (I'll attach a screenshot) and
  I seem to recall the title bar of Firefox being unreadable but the
  contents of web pages still being readable.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: ubuntu-release-upgrader-core 1:23.10.5
  ProcVersionSignature: Ubuntu 6.5.0-4.4-generic 6.5.0
  Uname: Linux 6.5.0-4-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia zfs
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CrashDB: ubuntu
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep  8 15:39:27 2023
  InstallationDate: Installed on 2018-08-10 (1855 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic 

[Touch-packages] [Bug 2039328] Re: Update ubuntu-meta with promotions done between last ubuntu-meta build & release

[Mauricio Faria de Oliveira]

** Changed in: ubuntu-meta (Ubuntu Noble)
   Status: Confirmed => Fix Committed

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

Title:
  Update ubuntu-meta with promotions done between last ubuntu-meta build
  & release

Status in ubuntu-meta package in Ubuntu:
  Fix Committed
Status in ubuntu-meta source package in Mantic:
  Confirmed
Status in ubuntu-meta source package in Noble:
  Fix Committed

Bug description:
  [ Impact ]

   * ubuntu-seeds were changed since last meta update
   * to ensure correct upgrades; regenerate ubuntu-meta with contents / changes 
done before release

  [ Test Plan ]

   * Check that arm64 upgrades of ubuntu-desktop-minimal from lunar to
  mantic install newly recommended packages.

  [ Where problems could occur ]

   * This is automatically generated change based on ubuntu-seeds commit
  [1].

   * Theoretically, regressions would occur if new desktop-minimal-recommends
     dependencies on arm64 (flash-kernel, protection-domain-mapper, qrtr-tools):
     - have issues on install during release-upgrade;
     - have issues on regular system usage (after installed).

  [ Other Info ]

   * ubuntu-meta was not uploaded during final freeze, to prevent
  rebuilding all images as changes affect arm64 only, which is a brand
  new release image

   * protection-domain-mapper [2] and qrtr [3] moved from universe to main in 
Mantic.
   * flash-kernel is/was already in main.

  [1] 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=afe820cd49514896e96d02303298ed873d8d7f8a
  [2] 
https://launchpad.net/ubuntu/+source/protection-domain-mapper/1.0-4ubuntu2/+publishinghistory
  [3] https://launchpad.net/ubuntu/+source/qrtr/1.0-2ubuntu1/+publishinghistory

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2039328/+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 2039328] Re: Update ubuntu-meta with promotions done between last ubuntu-meta build & release

[Mauricio Faria de Oliveira]

** Description changed:

  [ Impact ]
  
   * ubuntu-seeds were changed since last meta update
   * to ensure correct upgrades; regenerate ubuntu-meta with contents / changes 
done before release
  
  [ Test Plan ]
  
   * Check that arm64 upgrades of ubuntu-desktop-minimal from lunar to
  mantic install newly recommended packages.
  
  [ Where problems could occur ]
  
   * This is automatically generated change based on ubuntu-seeds commit
  [1].
  
   * Theoretically, regressions would occur if new desktop-minimal-recommends
     dependencies on arm64 (flash-kernel, protection-domain-mapper, qrtr-tools):
     - have issues on install during release-upgrade;
     - have issues on regular system usage (after installed).
  
  [ Other Info ]
  
   * ubuntu-meta was not uploaded during final freeze, to prevent
  rebuilding all images as changes affect arm64 only, which is a brand new
  release image
  
-  * protection-domain-mapper [2] and qrtr moved from universe to main in 
Mantic.
+  * protection-domain-mapper [2] and qrtr [3] moved from universe to main in 
Mantic.
   * flash-kernel is/was already in main.
  
  [1] 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=afe820cd49514896e96d02303298ed873d8d7f8a
  [2] 
https://launchpad.net/ubuntu/+source/protection-domain-mapper/1.0-4ubuntu2/+publishinghistory
  [3] https://launchpad.net/ubuntu/+source/qrtr/1.0-2ubuntu1/+publishinghistory

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

Title:
  Update ubuntu-meta with promotions done between last ubuntu-meta build
  & release

Status in ubuntu-meta package in Ubuntu:
  Confirmed
Status in ubuntu-meta source package in Mantic:
  Confirmed
Status in ubuntu-meta source package in Noble:
  Confirmed

Bug description:
  [ Impact ]

   * ubuntu-seeds were changed since last meta update
   * to ensure correct upgrades; regenerate ubuntu-meta with contents / changes 
done before release

  [ Test Plan ]

   * Check that arm64 upgrades of ubuntu-desktop-minimal from lunar to
  mantic install newly recommended packages.

  [ Where problems could occur ]

   * This is automatically generated change based on ubuntu-seeds commit
  [1].

   * Theoretically, regressions would occur if new desktop-minimal-recommends
     dependencies on arm64 (flash-kernel, protection-domain-mapper, qrtr-tools):
     - have issues on install during release-upgrade;
     - have issues on regular system usage (after installed).

  [ Other Info ]

   * ubuntu-meta was not uploaded during final freeze, to prevent
  rebuilding all images as changes affect arm64 only, which is a brand
  new release image

   * protection-domain-mapper [2] and qrtr [3] moved from universe to main in 
Mantic.
   * flash-kernel is/was already in main.

  [1] 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=afe820cd49514896e96d02303298ed873d8d7f8a
  [2] 
https://launchpad.net/ubuntu/+source/protection-domain-mapper/1.0-4ubuntu2/+publishinghistory
  [3] https://launchpad.net/ubuntu/+source/qrtr/1.0-2ubuntu1/+publishinghistory

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2039328/+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 2039328] Re: Update ubuntu-meta with promotions done between last ubuntu-meta build & release

[Mauricio Faria de Oliveira]

Updated regression potential with theoretical issues, and other info
with status in main for protection-domain-mapper and qrtr.

** Description changed:

  [ Impact ]
  
-  * ubuntu-seeds were changed since last meta update
-  * to ensure correct upgrades; regenerate ubuntu-meta with contents / changes 
done before release
+  * ubuntu-seeds were changed since last meta update
+  * to ensure correct upgrades; regenerate ubuntu-meta with contents / changes 
done before release
  
  [ Test Plan ]
  
-  * Check that arm64 upgrades of ubuntu-desktop-minimal from lunar to
+  * Check that arm64 upgrades of ubuntu-desktop-minimal from lunar to
  mantic install newly recommended packages.
  
  [ Where problems could occur ]
  
-  * This is automatically generated change
+  * This is automatically generated change based on ubuntu-seeds commit
+ [1].
+ 
+  * Theoretically, regressions would occur if new desktop-minimal-recommends
+dependencies on arm64 (flash-kernel, protection-domain-mapper, qrtr-tools):
+- have issues on install during release-upgrade;
+- have issues on regular system usage (after installed).
  
  [ Other Info ]
-  
-  * ubuntu-meta was not uploaded during final freeze, to prevent rebuilding 
all images as changes affect arm64 only, which is a brand new release image
+ 
+  * ubuntu-meta was not uploaded during final freeze, to prevent
+ rebuilding all images as changes affect arm64 only, which is a brand new
+ release image
+ 
+ [1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu-
+ seeds/+git/ubuntu/commit/?id=afe820cd49514896e96d02303298ed873d8d7f8a

** Description changed:

  [ Impact ]
  
   * ubuntu-seeds were changed since last meta update
   * to ensure correct upgrades; regenerate ubuntu-meta with contents / changes 
done before release
  
  [ Test Plan ]
  
   * Check that arm64 upgrades of ubuntu-desktop-minimal from lunar to
  mantic install newly recommended packages.
  
  [ Where problems could occur ]
  
   * This is automatically generated change based on ubuntu-seeds commit
  [1].
  
-  * Theoretically, regressions would occur if new desktop-minimal-recommends
-dependencies on arm64 (flash-kernel, protection-domain-mapper, qrtr-tools):
-- have issues on install during release-upgrade;
-- have issues on regular system usage (after installed).
+  * Theoretically, regressions would occur if new desktop-minimal-recommends
+    dependencies on arm64 (flash-kernel, protection-domain-mapper, qrtr-tools):
+    - have issues on install during release-upgrade;
+    - have issues on regular system usage (after installed).
  
  [ Other Info ]
  
   * ubuntu-meta was not uploaded during final freeze, to prevent
  rebuilding all images as changes affect arm64 only, which is a brand new
  release image
  
+  * protection-domain-mapper and qrtr moved from universe to main in Mantic.
+  * flash-kernel is/was already in main.
+ 
  [1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu-
  seeds/+git/ubuntu/commit/?id=afe820cd49514896e96d02303298ed873d8d7f8a

** Description changed:

  [ Impact ]
  
   * ubuntu-seeds were changed since last meta update
   * to ensure correct upgrades; regenerate ubuntu-meta with contents / changes 
done before release
  
  [ Test Plan ]
  
   * Check that arm64 upgrades of ubuntu-desktop-minimal from lunar to
  mantic install newly recommended packages.
  
  [ Where problems could occur ]
  
   * This is automatically generated change based on ubuntu-seeds commit
  [1].
  
   * Theoretically, regressions would occur if new desktop-minimal-recommends
     dependencies on arm64 (flash-kernel, protection-domain-mapper, qrtr-tools):
     - have issues on install during release-upgrade;
     - have issues on regular system usage (after installed).
  
  [ Other Info ]
  
   * ubuntu-meta was not uploaded during final freeze, to prevent
  rebuilding all images as changes affect arm64 only, which is a brand new
  release image
  
-  * protection-domain-mapper and qrtr moved from universe to main in Mantic.
-  * flash-kernel is/was already in main.
+  * protection-domain-mapper [2] and qrtr moved from universe to main in 
Mantic.
+  * flash-kernel is/was already in main.
  
- [1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu-
- seeds/+git/ubuntu/commit/?id=afe820cd49514896e96d02303298ed873d8d7f8a
+ [1] 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=afe820cd49514896e96d02303298ed873d8d7f8a
+ [2] 
https://launchpad.net/ubuntu/+source/protection-domain-mapper/1.0-4ubuntu2/+publishinghistory
+ [3] https://launchpad.net/ubuntu/+source/qrtr/1.0-2ubuntu1/+publishinghistory

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

Title:
  Update ubuntu-meta with promotions done between last ubuntu-meta build
  & release

Status in ubuntu-meta package in Ubuntu:
  Confirmed
Status in ubuntu-meta 

[Touch-packages] [Bug 2039328] Re: Update ubuntu-meta with promotions done between last ubuntu-meta build & release

[Mauricio Faria de Oliveira]

The changes are not yet in the development release (Noble).

Submitted MR [1] with noble series update + these changes.

[1] https://code.launchpad.net/~mfo/ubuntu/+source/ubuntu-
meta/+git/ubuntu-meta/+merge/455081

** Merge proposal linked:
   
https://code.launchpad.net/~mfo/ubuntu/+source/ubuntu-meta/+git/ubuntu-meta/+merge/455081

** Also affects: ubuntu-meta (Ubuntu Noble)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-meta (Ubuntu Mantic)
   Importance: Undecided
   Status: New

** Changed in: ubuntu-meta (Ubuntu Mantic)
   Status: New => Confirmed

** Changed in: ubuntu-meta (Ubuntu Mantic)
   Importance: Undecided => Medium

** Changed in: ubuntu-meta (Ubuntu Noble)
   Status: New => Confirmed

** Changed in: ubuntu-meta (Ubuntu Noble)
   Importance: Undecided => Medium

** Changed in: ubuntu-meta (Ubuntu Noble)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

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

Title:
  Update ubuntu-meta with promotions done between last ubuntu-meta build
  & release

Status in ubuntu-meta package in Ubuntu:
  Confirmed
Status in ubuntu-meta source package in Mantic:
  Confirmed
Status in ubuntu-meta source package in Noble:
  Confirmed

Bug description:
  [ Impact ]

   * ubuntu-seeds were changed since last meta update
   * to ensure correct upgrades; regenerate ubuntu-meta with contents / changes 
done before release

  [ Test Plan ]

   * Check that arm64 upgrades of ubuntu-desktop-minimal from lunar to
  mantic install newly recommended packages.

  [ Where problems could occur ]

   * This is automatically generated change

  [ Other Info ]
   
   * ubuntu-meta was not uploaded during final freeze, to prevent rebuilding 
all images as changes affect arm64 only, which is a brand new release image

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2039328/+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 2038453] Re: [SRU] apt snapshot integration backport

[Mauricio Faria de Oliveira]

** Changed in: ubuntu-pro/18.04
   Status: New => Triaged

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

Title:
  [SRU] apt snapshot integration backport

Status in Ubuntu Pro:
  Triaged
Status in Ubuntu Pro 18.04 series:
  Triaged
Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Won't Fix
Status in apt source package in Focal:
  Confirmed
Status in apt source package in Jammy:
  Confirmed
Status in apt source package in Lunar:
  Won't Fix
Status in apt source package in Mantic:
  Fix Released

Bug description:
  [Impact]
  The snapshot service provides users access to older states of the archive 
with ease of use, and enables a consistent user experience across all supported 
releases, as otherwise users would have to rewrite their sources.list to make 
use of snapshots and set up pinning; hence partners requested the feature be 
SRUed to older releases as well.

  [Test plan]
  The complete regression test suite in autopkgtests includes an automatic test 
case for this and the known limitations that have been fixed. Aside from that, 
it is also worthwhile to do an end-to-end test:

  Configure snapshot=yes for Ubuntu sources in your sources.list and

  1. run apt update - it should not use snapshot
  2. run apt update --snapshot 20231001T00Z, it should download the snapshot
  3. run apt install --snapshot 20231001T00Z hello, it should install hello 
from the snapshot

  [Where problems could occur]
  The integration has been purposefully limited in how it works to reduce the 
impact it has on the APT code; hence it was possible to cherry-pick this into 
22.04, 20.04, and even 18.04, with only a minor editorial change. This 
significantly limits the risk.

  This feature is only enabled for sources with snapshot=yes (.list) or
  Snapshot: yes (.sources) or other truthy values apt recognizes. Most
  users will not have such entries as they did not have an APT
  supporting it.

  This combined should ensure that users do not experience any
  regressions. However the feature may be lacking in some ways that we
  may want to address in follow up SRUs; it has not been used in the
  wild a lot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-pro/+bug/2038453/+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 2038453] Re: [SRU] apt snapshot integration backport

[Mauricio Faria de Oliveira]

** Also affects: apt (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Also affects: ubuntu-pro
   Importance: Undecided
   Status: New

** Also affects: ubuntu-pro/18.04
   Importance: Undecided
   Status: New

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

Title:
  [SRU] apt snapshot integration backport

Status in Ubuntu Pro:
  New
Status in Ubuntu Pro 18.04 series:
  New
Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  Won't Fix
Status in apt source package in Focal:
  New
Status in apt source package in Jammy:
  New
Status in apt source package in Lunar:
  Won't Fix
Status in apt source package in Mantic:
  Fix Released

Bug description:
  [Impact]
  The snapshot service provides users access to older states of the archive 
with ease of use, and enables a consistent user experience across all supported 
releases, as otherwise users would have to rewrite their sources.list to make 
use of snapshots and set up pinning; hence partners requested the feature be 
SRUed to older releases as well.

  [Test plan]
  The complete regression test suite in autopkgtests includes an automatic test 
case for this and the known limitations that have been fixed. Aside from that, 
it is also worthwhile to do an end-to-end test:

  Configure snapshot=yes for Ubuntu sources in your sources.list and

  1. run apt update - it should not use snapshot
  2. run apt update --snapshot 20231001T00Z, it should download the snapshot
  3. run apt install --snapshot 20231001T00Z hello, it should install hello 
from the snapshot

  [Where problems could occur]
  The integration has been purposefully limited in how it works to reduce the 
impact it has on the APT code; hence it was possible to cherry-pick this into 
22.04, 20.04, and even 18.04, with only a minor editorial change. This 
significantly limits the risk.

  This feature is only enabled for sources with snapshot=yes (.list) or
  Snapshot: yes (.sources) or other truthy values apt recognizes. Most
  users will not have such entries as they did not have an APT
  supporting it.

  This combined should ensure that users do not experience any
  regressions. However the feature may be lacking in some ways that we
  may want to address in follow up SRUs; it has not been used in the
  wild a lot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-pro/+bug/2038453/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

All autopkgtests have now passed (lunar/jammy).

https://ubuntu-archive-team.ubuntu.com/proposed-migration/lunar/update_excuses.html#util-linux
https://ubuntu-archive-team.ubuntu.com/proposed-migration/jammy/update_excuses.html#util-linux

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Jammy:
  Fix Committed
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  Fix Committed
Status in util-linux source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

The autopkgtests failures in lunar seem to be a kernel issue during the
initialization of the virtio rng driver, when the mutex for
(generic/core) hw rng is acquired (apparently something else is holding
it indefinitely, thus the blocked task warnings show up, and it seems
the VM doesn't proceed to the point of being detected, and the test
fails/times out).

I haven't seen related commits listed in the later linux package
changelogs for lunar (this is with 6.2.0-25-generic), nor could
reproduce this in a LXD VM with the same version (it uses a virtio rng
device too).

Let's try again when another openstack image for lunar is available
(current/failing is 2023-07-17).

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Jammy:
  Fix Committed
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  Fix Committed
Status in util-linux source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

The autopkgtests failures in jammy seem to be of various sorts, but are
not expected to be related to this code change at all. I've skimmed
through them, and some seemed worth of retries (timeouts, network
issues, etc).

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Jammy:
  Fix Committed
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  Fix Committed
Status in util-linux source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2016145] Re: Wrong ownership for /var/lib/libuuid/

[Mauricio Faria de Oliveira]

Thanks for reporting this bug!

Could not reproduce with Kinetic (22.10) or Lunar (23.04).

Kinetic will EOL soon. Can you reproduce this with Lunar?

Thanks!


$ lsb_release -cs
No LSB modules are available.
lunar

$ uuidgen -t
039c7806-20ae-11ee-ba46-54e1ad759c00

...

$ lsb_release -cs
kinetic

$ uuidgen -t
1a838b2c-20ae-11ee-8bfa-335c39eef75c

$ dpkg -s uuid-runtime | grep Version:
Version: 2.38-4ubuntu1

$ ls -ld /var/lib/libuuid
drwxr-xr-x 2 root root 4096 May  3  2022 /var/lib/libuuid


** Changed in: util-linux (Ubuntu)
   Status: New => Invalid

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

Title:
  Wrong ownership for /var/lib/libuuid/

Status in util-linux package in Ubuntu:
  Invalid

Bug description:
  Ubuntu 22.10, uuid-runtime version 2.38-4ubuntu1

  I noticed that if I ran "uuidgen -t" then I would get a line like this
  in my system logs: "uuidd: failed to open/lock clock counter"

  Using strace I saw that the reason was a lack of permission to write
  to "/var/lib/libuuid/clock.txt".  The directory "/var/lib/libuuid/" is
  owned by root, however "uuidd" is run as a systemd service
  (uuidd.service) as user "uuidd".  This fixed it: "sudo chown
  uuidd:uuidd /var/lib/libuuid/".

  So I think the uuid-runtime package should ensure that
  "/var/lib/libuuid" is owned by "uuid".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2016145/+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 1981769] Re: blkid fails to find btrfs zoned filesystem label or uuid

[Mauricio Faria de Oliveira]

The problem does not seem to be in util-linux, as it works correctly
with a loop device.

Can you confirm whether you have /dev/disk/by-label/ symlinks for the
new filesystem?

$ lsb_release -cs
jammy

$ truncate -s 15T disk.img
$ DEV=$(sudo losetup --find --show disk.img)

$ sudo mkfs.btrfs -O zoned -d single -m single -f $DEV -L cf1657839355
btrfs-progs v5.16.2
See http://btrfs.wiki.kernel.org for more information.

NOTE: several default settings have changed in version 5.15, please make sure
  this does not affect your deployments:
  - DUP for metadata (-m dup)
  - enabled no-holes (-O no-holes)
  - enabled free-space-tree (-R free-space-tree)

Label:  cf1657839355
UUID:   381ff1f0-714a-411e-95c5-0fbd67979da5
Node size:  16384
Sector size:4096
Filesystem size:15.00TiB
Block group profiles:
  Data: single  256.00MiB
  Metadata: single  256.00MiB
  System:   single  256.00MiB
SSD detected:   no
Zoned device:   yes
  Zone size:256.00MiB
Incompat features:  extref, skinny-metadata, no-holes, zoned
Runtime features:   free-space-tree
Checksum:   crc32c
Number of devices:  1
Devices:
   IDSIZE  PATH
115.00TiB  /dev/loop5

$ sudo blkid | grep $DEV
/dev/loop5: LABEL="cf1657839355" UUID="381ff1f0-714a-411e-95c5-0fbd67979da5" 
UUID_SUB="0c2c7073-6ee7-4d42-aefe-834cb0a7f1b2" BLOCK_SIZE="4096" TYPE="btrfs"

$ sudo mount LABEL=cf1657839355 /mnt
$ mount | grep /mnt
/dev/loop5 on /mnt type btrfs 
(rw,relatime,discard=async,space_cache=v2,subvolid=5,subvol=/)

$ ls -l /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 11 Jul 12 12:03 UEFI -> ../../sda15
lrwxrwxrwx 1 root root 11 Jul 12 12:11 cf1657839355 -> ../../loop5
lrwxrwxrwx 1 root root 10 Jul 12 12:03 cloudimg-rootfs -> ../../sda1


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

** Changed in: util-linux (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  blkid fails to find btrfs zoned filesystem label or uuid

Status in util-linux package in Ubuntu:
  Invalid

Bug description:
  System Info:

  lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  
  1. Using an HM SMR drive (I used: ST14000NM0007-2G) create a zoned btrfs 
filesystem

  sudo mkfs.btrfs -O zoned -d single -m single -f /dev/sdb -L cf1657839355
  btrfs-progs v5.16.2
  See http://btrfs.wiki.kernel.org for more information.

  Resetting device zones /dev/sdb (52156 zones) ...
  NOTE: several default settings have changed in version 5.15, please make sure
this does not affect your deployments:
- DUP for metadata (-m dup)
- enabled no-holes (-O no-holes)
- enabled free-space-tree (-R free-space-tree)

  Label:  cf1657839355
  UUID:   5b7d5659-0ed3-45d3-a36b-fb58eeb93f72
  Node size:  16384
  Sector size:4096
  Filesystem size:12.73TiB
  Block group profiles:
Data: single  256.00MiB
Metadata: single  256.00MiB
System:   single  256.00MiB
  SSD detected:   no
  Zoned device:   yes
Zone size:256.00MiB
  Incompat features:  extref, skinny-metadata, no-holes, zoned
  Runtime features:   free-space-tree
  Checksum:   crc32c
  Number of devices:  1
  Devices:
 IDSIZE  PATH
  112.73TiB  /dev/sdb

  2. Try to use LABEL method to mount

  sudo mount LABEL=cf1657839355 cf1657839355
  mount: cf1657839355: can't find LABEL=cf1657839355.

  Expected that LABEL would be found.  I suspect that libblkid is where
  the issue is since this commands returns all of my other block devices
  except for /dev/sdb.

  sudo blkid|grep sdb

  
  It will mount using hard coded device path

  sudo mount /dev/sdb cf1657839355
  df -h /dev/sdb
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sdb 13T  3.5M   13T   1% /cf1657839355
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  DistroRelease: Ubuntu 22.04
  InstallationDate: Installed on 2021-05-20 (421 days ago)
  InstallationMedia: Ubuntu-Server 20.10 "Groovy Gorilla" - Release amd64 
(20201022)
  Package: util-linux 2.37.2-4ubuntu3
  PackageArchitecture: amd64
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 5.15.0-41.44-generic 5.15.39
  Tags:  jammy uec-images
  Uname: Linux 5.15.0-41-generic x86_64
  UpgradeStatus: Upgraded to jammy on 2022-07-14 (1 days ago)
  UserGroups: N/A
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1981769/+subscriptions


-- 
Mailing list: 

[Touch-packages] [Bug 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

Steve / #17,

Sorry, this was discussed internally at the time, but for some reason
the answers didn't make it here back then.

If we get another bug (e.g., another simple change from existing util-
linux bugs, that still makes sense to be SRUed) that can be combined
with this SRU, would that be good to go?

Thanks,
Mauricio

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  Incomplete
Status in util-linux source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

Uploaded to Lunar and Jammy, but not Kinetic (Won't Fix).

$ ubuntu-distro-info --series=kinetic --days=eol
45

Thanks!

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  In Progress
Status in util-linux source package in Mantic:
  Fix Released

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

util-linux 2.38.1-5ubuntu1 finally migrated from mantic-proposed to mantic
(its autopkgtests were very slow/cycling last week, apparently).

I'll check for potential sponsors to the debdiff in comment #10.

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  In Progress
Status in util-linux source package in Mantic:
  In Progress

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

For Mantic, this indeed requires a patch, not a merge/sync, as Debian
doesn't have the commit yet either.

$ git remote get-url origin
git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git

$ git describe --contains 6857cccbb4157d5da34ca98f77a0ac9d68e1e740
v2.39-rc1~126^2~4

$ git show v2.39 | grep Date:
Date:   Wed May 17 12:27:51 2023 +0200
Date:   Wed May 17 11:58:48 2023 +0200

$ rmadison -a source util-linux | grep mantic
 util-linux | 2.38.1-4ubuntu1  | mantic  | source
 util-linux | 2.38.1-5ubuntu1  | mantic-proposed | source

$ rmadison -u debian -a source util-linux
...
util-linux | 2.38.1-5 | testing| source
util-linux | 2.38.1-5 | unstable   | source
util-linux | 2.38.1-5 | unstable-debug | source

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  In Progress
Status in util-linux source package in Mantic:
  In Progress

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

Debdiff on top of mantic-proposed (2.38.1-5ubuntu1), which should
migrate soon (all good on update-excuses [1] / pending autopkgtests).

https://people.canonical.com/~ubuntu-archive/proposed-
migration/update_excuses.html#util-linux

** Patch added: "lp2019856-mantic-util-linux.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+attachment/5675082/+files/lp2019856-mantic-util-linux.debdiff

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  In Progress
Status in util-linux source package in Mantic:
  In Progress

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

Test packages in ppa:mfo/lp2019856, verified with GDB
(to fake CPU IDs) on Google Cloud ARM-based instances.

No differences in `lscpu` output for non-affected CPU.
Expected output for both affected CPUs (0xd15, 0xd4f).

Tested on LXD containers for Mantic, Lunar, and Jammy
(not on Kinetic as it will EOL soon, ~2 months).

Mantic:
---

$ lxc launch ubuntu-daily:mantic mantic
$ lxc shell mantic

# lsb_release -cs
No LSB modules are available.
mantic

Old:

# apt install util-linux/mantic-proposed

# dpkg -s util-linux | grep Version:
Version: 2.38.1-5ubuntu1

# lscpu | grep -e 'Vendor ID:' -e 'Model name:'
Vendor ID:   ARM
Model name:  Neoverse-N1

# lscpu > lscpu.old

Old/GDB:

# apt install gdb

# cat >lp2019856-reproducer.gdb &1 | grep -e '^\$' -e 'Model name:'
$1 = 0xaaad8570 "0xd0c"
$2 = (void *) 0xaaad8570
$3 = 0xaaad8570 "0xd15"
Model name:  -
$4 = 0xaaad8570 "0xd0c"
$5 = (void *) 0xaaad8570
$6 = 0xaaad8570 "0xd4f"
Model name:  -

New:

# add-apt-repository -y ppa:mfo/lp2019856
# sed -i '/Components:/ s,$, main/debug,' 
/etc/apt/sources.list.d/mfo-ubuntu-lp2019856-mantic.sources
# apt update
# apt install -y util-linux util-linux-dbgsym

# dpkg -s util-linux | grep Version:
Version: 2.38.1-5ubuntu2

# lscpu | grep -e 'Vendor ID:' -e 'Model name:'
Vendor ID:   ARM
Model name:  Neoverse-N1

# lscpu > lscpu.new
# diff lscpu.old lscpu.new
#

New/GDB:

# gdb -x lp2019856-reproducer.gdb lscpu 2>&1 | grep -e '^\$' -e 'Model 
name:'
$1 = 0xaaad8570 "0xd0c"
$2 = (void *) 0xaaad8570
$3 = 0xaaad8570 "0xd15"
Model name:  Cortex-R82
$4 = 0xaaad8570 "0xd0c"
$5 = (void *) 0xaaad8570
$6 = 0xaaad8570 "0xd4f"
Model name:  Neoverse-V2



Lunar
---


$ lxc launch ubuntu:lunar lunar
$ lxc shell lunar

# lsb_release -cs
No LSB modules are available.
lunar

Old:

# dpkg -s util-linux | grep Version:
Version: 2.38.1-4ubuntu1

# lscpu | grep -e 'Vendor ID:' -e 'Model name:'
Vendor ID:   ARM
Model name:  Neoverse-N1

# lscpu > lscpu.old
#

Old/GDB:

# apt install gdb
# export DEBUGINFOD_URLS="https://debuginfod.ubuntu.com;

# cat >lp2019856-reproducer.gdb <&1 | grep -e '^\$' -e 'Model name:'
$1 = 0xaaad8570 "0xd0c"
$2 = (void *) 0xaaad8570
$3 = 0xaaad8570 "0xd15"
Model name:  -
$4 = 0xaaad8570 "0xd0c"
$5 = (void *) 0xaaad8570
$6 = 0xaaad8570 "0xd4f"
Model name:  -

New:

# add-apt-repository -y ppa:mfo/lp2019856
# sed -i '/^deb .* main$/ s:$: main/debug:' 
/etc/apt/sources.list.d/mfo-ubuntu-lp2019856-lunar.list
# apt update
# apt install -y util-linux util-linux-dbgsym

# dpkg -s util-linux | grep Version:
Version: 2.38.1-4ubuntu1.1

# lscpu | grep -e 'Vendor ID:' -e 'Model name:'
Vendor ID:   ARM
Model name:  Neoverse-N1

# lscpu > lscpu.new
# diff lscpu.old lscpu.new
#

New/GDB:

# gdb -x lp2019856-reproducer.gdb lscpu 2>&1 | grep -e '^\$' -e 'Model 
name:'
$1 = 0xaaad8570 "0xd0c"
$2 = (void *) 0xaaad8570
$3 = 0xaaad8570 "0xd15"
Model name:  Cortex-R82
$4 = 0xaaad8570 "0xd0c"
$5 = (void *) 0xaaad8570
$6 = 0xaaad8570 "0xd4f"
Model name:  Neoverse-V2


Jammy
---

$ lxc launch ubuntu:jammy jammy
lxc shell jammy

# lsb_release -cs
jammy

Old:

# dpkg -s util-linux | grep Version:
Version: 2.37.2-4ubuntu3
#

# lscpu | grep -e 'Vendor ID:' -e 'Model name:'
Vendor ID:   ARM
Model name:  Neoverse-N1

# lscpu > lscpu.old

Old/GDB:

# wget 
https://launchpad.net/ubuntu/+archive/primary/+files/util-linux-dbgsym_2.37.2-4ubuntu3_arm64.ddeb
# apt install -y gdb ./util-linux-dbgsym_2.37.2-4ubuntu3_arm64.ddeb

* Jammy differences: break on arm_ids_decode() by line, and no
Model name if unknown.

# cat >lp2019856-reproducer-jammy.gdb <&1 | grep -e '^\$' -e 
'Model name:'
$1 = 0xaaacf5b0 "0xd0c"
$2 = (void *) 0xaaacf5b0
$3 = 0xaaacf5b0 "0xd15"
   

[Touch-packages] [Bug 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

Hey Heather, thanks for the updated debdiffs!

I've looked at them, and did minor fixes to DEP3
(moved them out of the original commit message, 
after `---`, and added Origin: fields), and just
a cosmetic adjustment to the changelog.

It turns out this patch isn't present in Mantic.
I already handled the debdiff/tests; don't worry.
I'll look for a sponsor for the devel release,
and handle the stable releases/SRUs afterward.

I marked Kinetic as won't fix, as it's not needed
and close to EOL anyway.

  $ ubuntu-distro-info --series=kinetic --days=eol
  58

I removed the verification tags you added? 
They are added automatically by the SRU machinery
when the packages land in -proposed for testing.

cheers,
Mauricio

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  In Progress
Status in util-linux source package in Mantic:
  In Progress

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

** Description changed:

  [Impact]
- When running "lscpu" on a Grace-based system + Ubuntu 22.04, it doesn't 
report a model name:
+ 
+ When running "lscpu" on a Grace-based system + Ubuntu 22.04, it doesn't
+ report a model name:
  
  Vendor ID: ARM
  Model: 0
  
  [Fix]
- Adding the additional arm_part to sys-utils/lscpu-arm.c solves the problem. 
The commit below adds the specific codes missing from Jammy's version.
+ 
+ Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
+ problem. The commit below adds the specific codes missing from Jammy's
+ version.
  
  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740
  
- [Evidence]
- When upstream code is compiled, output of lscpu is correctly displayed:
+ [Test Steps]
+ 
+ * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2
  
+ * Verify whether output of lscpu doesn't change on old CPUs; eg:
+ Vendor ID: ARM
+ Model name: Neoverse-N1
+ 
  [What Could Go Wrong]
- The fix does not apply directly to Jammy's version, as other commits change 
sys-utils/lscpu-arm.c. The suggestion is only to add the missing arm_part to 
the list.
+ 
+ The fix only introduces additional model identifiers to match
+ against and print a model name string, thus regression impact
+ should be contained within lscpu and printing cpus model name
+ on ARM systems. 
+ 
+ Output doesn't change on systems with non-affected CPU models.

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  In Progress
Status in util-linux source package in Mantic:
  In Progress

Bug description:
  [Impact]

  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it
  doesn't report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]

  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the
  problem. The commit below adds the specific codes missing from Jammy's
  version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Test Steps]

  * Verify whether output of lscpu is correct on new CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-V2

  * Verify whether output of lscpu doesn't change on old CPUs; eg:
  Vendor ID: ARM
  Model name: Neoverse-N1

  [What Could Go Wrong]

  The fix only introduces additional model identifiers to match
  against and print a model name string, thus regression impact
  should be contained within lscpu and printing cpus model name
  on ARM systems. 

  Output doesn't change on systems with non-affected CPU models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

** Also affects: util-linux (Ubuntu Kinetic)
   Importance: Undecided
   Status: New

** Also affects: util-linux (Ubuntu Mantic)
   Importance: Undecided
   Status: New

** Changed in: util-linux (Ubuntu Kinetic)
   Status: New => Won't Fix

** Changed in: util-linux (Ubuntu Mantic)
   Status: New => In Progress

** Changed in: util-linux (Ubuntu Mantic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Tags removed: verification-needed-jammy verification-needed-lunar

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Kinetic:
  Won't Fix
Status in util-linux source package in Lunar:
  In Progress
Status in util-linux source package in Mantic:
  In Progress

Bug description:
  [Impact]
  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it doesn't 
report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]
  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the problem. 
The commit below adds the specific codes missing from Jammy's version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Evidence]
  When upstream code is compiled, output of lscpu is correctly displayed:
  Vendor ID: ARM
  Model name: Neoverse-V2

  [What Could Go Wrong]
  The fix does not apply directly to Jammy's version, as other commits change 
sys-utils/lscpu-arm.c. The suggestion is only to add the missing arm_part to 
the list.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

Heather mentioned some changes she has for the debdiffs, I also noted
some changes to DEP3 headers, and debdiffs v2 are in progress. Thanks,
Heather!

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  New
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Lunar:
  In Progress

Bug description:
  [Impact]
  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it doesn't 
report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]
  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the problem. 
The commit below adds the specific codes missing from Jammy's version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Evidence]
  When upstream code is compiled, output of lscpu is correctly displayed:
  Vendor ID: ARM
  Model name: Neoverse-V2

  [What Could Go Wrong]
  The fix does not apply directly to Jammy's version, as other commits change 
sys-utils/lscpu-arm.c. The suggestion is only to add the missing arm_part to 
the list.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems

[Mauricio Faria de Oliveira]

** Tags added: se-sponsor-mfo

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

Title:
  Add missing ARM-cores to support Grace-based systems

Status in util-linux package in Ubuntu:
  New
Status in util-linux source package in Jammy:
  In Progress
Status in util-linux source package in Lunar:
  In Progress

Bug description:
  [Impact]
  When running "lscpu" on a Grace-based system + Ubuntu 22.04, it doesn't 
report a model name:

  Vendor ID: ARM
  Model: 0

  [Fix]
  Adding the additional arm_part to sys-utils/lscpu-arm.c solves the problem. 
The commit below adds the specific codes missing from Jammy's version.

  https://github.com/util-linux/util-
  linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740

  [Evidence]
  When upstream code is compiled, output of lscpu is correctly displayed:
  Vendor ID: ARM
  Model name: Neoverse-V2

  [What Could Go Wrong]
  The fix does not apply directly to Jammy's version, as other commits change 
sys-utils/lscpu-arm.c. The suggestion is only to add the missing arm_part to 
the list.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 1856871] Re: i/o error if next unused loop device is queried

[Mauricio Faria de Oliveira]

The fix/commit is applied in v5.12, thus available on Jammy
(v5.15-based).

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4ceddce55eb35d15b0f87f5dcf6f0058fd15d3a4


~/git/linux$ git describe --contains 4ceddce55eb35d15b0f87f5dcf6f0058fd15d3a4
v5.12-rc1-dontuse~7^2~13


** Also affects: parted (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: udev (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: snapd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: linux (Ubuntu Jammy)
   Status: New => Fix Released

** Changed in: parted (Ubuntu Jammy)
   Status: New => Invalid

** No longer affects: parted (Ubuntu Jammy)

** No longer affects: snapd (Ubuntu Jammy)

** No longer affects: udev (Ubuntu Jammy)

** No longer affects: systemd (Ubuntu Jammy)

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

Title:
  i/o error if next unused loop device is queried

Status in linux package in Ubuntu:
  Fix Released
Status in parted package in Ubuntu:
  Invalid
Status in snapd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in udev package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Released

Bug description:
  This is reproducible in Bionic and late.

  Here's an example running 'focal':

  $ lsb_release -cs
  focal

  $ uname -r
  5.3.0-24-generic

  The error is:
  blk_update_request: I/O error, dev loop2, sector 0

  and on more recent kernel:

  kernel: [18135.185709] blk_update_request: I/O error, dev loop18,
  sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0

  
  How to trigger it:
  $ sosreport -o block

  or more precisely the cmd causing the situation inside the block plugin:
  $ parted -s $(losetup -f) unit s print

  https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52

  but if I run it on the next next unused loop device, in this case
  /dev/loop3 (which is also unused), no errors.

  While I agree that sosreport shouldn't query unused loop devices,
  there is definitely something going on with the next unused loop
  device.

  What is differentiate loop2 and loop3 and any other unused ones ?

  3 things so far I have noticed:
  * loop2 is the next unused loop device (losetup -f)
  * A reboot is needed (if some loop modification (snap install, mount loop, 
...) has been made at runtime
  * I have also noticed that loop2 (or whatever the next unused one is) have 
some stat as oppose to other unused loop devices. The stat exist already right 
after the system boot for the next unused loop device.

  /sys/block/loop2/stat
  ::
  2 0 10 0 1 0 0 0 0 0 0

  2  = number of read I/Os processed
  10 = number of sectors read
  1  = number of write I/Os processed

  Explanation of each column:
  https://www.kernel.org/doc/html/latest/block/stat.html

  while /dev/loop3 doesn't

  /sys/block/loop3/stat
  ::
  0 0 0 0 0 0 0 0 0 0 0

  Which tells me that something during the boot process most likely
  acquired (on purpose or not) the next unused loop and possibly didn't
  released it well enough.

  If loop2 is generating errors, and I install a snap, the snap squashfs
  will take loop2, making loop3 the next unused loop device.

  If I query loop3 with 'parted' right after, no errors.

  If I reboot, and query loop3 again, then no I'll have an error.

  To triggers the errors it need to be after a reboot and it only impact
  the first unused loop device available (losetup -f).

  This was tested with focal/systemd whic his very close to latest
  upstream code.

  This has been test with latest v5.5 mainline kernel as well.

  For now, I don't think it's a kernel problem, I'm more thinking of a
  userspace misbehaviour dealing with loop device (or block device) at
  boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+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 1677668] Re: no GARPs during ephemeral boot

[Mauricio Faria de Oliveira]

Marking bug as Invalid for MAAS as per previous comment, incomplete
status since, and input from Björn and Jerzy.

** Changed in: maas
   Status: Incomplete => Invalid

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

Title:
  no GARPs during ephemeral boot

Status in MAAS:
  Invalid
Status in cloud-init package in Ubuntu:
  Incomplete
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  Deploys time out with an error on the console that says,

  "Can not apply stage final, no datasource found! Likely bad things to
  come!"

  How to duplicate:
  MAAS Version 2.1.3+bzr5573-0ubuntu1 (16.04.1)
  1) Rack Controller and Region Controller in different VLANs
  2) Use Cisco ASA as the router with "ARP Inspection" enabled
  3) Clear the router ARP cache
  4) Deploy 2 maas machines with interfaces set to "Static assign"
  5) Observe deploys successfully
  6) Release both machines and swap IP's.
  7) Redeploy the same 2 machines
  8) Observe deploy failure with the machine consoles stuck in the "ubuntu 
login" screen with "Can not apply stage final, no datasource Found! Likely bad 
things to come!"
   
  The root cause is that during ephemeral PXE booting, no GARPs are sent, which 
in our environment will cause our router (Cisco ASA) to hold on to ARP table 
entries until it expires (default= 4 hours).  Then combined with ASA feature 
"ARP Inspection" will drop packets from a MaaS machine using the previously 
used IP from a different MaaS machine.

  The ephemeral boot image ephemeral-ubuntu-amd64-ga-16.04-xenial-daily.

  Running tcpdump on the Rack Controller, showed no GARPs from the
  deploying MaaS machine.  If there were GARPs sent, then the router
  would refresh its ARP cache thus avoiding the ARP Inspection dropping.

  [Excerpt from Cisco ASA]
  
http://www.cisco.com/c/en/us/td/docs/security/asa/asa94/config-guides/cli/general/asa-94-general-config/basic-arp-mac.pdf
  When you enable ARP inspection, the ASA compares the MAC address, IP address, 
and source interface in
  all ARP packets to static entries in the ARP table, and takes the following 
actions:
  • If the IP address, MAC address, and source interface match an ARP entry, 
the packet is passed through.
  • If there is a mismatch between the MAC address, the IP address, or the 
interface, then the ASA drops
  the packet.
  • If the ARP packet does not match any entries in the static ARP table, then 
you can set the ASA to either
  forward the packet out all interfaces (flood), or to drop the packet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1677668/+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 1677668] Re: no GARPs during ephemeral boot

[Mauricio Faria de Oliveira]

** Tags added: se-00140843

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

Title:
  no GARPs during ephemeral boot

Status in MAAS:
  Incomplete
Status in cloud-init package in Ubuntu:
  Incomplete
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  Deploys time out with an error on the console that says,

  "Can not apply stage final, no datasource found! Likely bad things to
  come!"

  How to duplicate:
  MAAS Version 2.1.3+bzr5573-0ubuntu1 (16.04.1)
  1) Rack Controller and Region Controller in different VLANs
  2) Use Cisco ASA as the router with "ARP Inspection" enabled
  3) Clear the router ARP cache
  4) Deploy 2 maas machines with interfaces set to "Static assign"
  5) Observe deploys successfully
  6) Release both machines and swap IP's.
  7) Redeploy the same 2 machines
  8) Observe deploy failure with the machine consoles stuck in the "ubuntu 
login" screen with "Can not apply stage final, no datasource Found! Likely bad 
things to come!"
   
  The root cause is that during ephemeral PXE booting, no GARPs are sent, which 
in our environment will cause our router (Cisco ASA) to hold on to ARP table 
entries until it expires (default= 4 hours).  Then combined with ASA feature 
"ARP Inspection" will drop packets from a MaaS machine using the previously 
used IP from a different MaaS machine.

  The ephemeral boot image ephemeral-ubuntu-amd64-ga-16.04-xenial-daily.

  Running tcpdump on the Rack Controller, showed no GARPs from the
  deploying MaaS machine.  If there were GARPs sent, then the router
  would refresh its ARP cache thus avoiding the ARP Inspection dropping.

  [Excerpt from Cisco ASA]
  
http://www.cisco.com/c/en/us/td/docs/security/asa/asa94/config-guides/cli/general/asa-94-general-config/basic-arp-mac.pdf
  When you enable ARP inspection, the ASA compares the MAC address, IP address, 
and source interface in
  all ARP packets to static entries in the ARP table, and takes the following 
actions:
  • If the IP address, MAC address, and source interface match an ARP entry, 
the packet is passed through.
  • If there is a mismatch between the MAC address, the IP address, or the 
interface, then the ASA drops
  the packet.
  • If the ARP packet does not match any entries in the static ARP table, then 
you can set the ASA to either
  forward the packet out all interfaces (flood), or to drop the packet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1677668/+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 2009699] Re: sytemd-udev package upgrade breaks if udev is masked

[Mauricio Faria de Oliveira]

Hey Simon. Understood, thanks for the clarification!

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

Title:
  sytemd-udev package upgrade breaks if udev is masked

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  The Anbox Cloud LXD images are based of the standard Ubuntu cloud
  images for LXD but have the systemd-udevd.service unit masked
  (`systemctl mask systemd-udevd.service`) as we do not need udev.

  With the latest security patch on Ubuntu 22.04 upgrading the udev
  package fails:

  ...
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: left to upgrade {'udev', 
'libudev1'}
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: applying set ['udev', 
'libudev1']
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: Log ended: 2023-03-07  
21:33:47
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: Log started: 2023-03-07  
21:33:48
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: [614B blob data]
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: Preparing to unpack 
.../udev_249.11-0ubuntu3.7_arm64.deb ...
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: Unpacking udev 
(249.11-0ubuntu3.7) over (249.11-0ubuntu3.6) ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Preparing to unpack 
.../libudev1_249.11-0ubuntu3.7_arm64.deb ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Unpacking libudev1:arm64 
(249.11-0ubuntu3.7) over (249.11-0ubuntu3.6) ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Setting up libudev1:arm64 
(249.11-0ubuntu3.7) ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Setting up udev 
(249.11-0ubuntu3.7) ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag systemd[1]: Reloading.
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Failed to restart 
udev.service: Unit udev.service failed to load properly, please adjust/correct 
and reload service manager: File exists
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: See system logs and 
'systemctl status udev.service' for details.
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: invoke-rc.d: initscript 
udev, action "restart" failed.

  We can workaround this by doing a patch release to our users next week
  but it would be a lot better if the package scripts check if the
  service unit is masked and if it is avoid restarting udev.service

  The problem isn't introduced with the 249.11-0ubuntu3.7 but should
  exist for longer already. It just became a problem for us due to the
  security patch rolling in via unattended-upgrades

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2009699/+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 2009699] Re: sytemd-udev package upgrade breaks if udev is masked

[Mauricio Faria de Oliveira]

Hi Simon,

Thanks for the detailed report!

For testing purposes, this can be reproduced this with standard LXD
images by masking the systemd-udev.service unit, as you described.

Could you please confirm if from the Anbox perspective, for a
workaround, is it OK to temporatily unmask/start the unit (due to
restart), then upgrade the package, and stop/mask again?

For example:

lxc launch ubuntu:jammy jammy-udev-masked
lxc exec jammy-udev-masked -- su - ubuntu

$ dpkg -s udev | grep Version:
Version: 249.11-0ubuntu3.6

sudo systemctl mask systemd-udevd.service
sudo systemctl stop systemd-udevd.service

sudo apt update && sudo apt install -y udev

...
Setting up udev (249.11-0ubuntu3.7) ...
Failed to restart udev.service: Unit udev.service failed to load properly, 
please adjust/correct and reload service manager: File exists
See system logs and 'systemctl status udev.service' for details.
invoke-rc.d: initscript udev, action "restart" failed.
○ udev.service
 Loaded: error (Reason: Unit udev.service failed to load properly, please 
adjust/correct and reload service manager: File exists)
 Active: inactive (dead)
Warning: The unit file, source configuration file or drop-ins of udev.service 
changed on disk. Run 'systemctl daemon-reload' to reload units.
dpkg: error processing package udev (--configure):
 installed udev package post-installation script subprocess returned error exit 
status 1
dmesg: read kernel buffer failed: Operation not permitted
...

sudo systemctl unmask systemd-udevd.service
sudo apt install -f

sudo systemctl mask systemd-udevd.service
sudo systemctl stop systemd-udevd.service

** 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/2009699

Title:
  sytemd-udev package upgrade breaks if udev is masked

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  The Anbox Cloud LXD images are based of the standard Ubuntu cloud
  images for LXD but have the systemd-udevd.service unit masked
  (`systemctl mask systemd-udevd.service`) as we do not need udev.

  With the latest security patch on Ubuntu 22.04 upgrading the udev
  package fails:

  ...
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: left to upgrade {'udev', 
'libudev1'}
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: applying set ['udev', 
'libudev1']
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: Log ended: 2023-03-07  
21:33:47
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: Log started: 2023-03-07  
21:33:48
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: [614B blob data]
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: Preparing to unpack 
.../udev_249.11-0ubuntu3.7_arm64.deb ...
  Mar 07 21:33:48 ams-cg3qqttdjmctnqegcqag sh[753]: Unpacking udev 
(249.11-0ubuntu3.7) over (249.11-0ubuntu3.6) ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Preparing to unpack 
.../libudev1_249.11-0ubuntu3.7_arm64.deb ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Unpacking libudev1:arm64 
(249.11-0ubuntu3.7) over (249.11-0ubuntu3.6) ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Setting up libudev1:arm64 
(249.11-0ubuntu3.7) ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Setting up udev 
(249.11-0ubuntu3.7) ...
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag systemd[1]: Reloading.
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: Failed to restart 
udev.service: Unit udev.service failed to load properly, please adjust/correct 
and reload service manager: File exists
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: See system logs and 
'systemctl status udev.service' for details.
  Mar 07 21:33:49 ams-cg3qqttdjmctnqegcqag sh[753]: invoke-rc.d: initscript 
udev, action "restart" failed.

  We can workaround this by doing a patch release to our users next week
  but it would be a lot better if the package scripts check if the
  service unit is masked and if it is avoid restarting udev.service

  The problem isn't introduced with the 249.11-0ubuntu3.7 but should
  exist for longer already. It just became a problem for us due to the
  security patch rolling in via unattended-upgrades

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2009699/+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 1937110] Re: dhcp option 121 & 249

[Mauricio Faria de Oliveira]

Verification done on focal
(full steps on comment #13)

$ lxc shell focal-dhcpd

# add-apt-repository -y 'deb http://archive.ubuntu.com/ubuntu focal-
proposed main'

root@focal-dhcpd:~# apt policy isc-dhcp-client
isc-dhcp-client:
  Installed: 4.4.1-2.1ubuntu5.20.04.4
  Candidate: 4.4.1-2.1ubuntu5.20.04.5
  Version table:
 4.4.1-2.1ubuntu5.20.04.5 500
500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
...

# apt download isc-dhcp-client
# python3 -m http.server
...

$ lxc shell focal-dhclient

# wget 10.11.12.13:8000/isc-dhcp-client_4.4.1-2.1ubuntu5.20.04.5_amd64.deb
# dpkg -i isc-dhcp-client_4.4.1-2.1ubuntu5.20.04.5_amd64.deb

# lsinitramfs /boot/initrd.img-$(uname -r) | grep dhclient-exit-hooks.d
#

# update-initramfs -u

# lsinitramfs /boot/initrd.img-$(uname -r) | grep dhclient-exit-hooks.d
etc/dhcp/dhclient-exit-hooks.d
etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes

# cat 

[Touch-packages] [Bug 1937110] Re: dhcp option 121 & 249

[Mauricio Faria de Oliveira]

Verification done on jammy
(full steps on comment #12)

$ lxc shell jammy-dhcpd

# add-apt-repository -yp proposed

# apt policy isc-dhcp-client
isc-dhcp-client:
  Installed: 4.4.1-2.3ubuntu2.3
  Candidate: 4.4.1-2.3ubuntu2.4
  Version table:
 4.4.1-2.3ubuntu2.4 500
500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
...

# apt download isc-dhcp-client
# python3 -m http.server
...

$ lxc shell jammy-dhclient

# wget 10.11.12.13:8000/isc-dhcp-client_4.4.1-2.3ubuntu2.4_amd64.deb
# dpkg -i isc-dhcp-client_4.4.1-2.3ubuntu2.4_amd64.deb

# lsinitramfs /boot/initrd.img-$(uname -r) | grep dhclient-exit-hooks.d
#

# update-initramfs -u

# lsinitramfs /boot/initrd.img-$(uname -r) | grep dhclient-exit-hooks.d
etc/dhcp/dhclient-exit-hooks.d
etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes

# cat 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

The -proposed packages have also been verified by the Microsoft Azure team.
14k+ VM deployments with the fix didn't observe the issue over the weekend.

Marking jammy/focal as verified based on that plus 2 synthetic tests
above.

** Tags removed: verification-needed verification-needed-focal 
verification-needed-jammy
** Tags added: verification-done verification-done-focal verification-done-jammy

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  Fix Committed
Status in isc-dhcp source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

   * Occasionally, during instance boot or machine start-up,
 dhclient will attempt to acquire a dhcp lease and fail,
 leaving the instance with no IP address and making it
 unreachable.

   * This happens about once every 100 reboots on bare metal,
 or affecting between ~0.3% to 2% of deployments on Azure
 (comment #2).
 
   * Azure uses dhclient called from cloud-init instead of
 systemd-networkd, and this is causing issues with larger
 deployments.

   * The logs of an affected dhclient produce the following:

 Listening on LPF/enp1s0/52:54:00:1c:d7:00
 Sending on   LPF/enp1s0/52:54:00:1c:d7:00
 Sending on   Socket/fallback
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 ...
 (omitting 20 similar lines)
 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 No DHCPOFFERS received.
 No working leases in persistent database - sleeping.

   * This only impacts Focal and Jammy, where bind9-libs
 are multi-threaded (Bionic/earlier and Kinetic/later
 are single-threaded).

   * The actual problem is dhclient containing a thread
 concurrency race condition, and when the race occurs,
 the read socket is incorrectly/prematurely unwatched
 because required structures are not yet consistent,
 thus dhclient does not read any DHCPOFFER replies.

   * Detailed analysis of the issue is in comment #17.

  [Fix]

   * Prevent the race condition by starting to watch the
 read socket after required structures are consistent.
   
   * The fix has been tested in Azure w/ 13500 instances,
 and no errors have been observed (previously: 0.4%).
 
   * Anyway, in case regressions are observed, the patch
 introduces 2 switches to revert to previous behavior,
 which can be applied per-process or system-wide:
 - DHCP_FD_FLAGS_POKE=0 environment variable
 - dhcp.fd_flags_poke=0 kernel cmdline option 
   
   * (Previous approaches/discussions included reverting
  bind9-libs to single-threaded, but we concluded it
  would have more regression risk than the expected
  [some bits in comment #8, and some internal chat],
  and remove exported symbols (apparently unused, but).
  We also considered a mutex/spinlock approach, but
  later found a simpler way w/ isc lib; comment #13.)
  
  [Test Plan]

   * Synthetic reproducer with GDB to force the race
 condition, and DHCP server/client/noise injection
 is described in comment #9.
   
   * Test with the original package (problem occurs).
   
   * Test with the modified package (problem fixed).
 - Set DHCP_FD_FLAGS_POKE=0 (problem occurs).
 - Set dhcp.fd_flags_poke=0 (problem occurs).

  [Regression Potential]

   * 1) dhclient failing to acquire DHCP leases.
  
   * 2) dhcpd is also affected by code changes,
 thus failures to handle DHCP lease requests
 also have potential for regressions.
 
   * 3) the functional change added by the fix,
 if a regression were to occur, would likely
 be an issue only under some (unknown) race
 condition as well, thus expected to be rare.

   * Note: this potentially affects Focal/Jammy 
 on Azure as a whole, per usage of dhclient
 in cloud-init instead of systemd-networkd.
 
 Azure provided extensive testing for all 3
 approaches (mostly internal communications,
 and some bug comments), with ~13k instances.
 
 No issues were observed (previously: 0.4%).
 
   * Such testing scale seems to indicate that
 there are no regressions for dhclient to
 acquire DHCP leases (1), nor another race
 condition that hit the fix/new behavior (3).
 
 With that, apparently (2) should be OK too.
 
   * Also, so to mitigate the regression risk
 as much as possible, there's very detailed
 analysis provided here (comments #17, 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

verification done on focal
(full steps in comment #9)

The issue is not reproducible with the package in -proposed,
and is reproducible with the 2 switches for the old behavior
(DHCP_FD_FLAGS_POKE=0 or dhcp.fd_flags_poke=0), as expected.

...

# add-apt-repository -y 'deb http://archive.ubuntu.com/ubuntu focal-
proposed main'

# apt policy isc-dhcp-client
isc-dhcp-client:
  Installed: 4.4.1-2.1ubuntu5.20.04.4
  Candidate: 4.4.1-2.1ubuntu5.20.04.5
  Version table:
 4.4.1-2.1ubuntu5.20.04.5 500
500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
...

# wget https://launchpad.net/ubuntu/+archive/primary/+files/isc-dhcp-
client-dbgsym_4.4.1-2.1ubuntu5.20.04.5_amd64.ddeb

# apt install -y isc-dhcp-client ./isc-dhcp-client-
dbgsym_4.4.1-2.1ubuntu5.20.04.5_amd64.ddeb gdb

Source code line numbers (for breakpoint):

 233 isc_result_t omapi_register_io_object (omapi_object_t *h,
 ...
 312 status = isc_socket_fdwatchcreate(dhcp_gbl_ctx.socketmgr,
 ...
 333 for (p = omapi_io_states.next;
  
# ip netns exec ns1 \
  gdb -ex 'set target-async on' -ex 'set non-stop on' -ex 'set pagination off' 
-ex 'set confirm off' -q dhclient

(gdb) break omapip/dispatch.c:333
(gdb) commands
shell sleep 0.2
continue
end
(gdb) run -d -v veth1
...
Thread 1 "dhclient" hit Breakpoint 1, omapi_register_io_object 
(h=0x561afb034940, readfd=0x561afad13630 , 
writefd=writefd@entry=0x0, reader=0x561afad30fb0 , 
writer=writer@entry=0x0, reaper=reaper@entry=0x0) at dispatch.c:337
337 in dispatch.c
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 (xid=0x72ac8a14)
DHCPOFFER of 192.168.42.100 from 192.168.42.1
DHCPREQUEST for 192.168.42.100 on veth1 to 255.255.255.255 port 67 
(xid=0x148aac72)
DHCPACK of 192.168.42.100 from 192.168.42.1 (xid=0x72ac8a14)
[Detaching after fork from child process 1037683]
bound to 192.168.42.100 -- renewal in 290 seconds.
^C
Thread 1 "dhclient" received signal SIGINT, Interrupt.
...

(gdb) run -d -v veth1 -r
...
DHCPRELEASE of 192.168.42.100 on veth1 to 192.168.42.1 port 67 (xid=0x20449570)
...

<<< WORKS 10/10 >>>

...

(gdb) set environment DHCP_FD_FLAGS_POKE 0

(gdb) run -d -v veth1
...
Thread 1 "dhclient" hit Breakpoint 1, omapi_register_io_object 
(h=0x557c0d5d1350, readfd=0x557c0beb8630 , writefd=0x0, 
reader=0x557c0bed5fb0 , writer=0x0, reaper=0x0) at 
dispatch.c:337
337 in dispatch.c
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 (xid=0xa5a2783d)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 6 (xid=0xa5a2783d)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 8 (xid=0xa5a2783d)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 10 (xid=0xa5a2783d)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 21 (xid=0xa5a2783d)
^C
Thread 1 "dhclient" received signal SIGINT, Interrupt.
...
(gdb) kill

<<< FAILS 3/3 >>>

(gdb) unset environment DHCP_FD_FLAGS_POKE

...

(gdb) shell echo "$(cat /proc/cmdline) dhcp.fd_flags_poke=0" >/tmp/cmdline
(gdb) shell mount --bind /tmp/cmdline /proc/cmdline
(gdb) shell cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.4.0-1084-kvm 
root=PARTUUID=7a9ea63e-b971-413c-9238-d59509520a9e ro console=tty1 
console=ttyS0 dhcp.fd_flags_poke=0

(gdb) run -d -v veth1
...
Thread 1 "dhclient" hit Breakpoint 1, omapi_register_io_object 
(h=0x5604afcaac00, readfd=0x5604ae2d3630 , writefd=0x0, 
reader=0x5604ae2f0fb0 , writer=0x0, reaper=0x0) at 
dispatch.c:337
337 in dispatch.c
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 (xid=0x6095ca20)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 7 (xid=0x6095ca20)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 18 (xid=0x6095ca20)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 7 (xid=0x6095ca20)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 14 (xid=0x6095ca20)
^C
Thread 1 "dhclient" received signal SIGINT, Interrupt.
...
(gdb) kill

<<< FAILS 3/3 >>>

(gdb) shell umount /proc/cmdline

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  Fix Committed
Status in isc-dhcp source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

   * Occasionally, during instance boot or machine start-up,
 dhclient will attempt to acquire a dhcp lease and fail,
 leaving the instance with no IP address and making it
 unreachable.

   * This happens about once every 100 reboots on bare metal,
 or affecting between ~0.3% to 2% of deployments on Azure
 (comment #2).
 
   * Azure uses dhclient called from cloud-init instead of
 systemd-networkd, and this is causing issues with larger
 deployments.

   * The logs of an affected 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

verification done on jammy 
(full steps in comment #9)

The issue is not reproducible with the package in -proposed,
and is reproducible with the 2 switches for the old behavior
(DHCP_FD_FLAGS_POKE=0 or dhcp.fd_flags_poke=0), as expected.

...

# add-apt-repository -yp proposed

# apt policy isc-dhcp-client
isc-dhcp-client:
  Installed: 4.4.1-2.3ubuntu2.3
  Candidate: 4.4.1-2.3ubuntu2.4
  Version table:
 4.4.1-2.3ubuntu2.4 500
500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
...

# wget https://launchpad.net/ubuntu/+archive/primary/+files/isc-dhcp-
client-dbgsym_4.4.1-2.3ubuntu2.4_amd64.ddeb

# apt install -y isc-dhcp-client ./isc-dhcp-client-
dbgsym_4.4.1-2.3ubuntu2.4_amd64.ddeb gdb

Source code line numbers (for breakpoint):

 233 isc_result_t omapi_register_io_object (omapi_object_t *h,
 ...
 312 status = isc_socket_fdwatchcreate(dhcp_gbl_ctx.socketmgr,
 ...
 333 for (p = omapi_io_states.next;
  
# ip netns exec ns1 \
  gdb -ex 'set target-async on' -ex 'set non-stop on' -ex 'set pagination off' 
-ex 'set confirm off' -q dhclient

(gdb) break omapip/dispatch.c:333
(gdb) commands
shell sleep 0.2
continue
end
(gdb) run -d -v veth1
...
Thread 1 "dhclient" hit Breakpoint 1, omapi_register_io_object 
(h=0x558f3b9b1180, readfd=0x558f3b00f150 , writefd=0x0, 
reader=0x558f3b0114b0 , writer=0x0, reaper=0x0) at 
../omapip/dispatch.c:343
343 ../omapip/dispatch.c: No such file or directory.
Sending on   Socket/fallback
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 (xid=0x6909975b)
DHCPOFFER of 192.168.42.100 fbreak omapip/dispatch.c:333rom 192.168.42.1
DHCPREQUEST for 192.168.42.100 on veth1 to 255.255.255.255 port 67 
(xid=0x5b970969)
DHCPACK of 192.168.42.100 from 192.168.42.1 (xid=0x6909975b)
[Detaching after fork from child process 34351]
bound to 192.168.42.100 -- renewal in 301 seconds.
^C
Thread 1 "dhclient" received signal SIGINT, Interrupt.
...

(gdb) run -d -v veth1 -r
...
DHCPRELEASE of 192.168.42.100 on veth1 to 192.168.42.1 port 67 (xid=0x270d7f02)
...

<<< WORKS 10/10 >>>

...

(gdb) set environment DHCP_FD_FLAGS_POKE 0

(gdb) run -d -v veth1
...
Thread 1 "dhclient" hit Breakpoint 1, omapi_register_io_object 
(h=0x55e3f8364180, readfd=0x55e3f7828150 , writefd=0x0, 
reader=0x55e3f782a4b0 , writer=0x0, reaper=0x0) at 
../omapip/dispatch.c:343
343 ../omapip/dispatch.c: No such file or directory.
Sending on   Socket/fallback
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 (xid=0xd7155345)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 5 (xid=0xd7155345)
DHCPDISCOVER on veth1 to 255break omapip/dispatch.c:333.255.255.255 port 67 
interval 6 (xid=0xd7155345)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 7 (xid=0xd7155345)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 7 (xid=0xd7155345)
^C
Thread 1 "dhclient" received signal SIGINT, Interrupt.
...
(gdb) kill

<<< FAILS 3/3 >>>

(gdb) unset environment DHCP_FD_FLAGS_POKE

...

(gdb) shell echo "$(cat /proc/cmdline) dhcp.fd_flags_poke=0" >/tmp/cmdline
(gdb) shell mount --bind /tmp/cmdline /proc/cmdline
(gdb) shell cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.15.0-1025-kvm 
root=PARTUUID=72954768-850e-45d3-a9ca-d064a700c8b5 ro console=tty1 
console=ttyS0 panic=-1 dhcp.fd_flags_poke=0

(gdb) run -d -v veth1
...
Sending on   Socket/fallback
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 (xid=0xf141b060)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 5 (xid=0xf141b060)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 13 (xid=0xf141b060)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 20 (xid=0xf141b060)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 11 (xid=0xf141b060)
^C
Thread 1 "dhclient" received signal SIGINT, Interrupt.
...
(gdb) kill

<<< FAILS 3/3 >>>

(gdb) shell umount /proc/cmdline

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  Fix Committed
Status in isc-dhcp source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

   * Occasionally, during instance boot or machine start-up,
 dhclient will attempt to acquire a dhcp lease and fail,
 leaving the instance with no IP address and making it
 unreachable.

   * This happens about once every 100 reboots on bare metal,
 or affecting between ~0.3% to 2% of deployments on Azure
 (comment #2).
 
   * Azure uses dhclient called from cloud-init instead of
 systemd-networkd, and this is causing issues with larger
 deployments.

   * The logs of an affected dhclient produce the following:

 Listening on LPF/enp1s0/52:54:00:1c:d7:00
 Sending on 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

** Tags added: se-sru-sponsor-mfo

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

   * Occasionally, during instance boot or machine start-up,
 dhclient will attempt to acquire a dhcp lease and fail,
 leaving the instance with no IP address and making it
 unreachable.

   * This happens about once every 100 reboots on bare metal,
 or affecting between ~0.3% to 2% of deployments on Azure
 (comment #2).
 
   * Azure uses dhclient called from cloud-init instead of
 systemd-networkd, and this is causing issues with larger
 deployments.

   * The logs of an affected dhclient produce the following:

 Listening on LPF/enp1s0/52:54:00:1c:d7:00
 Sending on   LPF/enp1s0/52:54:00:1c:d7:00
 Sending on   Socket/fallback
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 ...
 (omitting 20 similar lines)
 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 No DHCPOFFERS received.
 No working leases in persistent database - sleeping.

   * This only impacts Focal and Jammy, where bind9-libs
 are multi-threaded (Bionic/earlier and Kinetic/later
 are single-threaded).

   * The actual problem is dhclient containing a thread
 concurrency race condition, and when the race occurs,
 the read socket is incorrectly/prematurely unwatched
 because required structures are not yet consistent,
 thus dhclient does not read any DHCPOFFER replies.

   * Detailed analysis of the issue is in comment #17.

  [Fix]

   * Prevent the race condition by starting to watch the
 read socket after required structures are consistent.
   
   * The fix has been tested in Azure w/ 13500 instances,
 and no errors have been observed (previously: 0.4%).
 
   * Anyway, in case regressions are observed, the patch
 introduces 2 switches to revert to previous behavior,
 which can be applied per-process or system-wide:
 - DHCP_FD_FLAGS_POKE=0 environment variable
 - dhcp.fd_flags_poke=0 kernel cmdline option 
   
   * (Previous approaches/discussions included reverting
  bind9-libs to single-threaded, but we concluded it
  would have more regression risk than the expected
  [some bits in comment #8, and some internal chat],
  and remove exported symbols (apparently unused, but).
  We also considered a mutex/spinlock approach, but
  later found a simpler way w/ isc lib; comment #13.)
  
  [Test Plan]

   * Synthetic reproducer with GDB to force the race
 condition, and DHCP server/client/noise injection
 is described in comment #9.
   
   * Test with the original package (problem occurs).
   
   * Test with the modified package (problem fixed).
 - Set DHCP_FD_FLAGS_POKE=0 (problem occurs).
 - Set dhcp.fd_flags_poke=0 (problem occurs).

  [Regression Potential]

   * 1) dhclient failing to acquire DHCP leases.
  
   * 2) dhcpd is also affected by code changes,
 thus failures to handle DHCP lease requests
 also have potential for regressions.
 
   * 3) the functional change added by the fix,
 if a regression were to occur, would likely
 be an issue only under some (unknown) race
 condition as well, thus expected to be rare.

   * Note: this potentially affects Focal/Jammy 
 on Azure as a whole, per usage of dhclient
 in cloud-init instead of systemd-networkd.
 
 Azure provided extensive testing for all 3
 approaches (mostly internal communications,
 and some bug comments), with ~13k instances.
 
 No issues were observed (previously: 0.4%).
 
   * Such testing scale seems to indicate that
 there are no regressions for dhclient to
 acquire DHCP leases (1), nor another race
 condition that hit the fix/new behavior (3).
 
 With that, apparently (2) should be OK too.
 
   * Also, so to mitigate the regression risk
 as much as possible, there's very detailed
 analysis provided here (comments #17, #18)
 and more information about the fix in its
 patch file's comment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9-libs/+bug/1926139/+subscriptions


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

[Touch-packages] [Bug 1937110] Re: dhcp option 121 & 249

[Mauricio Faria de Oliveira]

Uploaded to Jammy/Focal.

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

Title:
  dhcp option 121 & 249

Status in subiquity:
  New
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

   * DHCP classless static routes aren't applied
 by dhclient at the initramfs (e.g., ip=dhcp).

   * This happens as rfc3442-classless-routes is
 not copied to /etc/dhcp/dhclient-exit-hooks.d/
 in the initramfs.

   * On Jammy, if such DHCP option(s) are present
 in the DHCP server response, the DHCP client
 ignores the 'routers' option from the server,
 thus leaving no routes configured.

   * On Focal, the older code still adds 'routers',
 which is slightly better, but still does not
 add the classless static routes.

  [Test Plan]

   * Use LXD container/VMs for DHCP server/client,
 configure the DHCP server with option 121,
 and some sample classless static routes.
 (see comments #12/jammy and #13/focal).

  [Regression Potential]

   * Acquisition of DHCP leases/routes at initramfs
 with ip=dhcp.

   * The code/script is not new, and is exercised
 normally during on rootfs (ie, post-initramfs)
 when dhclient is run.

   * It's also been in the initramfs in Kinetic
 already, since on Aug 2022; giving it tests.

  [Original Description]
  Hello,

  I'm running into issues with subiquity on a cloud provider.  The cloud
  provider is using an on-link L3 gateway.

  His DHCP response looks like this:

  OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
  OPTION:  54 (  4) Server identifier 172.31.1.1
  OPTION:  51 (  4) IP address leasetime  86400 (24h)
  OPTION:   1 (  4) Subnet mask   255.255.255.255
  OPTION:   3 (  4) Routers   172.31.1.1
  OPTION:   6 ( 12) DNS server
  OPTION: 121 ( 14) Classless Static Route20ac1f010100  ...
   ac1f0101 ..
  OPTION: 249 ( 14) MSFT - Classless route20ac1f010100  ...
   ac1f0101 ..

  Im booting the subiquity process with an patched ipxe
  (https://github.com/ipxe/ipxe/pull/104) like this:

  #!ipxe
  kernel .../vmlinuz initrd=initrd root=/dev/ram0 ramdisk_size=150 ip=dhcp 
url=https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/focal-live-server-amd64.iso
 autoinstall ds=nocloud-net;s=.../...-ad-78/ cloud-config-url=/dev/null
  initrd .../initrd
  boot

  initrd/vmlinuz is extracted right out of focal-live-server-amd64.iso

  Sadly subiquity is stuck with a broken network (because of missing
  dhcp option 121/249 support). It happens when its running the /init
  from the kernel right after kernel is booted, i guess even before the
  subiquity is started(?).

  After further debugging, it looks like the provided kernel 5.4.80 #90
  Ubuntu, is using busybox 1.30.1-4ubuntu~6.3 which includes isc-
  dhclient-4.4.1 which is lacking the given options.

  Would be awesome if this could be fixed.. maybe just a simple busybox
  compile option?

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1937110/+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 1937110] Re: dhcp option 121 & 249

[Mauricio Faria de Oliveira]

Reproducer with DHCP server/client on LXD. [Focal]

Bridge
---

sudo ip link add focalbr type bridge
sudo ip link set focalbr up


LXD container for DHCP server with classless static routes option
---

lxc init ubuntu:focal focal-dhcpd
lxc config device add focal-dhcpd eth0 nic nictype=bridged 
parent=focalbr
lxc config device add focal-dhcpd eth1 nic nictype=bridged parent=lxdbr0

lxc start focal-dhcpd
lxc shell focal-dhcpd

dhclient eth1

...

ip addr add 10.11.12.13/24 dev eth0

apt install -y isc-dhcp-server

echo 'INTERFACESv4="eth0"' >>/etc/default/isc-dhcp-server

cat <>/etc/dhcp/dhcpd.conf
option rfc3442-classless-static-routes code 121 = array of integer 8;

subnet 10.11.12.0 netmask 255.255.255.0 {

  range 10.11.12.100 10.11.12.110;

  option routers 10.11.12.13;

  option rfc3442-classless-static-routes
0,  10, 11, 12, 200,
8,  1,  10, 11, 12, 208,
16, 2, 1,   10, 11, 12, 216,
24, 3, 2, 1,10, 11, 12, 224,
32, 4, 3, 2, 1, 10, 11, 12, 232;
}
EOF

systemctl restart isc-dhcp-server.service


LXD VM for DHCP client
---

lxc init ubuntu:focal focal-dhclient --vm
lxc config device add focal-dhclient eth0 nic nictype=bridged 
parent=focalbr
# no regular lxdbr0 bridge / internet access.

lxc start focal-dhclient
lxc shell focal-dhclient

# ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp5s0:  mtu 1500 qdisc mq state UP 
mode DEFAULT group default qlen 1000
link/ether 00:16:3e:36:6b:c8 brd ff:ff:ff:ff:ff:ff

# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp5s0:  mtu 1500 qdisc mq state UP 
group default qlen 1000
link/ether 00:16:3e:36:6b:c8 brd ff:ff:ff:ff:ff:ff
inet 10.11.12.101/24 brd 10.11.12.255 scope global dynamic enp5s0
   valid_lft 582sec preferred_lft 582sec
inet6 fe80::216:3eff:fe36:6bc8/64 scope link
   valid_lft forever preferred_lft forever

# ip route
default via 10.11.12.200 dev enp5s0 proto dhcp src 10.11.12.101 metric 
100
1.0.0.0/8 via 10.11.12.208 dev enp5s0 proto dhcp src 10.11.12.101 
metric 100
2.1.0.0/16 via 10.11.12.216 dev enp5s0 proto dhcp src 10.11.12.101 
metric 100
3.2.1.0/24 via 10.11.12.224 dev enp5s0 proto dhcp src 10.11.12.101 
metric 100
4.3.2.1 via 10.11.12.232 dev enp5s0 proto dhcp src 10.11.12.101 metric 
100
10.11.12.0/24 dev enp5s0 proto kernel scope link src 10.11.12.101

Ok, all good from booted system's perspective.

Let's check at initramfs time, manually.

The classless routes aren't added if you run dhclient at the current
version.

cat 

[Touch-packages] [Bug 1937110] Re: dhcp option 121 & 249

[Mauricio Faria de Oliveira]

...
-   ac1f0101 ..
+  ac1f0101 ..
  OPTION: 249 ( 14) MSFT - Classless route20ac1f010100  ...
-   ac1f0101 ..
+  ac1f0101 ..
  
- 
- Im booting the subiquity process with an patched ipxe 
(https://github.com/ipxe/ipxe/pull/104) like this:
+ Im booting the subiquity process with an patched ipxe
+ (https://github.com/ipxe/ipxe/pull/104) like this:
  
  #!ipxe
  kernel .../vmlinuz initrd=initrd root=/dev/ram0 ramdisk_size=150 ip=dhcp 
url=https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/focal-live-server-amd64.iso
 autoinstall ds=nocloud-net;s=.../...-ad-78/ cloud-config-url=/dev/null
  initrd .../initrd
  boot
  
  initrd/vmlinuz is extracted right out of focal-live-server-amd64.iso
  
  Sadly subiquity is stuck with a broken network (because of missing dhcp
  option 121/249 support). It happens when its running the /init from the
  kernel right after kernel is booted, i guess even before the subiquity
  is started(?).
  
  After further debugging, it looks like the provided kernel 5.4.80 #90
  Ubuntu, is using busybox 1.30.1-4ubuntu~6.3 which includes isc-
  dhclient-4.4.1 which is lacking the given options.
  
- 
- Would be awesome if this could be fixed.. maybe just a simple busybox compile 
option?
+ Would be awesome if this could be fixed.. maybe just a simple busybox
+ compile option?

** Also affects: isc-dhcp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: isc-dhcp (Ubuntu Focal)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: isc-dhcp (Ubuntu Focal)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: isc-dhcp (Ubuntu Jammy)
   Status: Incomplete => In Progress

** Changed in: isc-dhcp (Ubuntu Jammy)
   Importance: High => Medium

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

Title:
  dhcp option 121 & 249

Status in subiquity:
  New
Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

   * DHCP classless static routes aren't applied
 by dhclient at the initramfs (e.g., ip=dhcp).

   * This happens as rfc3442-classless-routes is
 not copied to /etc/dhcp/dhclient-exit-hooks.d/
 in the initramfs.

   * On Jammy, if such DHCP option(s) are present
 in the DHCP server response, the DHCP client
 ignores the 'routers' option from the server,
 thus leaving no routes configured.

   * On Focal, the older code still adds 'routers',
 which is slightly better, but still does not
 add the classless static routes.

  [Test Plan]

   * Use LXD container/VMs for DHCP server/client,
 configure the DHCP server with option 121,
 and some sample classless static routes.
 (see comments #12/jammy and #13/focal).

  [Regression Potential]

   * Acquisition of DHCP leases/routes at initramfs
 with ip=dhcp.

   * The code/script is not new, and is exercised
 normally during on rootfs (ie, post-initramfs)
 when dhclient is run.

   * It's also been in the initramfs in Kinetic
 already, since on Aug 2022; giving it tests.

  [Original Description]
  Hello,

  I'm running into issues with subiquity on a cloud provider.  The cloud
  provider is using an on-link L3 gateway.

  His DHCP response looks like this:

  OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
  OPTION:  54 (  4) Server identifier 172.31.1.1
  OPTION:  51 (  4) IP address leasetime  86400 (24h)
  OPTION:   1 (  4) Subnet mask   255.255.255.255
  OPTION:   3 (  4) Routers   172.31.1.1
  OPTION:   6 ( 12) DNS server
  OPTION: 121 ( 14) Classless Static Route20ac1f010100  ...
   ac1f0101 ..
  OPTION: 249 ( 14) MSFT - Classless route20ac1f010100  ...
   ac1f0101 ..

  Im booting the subiquity process with an patched ipxe
  (https://github.com/ipxe/ipxe/pull/104) like this:

  #!ipxe
  kernel .../vmlinuz initrd=initrd root=/dev/ram0 ramdisk_size=150 ip=dhcp 
url=https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/focal-live-server-amd64.iso
 autoinstall ds=nocloud-net;s=.../...-ad-78/ cloud-config-url=/dev/null
  initrd .../initrd
  boot

  initrd/vmlinuz is extracted right out of focal-live-server-amd64.iso

  Sadly subiquity is stuck with a broken network (because of missing
  dhcp option 121/249 support). It happens when its running the /init
  from the kernel right after kernel is booted, i guess even before the
  subiquity is started(?).

  After further debugging, it look

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

>From the 'Where problems could occur' section.
Considerations on regressions and approaches.

[Where problems could occur]

isc-dhcp is a core package, and any change comes with the risk that
users would not be able to receive dhcp leases with dhclient, leaving
their systems with no IP address and unreachable, and could potentially
cripple images that depend on it, e.g. Microsoft Azure uses dhclient
called from cloud-init, instead of systemd-networkd, so a regression
could potentially affect all Ubuntu users on Azure.

Additionally, the code is called whenever sockets are constructed, and
isc-dhcp-server could also be affected.

We have mitigated the risks of regression as best as possible by adding
as much detail as possible to this launchpad bug, so it is clear how the
race operates and how the patch fixes the issue.

Mauricio has additionally added a environment variable and a kernel
command line parameter, that when present, disables the fix from
operating. If a regression were to occur, users can add these parameters
to their deployments to work around any issues.

Mauricio and Matthew have decided that the individual fix route is best
in terms of lessening regression risk, as the alternate solution would
be to disable threading on bind9-libs.

Disabling threading on bind9-libs, while complete as a solution, and
removes the risk of a future regression caused by thread concurrency
issues that are currently undetected, comes with the fact that it
removes publicly exported symbols from bind9-libs, and adds others, and
changes the entire library from multithreaded to single threaded. If any
users happen to use bind9-libs outside of isc-dhcp, they would see their
applications either fail to work due to missing symbols, or performance
would change.

Disabling threading on bind9-libs is shelved, and can be looked at in
the future if necessary.

Back to the individual fix solution, Chris Patterson, has been testing
this solution at scale on Azure, and in 13k instances, has not had a
failure. With the gdb reproducer, we are confident that adding the mutex
will not prevent other parts of the software from functioning correctly.



** Description changed:

  [Impact]
  
- Occasionally, during instance boot or machine start-up, dhclient will
- attempt to acquire a dhcp lease and fail, leaving the instance with no
- IP address and making it unreachable.
+  * Occasionally, during instance boot or machine start-up,
+dhclient will attempt to acquire a dhcp lease and fail,
+leaving the instance with no IP address and making it
+unreachable.
  
- This happens about once every 100 reboots on bare metal, or Chris
- Patterson in comment #2 describes it as affecting between ~0.3% to 2% of
- deployments on Microsoft Azure. Azure uses dhclient called from cloud-
- init instead of systemd-networkd, and this is causing issues with larger
- deployments.
+  * This happens about once every 100 reboots on bare metal,
+or affecting between ~0.3% to 2% of deployments on Azure
+(comment #2).
+
+  * Azure uses dhclient called from cloud-init instead of
+systemd-networkd, and this is causing issues with larger
+deployments.
  
- The logs of an affected dhclient produce the following:
+  * The logs of an affected dhclient produce the following:
  
- Listening on LPF/enp1s0/52:54:00:1c:d7:00
- Sending on   LPF/enp1s0/52:54:00:1c:d7:00
- Sending on   Socket/fallback
- DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
- DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
- ...
- (omitting 20 similar lines)
- ...
- DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
- DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
- DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
- No DHCPOFFERS received.
- No working leases in persistent database - sleeping.
+Listening on LPF/enp1s0/52:54:00:1c:d7:00
+Sending on   LPF/enp1s0/52:54:00:1c:d7:00
+Sending on   Socket/fallback
+DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
+DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
+...
+(omitting 20 similar lines)
+...
+DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
+DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
+DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
+No DHCPOFFERS received.
+No working leases in persistent database - sleeping.
  
- Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
- Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/
+  * This only impacts Focal and Jammy, where bind9-libs
+are multi-threaded (Bionic/earlier and Kinetic/later
+are single-threaded).
  
- The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
- packets being replied to with DHCPOFFER packets, but the got_one()
- callback is never called, dhclient does not read these DHCPOFFER
- packets, 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

From the 'Other Info' section.
Detailed analysis of the issue and more.

[Other Info]

Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

When you tcpdump dhclient, we see all DHCPDISCOVER packets being replied
to with DHCPOFFER packets, but the got_one() callback is never called,
dhclient does not read these DHCPOFFER packets, and continues sending
DHCPDISCOVER packets. Once it reaches 25 DHCPDISCOVER packets sent, it
gives up.

This behaviour led several bug reporters to believe it was a kernel
issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
is not the case, the actual problem is dhclient containing a thread
concurrency race condition, and when the race occurs, the read socket is
closed prematurely, and dhclient does not read any of the DHCPOFFER
replies.

tcpdump: 'Screenshot of Wireshark' attached.

...

I was reading around the upstream issue trackers, and found the
following two bug reports:

https://gitlab.isc.org/isc-projects/dhcp/-/issues/264
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996356

The ISC upstream report was actually quite detailed, and it has the same
symptoms of what we are experiencing.

Let's have a look at the root cause. The code I am using is isc-dhcp
4.4.1-2.1ubuntu5.20.04.4 from Focal.

common/discover.c

 567 void
 568 discover_interfaces(int state) {
...
1002 case AF_INET:
1003 default:
1004 status = omapi_register_io_object((omapi_object_t *)tmp,
1005   if_readsocket,
1006   0, got_one, 0, 0);
1007 break;
1008 }
...

In discover.c, we call discover_interfaces() to iterate over the
interfaces, and attempt to register a raw socket against it. We do this
by calling omapi_register_io_object() which is used for reading data,
and calls the elusive got_one() callback that you instrumented your code
to see if it was being called or not.

omapip/dispatch.c

196 /* Register an I/O handle so that we can do asynchronous I/O on it. */
197
198 isc_result_t omapi_register_io_object (omapi_object_t *h,
199int (*readfd) (omapi_object_t *),
200int (*writefd) (omapi_object_t *),
201isc_result_t (*reader)
202 (omapi_object_t *),
203isc_result_t (*writer)
204 (omapi_object_t *),
205isc_result_t (*reaper)
206 (omapi_object_t *))
207 {
...
241 /*
242  * Attach the I/O object to the isc socket library via the
243  * fdwatch function.  This allows the socket library to watch
244  * over a socket that we built.  If there are both a read and
245  * a write socket we asssume they are the same socket.
246  */
247
248 if (readfd) {
249 fd_flags |= ISC_SOCKFDWATCH_READ;
250 fd = readfd(h);
251 }
...
257
258 if (fd_flags != 0) {
259 status = isc_socket_fdwatchcreate(dhcp_gbl_ctx.socketmgr,
260   fd, fd_flags,
261   omapi_iscsock_cb,
262   obj,
263   dhcp_gbl_ctx.task,
264   >fd);
...
275 }
276
277
278 /* Find the last I/O state, if there are any. */
279 for (p = omapi_io_states.next;
280  p && p -> next; p = p -> next)
281 ;
282 if (p)
283 omapi_io_reference ( -> next, obj, MDL);
284 else
285 omapi_io_reference (_io_states.next, obj, MDL);
...

omapi_register_io_object() is called for each socket created, in this
case, the if_readsocket from discover_interfaces(). The file descriptor
is assigned ISC_SOCKFDWATCH_READ, and we enter the if statement.

The if statement calls isc_socket_fdwatchcreate(), which registers the
socket with the ISC socket manager, and sets up the callback
omapi_iscsock_cb(), to be called.

Once that has been done, we iterate over the omapi_io_states linked
list, which is a global list of registered sockets. We get to the end of
the list (or the beginning, if the list is empty), and add the socket to
the list.

Now, the bug happens between calling isc_socket_fdwatchcreate() to
register the socket with the socket manager, and adding it to the global
linked list.

Sometimes, the callback omapi_iscsock_cb() is called inbetween.

omapip/dispatch.c

101 /*
102  * Callback routine to connect the omapi I/O object and socket with
103  * the isc socket code.  The isc socket code will call this routine
104  * which will then call the correct local routine to process the bytes.
105  *
106  * Currently we are always willing to read more data, this should be 
modified
107  * so that on connections we don't read more if we already have enough.
108  *
109  * If we have more bytes to write we ask the library to call us when
110  * we can write more.  If we indicate we don't have more to write 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

Pressing Page Down 17 times to go over the bug description sounds like a
new record! ;-)

Just in case future reviewers don't find that as exciting while going
through reviews, I'll move some text into comments and reference them
from the description.

** Bug watch added: gitlab.isc.org/isc-projects/dhcp/-/issues #264
   https://gitlab.isc.org/isc-projects/dhcp/-/issues/264

** Bug watch added: Debian Bug tracker #996356
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996356

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

   * Occasionally, during instance boot or machine start-up,
 dhclient will attempt to acquire a dhcp lease and fail,
 leaving the instance with no IP address and making it
 unreachable.

   * This happens about once every 100 reboots on bare metal,
 or affecting between ~0.3% to 2% of deployments on Azure
 (comment #2).
 
   * Azure uses dhclient called from cloud-init instead of
 systemd-networkd, and this is causing issues with larger
 deployments.

   * The logs of an affected dhclient produce the following:

 Listening on LPF/enp1s0/52:54:00:1c:d7:00
 Sending on   LPF/enp1s0/52:54:00:1c:d7:00
 Sending on   Socket/fallback
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 ...
 (omitting 20 similar lines)
 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 ...
 No DHCPOFFERS received.
 No working leases in persistent database - sleeping.

   * This only impacts Focal and Jammy, where bind9-libs
 are multi-threaded (Bionic/earlier and Kinetic/later
 are single-threaded).

   * The actual problem is dhclient containing a thread
 concurrency race condition, and when the race occurs,
 the read socket is incorrectly/prematurely unwatched
 because required structures are not yet consistent,
 thus dhclient does not read any DHCPOFFER replies.

   * Detailed analysis of the issue is in comment #17.

  [Fix]

   * Prevent the race condition by starting to watch the
 read socket after required structures are consistent.
   
   * The fix has been tested in Azure w/ 13500 instances,
 and no errors have been observed (previously: 0.4%).
 
   * Anyway, in case regressions are observed, the patch
 introduces 2 switches to revert to previous behavior,
 which can be applied per-process or system-wide:
 - DHCP_FD_FLAGS_POKE=0 environment variable
 - dhcp.fd_flags_poke=0 kernel cmdline option 
   
   * (Previous approaches/discussions included reverting
  bind9-libs to single-threaded, but we concluded it
  would have more regression risk than the expected
  [some bits in comment #8, and some internal chat],
  and remove exported symbols (apparently unused, but).
  We also considered a mutex/spinlock approach, but
  later found a simpler way w/ isc lib; comment #13.)
  
  [Test Plan]

   * Synthetic reproducer with GDB to force the race
 condition, and DHCP server/client/noise injection
 is described in comment #9.
   
   * Test with the original package (problem occurs).
   
   * Test with the modified package (problem fixed).
 - Set DHCP_FD_FLAGS_POKE=0 (problem occurs).
 - Set dhcp.fd_flags_poke=0 (problem occurs).

  [Regression Potential]

   * 1) dhclient failing to acquire DHCP leases.
  
   * 2) dhcpd is also affected by code changes,
 thus failures to handle DHCP lease requests
 also have potential for regressions.
 
   * 3) the functional change added by the fix,
 if a regression were to occur, would likely
 be an issue only under some (unknown) race
 condition as well, thus expected to be rare.

   * Note: this potentially affects Focal/Jammy 
 on Azure as a whole, per usage of dhclient
 in cloud-init instead of systemd-networkd.
 
 Azure provided extensive testing for all 3
 approaches (mostly internal communications,
 and some bug comments), with ~13k instances.
 
 No issues were observed (previously: 0.4%).
 
   * Such testing scale seems to indicate that
 there are no regressions for dhclient to
 acquire DHCP leases (1), nor another race
 condition that hit the fix/new behavior (3).
 
 With that, apparently (2) should be OK too.
 
   * Also, so to mitigate the regression risk
 as 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

Jammy/22.04:
- test packages in ppa:mfo/lp1926139
- reproduction steps delta (based on comment #9)

...

Reproducer based on GDB and DHCP noise injection.

It uses 3 veth pairs (DHCP server/client/injector,
the latter two under namespaces) on a linux bridge.

...

LXD VM:

 lxc launch ubuntu:jammy lp1926139-jammy --vm
 lxc shell lp1926139-jammy

GDB Reproducer (original package):
==

Debug symbols:

 # wget 
https://launchpad.net/ubuntu/+archive/primary/+files/isc-dhcp-client-dbgsym_4.4.1-2.3ubuntu2.3_amd64.ddeb
 # apt install -y ./isc-dhcp-client-dbgsym_4.4.1-2.3ubuntu2.3_amd64.ddeb

Source code line numbers (for breakpoint):

 198 isc_result_t omapi_register_io_object (omapi_object_t *h,
 ...
 259 status = isc_socket_fdwatchcreate(dhcp_gbl_ctx.socketmgr,
 ...
 279 for (p = omapi_io_states.next;

Attempt to reproduce the issue
with a delay introduced via breakpoint on line 279:

 # ip netns exec ns1 \
   gdb -ex 'set target-async on' -ex 'set non-stop on' -ex 'set pagination off' 
-ex 'set confirm off' -q dhclient

 (gdb) break omapip/dispatch.c:279
 (gdb) commands
 shell sleep 0.2
 continue
 end
 (gdb) run -v -d veth1

GDB Reproducer (patched package):
==

Client & Debug symbols:

 # wget \
   
https://launchpad.net/~mfo/+archive/ubuntu/lp1926139/+files/isc-dhcp-client_4.4.1-2.3ubuntu2.3+lp1926139.2_amd64.deb
 \
   
https://launchpad.net/~mfo/+archive/ubuntu/lp1926139/+files/isc-dhcp-client-dbgsym_4.4.1-2.3ubuntu2.3+lp1926139.2_amd64.ddeb

  # sudo apt install \
 ./isc-dhcp-client_4.4.1-2.3ubuntu2.3+lp1926139.2_amd64.deb \
 ./isc-dhcp-client-dbgsym_4.4.1-2.3ubuntu2.3+lp1926139.2_amd64.ddeb

Source code line numbers (for breakpoint):

  233 isc_result_t omapi_register_io_object (omapi_object_t *h,
 ...
  312 status = isc_socket_fdwatchcreate(dhcp_gbl_ctx.socketmgr,
 ...
  333 for (p = omapi_io_states.next;

Attempt to reproduce the issue again, the same way,
with a delay introduced via breakpoint on line 333:

 # ip netns exec ns1 \
   gdb -ex 'set target-async on' -ex 'set non-stop on' -ex 'set pagination off' 
-ex 'set confirm off' -q dhclient

 (gdb) break omapip/dispatch.c:333
 (gdb) commands
 shell sleep 0.2
 continue
 end
 (gdb) run -v -d veth1

...

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump:
  Screenshot of Wireshark:

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix is to
  add a mutex that restricts access to the global linked list of open
  sockets, and ensures that a newly created socket is added to 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

** Patch added: "lp1926139_focal_isc-dhcp_v2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5643626/+files/lp1926139_focal_isc-dhcp_v2.debdiff

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump:
  Screenshot of Wireshark:

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix is to
  add a mutex that restricts access to the global linked list of open
  sockets, and ensures that a newly created socket is added to this
  list, before the socketmanager callback has an opportunity to walk
  this list when there is data immediately able to be read.

  Mauricio has provided such a patch, and includes options to disable
  this behaviour during runtime to minimise regression risk.

  [Testcase]

  Reproducer based on GDB and DHCP noise injection.

  It uses 3 veth pairs (DHCP server/client/injector,
  the latter two under namespaces) on a linux bridge.

  LXD VM:

   $ lxc launch ubuntu:focal lp1926139-focal --vm
   $ lxc shell lp1926139-focal

  Network Setup:

   # ip link add br0 type bridge
   # ip link set br0 up

   # ip link add veth0 type veth peer name veth0br
   # ip link set veth0 up
   # ip link set veth0br up master br0

   # ip netns add ns1
   # ip link add veth1 netns ns1 type veth peer name veth1br
   # ip -n ns1 link set veth1 up
   # ip link set veth1br up master br0

   # ip netns add ns2
   # ip link add veth2 netns ns2 type veth peer name veth2br
   # ip -n ns2 link set veth2 up
   # ip link set veth2br up master br0

  Network Check:

   # ip link show type veth | grep veth
   5: veth0br@veth0:  mtu 1500 qdisc noqueue 
master br0 state UP mode DEFAULT group default qlen 1000
   6: veth0@veth0br:  mtu 1500 qdisc noqueue 
state UP mode DEFAULT group default qlen 1000
   7: veth1br@if2:  mtu 1500 qdisc noqueue 
master br0 state UP mode DEFAULT group default qlen 1000
   8: veth2br@if2:  mtu 1500 qdisc noqueue 
master br0 state UP mode DEFAULT group default qlen 1000

   # ip -n ns1 link show type veth | grep veth
   2: veth1@if7:  mtu 1500 qdisc noqueue state 
UP mode DEFAULT group default qlen 1000

   # ip -n ns2 link show type veth | grep veth
   2: veth2@if8:  mtu 1500 qdisc noqueue state 
UP mode DEFAULT group default qlen 1000

  DHCP Server Setup:

   # apt install -y isc-dhcp-server

   # ip addr add 192.168.42.1/24 dev veth0

   # echo 'INTERFACESv4="veth0"' >>/etc/default/isc-dhcp-server

   # cat <>/etc/dhcp/dhcpd.conf
   subnet 192.168.42.0 netmask 255.255.255.0 {
 range 192.168.42.100 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

Test packages:

https://launchpad.net/~mfo/+archive/ubuntu/lp1926139
isc-dhcp 4.4.1-2.1ubuntu5.20.04.4+lp1926139.2 

Default behavior: issue fixed.
---

(gdb) break omapip/dispatch.c:333
(gdb) commands
shell sleep 0.2
continue
end

(gdb) run -d -v veth1
...
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 
(xid=0x9679b264)
DHCPOFFER of 192.168.42.100 from 192.168.42.1
DHCPREQUEST for 192.168.42.100 on veth1 to 255.255.255.255 port 67 
(xid=0x64b27996)
DHCPACK of 192.168.42.100 from 192.168.42.1 (xid=0x9679b264)
...
^C
(gdb) kill

Release address.

(gdb) run -d -v veth1 -r
...


Original behavior with environment variable: issue observed.
---

(gdb) set environment DHCP_FD_FLAGS_POKE 0
(gdb) run -d -v veth1
...
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 
(xid=0xc2db3363)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 5 
(xid=0xc2db3363)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 5 
(xid=0xc2db3363)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 6 
(xid=0xc2db3363)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 16 
(xid=0xc2db3363)
^C
...
(gdb) kill

(gdb) unset environment DHCP_FD_FLAGS_POKE


Original behavior with kernel cmdline option: issue observed.
---

(gdb) shell echo "$(cat /proc/cmdline) dhcp.fd_flags_poke=0" 
>/tmp/cmdline
(gdb) shell mount --bind /tmp/cmdline /proc/cmdline
(gdb) shell cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.4.0-1084-kvm 
root=PARTUUID=a1286399-334e-4597-b30f-da227b6c076b ro console=tty1 
console=ttyS0 panic=-1 dhcp.fd_flags_poke=0

(gdb) run -d -v veth1
...
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 
(xid=0x938a6b0b)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 4 
(xid=0x938a6b0b)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 8 
(xid=0x938a6b0b)
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 20 
(xid=0x938a6b0b)
^C
...
(gdb) kill

(gdb) shell umount /proc/cmdline

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump:
  Screenshot of Wireshark:

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix is to
  add a mutex that restricts access to the global linked 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

Hey Matthew, Chris,

Apparently there's a simpler, less intrusive, and more specific way to
do this.

Apologies that I missed this earlier, but I found more about the
possibilities in bind9-libs functions while checking the previous fix
approach for regressions.

Could you please provide your thoughts, Matthew?

If it looks good for you, please feel free to discuss additional testing
with Chris, if at all possible.

P.S.: the workaround disable switches are in, via environment variable
and kernel cmdline option.

Thanks!
Mauricio

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump:
  Screenshot of Wireshark:

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix is to
  add a mutex that restricts access to the global linked list of open
  sockets, and ensures that a newly created socket is added to this
  list, before the socketmanager callback has an opportunity to walk
  this list when there is data immediately able to be read.

  Mauricio has provided such a patch, and includes options to disable
  this behaviour during runtime to minimise regression risk.

  [Testcase]

  Reproducer based on GDB and DHCP noise injection.

  It uses 3 veth pairs (DHCP server/client/injector,
  the latter two under namespaces) on a linux bridge.

  LXD VM:

   $ lxc launch ubuntu:focal lp1926139-focal --vm
   $ lxc shell lp1926139-focal

  Network Setup:

   # ip link add br0 type bridge
   # ip link set br0 up

   # ip link add veth0 type veth peer name veth0br
   # ip link set veth0 up
   # ip link set veth0br up master br0

   # ip netns add ns1
   # ip link add veth1 netns ns1 type veth peer name veth1br
   # ip -n ns1 link set veth1 up
   # ip link set veth1br up master br0

   # ip netns add ns2
   # ip link add veth2 netns ns2 type veth peer name veth2br
   # ip -n ns2 link set veth2 up
   # ip link set veth2br up master br0

  Network Check:

   # ip link show type veth | grep veth
   5: veth0br@veth0:  mtu 1500 qdisc noqueue 
master br0 state UP mode DEFAULT group default qlen 1000
   6: veth0@veth0br:  mtu 1500 qdisc noqueue 
state UP mode DEFAULT group default qlen 1000
   7: veth1br@if2:  mtu 1500 qdisc noqueue 
master br0 state UP mode DEFAULT group default qlen 1000
   8: veth2br@if2:  mtu 1500 qdisc noqueue 
master br0 state UP mode DEFAULT group default qlen 1000

   # ip -n ns1 link show type veth | grep veth
   2: veth1@if7:  mtu 1500 qdisc noqueue state 
UP mode DEFAULT group default qlen 1000

   # ip -n ns2 link show type veth | grep veth
   2: 

[Touch-packages] [Bug 1996619] Re: Setfont error due to deprecated PIO_FONTX ioctl

[Mauricio Faria de Oliveira]

For documentation purposes.

The autopkgtests failures for systemd were unrelated to this
(not regressions).

I checked their logs and reran with the migration-reference/0
trigger so not to use kbd from -proposed; that failed as well.

The pending SRU and update-excuses pages no longer show kbd
blocked on the autopkgtests failures.

https://people.canonical.com/~ubuntu-archive/pending-sru.html
https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#kbd
https://people.canonical.com/~ubuntu-archive/proposed-migration/kinetic/update_excuses.html#kbd

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

Title:
  Setfont error due to deprecated PIO_FONTX ioctl

Status in subiquity:
  Invalid
Status in kbd package in Ubuntu:
  Fix Released
Status in kbd source package in Jammy:
  Fix Committed
Status in kbd source package in Kinetic:
  Fix Committed

Bug description:
  [Impact]

  There is an error message that get thrown in in syslog.
  There is a suggestion to fix by upgrading the KDB package to version 2.5.1+ 
(upstream) has a fix.

  It is caused by this line in subiquity
  
https://github.com/canonical/subiquity/blob/46f671d14d57a5da6bc3d60b1da6715b43954f0d/bin/subiquity-service#L11

  It's due to PIO_FONTX ioctl removed from kernel since 5.12
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff2047fb755d4415ec3c70ac799889371151796d

  In 2.4.5 of kbd which provide setfont in user space, they already
  switched over to use KDFONTOP only.

  [ Test Plan ]

  ### REPRODUCER STEPS ###

  # install libvirt
  sudo apt install qemu qemu-kvm libvirt-clients libvirt-daemon-system virtinst 
bridge-utils

  sudo systemctl enable libvirtd
  sudo systemctl start libvirtd

  # check libvirtd process is running
  virsh
  virsh list

  # get iso
  wget https://releases.ubuntu.com/22.04/ubuntu-22.04.1-live-server-amd64.iso

  # install vm
  sudo virt-install --cdrom='./ubuntu-22.04.1-live-server-amd64.iso'  
--name=setfont-repo --vcpus=2 --memory=2048 --disk size=20 --serial pty 
--graphics none --boot=uefi --debug

  # you can either do the full install,
  the error will be in the /var/log/installer.log file

  # or on the first page of the installer press Tab-> go to Help, -> Shell
  and cd /var/log/
  grep setfont* syslog

  # to show error message cd to
  /snap/subiquity/3698

  #execute
  setfont $SNAP/subiquity.psf

  # error
  root@ubuntu-server:/snap/subiquity/3698# setfont $SNAP/subiquity.psf
  setfont: ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: 
failed: Inappropriate ioctl for device

  # grep
  grep setfont* syslog
  Nov 14 18:22:11 ubuntu-server console-setup.sh[1107]: setfont: ERROR 
kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: 
Inappropriate ioctl for device
  Nov 14 18:22:29 ubuntu-server subiquity.subiquity-service[1878]: setfont: 
ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: 
Inappropriate ioctl for device

  [ Where problems could occur ]

  There could be a failure to correctly parse fonts.
  https://man7.org/linux/man-pages/man8/setfont.8.html

  [Other Notes]

  # github link to upstream repo & commit
  https://github.com/legionus/kbd
  
https://github.com/legionus/kbd/commit/2b68ba3ef22e6f68dcd9dc5c7fc47f72761f3764

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1996619/+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 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

** Patch added: "lp1926139_focal_isc-dhcp.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5642442/+files/lp1926139_focal_isc-dhcp.debdiff

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in bind9-libs source package in Focal:
  In Progress
Status in bind9-libs source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump: 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641810/+files/test.pcap
  Screenshot of Wireshark: 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641811/+files/Screenshot_2023-01-17-16-14-21_1920x1200%250A1920x1080%250A1920x1080.png

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix for
  this is to change bind9-libs from being built multithreaded, back to
  single threaded as intended by dhclient maintainers.

  In Focal and Jammy, isc-dhcp links against bind9 libraries provided in
  bind9-libs, while in Kinetic onward isc-dhcp has an in-tree bind9
  library it uses, which is already configured properly to --disable-
  threads.

  Change the Focal and Jammy bind9-libs to --disable-threads and update
  symbol files to reflect the library is single threaded again.

  [Testcase]

  Start a fresh Focal or Jammy instance.

  Download and set executable test-parallel.sh, and edit some lines:

  1) wget 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5593045/+files/test-parallel.sh
  2) chmod +x test-parallel.sh
  3) vim test-parallel.sh

  Change iface="enp5s0" to your interface, likely iface="enp1s0".
  Comment out the line "#   cp bionic-dhclient $workdir/dhclient".

  4) sudo ./test-parallel.sh

  After five minutes, if you issue reproduces, you will see "TEST
  FAILED".

  You can watch the output with:

  5) cat /tmp/dhclient-* | less

  Next, for instrumented runs, you need to build dhclient from source.

  1) sudo apt install build-essential devscripts
  2) apt source isc-dhcp
  3) sudo apt build-dep isc-dhcp
  4) cd isc-dhcp

  Apply the below patch:

  https://paste.ubuntu.com/p/hGsssrVyG4/

  5) patch -p1 < ~/patch.patch
  6) debuild -b -uc -us
  7) cd ..
  8) sudo dpkg -i isc-dhcp-client-*
  9) sudo ./test-parallel.sh
  10) cat /tmp/dhclient-* | less

  Look for the race, as described in "Other Info", namely:

  mruffell: registering with socket manager
  mruffell: callback called
  mruffell: omapi object is NULL
  mruffell: omapi object is NULL
  mruffell: Adding obj to linked list
  mruffell: Obj added to list

  The issue has reproduced.

  If you install the test package from the following ppa:

  

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

Hi Matthew,

Thanks for the excellent analysis and considerate fix proposal, as
always!

I looked at this for the last couple of days, for potential sponsorship.

I have attentively gone through the SRU template and Other Info section,
and considered the proposal to switch bind9-libs into --disable-threads,
with the goal of not only address this issue, but also prevent others:

> So, we have two options for a fix for Focal and Jammy:
> 
> 1) We disable threading for dhclient.
> 2) We add in a mutex to resolve this particular concurrency issue.
> [...]
> I think if we fix the problem, another issue will crop up in six months
> time, and it will be another concurrency issue.

...

I'm aware you realize such change is concerning :) thus explained it
well.

Changing this is Focal (around for almost 3 years) brings regression risk
to an amount I have the _impression_ the SRU team would not be okay with.

And even though I agree with your analysis, proposal and risk assessment,
I'm a bit concerned too, specially as this touches DHCP / IP addressing.

(I'm also very aware this is ultimately their call, not mine at all. :)

...

However, considering how much work and time have likely gone into this
(and internal status) I can't just say 'no' without trying to help out.

I'd like to bring a different opinion.

The reason it's concerning is the very same reason 2) is reasonable:

This concurrency issue (and potential for other concurrency issues)
has been around with Focal since 2020/04 (~3 years), and until now,
its impact does not seem to statistically significant:

> This happens about once every 100 reboots on bare metal, or [...]
> affecting between ~0.3% to 2% of deployments on Microsoft Azure.

So, if there's a way to fix this particular concurrency issue with
less regression risk, that might be worth it, as it would build on
top of dhclient's life on Focal, instead of starting it over again.

...

So, while reviewing the source code for your analysis, I had ideas.

First, a synthetic reproducer with GDB that works every time.

Second, a patch that addressed the issue with the test above.
(It's not final form, I'd like to add a way to turn it off.)

...

Could you please review and verify both, and share your 
thoughts on possibly going with that proposal instead?

Of course, if you disagree with the argument or approach,
or if turns out not to work on your end/tests, that's OK!

We would defer this to the Foundations team and SRU team.

- Test steps in the next comment.
- Test packages in ppa:mfo/lp1926139 [1].
- Debdiff attached for reference (code has details).

(Right now only Focal patches/packages are available.
I can go look at Jammy depending on your feedback.)

Hope this helps, after all.
Thanks again!

[1] https://launchpad.net/~mfo/+archive/ubuntu/lp1926139

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in bind9-libs source package in Focal:
  In Progress
Status in bind9-libs source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump: 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

Reproducer based on GDB and DHCP noise injection.

It uses 3 veth pairs (DHCP server/client/injector,
the latter two under namespaces) on a linux bridge.

LXD VM:

$ lxc launch ubuntu:focal lp1926139-focal --vm
$ lxc shell lp1926139-focal

Network Setup:

# ip link add br0 type bridge
# ip link set br0 up

# ip link add veth0 type veth peer name veth0br
# ip link set veth0 up
# ip link set veth0br up master br0

# ip netns add ns1
# ip link add veth1 netns ns1 type veth peer name veth1br
# ip -n ns1 link set veth1 up
# ip link set veth1br up master br0

# ip netns add ns2
# ip link add veth2 netns ns2 type veth peer name veth2br
# ip -n ns2 link set veth2 up
# ip link set veth2br up master br0

Network Check:

# ip link show type veth | grep veth
5: veth0br@veth0:  mtu 1500 qdisc 
noqueue master br0 state UP mode DEFAULT group default qlen 1000
6: veth0@veth0br:  mtu 1500 qdisc 
noqueue state UP mode DEFAULT group default qlen 1000
7: veth1br@if2:  mtu 1500 qdisc 
noqueue master br0 state UP mode DEFAULT group default qlen 1000
8: veth2br@if2:  mtu 1500 qdisc 
noqueue master br0 state UP mode DEFAULT group default qlen 1000

# ip -n ns1 link show type veth | grep veth
2: veth1@if7:  mtu 1500 qdisc noqueue 
state UP mode DEFAULT group default qlen 1000

# ip -n ns2 link show type veth | grep veth
2: veth2@if8:  mtu 1500 qdisc noqueue 
state UP mode DEFAULT group default qlen 1000

DHCP Server Setup:

# apt install -y isc-dhcp-server

# ip addr add 192.168.42.1/24 dev veth0

# echo 'INTERFACESv4="veth0"' >>/etc/default/isc-dhcp-server

# cat <>/etc/dhcp/dhcpd.conf
subnet 192.168.42.0 netmask 255.255.255.0 {
  range 192.168.42.100 192.168.42.200;
}
EOF

# systemctl restart isc-dhcp-server.service
# systemctl status isc-dhcp-server.service | grep Active:
 Active: active (running) since Thu 2023-01-19 02:06:18 UTC; 19s ago

# ss -nlp | grep 0.0.0.0:67
udp UNCONN   00 
0.0.0.0:67 0.0.0.0:*
 users:(("dhcpd",pid=3279,fd=9))

DHCP Server Check:

# ip netns exec ns1 \
  dhclient -v veth1
...
DHCPDISCOVER on veth1 to 255.255.255.255 port 67 interval 3 
(xid=0xd147ab17)
DHCPOFFER of 192.168.42.100 from 192.168.42.1
DHCPREQUEST for 192.168.42.100 on veth1 to 255.255.255.255 port 67 
(xid=0x17ab47d1)
DHCPACK of 192.168.42.100 from 192.168.42.1 (xid=0xd147ab17)
bound to 192.168.42.100 -- renewal in 245 seconds.

# ip netns exec ns1 \
  dhclient -v veth1 -r
...
DHCPRELEASE of 192.168.42.100 on veth1 to 192.168.42.1 port 67 
(xid=0x1cd4aacf)

DHCP Noise Setup:

# ip -n ns2 addr add 192.168.42.2/24 dev veth2

# ip netns exec ns2 \
  /bin/sh -c 'while sleep 0.1; do echo; done | nc -u -v -b -s 
192.168.42.2 -p 67 255.255.255.255 68' &
Connection to 255.255.255.255 68 port [udp/bootpc] succeeded!

i.e., every 0.1 seconds, broadcast a message as DHCP (port 67)
to DHCP client receive (port 68).

DHCP Noise Check:

# tcpdump -i veth0 -n 'udp and host 255.255.255.255' -c 10
...
02:13:26.993233 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.098317 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.205879 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.314234 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.424486 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.532431 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.639614 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.747633 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.864037 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
02:13:27.977402 IP 192.168.42.2.67 > 255.255.255.255.68: BOOTP/DHCP, 
unknown (0x0a) [|bootp]
...

GDB Reproducer (original package):
==

# apt install -y gdb

Capture DHCP Server's UDP packets for reference:

# tcpdump -i veth0 -n 'udp and host 192.168.42.1' -w 
veth0-udp-192-168-42-1.pcap & pid=$!

Debug symbols:

# wget 
https://launchpad.net/ubuntu/+archive/primary/+files/isc-dhcp-client-dbgsym_4.4.1-2.1ubuntu5.20.04.4_amd64.ddeb
# apt install -y 

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

[Mauricio Faria de Oliveira]

** Tags removed: sts-sponsor

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

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in bind9-libs source package in Focal:
  In Progress
Status in bind9-libs source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump: 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641810/+files/test.pcap
  Screenshot of Wireshark: 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641811/+files/Screenshot_2023-01-17-16-14-21_1920x1200%250A1920x1080%250A1920x1080.png

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix for
  this is to change bind9-libs from being built multithreaded, back to
  single threaded as intended by dhclient maintainers.

  In Focal and Jammy, isc-dhcp links against bind9 libraries provided in
  bind9-libs, while in Kinetic onward isc-dhcp has an in-tree bind9
  library it uses, which is already configured properly to --disable-
  threads.

  Change the Focal and Jammy bind9-libs to --disable-threads and update
  symbol files to reflect the library is single threaded again.

  [Testcase]

  Start a fresh Focal or Jammy instance.

  Download and set executable test-parallel.sh, and edit some lines:

  1) wget 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5593045/+files/test-parallel.sh
  2) chmod +x test-parallel.sh
  3) vim test-parallel.sh

  Change iface="enp5s0" to your interface, likely iface="enp1s0".
  Comment out the line "#   cp bionic-dhclient $workdir/dhclient".

  4) sudo ./test-parallel.sh

  After five minutes, if you issue reproduces, you will see "TEST
  FAILED".

  You can watch the output with:

  5) cat /tmp/dhclient-* | less

  Next, for instrumented runs, you need to build dhclient from source.

  1) sudo apt install build-essential devscripts
  2) apt source isc-dhcp
  3) sudo apt build-dep isc-dhcp
  4) cd isc-dhcp

  Apply the below patch:

  https://paste.ubuntu.com/p/hGsssrVyG4/

  5) patch -p1 < ~/patch.patch
  6) debuild -b -uc -us
  7) cd ..
  8) sudo dpkg -i isc-dhcp-client-*
  9) sudo ./test-parallel.sh
  10) cat /tmp/dhclient-* | less

  Look for the race, as described in "Other Info", namely:

  mruffell: registering with socket manager
  mruffell: callback called
  mruffell: omapi object is NULL
  mruffell: omapi object is NULL
  mruffell: Adding obj to linked list
  mruffell: Obj added to list

  The issue has reproduced.

  If you install the test package from the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf337873-test

  Instructions to install (on a Focal or Jammy system):
  1) sudo add-apt-repository 

[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem

[Mauricio Faria de Oliveira]

Hi. No, I haven't tested on that; but if this helps, the issue is
independent of platform/hypervisor as it's in ufw/firewall, thus the fix
should help anyway.

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

Title:
  ufw breaks boot on network root filesystem

Status in ufw:
  Fix Committed
Status in ufw package in Ubuntu:
  Fix Released
Status in ufw source package in Bionic:
  Fix Released
Status in ufw source package in Focal:
  Fix Released
Status in ufw source package in Hirsute:
  Fix Released
Status in ufw source package in Impish:
  Fix Released

Bug description:
  [Impact]

  A system with rootfs on iSCSI stops booting when ufw.service starts.
  The kernel logs iSCSI command/reset timeout until I/O fails and the
  root filesystem/journal break.

  The issue is that ufw_start() sets the default policy _first_, then
  adds rules _later_.

  So, a default INPUT policy of DROP (default setting in ufw) prevents
  further access to the root filesystem (blocks incoming iSCSI traffic)
  thus any rules that could help are not loaded (nor anything else.)

  [Fix]

  The fix is to set default policy after loading rules in ufw_start().
  That seems to be OK as `ip[6]tables-restore -n/--noflush` is used,
  and per iptables source, that only sets the chain policy.

  This allows the system to boot due to the RELATED,ESTABLISHED rule,
  that is introduced by before.rules in INPUT/ufw-before-input chain.

  The comparison of `iptables -L` before/after shows no differences
  (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors.

  [Test Steps]

   * Install Ubuntu on an iSCSI (or other network-based) root filesystem.
     (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.)

   * sudo ufw enable

   * Observed: system may stall immediately if no prior iptables rules.
     (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT)

   * Expected: system continues working.

   * sudo reboot

   * Observed: system boot stalls once ufw.service starts (see below.)
   * Expected: system boot should move on.

  [Regression Potential]

   * Potential regressions would be observed on ufw start/reload,
     when iptables rules are configured.

   * The resulting iptables configuration has been compared
     before/after the change, with identical rules on both.

  [Other Info]

   * Fixed in Debian and Jammy.

  [ufw info]

  # ufw --version
  ufw 0.36
  Copyright 2008-2015 Canonical Ltd.

  # lsb_release -cs
  focal

  [Boot Log]

  [ 232.168355] iBFT detected.
  Begin: Running /scripts/init-premount ... done.
  Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
  Setting up software interface enp45s0f0np0
  ...
  [ 254.644505] Loading iSCSI transport class v2.0-870.
  [ 254.714938] iscsi: registered transport (tcp)
  [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP
  ...
  [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 
GB/120 GiB)
  ...
  [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. 
Opts: (null)
  ...
  [ 266.620860] systemd[1]: Starting Uncomplicated firewall...
  Starting Uncomplicated firewall...
  ...
  [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 
timedout
  [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 
timedout
  [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696
  [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13]
  [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout
  [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 
timedout
  [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh
  [ 314.107541] session1: iscsi_tmf_timedout tmf timedout
  [ 314.169797] connection1:0: detected conn error (1021)
  [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 
0x13]
  [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246
  [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5
  [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it 
completed.
  [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 
lun 1]
  [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED
  [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 
tgt <...>]
  [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED
  [ 315.063456] connection1:0: detected conn error (1021)
  [ 315.125743] session1: iscsi_eh_session_reset wait for relogin
  [ 398.843556] INFO: task systemd:1 blocked for more 

[Touch-packages] [Bug 1996619] Re: Setfont error due to deprecated PIO_FONTX ioctl

[Mauricio Faria de Oliveira]

Thanks, Heather! 
Uploaded to Kinetic and Jammy (minor adjustments; build tested on supported 
archs w/ -proposed).

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

Title:
  Setfont error due to deprecated PIO_FONTX ioctl

Status in subiquity:
  Invalid
Status in kbd package in Ubuntu:
  Fix Released
Status in kbd source package in Jammy:
  In Progress
Status in kbd source package in Kinetic:
  In Progress

Bug description:
  [Impact]

  There is an error message that get thrown in in syslog.
  There is a suggestion to fix by upgrading the KDB package to version 2.5.1+ 
(upstream) has a fix.

  It is caused by this line in subiquity
  
https://github.com/canonical/subiquity/blob/46f671d14d57a5da6bc3d60b1da6715b43954f0d/bin/subiquity-service#L11

  It's due to PIO_FONTX ioctl removed from kernel since 5.12
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff2047fb755d4415ec3c70ac799889371151796d

  In 2.4.5 of kbd which provide setfont in user space, they already
  switched over to use KDFONTOP only.

  [ Test Plan ]

  ### REPRODUCER STEPS ###

  # install libvirt
  sudo apt install qemu qemu-kvm libvirt-clients libvirt-daemon-system virtinst 
bridge-utils

  sudo systemctl enable libvirtd
  sudo systemctl start libvirtd

  # check libvirtd process is running
  virsh
  virsh list

  # get iso
  wget https://releases.ubuntu.com/22.04/ubuntu-22.04.1-live-server-amd64.iso

  # install vm
  sudo virt-install --cdrom='./ubuntu-22.04.1-live-server-amd64.iso'  
--name=setfont-repo --vcpus=2 --memory=2048 --disk size=20 --serial pty 
--graphics none --boot=uefi --debug

  # you can either do the full install,
  the error will be in the /var/log/installer.log file

  # or on the first page of the installer press Tab-> go to Help, -> Shell
  and cd /var/log/
  grep setfont* syslog

  # to show error message cd to
  /snap/subiquity/3698

  #execute
  setfont $SNAP/subiquity.psf

  # error
  root@ubuntu-server:/snap/subiquity/3698# setfont $SNAP/subiquity.psf
  setfont: ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: 
failed: Inappropriate ioctl for device

  # grep
  grep setfont* syslog
  Nov 14 18:22:11 ubuntu-server console-setup.sh[1107]: setfont: ERROR 
kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: 
Inappropriate ioctl for device
  Nov 14 18:22:29 ubuntu-server subiquity.subiquity-service[1878]: setfont: 
ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: 
Inappropriate ioctl for device

  [ Where problems could occur ]

  There could be a failure to correctly parse fonts.
  https://man7.org/linux/man-pages/man8/setfont.8.html

  [Other Notes]

  # github link to upstream repo & commit
  https://github.com/legionus/kbd
  
https://github.com/legionus/kbd/commit/2b68ba3ef22e6f68dcd9dc5c7fc47f72761f3764

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1996619/+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 1996958] Re: [Azure] 18.04 - non-unique ID_PATH for SCSI disks

[Mauricio Faria de Oliveira]

We haven't heard back from the original reporter (see comment #5).

Thus, marking this as `Won't Fix` for now, and attaching debdiff
for documentation purposes only (not for sponsoring).

** Changed in: systemd (Ubuntu Bionic)
   Status: In Progress => Won't Fix

** Changed in: systemd (Ubuntu Bionic)
 Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned)

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

Title:
  [Azure] 18.04 - non-unique ID_PATH for SCSI disks

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix

Bug description:
  [Impact]

   * The PATH_ID for SCSI disks on Azure/Hyper-V might not be unique
 with the systemd/udev version in Ubuntu 18.04 LTS (Bionic Beaver).

   * This cause issues on applications that require unique PATH_IDs;
 for example Veritas Dynamic Multi-Pathing (DMP).

   * The fix introduces changes to PATH_ID format/values for VMBUS,
 which would break stable names/links, so it must be an opt-in.

   * The kernel command line option 'udev.new_vmbus_path_id' (boolean)
 can be used to opt in to (different) unique PATH_IDs.

   * It's not used by default (i.e., no behavior change by default).

  [Test Plan]

   1. Launch an Ubuntu 18.04 VM on Azure
   2. Add extra disks to the VM
   3. Check the disks PATH_ID for (non-)unique values
   4. (Opt-in for the fix with kernel cmdline option; repeat 3.)

   * Before:

$ lsscsi | grep /dev/sd
[0:0:0:0]diskMsft Virtual Disk 1.0   /dev/sdc
[0:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdd
[1:0:0:0]diskMsft Virtual Disk 1.0   /dev/sda
[1:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdb

$ for sd in /dev/sd?; do \
  udevadm test-builtin path_id /block/${sd#/dev} \
2>/dev/null | grep ID_PATH=; \
  done | sort | uniq -c
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1

   * After:

Opt-in mechanism:

$ cat </dev/null | grep ID_PATH=; \
  done | sort | uniq -c
1 ID_PATH=acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-0
1 ID_PATH=acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-1
1 ID_PATH=acpi-VMBUS:00-vmbus-f8b3781b1e824818a1c363d806ec15bb-lun-0
1 ID_PATH=acpi-VMBUS:00-vmbus-f8b3781b1e824818a1c363d806ec15bb-lun-1

  [Where problems might occur]

   * The PATH_ID property of SCSI disks on Azure/Hyper-V
 (ie, on VMBUS) might display problems, and impact
 applications/userspace that use /dev/disk/by-path.

   * There are no functional changes in the existing code path
 (see patch for '37' and related math).  The new code path
 is guarded with an opt-in option (not used by default).

  [Other Info]

   * upstream patch:
     
https://github.com/systemd/systemd/commit/cf3fabacaa141a1224a2ad239806a1fa28b51687

   * present in Focal and later:

  systemd.git$ git describe --contains cf3fabacaa141a1224a2ad239806a1fa28b51687
  v239~511

  $ rmadison -a source systemd
   systemd | 204-5ubuntu20 | trusty  | source
   systemd | 204-5ubuntu20.31  | trusty-security | source
   systemd | 204-5ubuntu20.31  | trusty-updates  | source
   systemd | 229-4ubuntu4  | xenial  | source
   systemd | 229-4ubuntu21.27  | xenial-security | source
   systemd | 229-4ubuntu21.31  | xenial-updates  | source
   systemd | 237-3ubuntu10 | bionic  | source
   systemd | 237-3ubuntu10.56  | bionic-security | source
   systemd | 237-3ubuntu10.56  | bionic-updates  | source
   systemd | 245.4-4ubuntu3| focal   | source
   systemd | 245.4-4ubuntu3.15 | focal-security  | source
   systemd | 245.4-4ubuntu3.18 | focal-updates   | source
   systemd | 245.4-4ubuntu3.19 | focal-proposed  | source
   systemd | 249.11-0ubuntu3   | jammy   | source
   systemd | 249.11-0ubuntu3.6 | jammy-updates   | source
   systemd | 251.4-1ubuntu7| kinetic | source
   systemd | 251.4-1ubuntu7| lunar   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1996958/+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 1996958] Re: [Azure] 18.04 - non-unique ID_PATH for SCSI disks

[Mauricio Faria de Oliveira]

** Patch added: "lp1996958-bionic-systemd.debdiff"
   
https://bugs.launchpad.net/ubuntu/bionic/+source/systemd/+bug/1996958/+attachment/5635743/+files/lp1996958-bionic-systemd.debdiff

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

Title:
  [Azure] 18.04 - non-unique ID_PATH for SCSI disks

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Won't Fix

Bug description:
  [Impact]

   * The PATH_ID for SCSI disks on Azure/Hyper-V might not be unique
 with the systemd/udev version in Ubuntu 18.04 LTS (Bionic Beaver).

   * This cause issues on applications that require unique PATH_IDs;
 for example Veritas Dynamic Multi-Pathing (DMP).

   * The fix introduces changes to PATH_ID format/values for VMBUS,
 which would break stable names/links, so it must be an opt-in.

   * The kernel command line option 'udev.new_vmbus_path_id' (boolean)
 can be used to opt in to (different) unique PATH_IDs.

   * It's not used by default (i.e., no behavior change by default).

  [Test Plan]

   1. Launch an Ubuntu 18.04 VM on Azure
   2. Add extra disks to the VM
   3. Check the disks PATH_ID for (non-)unique values
   4. (Opt-in for the fix with kernel cmdline option; repeat 3.)

   * Before:

$ lsscsi | grep /dev/sd
[0:0:0:0]diskMsft Virtual Disk 1.0   /dev/sdc
[0:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdd
[1:0:0:0]diskMsft Virtual Disk 1.0   /dev/sda
[1:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdb

$ for sd in /dev/sd?; do \
  udevadm test-builtin path_id /block/${sd#/dev} \
2>/dev/null | grep ID_PATH=; \
  done | sort | uniq -c
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1

   * After:

Opt-in mechanism:

$ cat 

[Touch-packages] [Bug 1834250] Re: update-grub complains about non-existent drives (due to cardreader)

[Mauricio Faria de Oliveira]

** Changed in: lvm2 (Ubuntu Focal)
 Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned)

** Tags removed: sts-sponsor-mfo

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

Title:
  update-grub complains about non-existent drives (due to cardreader)

Status in lvm2 package in Ubuntu:
  Fix Released
Status in lvm2 source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * `update-grub` (actually `vgs`) complains about
     'No medium found' on systems with card readers
     that have no card in.

   * This may confuse users who aren't sure whether
     it means problems occurred with the bootloader,
     and concern their ability to safely boot again.

   * The workaround is to add a filter to LVM config,
     but this might be hard to find and error prone.
     (And not even seem relate to `update-grub` at
     all, specially on non-LVM storage layouts.)
     [See comment #16]

   * The fix replaces calls to `dev_open_readonly()`
 with `dev_open_readonly_quiet()` in scan path,
 where such errors are not a problem.

  [Test Plan]

   * Run `vgs` on a system with a card reader
     and check for 'No medium found' messages.

   * Run `strace -f -e openat vgs` to confirm
     system calls/error codes have no changes.

   * [See comment #20]

  [Where problems could occur]

   * The patch changes syscall error reporting on the
     'scan' path, so problems could occur when listing
     LVM resources in block devices (e.g., list volume
     groups with `vgs`).

   * There's little to no changes upstream on this area,
     and the change is present in Jammy; both help with
     a lower chance of regression.

  [Other Info]

   * `block-proposed-focal`: The upload is being staged
     as it's just a cosmetic change, but affects `lvm2`,
     which is present in so many systems, triggering a
     lot of upgrades/boot risk (in case something else
     broke and this upgrade could reveal it indirectly).

   * So, it will probably only be released once a more
     serious issue has to be fixed in `lvm2`.

   * Scope: Jammy has the fix, and Impish will EOL soon.

  [Original Bug Description]

  sudo update-grub

  Sourcing file `/etc/default/grub'
  Sourcing file `/etc/default/grub.d/init-select.cfg'
  Generating grub configuration file ...
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
  Found linux image: /boot/vmlinuz-5.0.0-17-generic
  Found initrd image: /boot/initrd.img-5.0.0-17-generic
  Found linux image: /boot/vmlinuz-5.0.0-16-generic
  Found initrd image: /boot/initrd.img-5.0.0-16-generic
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
  Adding boot menu entry for EFI firmware configuration
  done

  --

  lsblk

  NAME MAJ:MIN

[Touch-packages] [Bug 1996619] Re: Setfont error due to deprecated PIO_FONTX ioctl

[Mauricio Faria de Oliveira]

Heather and I internally discussed some feedback/review for the revised
debdiffs.

** Tags removed: sts-sponsor
** Tags added: se-sponsor-mfo

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

Title:
  Setfont error due to deprecated PIO_FONTX ioctl

Status in subiquity:
  Invalid
Status in kbd package in Ubuntu:
  Fix Released
Status in kbd source package in Jammy:
  In Progress
Status in kbd source package in Kinetic:
  In Progress

Bug description:
  [Impact]

  There is an error message that get thrown in in syslog.
  There is a suggestion to fix by upgrading the KDB package to version 2.5.1+ 
(upstream) has a fix.

  It is caused by this line in subiquity
  
https://github.com/canonical/subiquity/blob/46f671d14d57a5da6bc3d60b1da6715b43954f0d/bin/subiquity-service#L11

  It's due to PIO_FONTX ioctl removed from kernel since 5.12
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff2047fb755d4415ec3c70ac799889371151796d

  In 2.4.5 of kbd which provide setfont in user space, they already
  switched over to use KDFONTOP only.

  [ Test Plan ]

  ### REPRODUCER STEPS ###

  # install libvirt
  sudo apt install qemu qemu-kvm libvirt-clients libvirt-daemon-system virtinst 
bridge-utils

  sudo systemctl enable libvirtd
  sudo systemctl start libvirtd

  # check libvirtd process is running
  virsh
  virsh list

  # get iso
  wget https://releases.ubuntu.com/22.04/ubuntu-22.04.1-live-server-amd64.iso

  # install vm
  sudo virt-install --cdrom='./ubuntu-22.04.1-live-server-amd64.iso'  
--name=setfont-repo --vcpus=2 --memory=2048 --disk size=20 --serial pty 
--graphics none --boot=uefi --debug

  # you can either do the full install,
  the error will be in the /var/log/installer.log file

  # or on the first page of the installer press Tab-> go to Help, -> Shell
  and cd /var/log/
  grep setfont* syslog

  # to show error message cd to
  /snap/subiquity/3698

  #execute
  setfont $SNAP/subiquity.psf

  # error
  root@ubuntu-server:/snap/subiquity/3698# setfont $SNAP/subiquity.psf
  setfont: ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: 
failed: Inappropriate ioctl for device

  # grep
  grep setfont* syslog
  Nov 14 18:22:11 ubuntu-server console-setup.sh[1107]: setfont: ERROR 
kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: 
Inappropriate ioctl for device
  Nov 14 18:22:29 ubuntu-server subiquity.subiquity-service[1878]: setfont: 
ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: 
Inappropriate ioctl for device

  [ Where problems could occur ]

  There could be a failure to correctly parse fonts.
  https://man7.org/linux/man-pages/man8/setfont.8.html

  [Other Notes]

  # github link to upstream repo & commit
  https://github.com/legionus/kbd
  
https://github.com/legionus/kbd/commit/2b68ba3ef22e6f68dcd9dc5c7fc47f72761f3764

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1996619/+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 1996958] Re: [Azure] 18.04 - non-unique PATH_ID for SCSI disks

[Mauricio Faria de Oliveira]

Scenario 2) LUN numbers 0, 1, and 5 (non-0/1 test).

$ dmesg | grep Hypervisor
[0.00] Hypervisor detected: Microsoft Hyper-V

$ uname -r
5.4.0-1094-azure

$ lsscsi | grep sd
[0:0:0:0]diskMsft Virtual Disk 1.0   /dev/sda
[0:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdb
[1:0:0:0]diskMsft Virtual Disk 1.0   /dev/sdc
[1:0:0:5]diskMsft Virtual Disk 1.0   /dev/sdd

$ ls -d /sys/bus/vmbus/devices/*/host*/target*/*/block/sd*

/sys/bus/vmbus/devices/f8b3781a-1e82-4818-a1c3-63d806ec15bb/host0/target0:0:0/0:0:0:0/block/sda

/sys/bus/vmbus/devices/f8b3781a-1e82-4818-a1c3-63d806ec15bb/host0/target0:0:0/0:0:0:1/block/sdb

/sys/bus/vmbus/devices/f8b3781b-1e82-4818-a1c3-63d806ec15bb/host1/target1:0:0/1:0:0:0/block/sdc

/sys/bus/vmbus/devices/f8b3781b-1e82-4818-a1c3-63d806ec15bb/host1/target1:0:0/1:0:0:5/block/sdd


Before: (non-unique ID_PATHs; some disks missing by-path symlinks)
--

$ dpkg -s udev | grep Version:
Version: 237-3ubuntu10.56

$ for sd in /sys/block/sd*; do udevadm test-builtin path_id $sd; done 
2>/dev/null | grep ID_PATH= | sort | uniq -c
  2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  1 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1
  1 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:5

$ ll /dev/disk/by-path
total 0
drwxr-xr-x 2 root root 200 Nov 18 20:18 ./
drwxr-xr-x 9 root root 180 Nov 18 20:18 ../
lrwxrwxrwx 1 root root   9 Nov 18 20:18 acpi-VMBUS:00-scsi-0:0:0:0 -> 
../../sda
lrwxrwxrwx 1 root root  10 Nov 18 20:18 
acpi-VMBUS:00-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  11 Nov 18 20:18 
acpi-VMBUS:00-scsi-0:0:0:0-part14 -> ../../sda14
lrwxrwxrwx 1 root root  11 Nov 18 20:18 
acpi-VMBUS:00-scsi-0:0:0:0-part15 -> ../../sda15
lrwxrwxrwx 1 root root   9 Nov 18 20:18 acpi-VMBUS:00-scsi-0:0:0:1 -> 
../../sdb
lrwxrwxrwx 1 root root  10 Nov 18 20:18 
acpi-VMBUS:00-scsi-0:0:0:1-part1 -> ../../sdb1
lrwxrwxrwx 1 root root   9 Nov 18 20:18 acpi-VMBUS:00-scsi-0:0:0:2 -> 
../../sr0
lrwxrwxrwx 1 root root   9 Nov 18 20:18 acpi-VMBUS:00-scsi-0:0:0:5 -> 
../../sdd


After: (non-unique ID_PATHs by default; unique ID_PATHs w/ opt-in)
-

Install test packages:

$ sudo add-apt-repository ppa:mfo/lp1996958

$ sudo apt install $(dpkg -l | awk '$3 == "237-3ubuntu10.56" { print $2 
}')

$ dpkg -s udev | grep Version:
Version: 237-3ubuntu10.56+lp1996958.1

$ sudo reboot

No change by default (opt-in disabled):
  
$ for sd in /sys/block/sd*; do udevadm test-builtin path_id $sd; done 
2>/dev/null | grep ID_PATH= | sort | uniq -c
  2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  1 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1
  1 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:5

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.4.0-1094-azure 
root=UUID=898098a3-2c50-49fd-ac32-98a16d91c16b ro console=tty1 console=ttyS0 
earlyprintk=ttyS0

Enable opt-in:

$ cat  ../../sda
lrwxrwxrwx 1 root root  10 Nov 18 20:42 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  11 Nov 18 20:42 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-0-part14 -> ../../sda14
lrwxrwxrwx 1 root root  11 Nov 18 20:42 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-0-part15 -> ../../sda15
lrwxrwxrwx 1 root root   9 Nov 18 20:42 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-1 -> ../../sdb
lrwxrwxrwx 1 root root  10 Nov 18 20:42 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-1-part1 -> ../../sdb1
lrwxrwxrwx 1 root root   9 Nov 18 20:42 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-2 -> ../../sr0
lrwxrwxrwx 1 root root   9 Nov 18 20:42 
acpi-VMBUS:00-vmbus-f8b3781b1e824818a1c363d806ec15bb-lun-0 -> ../../sdc
lrwxrwxrwx 1 root root   9 Nov 18 20:42 
acpi-VMBUS:00-vmbus-f8b3781b1e824818a1c363d806ec15bb-lun-5 -> ../../sdd

(Note the UUIDs/GUIDs match the sysfs paths.)

** Summary changed:

- [Azure] 18.04 - non-unique PATH_ID for SCSI disks
+ [Azure] 

[Touch-packages] [Bug 1996958] Re: [Azure] 18.04 - non-unique PATH_ID for SCSI disks

[Mauricio Faria de Oliveira]

Scenario 1) LUN numbers 0 and 1 only.

$ dmesg | grep Hypervisor
[0.00] Hypervisor detected: Microsoft Hyper-V

$ uname -r
5.4.0-1094-azure

$ lsscsi | grep sd
[0:0:0:0]diskMsft Virtual Disk 1.0   /dev/sdc
[0:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdd
[1:0:0:0]diskMsft Virtual Disk 1.0   /dev/sda
[1:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdb

$ ls -d /sys/bus/vmbus/devices/*/host*/target*/*/block/sd*

/sys/bus/vmbus/devices/f8b3781a-1e82-4818-a1c3-63d806ec15bb/host0/target0:0:0/0:0:0:0/block/sdc

/sys/bus/vmbus/devices/f8b3781a-1e82-4818-a1c3-63d806ec15bb/host0/target0:0:0/0:0:0:1/block/sdd

/sys/bus/vmbus/devices/f8b3781b-1e82-4818-a1c3-63d806ec15bb/host1/target1:0:0/1:0:0:0/block/sda

/sys/bus/vmbus/devices/f8b3781b-1e82-4818-a1c3-63d806ec15bb/host1/target1:0:0/1:0:0:1/block/sdb

Before: (non-unique ID_PATHs; some disks missing by-path symlinks)
--

$ dpkg -s udev | grep Version:
Version: 237-3ubuntu10.56

$ for sd in /sys/block/sd*; do udevadm test-builtin path_id $sd; done 
2>/dev/null | grep ID_PATH= | sort | uniq -c
  2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1

$ ll /dev/disk/by-path
total 0
drwxr-xr-x 2 root root 180 Nov 18 20:16 ./
drwxr-xr-x 9 root root 180 Nov 18 20:16 ../
lrwxrwxrwx 1 root root   9 Nov 18 20:16 acpi-VMBUS:00-scsi-0:0:0:0 -> 
../../sdc
lrwxrwxrwx 1 root root  10 Nov 18 20:16 
acpi-VMBUS:00-scsi-0:0:0:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  11 Nov 18 20:16 
acpi-VMBUS:00-scsi-0:0:0:0-part14 -> ../../sdc14
lrwxrwxrwx 1 root root  11 Nov 18 20:16 
acpi-VMBUS:00-scsi-0:0:0:0-part15 -> ../../sdc15
lrwxrwxrwx 1 root root   9 Nov 18 20:16 acpi-VMBUS:00-scsi-0:0:0:1 -> 
../../sdd
lrwxrwxrwx 1 root root  10 Nov 18 20:16 
acpi-VMBUS:00-scsi-0:0:0:1-part1 -> ../../sdd1
lrwxrwxrwx 1 root root   9 Nov 18 20:16 acpi-VMBUS:00-scsi-0:0:0:2 -> 
../../sr0

After: (non-unique ID_PATHs by default; unique ID_PATHs w/ opt-in)
-

Install test packages:

$ sudo add-apt-repository ppa:mfo/lp1996958

$ sudo apt install $(dpkg -l | awk '$3 == "237-3ubuntu10.56" { print $2 
}')

$ dpkg -s udev | grep Version:
Version: 237-3ubuntu10.56+lp1996958.1

No change by default (opt-in disabled):

$ sudo reboot

$ for sd in /sys/block/sd*; do udevadm test-builtin path_id $sd; done 
2>/dev/null | grep ID_PATH= | sort | uniq -c
  2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.4.0-1094-azure 
root=UUID=898098a3-2c50-49fd-ac32-98a16d91c16b ro console=tty1 console=ttyS0 
earlyprintk=ttyS0

Enable opt-in:

$ cat  ../../sda
lrwxrwxrwx 1 root root  10 Nov 18 20:39 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  11 Nov 18 20:39 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-0-part14 -> ../../sda14
lrwxrwxrwx 1 root root  11 Nov 18 20:39 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-0-part15 -> ../../sda15
lrwxrwxrwx 1 root root   9 Nov 18 20:39 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-1 -> ../../sdb
lrwxrwxrwx 1 root root  10 Nov 18 20:39 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-1-part1 -> ../../sdb1
lrwxrwxrwx 1 root root   9 Nov 18 20:39 
acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-2 -> ../../sr0
lrwxrwxrwx 1 root root   9 Nov 18 20:39 
acpi-VMBUS:00-vmbus-f8b3781b1e824818a1c363d806ec15bb-lun-0 -> ../../sdc
lrwxrwxrwx 1 root root   9 Nov 18 20:39 
acpi-VMBUS:00-vmbus-f8b3781b1e824818a1c363d806ec15bb-lun-1 -> ../../sdd

(Note the UUIDs/GUIDs match the sysfs paths.)

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

Title:
  [Azure] 18.04 - non-unique ID_PATH for SCSI disks

Status in systemd package in Ubuntu:
  Fix Released
Status in 

[Touch-packages] [Bug 1996958] Re: [Azure] 18.04 - non-unique PATH_ID for SCSI disks

[Mauricio Faria de Oliveira]

Test packages on ppa:mfo/lp1996958 [1].

Initial tests show positive results (next comments).
Waiting on feedback from the original reporter.

[1] https://launchpad.net/~mfo/+archive/ubuntu/lp1996958

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

Title:
  [Azure] 18.04 - non-unique ID_PATH for SCSI disks

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * The PATH_ID for SCSI disks on Azure/Hyper-V might not be unique
 with the systemd/udev version in Ubuntu 18.04 LTS (Bionic Beaver).

   * This cause issues on applications that require unique PATH_IDs;
 for example Veritas Dynamic Multi-Pathing (DMP).

   * The fix introduces changes to PATH_ID format/values for VMBUS,
 which would break stable names/links, so it must be an opt-in.

   * The kernel command line option 'udev.new_vmbus_path_id' (boolean)
 can be used to opt in to (different) unique PATH_IDs.

   * It's not used by default (i.e., no behavior change by default).

  [Test Plan]

   1. Launch an Ubuntu 18.04 VM on Azure
   2. Add extra disks to the VM
   3. Check the disks PATH_ID for (non-)unique values
   4. (Opt-in for the fix with kernel cmdline option; repeat 3.)

   * Before:

$ lsscsi | grep /dev/sd
[0:0:0:0]diskMsft Virtual Disk 1.0   /dev/sdc
[0:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdd
[1:0:0:0]diskMsft Virtual Disk 1.0   /dev/sda
[1:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdb

$ for sd in /dev/sd?; do \
  udevadm test-builtin path_id /block/${sd#/dev} \
2>/dev/null | grep ID_PATH=; \
  done | sort | uniq -c
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1

   * After:

Opt-in mechanism:

$ cat 

[Touch-packages] [Bug 1996958] Re: [Azure] 18.04 - non-unique PATH_ID for SCSI disks

[Mauricio Faria de Oliveira]

I have verified the scenario that Seyeong mentioned
where the patch apparently dit not make a difference
(SCSI disks with LUN numbers greater than 1, eg, 5).

My observation is it indeed works/makes a difference.

He went out on vacation (so I'm reassigning the bug), and
cannot confirm this, but per internal comments I believe
that observation was based on /dev/disk/by-path symlinks,
which are not updated automatically (on test pkg install).

The PATH_IDs obtained with `udevadm info` were correct,
though, so it's working as expected (just needed reboot).

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

Title:
  [Azure] 18.04 - non-unique PATH_ID for SCSI disks

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * The PATH_ID for SCSI disks on Azure/Hyper-V might not be unique
 with the systemd/udev version in Ubuntu 18.04 LTS (Bionic Beaver).

   * This cause issues on applications that require unique PATH_IDs;
 for example Veritas Dynamic Multi-Pathing (DMP).

   * The fix introduces changes to PATH_ID format/values for VMBUS,
 which would break stable names/links, so it must be an opt-in.

   * The kernel command line option 'udev.new_vmbus_path_id' (boolean)
 can be used to opt in to (different) unique PATH_IDs.

   * It's not used by default (i.e., no behavior change by default).

  [Test Plan]

   1. Launch an Ubuntu 18.04 VM on Azure
   2. Add extra disks to the VM
   3. Check the disks PATH_ID for (non-)unique values
   4. (Opt-in for the fix with kernel cmdline option; repeat 3.)

   * Before:

$ lsscsi | grep /dev/sd
[0:0:0:0]diskMsft Virtual Disk 1.0   /dev/sdc
[0:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdd
[1:0:0:0]diskMsft Virtual Disk 1.0   /dev/sda
[1:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdb

$ for sd in /dev/sd?; do \
  udevadm test-builtin path_id /block/${sd#/dev} \
2>/dev/null | grep ID_PATH=; \
  done | sort | uniq -c
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1

   * After:

Opt-in mechanism:

$ cat 

[Touch-packages] [Bug 1996958] Re: [Azure] 18.04 - /by-path/ has the same path

[Mauricio Faria de Oliveira]

 245.4-4ubuntu3.19 | focal-proposed  | source
+  systemd | 249.11-0ubuntu3   | jammy   | source
+  systemd | 249.11-0ubuntu3.6 | jammy-updates   | source
+  systemd | 251.4-1ubuntu7| kinetic | source
+  systemd | 251.4-1ubuntu7| lunar   | source

** Summary changed:

- [Azure] 18.04 - /by-path/ has the same path
+ [Azure] 18.04 - non-unique PATH_ID for SCSI disks

** Changed in: systemd (Ubuntu Bionic)
 Assignee: Seyeong Kim (seyeongkim) => Mauricio Faria de Oliveira (mfo)

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

Title:
  [Azure] 18.04 - non-unique PATH_ID for SCSI disks

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * The PATH_ID for SCSI disks on Azure/Hyper-V might not be unique
 with the systemd/udev version in Ubuntu 18.04 LTS (Bionic Beaver).

   * This cause issues on applications that require unique PATH_IDs;
 for example Veritas Dynamic Multi-Pathing (DMP).

   * The fix introduces changes to PATH_ID format/values for VMBUS,
 which would break stable names/links, so it must be an opt-in.

   * The kernel command line option 'udev.new_vmbus_path_id' (boolean)
 can be used to opt in to (different) unique PATH_IDs.

   * It's not used by default (i.e., no behavior change by default).

  [Test Plan]

   1. Launch an Ubuntu 18.04 VM on Azure
   2. Add extra disks to the VM
   3. Check the disks PATH_ID for (non-)unique values
   4. (Opt-in for the fix with kernel cmdline option; repeat 3.)

   * Before:

$ lsscsi | grep /dev/sd
[0:0:0:0]diskMsft Virtual Disk 1.0   /dev/sdc
[0:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdd
[1:0:0:0]diskMsft Virtual Disk 1.0   /dev/sda
[1:0:0:1]diskMsft Virtual Disk 1.0   /dev/sdb

$ for sd in /dev/sd?; do \
  udevadm test-builtin path_id /block/${sd#/dev} \
2>/dev/null | grep ID_PATH=; \
  done | sort | uniq -c
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
2 ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1

   * After:

Opt-in mechanism:

$ cat </dev/null | grep ID_PATH=; \
  done | sort | uniq -c
1 ID_PATH=acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-0
1 ID_PATH=acpi-VMBUS:00-vmbus-f8b3781a1e824818a1c363d806ec15bb-lun-1
1 ID_PATH=acpi-VMBUS:00-vmbus-f8b3781b1e824818a1c363d806ec15bb-lun-0
1 ID_PATH=acpi-VMBUS:00-vmbus-f8b3781b1e824818a1c363d806ec15bb-lun-1

  [Where problems might occur]

   * The PATH_ID property of SCSI disks on Azure/Hyper-V
 (ie, on VMBUS) might display problems, and impact
 applications/userspace that use /dev/disk/by-path.

   * There are no functional changes in the existing code path
 (see patch for '37' and related math).  The new code path
 is guarded with an opt-in option (not used by default).

  [Other Info]

   * upstream patch:
     
https://github.com/systemd/systemd/commit/cf3fabacaa141a1224a2ad239806a1fa28b51687

   * present in Focal and later:

  systemd.git$ git describe --contains cf3fabacaa141a1224a2ad239806a1fa28b51687
  v239~511

  $ rmadison -a source systemd
   systemd | 204-5ubuntu20 | trusty  | source
   systemd | 204-5ubuntu20.31  | trusty-security | source
   systemd | 204-5ubuntu20.31  | trusty-updates  | source
   systemd | 229-4ubuntu4  | xenial  | source
   systemd | 229-4ubuntu21.27  | xenial-security | source
   systemd | 229-4ubuntu21.31  | xenial-updates  | source
   systemd | 237-3ubuntu10 | bionic  | source
   systemd | 237-3ubuntu10.56  | bionic-security | source
   systemd | 237-3ubuntu10.56  | bionic-updates  | source
   systemd | 245.4-4ubuntu3| focal   | source
   systemd | 245.4-4ubuntu3.15 | focal-security  | source
   systemd | 245.4-4ubuntu3.18 | focal-updates   | source
   systemd | 245.4-4ubuntu3.19 | focal-proposed  | source
   systemd | 249.11-0ubuntu3   | jammy   | source
   systemd | 249.11-0ubuntu3.6 | jammy-updates   | source
   systemd | 251.4-1ubuntu7| kinetic | source
   systemd | 251.4-1ubuntu7| lunar   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1996958/+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 1996958] Re: [Azure] 18.04 - /by-path/ has the same path

[Mauricio Faria de Oliveira]

** Description changed:

  [Impact]
  Azure 18.04 has issue with /dev/disk/by-path/ has the same path name when vm 
has multiple disks.
  
  [Test Plan]
  1. launch 18.04 on azure
  2. add extra disk to #1 vm
  3. check the path
  
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sda | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_0
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sdb | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_1
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sdc | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_0
  
  [Where problems might occur]
  TBD
  
- [Others]
+ [Other Info]
  
- upstream patch
- 
https://github.com/systemd/systemd/commit/cf3fabacaa141a1224a2ad239806a1fa28b51687
+  * upstream patch:
+
https://github.com/systemd/systemd/commit/cf3fabacaa141a1224a2ad239806a1fa28b51687
+ 
+  * present in Focal and later:
+ 
+ systemd.git$ git describe --contains cf3fabacaa141a1224a2ad239806a1fa28b51687
+ v239~511
+ 
+ $ rmadison -a source systemd
+  systemd | 204-5ubuntu20 | trusty  | source
+  systemd | 204-5ubuntu20.31  | trusty-security | source
+  systemd | 204-5ubuntu20.31  | trusty-updates  | source
+  systemd | 229-4ubuntu4  | xenial  | source
+  systemd | 229-4ubuntu21.27  | xenial-security | source
+  systemd | 229-4ubuntu21.31  | xenial-updates  | source
+  systemd | 237-3ubuntu10 | bionic  | source
+  systemd | 237-3ubuntu10.56  | bionic-security | source
+  systemd | 237-3ubuntu10.56  | bionic-updates  | source
+  systemd | 245.4-4ubuntu3| focal   | source
+  systemd | 245.4-4ubuntu3.15 | focal-security  | source
+  systemd | 245.4-4ubuntu3.18 | focal-updates   | source
+  systemd | 245.4-4ubuntu3.19 | focal-proposed  | source
+  systemd | 249.11-0ubuntu3   | jammy   | source
+  systemd | 249.11-0ubuntu3.6 | jammy-updates   | source
+  systemd | 251.4-1ubuntu7| kinetic | source
+  systemd | 251.4-1ubuntu7| lunar   | source

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

Title:
  [Azure] 18.04 - /by-path/ has the same path

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]
  Azure 18.04 has issue with /dev/disk/by-path/ has the same path name when vm 
has multiple disks.

  [Test Plan]
  1. launch 18.04 on azure
  2. add extra disk to #1 vm
  3. check the path

  xtrusia@test-canonical:~$ udevadm info --name=/dev/sda | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_0
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sdb | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_1
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sdc | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_0

  [Where problems might occur]
  TBD

  [Other Info]

   * upstream patch:
 
https://github.com/systemd/systemd/commit/cf3fabacaa141a1224a2ad239806a1fa28b51687

   * present in Focal and later:

  systemd.git$ git describe --contains cf3fabacaa141a1224a2ad239806a1fa28b51687
  v239~511

  $ rmadison -a source systemd
   systemd | 204-5ubuntu20 | trusty  | source
   systemd | 204-5ubuntu20.31  | trusty-security | source
   systemd | 204-5ubuntu20.31  | trusty-updates  | source
   systemd | 229-4ubuntu4  | xenial  | source
   systemd | 229-4ubuntu21.27  | xenial-security | source
   systemd | 229-4ubuntu21.31  | xenial-updates  | source
   systemd | 237-3ubuntu10 | bionic  | source
   systemd | 237-3ubuntu10.56  | bionic-security | source
   systemd | 237-3ubuntu10.56  | bionic-updates  | source
   systemd | 245.4-4ubuntu3| focal   | source
   systemd | 245.4-4ubuntu3.15 | focal-security  | source
   systemd | 245.4-4ubuntu3.18 | focal-updates   | source
   systemd | 245.4-4ubuntu3.19 | focal-proposed  | source
   systemd | 249.11-0ubuntu3   | jammy   | source
   systemd | 249.11-0ubuntu3.6 | jammy-updates   | source
   systemd | 251.4-1ubuntu7| kinetic | source
   systemd | 251.4-1ubuntu7| lunar   | source

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1996958/+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 1996958] Re: [Azure] 18.04 - /by-path/ has the same path

[Mauricio Faria de Oliveira]

** Description changed:

  [Impact]
  Azure 18.04 has issue with /dev/disk/by-path/ has the same path name when vm 
has multiple disks.
  
  [Test Plan]
  1. launch 18.04 on azure
  2. add extra disk to #1 vm
  3. check the path
  
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sda | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_0
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sdb | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_1
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sdc | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_0
  
  [Where problems might occur]
  TBD
  
  [Others]
  
  upstream patch
- 
https://github.com/systemd/systemd/pull/8509/commits/f3a1d5756e2fc4a8508caf3859a481cebf9d28a7
+ 
https://github.com/systemd/systemd/commit/cf3fabacaa141a1224a2ad239806a1fa28b51687

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

Title:
  [Azure] 18.04 - /by-path/ has the same path

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]
  Azure 18.04 has issue with /dev/disk/by-path/ has the same path name when vm 
has multiple disks.

  [Test Plan]
  1. launch 18.04 on azure
  2. add extra disk to #1 vm
  3. check the path

  xtrusia@test-canonical:~$ udevadm info --name=/dev/sda | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_0
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sdb | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:1
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_1
  xtrusia@test-canonical:~$ udevadm info --name=/dev/sdc | grep ID_PATH
  E: ID_PATH=acpi-VMBUS:00-scsi-0:0:0:0
  E: ID_PATH_TAG=acpi-VMBUS_00-scsi-0_0_0_0

  [Where problems might occur]
  TBD

  [Others]

  upstream patch
  
https://github.com/systemd/systemd/commit/cf3fabacaa141a1224a2ad239806a1fa28b51687

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1996958/+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 1991235] Re: systemd 237-3ubuntu10.56 times out on getpwuid

[Mauricio Faria de Oliveira]

Ah, you might want to do systemd first, if a reboot isn't desirable.
If a reboot is fine, then maybe also just check again after reboot,
in case it's a transient system condition unrelated to the upgrades.

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

Title:
  systemd 237-3ubuntu10.56 times out on getpwuid

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  We've recently upgraded packages on one of our images from systemd
  237-3ubuntu10.53 to 237-3ubuntu10.56 and are experiencing some
  performance issues. A kernel upgrade also happened (4.15.0.192.177 ->
  4.15.0.193.178) but I thought I'd check here first. Sorry if I'm
  raising this in the wrong place!

  Various operations are very slow:
  * logging in via SSH
  * ps auxf
  * top
  * systemctl
  * + more

  Weirdly, the issue seems to only happen on Amazon EC2 imported
  machines, and not when running under ESXi, although this may be a red
  herring.

  strace-ing ps shows a timeout reading from some kind of DBus socket:

  recvmsg(6, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="/org/freedesktop/DBus\0\0\0\2\1s\0\24\0\0\0"..., 
iov_len=146}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 146
   > /lib/x86_64-linux-gnu/libc-2.27.so(recvmsg+0x14) [0x122934]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwnam_r+0xf257) 
[0x21df7]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2() [0x10fd1]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwuid_r+0x377) 
[0x12b27]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid_r+0x145) [0xe39e5]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid+0x98) [0xe3148]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x5c) [0x5bfc]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x1ebb) [0x7a5b]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproc+0x149) [0x8659]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproctab2+0x8a) [0x912a]
   > /bin/ps(_init+0xe3b) [0xaef3]
   > /lib/x86_64-linux-gnu/libc-2.27.so(__libc_start_main+0xe7) [0x21c87]
   > /bin/ps(_init+0x1322) [0xb3da]
  recvmsg(6, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 
EAGAIN (Resource temporarily unavailable)
   > /lib/x86_64-linux-gnu/libc-2.27.so(recvmsg+0x14) [0x122934]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwnam_r+0xf257) 
[0x21df7]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2() [0x10fd1]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwuid_r+0x377) 
[0x12b27]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid_r+0x145) [0xe39e5]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid+0x98) [0xe3148]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x5c) [0x5bfc]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x1ebb) [0x7a5b]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproc+0x149) [0x8659]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproctab2+0x8a) [0x912a]
   > /bin/ps(_init+0xe3b) [0xaef3]
   > /lib/x86_64-linux-gnu/libc-2.27.so(__libc_start_main+0xe7) [0x21c87]
   > /bin/ps(_init+0x1322) [0xb3da]
  ppoll([{fd=6, events=POLLIN}], 1, {tv_sec=24, tv_nsec=995725000}, NULL, 8) = 
0 (Timeout) <
   > /lib/x86_64-linux-gnu/libc-2.27.so(ppoll+0x4a) [0x114c5a]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwnam_r+0x1795f) 
[0x2a4ff]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2() [0x1100a]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwuid_r+0x377) 
[0x12b27]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid_r+0x145) [0xe39e5]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid+0x98) [0xe3148]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x5c) [0x5bfc]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x1ebb) [0x7a5b]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproc+0x149) [0x8659]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproctab2+0x8a) [0x912a]
   > /bin/ps(_init+0xe3b) [0xaef3]
   > /lib/x86_64-linux-gnu/libc-2.27.so(__libc_start_main+0xe7) [0x21c87]
   > /bin/ps(_init+0x1322) [0xb3da]


  LSB release output:

  Description:Ubuntu 18.04.6 LTS
  Release:18.04

  Unfortunately I'm unsure how to investigate this further.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1991235/+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 1991235] Re: systemd 237-3ubuntu10.56 times out on getpwuid

[Mauricio Faria de Oliveira]

> ... from systemd 237-3ubuntu10.53 to 237-3ubuntu10.56 
> and are experiencing some performance issues. 
> A kernel upgrade also happened (4.15.0.192.177 -> 4.15.0.193.178)

> but I thought I'd check here first. 
> Sorry if I'm raising this in the wrong place!

Thanks for the bug report!
No worries; this is totally fine -- one can redirect to another package/project 
if appropriate.

> Unfortunately I'm unsure how to investigate this further.

I'd suggest to reboot/revert one upgrade at a time, to verify
which of kernel/systemd are associated with this, if any; eg:

First reboot to the old kernel (4.15.0-192), and check if the issue persists.
If it doesn't, then we should look at the kernel.
If it does, downgrade systemd (you can find the .debs for 10.53 here [1],
and download/reinstall as needed, e.g., `dpkg -l | grep 237-3ubuntu10.56`)
If the issue doesn't persist, we should look at systemd.
If it does, then it's neither kernel/systemd, and might be something else.

Hope this helps!

[1]
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.53/+build/22621099

** 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/1991235

Title:
  systemd 237-3ubuntu10.56 times out on getpwuid

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  We've recently upgraded packages on one of our images from systemd
  237-3ubuntu10.53 to 237-3ubuntu10.56 and are experiencing some
  performance issues. A kernel upgrade also happened (4.15.0.192.177 ->
  4.15.0.193.178) but I thought I'd check here first. Sorry if I'm
  raising this in the wrong place!

  Various operations are very slow:
  * logging in via SSH
  * ps auxf
  * top
  * systemctl
  * + more

  Weirdly, the issue seems to only happen on Amazon EC2 imported
  machines, and not when running under ESXi, although this may be a red
  herring.

  strace-ing ps shows a timeout reading from some kind of DBus socket:

  recvmsg(6, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="/org/freedesktop/DBus\0\0\0\2\1s\0\24\0\0\0"..., 
iov_len=146}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 146
   > /lib/x86_64-linux-gnu/libc-2.27.so(recvmsg+0x14) [0x122934]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwnam_r+0xf257) 
[0x21df7]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2() [0x10fd1]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwuid_r+0x377) 
[0x12b27]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid_r+0x145) [0xe39e5]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid+0x98) [0xe3148]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x5c) [0x5bfc]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x1ebb) [0x7a5b]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproc+0x149) [0x8659]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproctab2+0x8a) [0x912a]
   > /bin/ps(_init+0xe3b) [0xaef3]
   > /lib/x86_64-linux-gnu/libc-2.27.so(__libc_start_main+0xe7) [0x21c87]
   > /bin/ps(_init+0x1322) [0xb3da]
  recvmsg(6, {msg_namelen=0}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 
EAGAIN (Resource temporarily unavailable)
   > /lib/x86_64-linux-gnu/libc-2.27.so(recvmsg+0x14) [0x122934]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwnam_r+0xf257) 
[0x21df7]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2() [0x10fd1]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwuid_r+0x377) 
[0x12b27]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid_r+0x145) [0xe39e5]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid+0x98) [0xe3148]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x5c) [0x5bfc]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x1ebb) [0x7a5b]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproc+0x149) [0x8659]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproctab2+0x8a) [0x912a]
   > /bin/ps(_init+0xe3b) [0xaef3]
   > /lib/x86_64-linux-gnu/libc-2.27.so(__libc_start_main+0xe7) [0x21c87]
   > /bin/ps(_init+0x1322) [0xb3da]
  ppoll([{fd=6, events=POLLIN}], 1, {tv_sec=24, tv_nsec=995725000}, NULL, 8) = 
0 (Timeout) <
   > /lib/x86_64-linux-gnu/libc-2.27.so(ppoll+0x4a) [0x114c5a]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwnam_r+0x1795f) 
[0x2a4ff]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2() [0x1100a]
   > /lib/x86_64-linux-gnu/libnss_systemd.so.2(_nss_systemd_getpwuid_r+0x377) 
[0x12b27]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid_r+0x145) [0xe39e5]
   > /lib/x86_64-linux-gnu/libc-2.27.so(getpwuid+0x98) [0xe3148]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x5c) [0x5bfc]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(pwcache_get_user+0x1ebb) [0x7a5b]
   > /lib/x86_64-linux-gnu/libprocps.so.6.0.0(readproc+0x149) [0x8659]
   > 

[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu

[Mauricio Faria de Oliveira]

Hey Jeremy,

Understood; thanks for clarifying!

I thought that maybe having upstream input could be helpful
(as Julian mentioned to avoid diverging further), but if it
is so much different nowadays, as you mentioned, it likely
won't be that helpful anyway.

By the way, appreciate that "newbie" statement.. after all
this work/analysis/patches, I couldn't think that of you :)

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

Title:
  Can't boot: "error: out of memory." immediately after the grub menu

Status in grub:
  Unknown
Status in OEM Priority Project:
  Triaged
Status in grub2-signed package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  [Impact]

   * In some cases, if the users’ initramfs grow bigger, then it’ll
  likely not be able to be loaded by grub2.

   * Some real cases from OEM projects:

  In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
  puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
  Also the gfxpayload=auto will remain to use 4K resolution since it’s
  what EFI POST passed.

  In this case, the grub isn't able to load initramfs because the
  grub_memalign() won't be able to get suitable memory for the larger
  file:

  ```
  #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
  #1 0x7dd7b074 in grub_malloc (size=592214020) at 
../../../grub-core/kern/mm.c:408
  #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
  at ../../../grub-core/kern/verifiers.c:150
  #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 
"/boot/initrd.img-5.17.0-1011-oem",
  type=131076) at ../../../grub-core/kern/file.c:121
  #4 0x7bcd5a30 in ?? ()
  #5 0x7fe21247 in ?? ()
  #6 0x7bc030c8 in ?? ()
  #7 0x00017fe21238 in ?? ()
  #8 0x7bcd5320 in ?? ()
  #9 0x7fe21250 in ?? ()
  #10 0x in ?? ()
  ```

  Based on grub_mm_dump, we can see the memory fragment (some parts seem
  likely be used because of 4K resolution?) and doesn’t have available
  contiguous memory for larger file as:

  ```
  grub_real_malloc(...)
  ...
  if (cur->size >= n + extra)
  ```

  Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
  guide 4.2.3[2], we can ask 32bits+ on AllocatePages().

  As most X86_64 platforms should support 64 bits addressing, we should
  extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
  memory.

   * When users grown the initramfs, then probably will get initramfs
  not found which really annoyed and impact the user experience (system
  not able to boot).

  [Test Plan]

   * detailed instructions how to reproduce the bug:

  1. Any method to grow the initramfs, such as install nvidia-driver.

  2. If developers would like to reproduce, then could dd if=/dev/random
  of=... bs=1M count=500, something like:

  ```
  $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
  #!/bin/sh

  PREREQ=""

  prereqs()
  {
  echo "$PREREQ"
  }

  case $1 in
  # get pre-requisites
  prereqs)
  prereqs
  exit 0
  ;;
  esac

  . /usr/share/initramfs-tools/hook-functions
  dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
  ```

  And then update-initramfs

   * After applying my patches, the issue is gone.

   * I did also test my test grubx64.efi in:

  1. X86_64 qemu with
  1.1. 60M initramfs + 5.15.0-37-generic kernel
  1.2. 565M initramfs + 5.17.0-1011-oem kernel

  2. Amd64 HP mobile workstation with
  2.1. 65M initramfs + 5.15.0-39-generic kernel
  2.2. 771M initramfs + 5.17.0-1011-oem kernel

  All working well.

  [Where problems could occur]

  * The changes almost in i386/efi, thus the impact will be in the i386 / 
x86_64 EFI system.
  The other change is to modify the “grub-core/kern/efi/mm.c” but I use the 
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
  Thus it should not impact them.

  * There is a “#if defined(__x86_64__)” which intent to limit the >
  32bits code in i386 system and also

  ```
   #if defined (__code_model_large__)
  -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
  +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
  +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
   #else
   #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
  +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
   #endif
  ```

  If everything works as expected, then i386 should working good.

  If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
  4GB memory region and never be able to access.

  [Other Info]

   * Upstream grub2 bug #61058
  https://savannah.gnu.org/bugs/index.php?61058

   * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320

   * Test grubx64.efi:
  

[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu

[Mauricio Faria de Oliveira]

Hi Jeremy,

It seems the PR in rhboot's grub2 hasn't been reviewed yet;
just mentions from other folks who also found it helpful.

Would you consider sending this to the grub-devel list? (i.e., upstream gnu's 
grub2)
It looks like it wasn't yet (search results only cover rhboot).

By the way, this type of change had an interesting discussion
about the implementation approach a few years ago [1], but it
seems it ceased as the sender didn't provide further replies.

Your understanding of the tech details seems very deep, so it
might hopefully be a good opportunity to propose that again :)

Thanks!

[1] https://lists.gnu.org/archive/html/grub-devel/2017-03/msg00032.html

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

Title:
  Can't boot: "error: out of memory." immediately after the grub menu

Status in grub:
  Unknown
Status in OEM Priority Project:
  Triaged
Status in grub2-signed package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  [Impact]

   * In some cases, if the users’ initramfs grow bigger, then it’ll
  likely not be able to be loaded by grub2.

   * Some real cases from OEM projects:

  In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
  puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
  Also the gfxpayload=auto will remain to use 4K resolution since it’s
  what EFI POST passed.

  In this case, the grub isn't able to load initramfs because the
  grub_memalign() won't be able to get suitable memory for the larger
  file:

  ```
  #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
  #1 0x7dd7b074 in grub_malloc (size=592214020) at 
../../../grub-core/kern/mm.c:408
  #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
  at ../../../grub-core/kern/verifiers.c:150
  #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 
"/boot/initrd.img-5.17.0-1011-oem",
  type=131076) at ../../../grub-core/kern/file.c:121
  #4 0x7bcd5a30 in ?? ()
  #5 0x7fe21247 in ?? ()
  #6 0x7bc030c8 in ?? ()
  #7 0x00017fe21238 in ?? ()
  #8 0x7bcd5320 in ?? ()
  #9 0x7fe21250 in ?? ()
  #10 0x in ?? ()
  ```

  Based on grub_mm_dump, we can see the memory fragment (some parts seem
  likely be used because of 4K resolution?) and doesn’t have available
  contiguous memory for larger file as:

  ```
  grub_real_malloc(...)
  ...
  if (cur->size >= n + extra)
  ```

  Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
  guide 4.2.3[2], we can ask 32bits+ on AllocatePages().

  As most X86_64 platforms should support 64 bits addressing, we should
  extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
  memory.

   * When users grown the initramfs, then probably will get initramfs
  not found which really annoyed and impact the user experience (system
  not able to boot).

  [Test Plan]

   * detailed instructions how to reproduce the bug:

  1. Any method to grow the initramfs, such as install nvidia-driver.

  2. If developers would like to reproduce, then could dd if=/dev/random
  of=... bs=1M count=500, something like:

  ```
  $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
  #!/bin/sh

  PREREQ=""

  prereqs()
  {
  echo "$PREREQ"
  }

  case $1 in
  # get pre-requisites
  prereqs)
  prereqs
  exit 0
  ;;
  esac

  . /usr/share/initramfs-tools/hook-functions
  dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
  ```

  And then update-initramfs

   * After applying my patches, the issue is gone.

   * I did also test my test grubx64.efi in:

  1. X86_64 qemu with
  1.1. 60M initramfs + 5.15.0-37-generic kernel
  1.2. 565M initramfs + 5.17.0-1011-oem kernel

  2. Amd64 HP mobile workstation with
  2.1. 65M initramfs + 5.15.0-39-generic kernel
  2.2. 771M initramfs + 5.17.0-1011-oem kernel

  All working well.

  [Where problems could occur]

  * The changes almost in i386/efi, thus the impact will be in the i386 / 
x86_64 EFI system.
  The other change is to modify the “grub-core/kern/efi/mm.c” but I use the 
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
  Thus it should not impact them.

  * There is a “#if defined(__x86_64__)” which intent to limit the >
  32bits code in i386 system and also

  ```
   #if defined (__code_model_large__)
  -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
  +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
  +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
   #else
   #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
  +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
   #endif
  ```

  If everything works as expected, then i386 should working good.

  If not lucky, based on “UEFI writers’ guide”[2], 

[Touch-packages] [Bug 1983100] Re: dotnet build intermittently crashes with segfault on Ubuntu 18.04

[Mauricio Faria de Oliveira]

Nicolas and I talked about a brief review of the debdiff,
and he kindly agreed to provide an update/v2 to address:
- changelog version and description line
- patches dep3 headers and lpnumber- prefix

... while patches are reviewed for feedback (not yet done).

Thanks, Nicolas!

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

Title:
  dotnet build intermittently crashes with segfault on Ubuntu 18.04

Status in openssl package in Ubuntu:
  New
Status in openssl source package in Bionic:
  New

Bug description:
  [Impact]

  Bionic's OpenSSL 1.1.1 package
  (https://launchpad.net/ubuntu/bionic/+source/openssl) is the only
  version of openssl 1.1.1 on any distro that we've encountered that
  does not have support for the OPENSSL_NO_ATEXIT functionality from
  1.1.1b (openssl/openssl@c2b3db2).

  The threading model in .NET has the possibility that background
  threads are still running when exit() is called, which can cause
  SIGSEGV if a background thread interacts with OpenSSL after/while it
  has unloaded. For that reason, we always initialize OpenSSL 1.1.1 with
  the OPENSSL_NO_ATEXIT flag (which, of all the distros we run on only
  has no effect on Bionic).

  We feel that the stability of applications on Ubuntu 18.04 would be
  improved if the functionality of OPENSSL_NO_ATEXIT was merged into the
  bionic openssl 1.1.1 package, even if the constant isn't published
  into the header for the dev package.

  Context:
  https://github.com/dotnet/runtime/issues/48411#issuecomment-1178405101

  [Test Plan]

  The described behavior can be reproduced by passing the
  OPENSSL_NO_ATEXIT to the OPENSSL_init_ssl() call. The application will
  terminate with a SEGFAULT. More concretely, a minimal reproducer is:

  #include 
  #include 
  #include 

  #ifndef OPENSSL_INIT_NO_ATEXIT
  #define OPENSSL_INIT_NO_ATEXIT 0x0008L
  #endif

  static void print_error_string()
  {
  printf("print_error_string:\n");
  printf("ERR_reason_error_string(0) => %s\n", ERR_reason_error_string(0));
  }

  int main(int argc, char* argv[])
  {
  // register this handler first, so it runs last.
  atexit(print_error_string);

  OPENSSL_init_ssl(
  OPENSSL_INIT_ADD_ALL_CIPHERS |
  OPENSSL_INIT_ADD_ALL_DIGESTS |
  OPENSSL_INIT_LOAD_CONFIG |
  OPENSSL_INIT_NO_ATEXIT |
  OPENSSL_INIT_LOAD_CRYPTO_STRINGS |
  OPENSSL_INIT_LOAD_SSL_STRINGS,
  NULL);

  print_error_string();

  return 0;
  }

  Building

  $ sudo apt install libssl-dev
  $ gcc test.c -lssl -lcrypto
  $ ./a.out
  print_error_string:
  ERR_reason_error_string(0) => (null)
  print_error_string:
  Segmentation fault (core dumped)

  [Where problems could occur]

  The patches adds an option to the OPENSSL_init_crypto() function to
  disable the default behavior of calling of a cleanup function on
  application exit. The patch also includes a few bug fixes around
  various initializations that were supposed to happen once when running
  threaded but were not.

  These changes have the potential for regressions and it is conceivable
  that they lead to incorrect behavior. However, I have also backported
  and included all new testing functions in the hope that the changed
  behavior will get appropriate testing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1983100/+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 1951279] Re: OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds

[Mauricio Faria de Oliveira]

Update: this has been fixed in Focal (same fix commit):

openssl (1.1.1f-1ubuntu2.11) focal; urgency=medium

  * Fixup pointer authentication for armv8 systems that support it when
using the poly1305 MAC, preventing segmentation faults. (LP: #1960863)
- d/p/lp-1960863-crypto-poly1305-asm-fix-armv8-pointer-authenticat.patch

 -- Matthew Ruffell   Tue, 15 Feb 2022
10:10:01 +1300

** Changed in: openssl (Ubuntu Focal)
   Status: Confirmed => Fix Released

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

Title:
  OpenSSL 1.1.1f raise a segmentation faults on Arm64 builds

Status in OpenSSL:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  Fix Released
Status in openssl package in Debian:
  Fix Released

Bug description:
  Description
  ---

  It seems that current Ubuntu 20.04 (Focal) distribution for
  Arm64/Aarch64 raise a segmentation fault when certain validates some
  certificates.

  This issue affects only to Arm64/Aarch64 all the tools statically or
  dynamically linked with this version of the library are affected
  (Libcurl4, Curl, Wget, OpenJDK, Curl-PHP, etc).

  
  Environment and platform
  
  Linux 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:29:20 UTC 2021 aarch64 
aarch64 aarch64 GNU/Linux

  
  Steps to reproduce
  --

  1. Run:

  curl -v https://graph.facebook.com/v12.0/act_111/

  or

  wget https://graph.facebook.com/v12.0/act_111/

  
  Result received
  ---

  Segmentation fault (core dumped)

  
  Notes
  -

  This bug was found by the Curl users:
  See: https://github.com/curl/curl/issues/8024

  I believe that this bug is related to
  https://ubuntu.com/security/CVE-2020-1967 that maybe used as a vector
  point for code injection.

  Actually there isn't any replacement for OpenSSL 1.1.1f for Focal
  (Arm64), so it makes difficult to use Ubuntu 20.04 in a production
  environment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/1951279/+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 1947099] Re: ipconfig does not honour user-requested timeouts in some cases

[Mauricio Faria de Oliveira]

Setting verification-done-bionic per comments 39/40.

** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic

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

Title:
  ipconfig does not honour user-requested timeouts in some cases

Status in klibc package in Ubuntu:
  Won't Fix
Status in klibc source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  In some cases, ipconfig can take a longer time than the user-specified 
timeouts, causing unexpected delays.

  [Test Plan]

  - Check that the ipconfig utility is able to obtain an IP through
  dhcp:

  # ip l set dev ens9 down
  # date; /usr/lib/klibc/bin/ipconfig ens9; date

  - Check if it respects the timeout (i.e. 2 seconds in the example
  below):

  # ip l set dev ens9 down
  # date; /usr/lib/klibc/bin/ipconfig -t 2 ens9; date

  - The original issue is that timeout is being ignored when not
  receiving any reply from a DHCP Server, so for this test you have to
  stop your DHCP Server (i.e. dnsmasq) and then test the timeouts:

  # ip l set dev ens9 down
  # date; /usr/lib/klibc/bin/ipconfig -t 2 ens9; date

  # ip l set dev ens9 down
  # date; /usr/lib/klibc/bin/ipconfig -t 5 ens9; date

  Make sure it times out respectivelly in 2 and 5 seconds.

  [racb: pending agreement with the SRU team; please see comment 37]

  Any situation where ipconfig encounters an error sending the DHCP
  packet, it will automatically set a delay of 10 seconds, which could
  be longer than the user-specified timeout. It can be reproduced by
  creating a dummy interface and attempting to run ipconfig on it with a
  timeout value of less than 10:

  # ip link add eth1 type dummy
  # date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
  Thu Nov 18 04:46:13 EST 2021
  IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
  IP-Config: no response after 2 secs - giving up
  Thu Nov 18 04:46:23 EST 2021

  ^ Notice above, ipconfig thinks that it waited 2 seconds, but the
  timestamps show an actual delay of 10 seconds.

  [Where problems could occur]
  Please see reproduction steps above. We are seeing this in production too 
(see comment #2).

  [Other Info]
  A patch to fix the issue is being proposed here. It is a safe fix - it only 
checks before going into sleep that the timeout never exceeds the 
user-requested value.

  [Original Description]

  In some cases, ipconfig can take longer than the user-specified
  timeouts, causing unexpected delays.

  in main.c, in function loop(), the process can go into
  process_timeout_event() (or process_receive_event() ) and if it
  encounters an error situation, will set an attempt to "try again
  later" at time equal now + 10 seconds by setting

  s->expire = now + 10;

  This can happen at any time during the main event loop, which can end
  up extending the user-specified timeout if "now + 10" is greater than
  "start_time + user-specified-timeout".

  I believe a patch like the following is needed to avoid this problem:

  --- a/usr/kinit/ipconfig/main.c
  +++ b/usr/kinit/ipconfig/main.c
  @@ -437,6 +437,13 @@ static int loop(void)

  if (timeout > s->expire - now.tv_sec)
  timeout = s->expire - now.tv_sec;
  +
  +   /* Compensate for already-lost time */
  +   gettimeofday(, NULL);
  +   if (now.tv_sec + timeout > start + loop_timeout) {
  +   timeout = loop_timeout - (now.tv_sec - start);
  +   printf("Lowered timeout to match user request 
= (%d s) \n", timeout);
  +   }
  }

  I believe the current behaviour is buggy. This is confirmed when the
  following line is executed:

  if (loop_timeout >= 0 &&
  now.tv_sec - start >= loop_timeout) {
  printf("IP-Config: no response after %d "
     "secs - giving up\n", loop_timeout);
  rc = -1;
  goto bail;
  }

  'loop_timeout' is the user-specified time-out. With a value of 2, in
  case of error, this line prints:

  IP-Config: no response after 2 secs - giving up

  So it thinks that it waited 2 seconds - however, in reality it had
  actually waited for 10 seconds.

  The suggested code-change ensures that the timeout that is actually
  used never exceeds the user-specified timeout.

  [ Regression potential ]

  This change ensures that user-specified timeouts are never exceeded, which is 
a problem that appears to happen only in case of interface errors.
  It may be that someone is relying on current behaviour where they receive 
DHCP offers after 

[Touch-packages] [Bug 1834250] Re: update-grub complains about non-existent drives (due to cardreader)

[Mauricio Faria de Oliveira]

Verification done on focal-proposed; all good.

Host:
---

$ sudo dd if=/dev/sda of=/dev/null
dd: failed to open '/dev/sda': No medium found

$ lxc launch ubuntu:focal lp1834250
$ lxc config device add lp1834250 host-sda unix-block source=/dev/sda 
path=/dev/sda
$ lxc shell lp1834250

Container:
---

# lsb_release -cs
focal

focal-updates: error messages

# dpkg -s lvm2 | grep Version:
Version: 2.03.07-1ubuntu1

# vgs
  /dev/sda: open failed: No medium found
  /dev/sda: open failed: No medium found

# strace -e openat vgs 2>&1 | grep /dev/sda
openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_DIRECT|O_NOATIME) = -1 
ENOMEDIUM (No medium found)
openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_NOATIME) = -1 ENOMEDIUM (No 
medium found)
  /dev/sda: open failed: No medium found
openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_DIRECT|O_NOATIME) = -1 
ENOMEDIUM (No medium found)
openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_NOATIME) = -1 ENOMEDIUM (No 
medium found)
  /dev/sda: open failed: No medium found
# vgs
  /dev/sda: open failed: No medium found
  /dev/sda: open failed: No medium found

focal-proposed: no error messages; same syscall behavior

# echo 'deb http://archive.ubuntu.com/ubuntu focal-proposed main' 
>>/etc/apt/sources.list
# apt update
# apt-cache madison lvm2 | grep focal-proposed
  lvm2 | 2.03.07-1ubuntu1.1 | http://archive.ubuntu.com/ubuntu 
focal-proposed/main amd64 Packages
# apt install lvm2

# dpkg -s lvm2 | grep Version:
Version: 2.03.07-1ubuntu1.1

# vgs
#

# strace -e openat vgs 2>&1 | grep /dev/sda
openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_DIRECT|O_NOATIME) = -1 
ENOMEDIUM (No medium found)
openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_NOATIME) = -1 ENOMEDIUM (No 
medium found)
openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_DIRECT|O_NOATIME) = -1 
ENOMEDIUM (No medium found)
openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_NOATIME) = -1 ENOMEDIUM (No 
medium found)


** Tags removed: verification-needed-focal
** Tags added: verification-done-focal

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

Title:
  update-grub complains about non-existent drives (due to cardreader)

Status in lvm2 package in Ubuntu:
  Fix Released
Status in lvm2 source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * `update-grub` (actually `vgs`) complains about
     'No medium found' on systems with card readers
     that have no card in.

   * This may confuse users who aren't sure whether
     it means problems occurred with the bootloader,
     and concern their ability to safely boot again.

   * The workaround is to add a filter to LVM config,
     but this might be hard to find and error prone.
     (And not even seem relate to `update-grub` at
     all, specially on non-LVM storage layouts.)
     [See comment #16]

   * The fix replaces calls to `dev_open_readonly()`
 with `dev_open_readonly_quiet()` in scan path,
 where such errors are not a problem.

  [Test Plan]

   * Run `vgs` on a system with a card reader
     and check for 'No medium found' messages.

   * Run `strace -f -e openat vgs` to confirm
     system calls/error codes have no changes.

   * [See comment #20]

  [Where problems could occur]

   * The patch changes syscall error reporting on the
     'scan' path, so problems could occur when listing
     LVM resources in block devices (e.g., list volume
     groups with `vgs`).

   * There's little to no changes upstream on this area,
     and the change is present in Jammy; both help with
     a lower chance of regression.

  [Other Info]

   * `block-proposed-focal`: The upload is being staged
     as it's just a cosmetic change, but affects `lvm2`,
     which is present in so many systems, triggering a
     lot of upgrades/boot risk (in case something else
     broke and this upgrade could reveal it indirectly).

   * So, it will probably only be released once a more
     serious issue has to be fixed in `lvm2`.

   * Scope: Jammy has the fix, and Impish will EOL soon.

  [Original Bug Description]

  sudo update-grub

  Sourcing file `/etc/default/grub'
  Sourcing file `/etc/default/grub.d/init-select.cfg'
  Generating grub configuration file ...
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No 

[Touch-packages] [Bug 1834250] Re: update-grub complains about non-existent drives (due to cardreader)

[Mauricio Faria de Oliveira]

** Patch added: "lp1834250_lvm2_focal.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1834250/+attachment/5593897/+files/lp1834250_lvm2_focal.debdiff

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

Title:
  update-grub complains about non-existent drives (due to cardreader)

Status in lvm2 package in Ubuntu:
  Fix Released
Status in lvm2 source package in Focal:
  In Progress

Bug description:
  [Impact]

   * `update-grub` (actually `vgs`) complains about
     'No medium found' on systems with card readers
     that have no card in.

   * This may confuse users who aren't sure whether
     it means problems occurred with the bootloader,
     and concern their ability to safely boot again.

   * The workaround is to add a filter to LVM config,
     but this might be hard to find and error prone.
     (And not even seem relate to `update-grub` at
     all, specially on non-LVM storage layouts.)
     [See comment #16]

   * The fix replaces calls to `dev_open_readonly()`
 with `dev_open_readonly_quiet()` in scan path,
 where such errors are not a problem.

  [Test Plan]

   * Run `vgs` on a system with a card reader
     and check for 'No medium found' messages.

   * Run `strace -f -e openat vgs` to confirm
     system calls/error codes have no changes.

   * [See comment #20]

  [Where problems could occur]

   * The patch changes syscall error reporting on the
     'scan' path, so problems could occur when listing
     LVM resources in block devices (e.g., list volume
     groups with `vgs`).

   * There's little to no changes upstream on this area,
     and the change is present in Jammy; both help with
     a lower chance of regression.

  [Other Info]

   * `block-proposed-focal`: The upload is being staged
     as it's just a cosmetic change, but affects `lvm2`,
     which is present in so many systems, triggering a
     lot of upgrades/boot risk (in case something else
     broke and this upgrade could reveal it indirectly).

   * So, it will probably only be released once a more
     serious issue has to be fixed in `lvm2`.

   * Scope: Jammy has the fix, and Impish will EOL soon.

  [Original Bug Description]

  sudo update-grub

  Sourcing file `/etc/default/grub'
  Sourcing file `/etc/default/grub.d/init-select.cfg'
  Generating grub configuration file ...
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
  Found linux image: /boot/vmlinuz-5.0.0-17-generic
  Found initrd image: /boot/initrd.img-5.0.0-17-generic
  Found linux image: /boot/vmlinuz-5.0.0-16-generic
  Found initrd image: /boot/initrd.img-5.0.0-16-generic
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
  Adding boot menu entry for EFI firmware configuration
  done

  --

  lsblk

  

[Touch-packages] [Bug 1834250] Re: update-grub complains about non-existent drives (due to cardreader)

[Mauricio Faria de Oliveira]

Uploaded to Focal, and tagged block-proposed-focal.

Attaching slightly modified debdiff (local build version),
for users who want to build lvm2 before a SRU is released.

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

Title:
  update-grub complains about non-existent drives (due to cardreader)

Status in lvm2 package in Ubuntu:
  Fix Released
Status in lvm2 source package in Focal:
  In Progress

Bug description:
  [Impact]

   * `update-grub` (actually `vgs`) complains about
     'No medium found' on systems with card readers
     that have no card in.

   * This may confuse users who aren't sure whether
     it means problems occurred with the bootloader,
     and concern their ability to safely boot again.

   * The workaround is to add a filter to LVM config,
     but this might be hard to find and error prone.
     (And not even seem relate to `update-grub` at
     all, specially on non-LVM storage layouts.)
     [See comment #16]

   * The fix replaces calls to `dev_open_readonly()`
 with `dev_open_readonly_quiet()` in scan path,
 where such errors are not a problem.

  [Test Plan]

   * Run `vgs` on a system with a card reader
     and check for 'No medium found' messages.

   * Run `strace -f -e openat vgs` to confirm
     system calls/error codes have no changes.

   * [See comment #20]

  [Where problems could occur]

   * The patch changes syscall error reporting on the
     'scan' path, so problems could occur when listing
     LVM resources in block devices (e.g., list volume
     groups with `vgs`).

   * There's little to no changes upstream on this area,
     and the change is present in Jammy; both help with
     a lower chance of regression.

  [Other Info]

   * `block-proposed-focal`: The upload is being staged
     as it's just a cosmetic change, but affects `lvm2`,
     which is present in so many systems, triggering a
     lot of upgrades/boot risk (in case something else
     broke and this upgrade could reveal it indirectly).

   * So, it will probably only be released once a more
     serious issue has to be fixed in `lvm2`.

   * Scope: Jammy has the fix, and Impish will EOL soon.

  [Original Bug Description]

  sudo update-grub

  Sourcing file `/etc/default/grub'
  Sourcing file `/etc/default/grub.d/init-select.cfg'
  Generating grub configuration file ...
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
  Found linux image: /boot/vmlinuz-5.0.0-17-generic
  Found initrd image: /boot/initrd.img-5.0.0-17-generic
  Found linux image: /boot/vmlinuz-5.0.0-16-generic
  Found initrd image: /boot/initrd.img-5.0.0-16-generic
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
    /dev/sdc: open failed: No medium found
    /dev/sdd: open failed: No medium found
    /dev/sde: open failed: No medium found
    /dev/sdf: open failed: No medium found
  Adding boot menu entry for EFI firmware configuration
  done

  --

  lsblk