[Touch-packages] [Bug 2046844] Re: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP

2024-03-06 Thread Dimitri John Ledkov
** Also affects: firefox (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: firefox (Ubuntu)
Milestone: None => ubuntu-24.04

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

Title:
  AppArmor user namespace creation restrictions cause many applications
  to crash with SIGTRAP

Status in akonadiconsole package in Ubuntu:
  Fix Released
Status in akregator package in Ubuntu:
  Fix Released
Status in angelfish package in Ubuntu:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in bubblewrap package in Ubuntu:
  Confirmed
Status in cantor package in Ubuntu:
  Fix Released
Status in devhelp package in Ubuntu:
  Fix Released
Status in digikam package in Ubuntu:
  Fix Released
Status in epiphany-browser package in Ubuntu:
  Fix Released
Status in evolution package in Ubuntu:
  Fix Released
Status in falkon package in Ubuntu:
  Fix Released
Status in firefox package in Ubuntu:
  New
Status in freecad package in Ubuntu:
  Confirmed
Status in geary package in Ubuntu:
  Confirmed
Status in ghostwriter package in Ubuntu:
  Fix Released
Status in gnome-packagekit package in Ubuntu:
  Confirmed
Status in goldendict-webengine package in Ubuntu:
  Confirmed
Status in kalgebra package in Ubuntu:
  Fix Released
Status in kchmviewer package in Ubuntu:
  Confirmed
Status in kdeplasma-addons package in Ubuntu:
  Confirmed
Status in kgeotag package in Ubuntu:
  Fix Released
Status in kiwix package in Ubuntu:
  Confirmed
Status in kmail package in Ubuntu:
  Fix Released
Status in konqueror package in Ubuntu:
  Fix Released
Status in kontact package in Ubuntu:
  Fix Released
Status in marble package in Ubuntu:
  Fix Released
Status in notepadqq package in Ubuntu:
  Confirmed
Status in opam package in Ubuntu:
  Fix Released
Status in pageedit package in Ubuntu:
  Confirmed
Status in plasma-desktop package in Ubuntu:
  Confirmed
Status in plasma-welcome package in Ubuntu:
  Fix Released
Status in privacybrowser package in Ubuntu:
  Confirmed
Status in qmapshack package in Ubuntu:
  Confirmed
Status in qutebrowser package in Ubuntu:
  Confirmed
Status in rssguard package in Ubuntu:
  Confirmed
Status in steam package in Ubuntu:
  Fix Committed
Status in supercollider package in Ubuntu:
  Confirmed
Status in tellico package in Ubuntu:
  Fix Released

Bug description:
  Hi, I run Ubuntu development branch 24.04 and I have a problem with
  Epiphany browser 45.1-1 (Gnome Web): program doesn't launch, and I get
  this error

  $ epiphany
  bwrap: Creating new namespace failed: Permission denied

  ** (epiphany:12085): ERROR **: 14:44:35.023: Failed to fully launch 
dbus-proxy: Le processus fils s’est terminé avec le code 1
  Trappe pour point d'arrêt et de trace (core dumped)

  $ epiphany
  bwrap: Creating new namespace failed: Permission denied

  ** (epiphany:30878): ERROR **: 22:22:26.926: Failed to fully launch 
dbus-proxy: Le processus fils s’est terminé avec le code 1
  Trappe pour point d'arrêt et de trace (core dumped)

  Thanks for your help!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/akonadiconsole/+bug/2046844/+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 2055426] [NEW] busybox wget with https crashes

2024-02-29 Thread Dimitri John Ledkov
Public bug reported:

$ busybox wget https://start.ubuntu.com
Floating point exception (core dumped)

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: busybox (not installed)
ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4
Uname: Linux 6.8.0-11-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.28.0-0ubuntu1
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Thu Feb 29 13:55:07 2024
InstallationDate: Installed on 2024-02-20 (9 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240219)
ProcEnviron:
 LANG=en_US.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=
SourcePackage: busybox
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-bug noble wayland-session

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

Title:
  busybox wget with https crashes

Status in busybox package in Ubuntu:
  New

Bug description:
  $ busybox wget https://start.ubuntu.com
  Floating point exception (core dumped)

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: busybox (not installed)
  ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4
  Uname: Linux 6.8.0-11-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.28.0-0ubuntu1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb 29 13:55:07 2024
  InstallationDate: Installed on 2024-02-20 (9 days ago)
  InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240219)
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: busybox
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2055426/+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 2037604] Re: Backport packages for 22.04.4 HWE stack

2024-01-09 Thread Dimitri John Ledkov
i guess rebuilding gnome snaps with proposed on arm64 and testing that
new gnome snap on mantic for pi5 & x1s would help.

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

Title:
  Backport packages for 22.04.4 HWE stack

Status in directx-headers package in Ubuntu:
  Invalid
Status in mesa package in Ubuntu:
  Invalid
Status in rust-bindgen package in Ubuntu:
  Invalid
Status in rust-clang-sys package in Ubuntu:
  Invalid
Status in directx-headers source package in Jammy:
  Fix Committed
Status in mesa source package in Jammy:
  Fix Committed
Status in rust-bindgen source package in Jammy:
  Invalid
Status in rust-clang-sys source package in Jammy:
  Invalid

Bug description:
  [Impact]
  The graphics HWE stack from mantic needs to be backported for 22.04.4

  directx-headers
  - build-dep of the new Mesa

  mesa
  - new major release (23.2.x)
  - new HW support, Meteor Lake..

  [Test case]
  We want to cover at least 2-3 different, widely used and already previously 
supported GPU generations from both AMD and Intel which are supported by this 
release, as those are the ones that cover most bases; nouveau users tend to 
switch to the NVIDIA blob after installation. No need to test ancient GPU's 
supported by mesa-amber. And best to focus on the newer generations (~5y and 
newer) as the older ones are less likely to break at this point.
  - AMD: Vega, Navi1x (RX5000*), Navi2x (RX6000*), Navi3x (RX7000*)
  - Intel: gen9 (SKL/APL/KBL/CFL/WHL/CML), gen11 (ICL), gen12 (TGL/RKL/RPL/DG2)

  Install the new packages and run some tests:
  - check that the desktop is still using hw acceleration and hasn't fallen 
back to swrast/llvmpipe
  - run freely available benchmarks that torture the GPU (Unigine 
Heaven/Valley/Superposition)
  - run some games from Steam if possible

  and in each case check that there is no gfx corruption happening or
  worse.

  Note that upstream releases have already been tested for OpenGL and
  Vulkan conformance by their CI.

  [Where things could go wrong]
  This is a major update of Mesa, there could be regressions but we'll try to 
catch any with testing. And since it shares bugs with mantic, we'd already know 
if there are serious issues. We will backport the final 23.2.x at a later 
stage, the first backport is needed for enabling Intel Meteor Lake.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/directx-headers/+bug/2037604/+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 2046477] Re: Enable unprivileged user namespace restrictions by default

2024-01-02 Thread Dimitri John Ledkov
Can you please explain how all of this is handled during dist-upgrades?

Have all the packages with affected profiles have versioned depends
added?

Is the featured _not_ turned on during dist-upgrade from jammy hwe to
noble, but only after reboot? (as the kernel is compatible, yet during
upgrade the profiles may not be updated in the correct order)

** Changed in: apparmor (Ubuntu)
   Status: Fix Released => Triaged

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

Title:
  Enable unprivileged user namespace restrictions by default

Status in apparmor package in Ubuntu:
  Triaged

Bug description:
  As per https://discourse.ubuntu.com/t/spec-unprivileged-user-
  namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626,
  unprivileged user namespace restrictions for Ubuntu 23.10 are to be
  enabled by default via a sysctl.d conf file in apparmor, and for that
  to happen, the restrictions need to be enabled for 24.04

  When the unprivileged user namespace restrictions are enabled, various
  applications within and outside the Ubuntu archive fail to function,
  as they use unprivileged user namespaces as part of their normal
  operation.

  A search of the Ubuntu archive for the 23.10 release was performed
  looking for all applications that make legitimate use of the
  CLONE_NEWUSER argument, the details of which can be seen in
  
https://docs.google.com/spreadsheets/d/1MOPVoTW0BROF1TxYqoWeJ3c6w2xKElI4w-VjdCG0m9s/edit#gid=2102562502

  For each package identified in that list, an investigation was made to
  determine if the application actually used this as an unprivileged
  user, and if so which of the binaries within the package were
  affected.

  The full investigation can be seen in
  https://warthogs.atlassian.net/browse/SEC-1898 (which is unfortunately
  private) but is summarised to the following list of Ubuntu source
  packages, as well as some out-of-archive applications that are known
  to use unprivileged user namespaces.

  For each of these binaries, an apparmor profile is required so that
  the binary can be granted use of unprivileged user namespaces - an
  example profile for the ch-run binary within the charliecloud package
  is shown:

  $ cat /etc/apparmor.d/ch-run
  abi ,

  include 

  profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,

# Site-specific additions and overrides. See local/README for details.
include if exists 
  }

  However, in a few select cases, it has been decided not to ship an apparmor 
profile, since this would effectively allow this mitigation to be bypassed. In 
particular, the unshare and setns binaries within the util-linux package are 
installed on every Ubuntu system, and allow an unprivileged user the ability to 
launch an arbitrary application within a new user namespace. Any malicious 
application then that wished to exploit an unprivileged user namespace to 
conduct an attack on the kernel would simply need to spawn itself via `unshare 
-U` or similar to be granted this permission. Therefore, due to the ubiquitous 
nature of the unshare (and setns) binaries, profiles are not planned to be 
provided for these by default. 
  Similarly, the bwrap binary within bubblewrap is also installed by default on 
Ubuntu Desktop 24.04 and can also be used to launch arbitrary binaries within a 
new user namespace and so no profile is planned to be provided for this either.

  In Bug 2035315 new apparmor profiles were added to the apparmor
  package for various applications which require unprivileged user
  namespaces, using a new unconfined profile mode. They were also added
  in the AppArmor upstream project.

  As well as enabling the sysctl via the sysctl.d conf file, it is
  proposed to add logic into the apparmor.service systemd unit to check
  that the kernel supports the unconfined profile mode and that it is
  enabled - and if not then to force disable the userns restrictions
  sysctl via the following logic:

  userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns)
  unconfined_userns=$([ -f 
/sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] 
&& cat 
/sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || 
echo 0)
  if [ -n "$userns_restricted" ] && [ "$userns_restricted" -eq 1 ]; then
if [ "$unconfined_userns" -eq 0 ]; then
  # userns restrictions rely on unconfined userns to be supported
  echo "disabling unprivileged userns restrictions since unconfined userns 
is not supported / enabled"
  sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
fi
  fi

  This allows a local admin to disable the sysctl via the regular
  sysctl.d conf approach, but to also make sure we don't inadvertently
  enable it when it is not supported by the kernel.

To manage notifications about this bug go to:

[Touch-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable in noble

2023-12-11 Thread Dimitri John Ledkov
my expectation is that udev should be running (somewhere, not sure if it
needs to be both the host and the lxd guest) and that it should process
the device using locks https://systemd.io/BLOCK_DEVICE_LOCKING/.

After that is done, the device should be safe to operate on, in a
consistent manner.

After all,

   -P, --partscan
   Force the kernel to scan the partition table on a newly created
   loop device. Note that the partition table parsing depends on
   sector sizes. The default is sector size is 512 bytes, otherwise
   you need to use the option --sector-size together with --partscan.

Is only asking kernel to scan the device; to then generate "kernel udev"
events; for then udev to wakeup and process/emit "udev udev" events; and
create the required device nodes.

We have always been fixing and supporting running udev inside the lxd
containers, because of such things (in contexts of priviledged
containers, but outside of lp-buildd) to make all of this work.

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

Title:
  livecd-rootfs uses losetup -P for theoretically reliable/synchronous
  partition setup but it's not reliable in noble

Status in linux package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in util-linux package in Ubuntu:
  New

Bug description:
  In mantic, we migrated livecd-rootfs to use losetup -P instead of
  kpartx, with the expectation that this would give us a reliable, race-
  free way of loop-mounting partitions from a disk image during image
  build.

  In noble, we are finding that it is no longer reliable, and in fact
  fails rather often.

  It is most noticeable with riscv64 builds, which is the architecture
  where we most frequently ran into problems before with kpartx.  The
  first riscv64+generic build in noble where the expected loop partition
  device is not available is

https://launchpad.net/~ubuntu-
  cdimage/+livefs/ubuntu/noble/cpc/+build/531790

  The failure is however not unique to riscv64, and the autopkgtest for
  the latest version of livecd-rootfs (24.04.7) - an update that
  specifically tries to add more debugging code for this scenario - has
  also failed on ppc64el.

https://autopkgtest.ubuntu.com/packages/l/livecd-
  rootfs/noble/ppc64el

  The first failure happened on November 16.  While there has been an
  update to the util-linux package in noble, this did not land until
  November 23.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 1813581] Re: gpgme1.0 ftbfs in 18.04 LTS

2023-11-30 Thread Dimitri John Ledkov
can you please move such updates into esm-proposed instead?

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

Title:
  gpgme1.0 ftbfs in 18.04 LTS

Status in gpgme1.0 package in Ubuntu:
  Fix Released
Status in gpgme1.0 source package in Bionic:
  Won't Fix

Bug description:
  [Impact]
  according to
  
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html

  gpgme1.0 ftbfs.

  * Start testing of TofuInfoTest *
  Config: Using QtTest library 5.9.5, Qt 5.9.5 (x86_64-little_endian-lp64 
shared (dynamic) release build; by GCC 7.3.0)
  PASS   : TofuInfoTest::initTestCase()
  PASS   : TofuInfoTest::testTofuNull()
  PASS   : TofuInfoTest::testTofuInfo()
  PASS   : TofuInfoTest::testTofuSignCount()
  PASS   : TofuInfoTest::testTofuKeyList()
  PASS   : TofuInfoTest::testTofuPolicy()
  FAIL!  : TofuInfoTest::testTofuConflict() 'sig.validity() == 
Signature::Marginal' returned FALSE. ()
     Loc: [t-tofuinfo.cpp(458)]
  PASS   : TofuInfoTest::cleanupTestCase()
  Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 2386ms
  * Finished testing of TofuInfoTest *
  FAIL: t-tofuinfo

  [Test case]
  build it

  [Regression potential]
  This only changes the test suite run during build, and that one currently 
fails, so it can't cause any regression.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1813581/+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 1801762] Re: Dual-signed things should be easy to verify with one key

2023-11-29 Thread Dimitri John Ledkov
** Changed in: ubuntu-keyring (Ubuntu)
   Status: New => Confirmed

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

Title:
  Dual-signed things should be easy to verify with one key

Status in apt package in Ubuntu:
  New
Status in debmirror package in Ubuntu:
  New
Status in gnupg2 package in Ubuntu:
  New
Status in ubuntu-keyring package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  New

Bug description:
  As part of Ubuntu key rotation strategy, we rely on dual-signing
  (inline, or detached) such that validation with at least one key
  available in a keyring should be trusted, without using web-of-trust.

  However, it seems to be only correctly so far implemented by the apt's
  gpgv method.

  Ideally, we should ship an easy enough to use the helper that is `like
  gpgv` to use, and possibly reusing apt's gpgv code and/or exposing it
  via apt-key's verify.

  The problem seems to be that 1 good sig + 1 no public key available,
  results in gpgv exiting with 2, instead of 0 or 1.

  Ideally it should be easy enough to use gpgv/gpg to verify that at
  least one signature is good, and decrypt/extract signed contents only.

  More details and reproducers to follow.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1801762/+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 1437209] Re: package ubuntu-keyring 2012.05.19 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2

2023-11-27 Thread Dimitri John Ledkov
something is wrong with your install

gpg: keyblock resource `/etc/apt/trusted.gpg.d/webupd8team-sublime-text-2.gpg': 
resource limit
gpg: keyblock resource `/etc/apt/trusted.gpg.d/webupd8team-sublime-text-3.gpg': 
resource limit
gpg: keyblock resource `/etc/apt/trusted.gpg.d/webupd8team-tor-browser.gpg': 
resource limit
gpg: keyblock resource `/etc/apt/trusted.gpg.d/webupd8team-y-ppa-manager.gpg': 
resource limit


** Changed in: ubuntu-keyring (Ubuntu)
   Status: Confirmed => Invalid

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

Title:
  package ubuntu-keyring 2012.05.19 failed to install/upgrade:
  subprocess installed post-installation script returned error exit
  status 2

Status in ubuntu-keyring package in Ubuntu:
  Invalid

Bug description:
  This appeared randomly after upgrading from terminal. When I run
  software updater, it keeps prompting from "Partial upgrade"

  ProblemType: Package
  DistroRelease: Ubuntu 14.04
  Package: ubuntu-keyring 2012.05.19
  ProcVersionSignature: Ubuntu 3.13.0-46.79-generic 3.13.11-ckt15
  Uname: Linux 3.13.0-46-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.8
  AptOrdering:
   ubuntu-keyring: Install
   ubuntu-keyring: Configure
  Architecture: amd64
  Date: Fri Mar 27 13:43:09 2015
  DuplicateSignature: package:ubuntu-keyring:2012.05.19:subprocess installed 
post-installation script returned error exit status 2
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 2
  InstallationDate: Installed on 2014-05-08 (322 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  PackageArchitecture: all
  SourcePackage: ubuntu-keyring
  Title: package ubuntu-keyring 2012.05.19 failed to install/upgrade: 
subprocess installed post-installation script returned error exit status 2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1437209/+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 1060349] Re: package ubuntu-keyring 2011.11.21.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2

2023-11-27 Thread Dimitri John Ledkov
it seems maybe incompatible gnupg was installed on the system?

gpg: fatal: /etc/apt/trustdb.gpg: invalid trustdb


** Changed in: ubuntu-keyring (Ubuntu)
   Status: Confirmed => Invalid

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

Title:
  package ubuntu-keyring 2011.11.21.1 failed to install/upgrade:
  subprocess installed post-installation script returned error exit
  status 2

Status in ubuntu-keyring package in Ubuntu:
  Invalid

Bug description:
  I was trying to upgrade some programs .  And teminal says that my
  signing  key's weren't upgraded

  ProblemType: Package
  DistroRelease: Ubuntu 12.04
  Package: ubuntu-keyring 2011.11.21.1
  ProcVersionSignature: Ubuntu 3.2.0-31.50-generic-pae 3.2.28
  Uname: Linux 3.2.0-31-generic-pae i686
  ApportVersion: 2.0.1-0ubuntu12
  Architecture: i386
  Date: Tue Oct  2 12:06:52 2012
  Dependencies:
   
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 2
  InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 
(20120423)
  PackageArchitecture: all
  SourcePackage: ubuntu-keyring
  Title: package ubuntu-keyring 2011.11.21.1 failed to install/upgrade: 
subprocess installed post-installation script returned error exit status 2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1060349/+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 1553673] Re: package ubuntu-keyring 2012.05.19 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 2

2023-11-27 Thread Dimitri John Ledkov
Something is broken with these files:

gpg: /etc/apt/trusted.gpg.d/webupd8team-y-ppa-manager.gpg: recurso de bloqueo 
de claves: límite de recurso
gpg: /etc/apt/trusted.gpg.d/wine-wine-builds.gpg: recurso de bloqueo de claves: 
límite de recurso
gpg: /etc/apt/trusted.gpg.d/yorba-ppa.gpg: recurso de bloqueo de claves: límite 
de recurso

unrelated to ubuntu-keyring

** Changed in: ubuntu-keyring (Ubuntu)
   Status: New => Invalid

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

Title:
  package ubuntu-keyring 2012.05.19 failed to install/upgrade: el
  subproceso instalado el script post-installation devolvió el código de
  salida de error 2

Status in ubuntu-keyring package in Ubuntu:
  Invalid

Bug description:
  Fixed with this post forum:
  http://ubuntuforums.org/showthread.php?t=2257304=2

  Problem for exceeding or duplicate keys gpg. Possibly by way of adding
  PPA repositories.

  Thanks,
  David Gámiz Jiménez

  ProblemType: Package
  DistroRelease: Ubuntu 14.04
  Package: ubuntu-keyring 2012.05.19
  ProcVersionSignature: Ubuntu 3.13.0-79.123-generic 3.13.11-ckt33
  Uname: Linux 3.13.0-79-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.14.1-0ubuntu3.19
  AptOrdering:
   ubuntu-keyring: Install
   ubuntu-keyring: Configure
  Architecture: amd64
  Date: Sat Mar  5 10:54:29 2016
  DuplicateSignature: package:ubuntu-keyring:2012.05.19:el subproceso instalado 
el script post-installation devolvió el código de salida de error 2
  ErrorMessage: el subproceso instalado el script post-installation devolvió el 
código de salida de error 2
  InstallationDate: Installed on 2014-05-26 (649 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  PackageArchitecture: all
  RelatedPackageVersions:
   dpkg 1.17.5ubuntu5.5
   apt  1.0.1ubuntu2.11
  SourcePackage: ubuntu-keyring
  Title: package ubuntu-keyring 2012.05.19 failed to install/upgrade: el 
subproceso instalado el script post-installation devolvió el código de salida 
de error 2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1553673/+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 1897836] Re: package ubuntu-keyring 2012.05.19.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

2023-11-27 Thread Dimitri John Ledkov
something is wrong with your installation

gpg: invalid key resource URL `/etc/apt/trusted.gpg.d/home:osmc.gpg'

unrelated to this package

** Changed in: ubuntu-keyring (Ubuntu)
   Status: New => Won't Fix

** Changed in: ubuntu-keyring (Ubuntu)
   Status: Won't Fix => Invalid

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

Title:
  package ubuntu-keyring 2012.05.19.1 failed to install/upgrade:
  subprocess installed post-installation script returned error exit
  status 1

Status in ubuntu-keyring package in Ubuntu:
  Invalid

Bug description:
  - Ubuntu 16.04
  - ubuntu-keyring installed ver. 2012.05.19.1 (which is also the latest 
version)
  - I had previously had issues with an expired key from the OSMC installer, so 
I removed it, and after "sudo apt-get update" I've had no issues with 
mentioning that expired key. This issue with ubuntu-keyring now came up after 
the command "sudo apt-get upgrade" and looks like it could be related to that 
initial OSMC key issue.

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: ubuntu-keyring 2012.05.19.1
  ProcVersionSignature: Ubuntu 4.15.0-101.102~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-101-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.23
  Architecture: amd64
  Date: Tue Sep 29 21:49:03 2020
  ErrorMessage: subprocess installed post-installation script returned error 
exit status 1
  InstallationDate: Installed on 2017-07-07 (1181 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  PackageArchitecture: all
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.6
   apt  1.2.32ubuntu0.1
  SourcePackage: ubuntu-keyring
  Title: package ubuntu-keyring 2012.05.19.1 failed to install/upgrade: 
subprocess installed post-installation script returned error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1897836/+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 1752656] Re: Please SRU archive keyrings to older releases

2023-11-27 Thread Dimitri John Ledkov
SRU of debian keyring is also somehow counter productive. Most likely
usecase is to debootstrap unstable chroot. And for that to be done
correctly, often enough most recent debootstrap from debian is required
as otherwise the debootstrap might not complete, or complete incorrectly
(see all the recent usrmerge changes and flip-flops).

Similarly in Ubuntu keyring we have similar issue with debootstrap.
However we are trying to maintain as large overlap window as possible.

But it is impractical to SRU all keyrings ever, to all releases ever.
Thus this item is won't fix.

** Changed in: ubuntu-keyring (Ubuntu)
   Status: New => Won't Fix

** Changed in: debian-archive-keyring (Ubuntu)
   Status: New => Won't Fix

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

Title:
  Please SRU archive keyrings to older releases

Status in debian-archive-keyring package in Ubuntu:
  Won't Fix
Status in ubuntu-keyring package in Ubuntu:
  Won't Fix

Bug description:
  While not necessarily a critical issue for the Ubuntu keyrings, as
  Debian uses newer keys periodically, it becomes impossible with the
  default keyrings to verify the latest Debian archive files.

  It seems reasonable to ensure the keyring contents in all releases are
  the same, as the latest release is reflecting the latest archives.

  Related: bug 1801725

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-archive-keyring/+bug/1752656/+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 1776329] Re: apport-cli and cowbuilder fail with cert and keyring errors

2023-11-27 Thread Dimitri John Ledkov
** Changed in: ubuntu-keyring (Ubuntu)
   Status: Confirmed => Won't Fix

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

Title:
  apport-cli and cowbuilder fail with cert and keyring errors

Status in ubuntu-keyring package in Ubuntu:
  Won't Fix

Bug description:
  Description: Ubuntu 18.04 LTS
  Release: 18.04
  ubuntu-keyring:  Installed: 2018.02.28
  apport:  Installed: 2.20.9-0ubuntu7.2
  cowbuilder:  Installed: 0.86

  
  On a bionic system when attempting to report what I suspect is a bug in 
ubuntu-keying I got the following error

  start capture-
  $ apport-cli ubuntu-keyring

  *** Collecting problem information

  The collected information can be sent to the developers to improve the
  application. This might take a few minutes.
  .

  *** Send problem report to the developers?

  After the problem report has been sent, please fill out the form in the
  automatically opened web browser.

  What would you like to do? Your options are:
S: Send report (1.2 KB)
V: View report
K: Keep report file for sending later or copying to somewhere else
I: Cancel and ignore future crashes of this program version
C: Cancel
  Please choose (S/V/K/I/C): s

  *** Uploading problem information

  The collected information is being sent to the bug tracking system.
  This might take a few minutes.

  *** Error: Network problem

  Cannot connect to crash database, please check your Internet
  connection.

  

  Press any key to continue...  
  end capture---

  I worked around the problem by K'eeping the report and copying it to a
  Xenial system. From there I am submitting this bug report.

  The original problem that caused me to attempt to file a bug report
  against ubuntu-keyring was an attempt to build a bionic chroot for
  package building with the following command:

  start capture-
  # DIST=bionic cowbuilder --create --distribution bionic  --components "main 
universe" --basepath /var/cache/pbuilder/base-bionic-amd64-test.cow  --mirror 
http://us.archive.ubuntu.com:80/ubuntu --debootstrapopts 
--keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg
  I: Invoking pbuilder
  I: forking: pbuilder create --components 'main universe' --debootstrapopts 
--keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg --buildplace 
/var/cache/pbuilder/base-bionic-amd64-test.cow --mirror 
http://us.archive.ubuntu.com:80/ubuntu --distribution bionic --no-targz 
--extrapackages cowdancer
  W: /root/.pbuilderrc does not exist
  I: Running in no-targz mode
  I: Distribution is bionic.
  I: Current time: Mon Jun 11 22:44:21 UTC 2018
  I: pbuilder-time-stamp: 1528757061
  I: Building the build environment
  I: running debootstrap
  /usr/sbin/debootstrap
  I: Retrieving InRelease 
  I: Checking Release signature
  E: Release signed by unknown key (key id 3B4FE6ACC0B21F32)
  E: debootstrap failed
  E: Tail of debootstrap.log:
  gpgv: Signature made Thu Apr 26 23:38:40 2018 UTC
  gpgv:using RSA key 3B4FE6ACC0B21F32
  gpgv: Can't check signature: No public key
  E: End of debootstrap.log
  W: Aborting with an error
  E: pbuilder create failed
  I: forking: rm -rf /var/cache/pbuilder/base-bionic-amd64-test.cow
  end capture---

  On the same system the following command succeeds:

  start capture-
  DIST=xenial cowbuilder --create --distribution xenial \   
  
--components "main universe" \  
  
--basepath /var/cache/pbuilder/base-xenial-amd64.cow \  
  
--mirror http://us.archive.ubuntu.com:80/ubuntu \ 
--debootstrapopts --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg  
  
  end capture---

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: ubuntu-keyring 2018.02.28 [modified: 
usr/share/keyrings/ubuntu-archive-keyring.gpg]
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Mon Jun 11 22:51:48 2018
  Dependencies:
   
  PackageArchitecture: all
  ProcEnviron:
   LANG=en_US.UTF-8
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
  SourcePackage: ubuntu-keyring
  UpgradeStatus: No upgrade log present (probably fresh install)

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 2003701] Re: PKCS7: Message signed outside of X.509 validity window

2023-11-25 Thread Dimitri John Ledkov
I think UEFI spec says to not check timestamps against current time. But
I am not sure it says it is ok to have signature time to be outside of
the cert validity. Which violates pkcs7 signature spec.

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

Title:
  PKCS7: Message signed outside of X.509 validity window

Status in openssl package in Ubuntu:
  New
Status in sbsigntool package in Ubuntu:
  New

Bug description:
  When signing UEFI applications, the signature includes signing
  timestamp.

  Kernels, upon kexec, check that message signature is within the
  validity of the X.509 signing certificate.

  When using original canonical kernel team test key, I no longer can
  kexec kernels, as the test key has expired.

  UEFI specifications in general ignore signing time.

  IMHO we should remove / not include signing timestamp in the UEFI
  signatures to avoid this.

  ---

  i guess openssl needs to provide ability to create signatures without
  signingtime attribute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003701/+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 2041496] Re: btmgmt --index broken in Mantic

2023-11-21 Thread Dimitri John Ledkov
** Changed in: bluez (Ubuntu)
   Status: In Progress => Fix Committed

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

Title:
  btmgmt --index broken in Mantic

Status in Bluez Utilities:
  Unknown
Status in bluez package in Ubuntu:
  Fix Committed

Bug description:
  On Mantic:

  $ btmgmt --index 1 info
  Unable to open 1: No such file or directory (2)
  Index list with 1 item
  hci0: Primary controller
   addr B8:27:EB:CB:F8:8D version 9 manufacturer 305 class 0x6c
   supported settings: powered connectable fast-connectable discoverable 
bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy 
configuration static-addr phy-configuration
   current settings: powered ssp br/edr le secure-conn
   name rpi-5b-rev1d0-f88b
   short name
  hci0: Configuration options
   supported options: public-address
   missing options:

  Note the error 'Unable to open...' above.

  The machine has only a single hci so index 1 is invalid. The correct
  result should be:

  $ btmgmt --index 1 info
  Reading hci1 info failed with status 0x11 (Invalid Index)

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

2023-10-13 Thread Dimitri John Ledkov
Public bug reported:

[ 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

** Affects: ubuntu-meta (Ubuntu)
 Importance: Undecided
 Status: New

-- 
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:
  New

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 2039278] [NEW] Consistent naming of onboard NIC on all Pi on all Ubuntu

2023-10-13 Thread Dimitri John Ledkov
Public bug reported:

Consistent naming of onboard NIC on all Pi on all Ubuntu


We should have the one distro config, to force consistent oboard NIC naming on 
all Pi on all Ubuntu in the one place.

Let's find all the puzzle pieces and do it onces, and for all

** Affects: linux-raspi (Ubuntu)
 Importance: Undecided
 Status: New

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

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

** Affects: ubuntu-raspi-settings (Ubuntu)
 Importance: Undecided
 Status: New

** Also affects: ubuntu-raspi-settings (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: systemd-hwe (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-raspi (Ubuntu)
Milestone: None => later

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

Title:
  Consistent naming of onboard NIC on all Pi on all Ubuntu

Status in linux-raspi package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in systemd-hwe package in Ubuntu:
  New
Status in ubuntu-raspi-settings package in Ubuntu:
  New

Bug description:
  Consistent naming of onboard NIC on all Pi on all Ubuntu

  
  We should have the one distro config, to force consistent oboard NIC naming 
on all Pi on all Ubuntu in the one place.

  Let's find all the puzzle pieces and do it onces, and for all

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2039278/+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 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)

2023-10-12 Thread Dimitri John Ledkov
** Changed in: apparmor (Ubuntu)
   Status: Confirmed => Invalid

** Changed in: apparmor (Ubuntu Lunar)
   Status: Confirmed => Invalid

** Changed in: maas
   Status: Fix Committed => Fix Released

** Changed in: apparmor
   Status: Fix Committed => Fix Released

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

Title:
  udev fails to make prctl() syscall with apparmor=0 (as used by maas by
  default)

Status in AppArmor:
  Fix Released
Status in MAAS:
  Fix Released
Status in maas-images:
  Invalid
Status in apparmor package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in apparmor source package in Lunar:
  Invalid
Status in linux source package in Lunar:
  Fix Released
Status in systemd source package in Lunar:
  Invalid

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  Still gathering logs and info and will update as I go.

  
  Kernel Bug / Apparmor
  reproducer

  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
  $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd 
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'

  #start the VM
  
  Starting systemd-udevd version 252.5-2ubuntu3
  Spawning shell within the initramfs

  BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs) udevadm info --export-db
  Failed to set death signal: Invalid argument

  Observe that udevadm fails to setup death signal, with in systemd code
  is this

  
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
  util.c#L1252

  if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
  if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ? 
SIGINT : SIGTERM) < 0) {
  log_full_errno(prio, errno, "Failed to set death 
signal: %m");
  _exit(EXIT_FAILURE);
  }

  
  workaround set kernel commandline to `apparmor=1`
  

  MAAS bug
  Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor. 
Even for deployment and commisioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2016908/+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 2038909] Re: X13s desktop image is missing qcom power management tools

2023-10-11 Thread Dimitri John Ledkov
** Changed in: ubuntu-cdimage
   Status: New => Fix Committed

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

** Changed in: ubuntu-meta (Ubuntu)
Milestone: None => mantic-updates

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

Title:
  X13s desktop image is missing qcom power management tools

Status in Ubuntu CD Images:
  Fix Committed
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  X13s desktop image is missing qcom power management tools

  specifically protection-domain-mapper and qrtr-tools

  which potentially need MIR

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/2038909/+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 2038903] Re: X13s didn't run flashkernel as part of the install

2023-10-11 Thread Dimitri John Ledkov
** Also affects: ubuntu-meta (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  X13s didn't run flashkernel as part of the install

Status in Ubuntu CD Images:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  X13s didn't run flashkernel as part of the install

  hence dtb was not preset in /boot/ and thus installed system is
  incorrect.

  either we need to splice dtb into vmlinuz (which we can with sd-boot
  stub + zimg + devicetree) or make flashkernel run

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/2038903/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-06 Thread Dimitri John Ledkov
** Changed in: util-linux (Ubuntu Mantic)
   Status: New => Triaged

** Changed in: util-linux (Ubuntu Mantic)
   Importance: Undecided => Critical

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

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

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

** Changed in: ubuntu-power-systems
   Status: Confirmed => Invalid

** Changed in: maas-images
   Status: New => Confirmed

** Also affects: cloud-images
   Importance: Undecided
   Status: New

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in cloud-images:
  New
Status in maas-images:
  Confirmed
Status in The Ubuntu-power-systems project:
  Invalid
Status in Release Notes for Ubuntu:
  New
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in util-linux package in Ubuntu:
  Triaged
Status in linux source package in Mantic:
  Invalid
Status in systemd source package in Mantic:
  Invalid
Status in util-linux source package in Mantic:
  Triaged

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2037417/+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 2038567] Re: Disable restricting unprivileged change_profile by default, due to LXD latest/stable not yet compatible with this new apparmor feature

2023-10-06 Thread Dimitri John Ledkov
Fix under review https://lists.ubuntu.com/archives/kernel-
team/2023-October/146015.html

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

Title:
  Disable restricting unprivileged change_profile by default, due to LXD
  latest/stable not yet compatible with this new apparmor feature

Status in Release Notes for Ubuntu:
  New
Status in apparmor package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in lxd package in Ubuntu:
  Triaged
Status in snapd package in Ubuntu:
  New

Bug description:
  Following upgrade to 6.5.0-7 kernel in mantic cloud images we are
  seeing a regression in our cloud image tests. The test runs the
  following:

  ```
  lxd init --auto --storage-backend dir
  lxc launch ubuntu-daily:mantic mantic
  lxc info mantic
  lxc exec mantic -- cloud-init status --wait
  ```

  The `lxc exec mantic -- cloud-init status --wait` times out after 240s
  and will fail our test as a result.

  I have been able to replicate in a local VM

  ```
  wget 
http://cloud-images.ubuntu.com/mantic/20231005/mantic-server-cloudimg-amd64.img 
  wget --output-document=launch-qcow2-image-qemu.sh 
https://gist.githubusercontent.com/philroche/14c241c086a5730481e24178b654268f/raw/7af95cd4dfc8e1d0600e6118803d2c866765714e/gistfile1.txt
 
  chmod +x launch-qcow2-image-qemu.sh 

  ./launch-qcow2-image-qemu.sh --password passw0rd --image 
./mantic-server-cloudimg-amd64.img 
  cat < "./reproducer.sh"
  #!/bin/bash -eux
  lxd init --auto --storage-backend dir
  lxc launch ubuntu-daily:mantic mantic
  lxc info mantic
  lxc exec mantic -- cloud-init status --wait
  EOF
  chmod +x ./reproducer.sh
  sshpass -p passw0rd scp -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -P  ./reproducer.sh ubuntu@127.0.0.1:~/
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 sudo apt-get update
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 sudo apt-get upgrade 
--assume-yes
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 ./reproducer.sh
  ```

  The issue is not present with the 6.5.0-5 kernel and the issue is
  present regardless of the container launched. I tried the jammy
  container to test this.

  From my test VM

  ```
  ubuntu@cloudimg:~$ uname --all
  Linux cloudimg 6.5.0-7-generic #7-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 29 
09:14:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
  ubuntu@cloudimg:~$ uname --kernel-release
  6.5.0-7-generic
  ```

  This is a regression in our test that will block 23.10 cloud image
  release next week.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/2038567/+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 2038567] Re: Disable restricting unprivileged change_profile by default, due to LXD latest/snap not yet compatible with this new apparmor feature

2023-10-06 Thread Dimitri John Ledkov
** Summary changed:

- Mantic 6.5.0-7 kernel causes regression in LXD container usage
+ Disable restricting unprivileged change_profile by default, due to LXD 
latest/snap not yet compatible with this new apparmor feature

** Changed in: lxd (Ubuntu)
   Importance: Undecided => High

** Changed in: lxd (Ubuntu)
   Status: New => Triaged

** Changed in: linux (Ubuntu)
   Status: Incomplete => Triaged

** Summary changed:

- Disable restricting unprivileged change_profile by default, due to LXD 
latest/snap not yet compatible with this new apparmor feature
+ Disable restricting unprivileged change_profile by default, due to LXD 
latest/stable not yet compatible with this new apparmor feature

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

Title:
  Disable restricting unprivileged change_profile by default, due to LXD
  latest/stable not yet compatible with this new apparmor feature

Status in Release Notes for Ubuntu:
  New
Status in apparmor package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in lxd package in Ubuntu:
  Triaged
Status in snapd package in Ubuntu:
  New

Bug description:
  Following upgrade to 6.5.0-7 kernel in mantic cloud images we are
  seeing a regression in our cloud image tests. The test runs the
  following:

  ```
  lxd init --auto --storage-backend dir
  lxc launch ubuntu-daily:mantic mantic
  lxc info mantic
  lxc exec mantic -- cloud-init status --wait
  ```

  The `lxc exec mantic -- cloud-init status --wait` times out after 240s
  and will fail our test as a result.

  I have been able to replicate in a local VM

  ```
  wget 
http://cloud-images.ubuntu.com/mantic/20231005/mantic-server-cloudimg-amd64.img 
  wget --output-document=launch-qcow2-image-qemu.sh 
https://gist.githubusercontent.com/philroche/14c241c086a5730481e24178b654268f/raw/7af95cd4dfc8e1d0600e6118803d2c866765714e/gistfile1.txt
 
  chmod +x launch-qcow2-image-qemu.sh 

  ./launch-qcow2-image-qemu.sh --password passw0rd --image 
./mantic-server-cloudimg-amd64.img 
  cat < "./reproducer.sh"
  #!/bin/bash -eux
  lxd init --auto --storage-backend dir
  lxc launch ubuntu-daily:mantic mantic
  lxc info mantic
  lxc exec mantic -- cloud-init status --wait
  EOF
  chmod +x ./reproducer.sh
  sshpass -p passw0rd scp -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -P  ./reproducer.sh ubuntu@127.0.0.1:~/
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 sudo apt-get update
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 sudo apt-get upgrade 
--assume-yes
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 ./reproducer.sh
  ```

  The issue is not present with the 6.5.0-5 kernel and the issue is
  present regardless of the container launched. I tried the jammy
  container to test this.

  From my test VM

  ```
  ubuntu@cloudimg:~$ uname --all
  Linux cloudimg 6.5.0-7-generic #7-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 29 
09:14:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
  ubuntu@cloudimg:~$ uname --kernel-release
  6.5.0-7-generic
  ```

  This is a regression in our test that will block 23.10 cloud image
  release next week.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/2038567/+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 2036467] Re: superblock checksum mismatch in resize2fs

2023-10-05 Thread Dimitri John Ledkov
@rpocase please check internally I believe we have multiple azure & Aws
affected customers as per previous Salesforce escalations.

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

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  Confirmed
Status in e2fsprogs source package in Focal:
  New
Status in e2fsprogs source package in Jammy:
  New
Status in e2fsprogs source package in Mantic:
  Confirmed

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-05 Thread Dimitri John Ledkov
** Changed in: util-linux (Ubuntu Mantic)
Milestone: None => ubuntu-23.10

** Also affects: ubuntu-release-notes
   Importance: Undecided
   Status: New

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in The Ubuntu-power-systems project:
  Confirmed
Status in Release Notes for Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Confirmed
Status in util-linux package in Ubuntu:
  New
Status in linux source package in Mantic:
  Incomplete
Status in systemd source package in Mantic:
  Confirmed
Status in util-linux source package in Mantic:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2038567] Re: Mantic 6.5.0-7 kernel causes regression in LXD container usage

2023-10-05 Thread Dimitri John Ledkov
Current suspects are out of date apparmor features in livecd-rootfs
pending https://launchpad.net/ubuntu/+source/livecd-rootfs/23.10.55

kernel, apparmor, snapd, lxd, snapd again having fits about all of them
because of:

..
Make snap "snapd" (20092) available to the system

2023-10-05T19:04:57Z INFO Requested daemon restart (snapd snap).

..
Copy snap "lxd" data

2023-10-05T19:04:56Z ERROR unlinkat
/var/snap/lxd/common/var/lib/lxcfs/proc/cpuinfo: function not
implemented

..
Run install hook of "lxd" snap if present

2023-10-05T19:04:55Z ERROR run hook "install": cannot read mount
namespace identifier of pid 1: Permission denied


and also because of:

Oct 05 19:21:39 mantic-con-priv systemd[1]: snapd.service: Got notification 
message from PID 2560, but reception only permitted for main PID 2338
Oct 05 19:21:39 mantic-con-priv snapd[2338]: taskrunner.go:299: [change 7 
"Setup snap \"snapd\" (20092) security profiles" task] failed: cannot reload 
udev rules: exit status 1
Oct 05 19:21:39 mantic-con-priv snapd[2338]: udev output:
Oct 05 19:21:39 mantic-con-priv snapd[2338]: Failed to send reload request: No 
such file or directory
Oct 05 19:21:39 mantic-con-priv systemd[1]: snap-snapd-20092.mount: Deactivated 
successfully.
Oct 05 19:21:39 mantic-con-priv systemd[1]: snap-snapd-20092.mount: Unit 
process 2559 (snapfuse) remains running after unit stopped.
Oct 05 19:21:39 mantic-con-priv systemd[1]: Reloading requested from client PID 
2565 (unit snapd.service)...
Oct 05 19:21:39 mantic-con-priv systemd[1]: Reloading...
Oct 05 19:21:39 mantic-con-priv (sd-gens)[2568]: Read-only bind remount failed, 
ignoring: Permission denied


and because of:

Oct 05 19:20:58 cloudimg kernel: audit: type=1400
audit(1696533658.780:276): apparmor="DENIED" operation="mount"
class="mount" info="failed type match" error=-13 profile="lxd-dominant-
goldfish_" name="/snap/" pid=1940 comm="(sd-
gens)" flags="ro, remount, bind"

but could be util-linux too

** Also affects: apparmor (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: lxd (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: snapd (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Mantic 6.5.0-7 kernel causes regression in LXD container usage

Status in Release Notes for Ubuntu:
  New
Status in apparmor package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in lxd package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  New

Bug description:
  Following upgrade to 6.5.0-7 kernel in mantic cloud images we are
  seeing a regression in our cloud image tests. The test runs the
  following:

  ```
  lxd init --auto --storage-backend dir
  lxc launch ubuntu-daily:mantic mantic
  lxc info mantic
  lxc exec mantic -- cloud-init status --wait
  ```

  The `lxc exec mantic -- cloud-init status --wait` times out after 240s
  and will fail our test as a result.

  I have been able to replicate in a local VM

  ```
  wget 
http://cloud-images.ubuntu.com/mantic/20231005/mantic-server-cloudimg-amd64.img 
  wget --output-document=launch-qcow2-image-qemu.sh 
https://gist.githubusercontent.com/philroche/14c241c086a5730481e24178b654268f/raw/7af95cd4dfc8e1d0600e6118803d2c866765714e/gistfile1.txt
 
  chmod +x launch-qcow2-image-qemu.sh 

  ./launch-qcow2-image-qemu.sh --password passw0rd --image 
./mantic-server-cloudimg-amd64.img 
  cat < "./reproducer.sh"
  #!/bin/bash -eux
  lxd init --auto --storage-backend dir
  lxc launch ubuntu-daily:mantic mantic
  lxc info mantic
  lxc exec mantic -- cloud-init status --wait
  EOF
  chmod +x ./reproducer.sh
  sshpass -p passw0rd scp -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -P  ./reproducer.sh ubuntu@127.0.0.1:~/
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 sudo apt-get update
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 sudo apt-get upgrade 
--assume-yes
  sshpass -p passw0rd ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o 
StrictHostKeyChecking=no -p  ubuntu@127.0.0.1 ./reproducer.sh
  ```

  The issue is not present with the 6.5.0-5 kernel and the issue is
  present regardless of the container launched. I tried the jammy
  container to test this.

  From my test VM

  ```
  ubuntu@cloudimg:~$ uname --all
  Linux cloudimg 6.5.0-7-generic #7-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 29 
09:14:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
  ubuntu@cloudimg:~$ uname 

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

2023-10-05 Thread Dimitri John Ledkov
@foundations & EDM can we have this backported all the way to trusty?
Xenial for sure.

** Tags added: rls-mm-incoming

** Information type changed from Public to Public Security

** Also affects: cloud-images
   Importance: Undecided
   Status: New

** Changed in: cloud-images
   Importance: Undecided => Critical

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

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+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 2038512] Re: [Mediatek] mt8195-demo: please help to include these MediaTek drivers in initrd.img in CD/DVD release image

2023-10-05 Thread Dimitri John Ledkov
ubuntu kernel team does not handle which drivers do or do not get
included in the initrd.

Since this is stuff that affects generic, these should be added by
default for modules=most mode by initramfs-tools.

please contact ubuntu foundations team about this.

** Package changed: linux (Ubuntu) => initramfs-tools (Ubuntu)

** Changed in: initramfs-tools (Ubuntu)
   Status: Incomplete => New

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

Title:
  [Mediatek] mt8195-demo: please help to include these MediaTek drivers
  in initrd.img in CD/DVD release image

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  [Impact]
  Peripheral probe failure for MediaTek boards 'mt8195-demo' and 
'genio-1200-evk'.

  [Kernel version]
  6.2

  [Fix]
  I've used 'dracut' to examing the driver dependencies for boards 
'mt8195-demo' and 'genio-1200-evk'.
  It is able to buot into console and use USB port3. 
  Hope these drivers could help to run installer with USB disk in next daily 
build.

  Note: It won't work with 'update-initramfs -u -k 6.2.0-34-generic' if
  just simply add driver lists in '/etc/modules',
  '/etc/modprobe.d/mediatek.conf' or '/etc/modules-
  load.d/mediatek.conf'. I fixed this issue with 'dracut' and it seems
  this tool will include more common framework drivers into initrd.img.

  [MediaTek relate drivers]
  file: mediatek-drivers-for-mt8195-demo-bringup.txt
  (Not listed in probing sequence)

  i2c-mt65xx
  spi-mt65xx
  reset-ti-syscon
  mt6397
  rtc-mt6397
  mtk-pmic-wrap
  mt6315-regulator
  spmi-mtk-pmif
  mtk_scp_ipi
  mediatek-drm
  mtk-vcodec-dec
  mtk-vcodec-enc
  mtk_jpeg
  mtk-vcodec-common
  mtk-jpeg-enc-hw
  mtk-vpu
  mtk-jpeg-dec-hw
  mtk-cmdq-helper
  mtk-cmdq-helper
  mtk-cmdq-mailbox
  mtk-mdp3
  phy-mtk-mipi-dsi-drv
  btmtk
  leds-mt6360
  tcpci_mt6360
  mt6360_charger
  mt6360-regulator
  mt6360-core
  mt6359-regulator
  mt6360-adc
  snd-soc-mt8195-afe
  snd-soc-mtk-common
  snd-soc-dmic
  dwmac-mediatek
  stmmac-platform
  stmmac
  mtk-rng
  mtk_scp
  mtk_rpmsg
  pwm-mediatek
  pwm-mtk-disp
  nvmem_mtk-efuse
  mtk-sd
  cqhci
  phy-mtk-tphy
  mtu3
  xhci-mtk-hcd
  phy-mtk-pcie
  pcie-mediatek-gen3

  [lsmod log]
  file: lsmod-i1200-demo-kernel-6.2-dracut-initrd.txt

  [Other info]
  effected kernel (6.2-latest)
  ubuntu kernel for lunar, and Mantic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2038512/+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 2037642] Re: [FFe] Raspberry Pi 5 support

2023-10-05 Thread Dimitri John Ledkov
libcamera is not shipped on the images, and will be SRUed once tested.

** Changed in: pipewire (Ubuntu)
   Status: Triaged => Invalid

** Changed in: libcamera (Ubuntu)
Milestone: None => mantic-updates

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

Title:
  [FFe] Raspberry Pi 5 support

Status in libcamera package in Ubuntu:
  Triaged
Status in linux-meta-raspi package in Ubuntu:
  Fix Released
Status in linux-raspi package in Ubuntu:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Released
Status in pipewire package in Ubuntu:
  Invalid
Status in rpi-eeprom package in Ubuntu:
  Fix Released
Status in ubuntu-settings package in Ubuntu:
  Fix Released

Bug description:
  [ Impact ]

   * HWE for Raspberry Pi 5 https://raspberrypi.com/5

  [ Test Plan ]

   * Private builds tested on all existing/supported Raspberry Pi SKUs
  in armhf & arm64 variants

   * No regressions on any existing SKUs

   * Test that Raspberry Pi 5 boards work

  [ Where problems could occur ]

   * Mesa is upgraded, and there are patches to mesa, the raspberry-pi
  specific provider this has been tested but not as extensively.
  Separately there is mesa FFe granted to upgrade to latest release,
  thus these changes piggy-back on top of it.

   * libcamera has new build-depends on new package libpisp for the
  raspberry-pi specific provider which also affects pipewire to provide
  full webcam support.

   * These dependencies, will need to make their way into gnome platform
  snaps to be usable by default in Firefox.

  [ Other Info ]

   * The proposed code changes have been tested in private, prior to
  public announcement

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libcamera/+bug/2037642/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-04 Thread Dimitri John Ledkov
I believe reproducer is:

wget 
https://images.maas.io/ephemeral-v3/candidate/mantic/amd64/20231004.1/ga-23.10/generic/boot-kernel
wget 
https://images.maas.io/ephemeral-v3/candidate/mantic/amd64/20231004.1/ga-23.10/generic/boot-initrd

qemu-system-x86_64 -m 4G -smp 2 -nic user,model=virtio-net-pci -kernel
boot-kernel -initrd boot-initrd --append 'ip=dhcp
root=squash:http://images.maas.io/ephemeral-v3/candidate/mantic/amd64/20231004.1/squashfs
overlayroot=tmpfs overlayroot_cfgdisk=disabled systemd.log_level=debug
systemd.log_target=console systemd.journald.forward_to_console=1
debug=y'


for faster download you might want to have squashfs on local lan

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in The Ubuntu-power-systems project:
  Confirmed
Status in linux package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Confirmed
Status in linux source package in Mantic:
  Incomplete
Status in systemd source package in Mantic:
  Confirmed

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2036968] Re: Mantic minimized/minimal cloud images do not receive IP address during provisioning

2023-10-02 Thread Dimitri John Ledkov
analysis at https://github.com/canonical/cloud-init/issues/4451
identified systemd regression that is affecting mantic
the kernel workaround is here for virtio-net, but not for all other NIC types, 
i.e. e1000
and will likely affect other users too, not just cloud-init use case.

Request to consider fixing https://github.com/canonical/cloud-
init/issues/4451#issuecomment-1733881643 in systemd in Mantic for GA, or
0-day sru.

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: rls-mm-incoming

** Summary changed:

- Mantic minimized/minimal cloud images do not receive IP address during 
provisioning
+ Mantic minimized/minimal cloud images do not receive IP address during 
provisioning; systemd regression with wait-online

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

Title:
  Mantic minimized/minimal cloud images do not receive IP address during
  provisioning; systemd regression with wait-online

Status in cloud-images:
  New
Status in linux package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  New

Bug description:
  Following a recent change from linux-kvm kernel to linux-generic
  kernel in the mantic minimized images, there is a reproducable bug
  where a guest VM does not have an IP address assigned as part of
  cloud-init provisioning.

  This is easiest to reproduce when emulating arm64 on amd64 host. The
  bug is a race condition, so there could exist fast enough
  virtualisation on fast enough hardware where this bug is not present
  but in all my testing I have been able to reproduce.

  The latest mantic minimized images from http://cloud-
  images.ubuntu.com/minimal/daily/mantic/ have force initrdless boot and
  no initrd to fallback to.

  This but is not present in the non minimized/base images @
  http://cloud-images.ubuntu.com/mantic/ as these boot with initrd with
  the required drivers present for virtio-net.

  Reproducer

  ```
  wget -O "launch-qcow2-image-qemu-arm64.sh" 
https://people.canonical.com/~philroche/20230921-cloud-images-mantic-fail-to-provision/launch-qcow2-image-qemu-arm64.sh

  chmod +x ./launch-qcow2-image-qemu-arm64.sh
  wget 
https://people.canonical.com/~philroche/20230921-cloud-images-mantic-fail-to-provision/livecd.ubuntu-cpc.img
  ./launch-qcow2-image-qemu-arm64.sh --password passw0rd --image 
./livecd.ubuntu-cpc.img
  ```

  You will then be able to log in with user `ubuntu` and password
  `passw0rd`.

  You can run `ip a` and see that there is a network interface present
  (separate to `lo`) but no IP address has been assigned.

  ```
  ubuntu@cloudimg:~$ ip a
  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: enp0s1:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

  ```

  This is because when cloud-init is trying to configure network
  interfaces it doesn't find any so it doesn't configure any. But by the
  time boot is complete the network interface is present but cloud-init
  provisioning has already completed.

  You can verify this by running `sudo cloud-init clean && sudo cloud-
  init init`

  You can then see a successfully configured network interface

  ```
  ubuntu@cloudimg:~$ ip a
  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: enp0s1:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
  link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
  inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s1
     valid_lft 86391sec preferred_lft 86391sec
  inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic mngtmpaddr 
noprefixroute
     valid_lft 86393sec preferred_lft 14393sec
  inet6 fe80::5054:ff:fe12:3456/64 scope link
     valid_lft forever preferred_lft forever

  ```

  The bug is also reproducible with amd64 guest on adm64 host on
  older/slower hardware.

  The suggested fixes while debugging this issue are:

  * to include `virtio-net` as a built-in in the mantic generic kernel
  * understand what needs to change in cloud-init so that it can react to late 
additions of network interfaces

  I will file a separate bug against cloud-init to address the race
  condition on emulated guest/older hardware.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036968/+subscriptions


-- 
Mailing list: 

[Touch-packages] [Bug 2037202] Re: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up

2023-10-02 Thread Dimitri John Ledkov
I request this to be considered release critical, as this prevents all
kernel team & certification team deployments of mantic systems,
inhibiting our ability to test SRUs on all architectures.

** Tags added: rls-mm-incoming

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

Title:
  Mantic/23.10: PXE boot tries to initialize DHCP before network link is
  up

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  I'm not sure whether this is the correct package for this bug, please
  reassign if not.

  I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in
  order to perform an unattended installation. The kernel command line
  looks like that:

  iso/casper/vmlinuz --- ip=dhcp netboot=nfs
  nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s=

  This has worked perfectly before. However, in 23.10, the kernel tries
  to intialize DHCP before a network link is up.

  I can see a few instances of messages like the following:
  dhcpcd-10.0.2 starting
  dev: loaded udev
  no interfaces have a carrier
  exiting due to oneshot
  dhcpcd exited

  Then, the kernel tries to mount NFS, even though neither an IP address nor 
even a link is available:
  connect: Network is unreachable
  NFS over TCP not available from 192.168.1.1

  This is repeated for a while. In between, a message tells that now the link 
is up:
  [10.0002805] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: Rx/Tx

  The NFS messages repeat for a while, until the system gives up and I'm
  dropped into a busybox prompt.

  Executing dhcpcd now correctly gets IP addresses, but I don't know how
  to continue the boot from there.

  The problem occurs on most physical machines that I tried, but not in
  VMs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202/+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 1923363] Re: Grant access to hardware (UARTs, I2C, etc.) via custom udev rules

2023-09-30 Thread Dimitri John Ledkov
Does this have FFe?

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

Title:
  Grant access to hardware (UARTs, I2C, etc.) via custom udev rules

Status in cloud-init package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  Invalid
Status in ubuntu-settings package in Ubuntu:
  Confirmed
Status in user-setup package in Ubuntu:
  Invalid
Status in cloud-init source package in Impish:
  Won't Fix
Status in ubiquity source package in Impish:
  Invalid
Status in ubuntu-settings source package in Impish:
  Won't Fix
Status in user-setup source package in Impish:
  Invalid
Status in cloud-init source package in Jammy:
  Confirmed
Status in ubiquity source package in Jammy:
  Invalid
Status in ubuntu-settings source package in Jammy:
  Confirmed
Status in user-setup source package in Jammy:
  Invalid
Status in cloud-init source package in Kinetic:
  Won't Fix
Status in ubiquity source package in Kinetic:
  Invalid
Status in ubuntu-settings source package in Kinetic:
  Won't Fix
Status in user-setup source package in Kinetic:
  Invalid
Status in cloud-init source package in Lunar:
  Won't Fix
Status in ubiquity source package in Lunar:
  Invalid
Status in ubuntu-settings source package in Lunar:
  Won't Fix
Status in user-setup source package in Lunar:
  Invalid
Status in cloud-init source package in Mantic:
  Fix Released
Status in ubiquity source package in Mantic:
  Invalid
Status in ubuntu-settings source package in Mantic:
  Confirmed
Status in user-setup source package in Mantic:
  Invalid

Bug description:
  We're attempting to make the GPIO system on the Raspberry Pi images
  work "out of the box" on the new image. By default, GPIO kernel
  devices are made available to members of the "dialout" group which the
  initial user is added to by default on our server images. However,
  we've noticed that this isn't the case on the desktop images.

  The regression potential is minimal; the group already exists and
  we're simply adding the freshly created user to a new group and not
  removing any existing memberships. The group in question ("dialout")
  is also rarely used these days except for providing access to serial
  consoles, and as mentioned above is already a default membership on
  the server images. The change has been tested on the desktop image
  successfully.

  A test build of the updated image will be made under
  https://launchpad.net/~waveform/+archive/ubuntu/ubiquity and I'll
  attach a debdiff shortly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1923363/+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 2037642] Re: [FFe] Raspberry Pi 5 support

2023-09-30 Thread Dimitri John Ledkov
I cannot tell if
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1923363 has FFe
or not for the uaccess addition on udev rules.

** Changed in: mesa (Ubuntu)
   Status: Triaged => Fix Committed

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

Title:
  [FFe] Raspberry Pi 5 support

Status in libcamera package in Ubuntu:
  Triaged
Status in linux-meta-raspi package in Ubuntu:
  Triaged
Status in linux-raspi package in Ubuntu:
  Triaged
Status in mesa package in Ubuntu:
  Fix Committed
Status in pipewire package in Ubuntu:
  Triaged
Status in rpi-eeprom package in Ubuntu:
  Fix Released
Status in ubuntu-settings package in Ubuntu:
  Triaged

Bug description:
  [ Impact ]

   * HWE for Raspberry Pi 5 https://raspberrypi.com/5

  [ Test Plan ]

   * Private builds tested on all existing/supported Raspberry Pi SKUs
  in armhf & arm64 variants

   * No regressions on any existing SKUs

   * Test that Raspberry Pi 5 boards work

  [ Where problems could occur ]

   * Mesa is upgraded, and there are patches to mesa, the raspberry-pi
  specific provider this has been tested but not as extensively.
  Separately there is mesa FFe granted to upgrade to latest release,
  thus these changes piggy-back on top of it.

   * libcamera has new build-depends on new package libpisp for the
  raspberry-pi specific provider which also affects pipewire to provide
  full webcam support.

   * These dependencies, will need to make their way into gnome platform
  snaps to be usable by default in Firefox.

  [ Other Info ]

   * The proposed code changes have been tested in private, prior to
  public announcement

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libcamera/+bug/2037642/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-09-29 Thread Dimitri John Ledkov
I wonder if this is duplicate of
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202

And if the workaround in
https://bugs.launchpad.net/ubuntu/+source/initramfs-
tools/+bug/2037202/comments/1 can keep us going

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037642] [NEW] [FFe] Raspberry Pi 5 support

2023-09-28 Thread Dimitri John Ledkov
Public bug reported:

[ Impact ]

 * HWE for Raspberry Pi 5 https://raspberrypi.com/5

[ Test Plan ]

 * Private builds tested on all existing/supported Raspberry Pi SKUs in
armhf & arm64 variants

 * No regressions on any existing SKUs

 * Test that Raspberry Pi 5 boards work

[ Where problems could occur ]

 * Mesa is upgraded, and there are patches to mesa, the raspberry-pi
specific provider this has been tested but not as extensively.
Separately there is mesa FFe granted to upgrade to latest release, thus
these changes piggy-back on top of it.

 * libcamera has new build-depends on new package libpisp for the
raspberry-pi specific provider which also affects pipewire to provide
full webcam support.

 * These dependencies, will need to make their way into gnome platform
snaps to be usable by default in Firefox.

[ Other Info ]

 * The proposed code changes have been tested in private, prior to
public announcement

** Affects: libcamera (Ubuntu)
 Importance: Undecided
 Status: Confirmed

** Affects: linux-firmware-raspi (Ubuntu)
 Importance: Undecided
 Status: Confirmed

** Affects: linux-meta-raspi (Ubuntu)
 Importance: Undecided
 Status: Confirmed

** Affects: linux-raspi (Ubuntu)
 Importance: Undecided
 Status: Confirmed

** Affects: mesa (Ubuntu)
 Importance: Undecided
 Status: Confirmed

** Affects: pipewire (Ubuntu)
 Importance: Undecided
 Status: Confirmed

** Affects: rpi-eeprom (Ubuntu)
 Importance: Undecided
 Status: Confirmed

** Affects: ubuntu-settings (Ubuntu)
 Importance: Undecided
 Status: Confirmed

** Also affects: linux-meta-raspi (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: mesa (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: libcamera (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: pipewire (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: linux-firmware-raspi (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: rpi-eeprom (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: rpiboot (Ubuntu)
   Importance: Undecided
   Status: New

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

** Description changed:

  [ Impact ]
  
-  * HWE for Raspberry Pi 5 https://raspberrypi.com/5
+  * HWE for Raspberry Pi 5 https://raspberrypi.com/5
  
  [ Test Plan ]
  
-  * Private builds tested on all existing/supported Raspberry Pi SKUs in
+  * Private builds tested on all existing/supported Raspberry Pi SKUs in
  armhf & arm64 variants
  
-  * No regressions on any existing SKUs
+  * No regressions on any existing SKUs
  
-  * Test that Raspberry Pi 5 boards work
+  * Test that Raspberry Pi 5 boards work
  
  [ Where problems could occur ]
  
-  * Mesa is upgraded, and there are patches to mesa, the raspberry-pi
+  * Mesa is upgraded, and there are patches to mesa, the raspberry-pi
  specific provider this has been tested but not as extensively.
  Separately there is mesa FFe granted to upgrade to latest release, thus
  these changes piggy-back on top of it.
  
-  * libcamera has new build-depends for the raspberry-pi specific
- provider which also affects pipewire to provide full webcam support.
+  * libcamera has new build-depends on new package libpisp for the
+ raspberry-pi specific provider which also affects pipewire to provide
+ full webcam support.
  
-  * These dependencies, will need to make their way into gnome platform
+  * These dependencies, will need to make their way into gnome platform
  snaps to be usable by default in Firefox.
  
  [ Other Info ]
-  
-  * The proposed code changes have been tested in private, prior to public 
announcement
+ 
+  * The proposed code changes have been tested in private, prior to
+ public announcement

** Summary changed:

- Raspberry Pi 5 support
+ [FFe] Raspberry Pi 5 support

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

Title:
  [FFe] Raspberry Pi 5 support

Status in libcamera package in Ubuntu:
  Confirmed
Status in linux-firmware-raspi package in Ubuntu:
  Confirmed
Status in linux-meta-raspi package in Ubuntu:
  Confirmed
Status in linux-raspi package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  Confirmed
Status in pipewire package in Ubuntu:
  Confirmed
Status in rpi-eeprom package in Ubuntu:
  Confirmed
Status in ubuntu-settings package in Ubuntu:
  Confirmed

Bug description:
  [ Impact ]

   * HWE for Raspberry Pi 5 https://raspberrypi.com/5

  [ Test Plan ]

   * Private builds tested on all existing/supported Raspberry Pi SKUs
  in armhf & arm64 variants

   * No regressions on any existing SKUs

   * Test that Raspberry Pi 5 boards work

  [ Where problems could occur ]

   * Mesa is upgraded, and there are patches to mesa, the 

[Touch-packages] [Bug 2037425] Re: ubuntu-server pulls in ZFS userspace

2023-09-26 Thread Dimitri John Ledkov
** Changed in: ubuntu-meta (Ubuntu Mantic)
Milestone: None => ubuntu-23.10

** Tags added: rls-mm-incoming

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

Title:
  ubuntu-server pulls in ZFS userspace

Status in ubuntu-meta package in Ubuntu:
  New
Status in ubuntu-meta source package in Mantic:
  New

Bug description:
  ubuntu-server in Mantic pulls in zfs userspace packages and systemd
  services are automatically enabled, which means zfs kernel modules are
  automatically loaded at boot, for everybody. On Raspberry Pi, this
  results in +5MB of additional memory consumption which is not
  acceptable, especially not on 512MB devices.

  Culprit:
  
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=36c17dbdbfd13f1b386aa86d065a8a9d34c48a35

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2037425/+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 2037417] Re: mantic arm64 images are failing to deploy with failure to mount root and kernel filesystems

2023-09-26 Thread Dimitri John Ledkov
** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  mantic arm64 images are failing to deploy with failure to mount root
  and kernel filesystems

Status in maas-images:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2036885] Re: please add API to exclude things

2023-09-21 Thread Dimitri John Ledkov
dracut-install has these options:
  -P --mod-filter-nopathExclude kernel modules by path regexp
  -N --mod-filter-nonameExclude kernel modules by name regexp

I'm more thinking along the lines of:

rm_modules_dir()
rm_modules()

Which would apply mod-filter-nopath / mod-filter-noname, after the full
list of modules to include has been assembled.

I am assuming that any add module requests are bundled together into a
single dracut-install call, such that rm_modules()/rm_modules_dir() call
will be effective.

Then raspberri pi hook may have a list of things to exclude, which can
then be optionally disabled based on the toggles it would have.

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

Title:
  please add API to exclude things

Status in initramfs-tools package in Ubuntu:
  Triaged

Bug description:
  Please add API to exclude things

  It would be useful on Pi to say "yes include all graphics" but do
  exclude "amdgpu, nvidia" drivers and firmware related to those.

  Something along the lines of a "exclude filter list" for drivers &
  firmware.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2036885/+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 2036886] Re: please add api to repack initramfs

2023-09-21 Thread Dimitri John Ledkov
** Description changed:

  please add api to repack initramfs
  
- from the results of unpackinitramfs, including all early & main dirs
+ from the results of unpackinitramfs, including all early & main dirs.
+ 
+ Userstory: i want to tweak my initrd in-place by replacing broken
+ libc.so.6 with a patched one, I want to use unmkinitramfs, modify files
+ in main, repack it and boot it.
+ 
+ CLI:
+ 
+ $ unmkinitramfs /boot/initrd.img unpacked-initrd
+ $ ls unpacked-initrd/
+ early  early2  main
+ $ (edit things in unpacked-initrd/main/)
+ $ remkinitramfs unpacked-initrd patched-initrd.img
+ 
+ Where patched-initrd.img is now similar to /boot/initrd.img, apart from
+ the changed things.
+ 
+ I expect remkinitramfs like functionality that will take the output of
+ unmkinitramfs (e.g. unpacked-initrd/) directory as input, do
+ uncompressed cpio archives out of all the subdirs, make compressed cpio
+ archive out of main, and produce a patched-initrd.img that is ready for
+ booting.
+ 
+ It is very close to what mkinitramfs does, but skip calling all the
+ hooks to create things a fresh, and just do the final assembly step of
+ cpio and compression.

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

Title:
  please add api to repack initramfs

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  please add api to repack initramfs

  from the results of unpackinitramfs, including all early & main dirs.

  Userstory: i want to tweak my initrd in-place by replacing broken
  libc.so.6 with a patched one, I want to use unmkinitramfs, modify
  files in main, repack it and boot it.

  CLI:

  $ unmkinitramfs /boot/initrd.img unpacked-initrd
  $ ls unpacked-initrd/
  early  early2  main
  $ (edit things in unpacked-initrd/main/)
  $ remkinitramfs unpacked-initrd patched-initrd.img

  Where patched-initrd.img is now similar to /boot/initrd.img, apart
  from the changed things.

  I expect remkinitramfs like functionality that will take the output of
  unmkinitramfs (e.g. unpacked-initrd/) directory as input, do
  uncompressed cpio archives out of all the subdirs, make compressed
  cpio archive out of main, and produce a patched-initrd.img that is
  ready for booting.

  It is very close to what mkinitramfs does, but skip calling all the
  hooks to create things a fresh, and just do the final assembly step of
  cpio and compression.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2036886/+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 2036611] Re: FFe: Mesa 23.2.0

2023-09-21 Thread Dimitri John Ledkov
** Description changed:

  Upstream still hasn't released Mesa 23.2.0 (as of Sep 19th) which is
  almost seven weeks past it's original release date. But at least we have
  an rc3 which is "only" two weeks old. Yes, we are getting close to
  mantic release but this series is something we want for Intel Meteor
  Lake support.
  
  This is now fresh in Debian unstable, and has been in Fedora 39 for a
  month already without any apparent drama.
  
  Build available at the x-staging ppa
  https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages
  (status: i386 build failed due to an upstream bug, which requires 
llvmspirvlib headers to exist even if rusticl OpenCL driver is not enabled)
  
- 
- xnox: Separately to amd64, this new mesa would also be useful on many arm64 
platforms with a lot of improvements for RaspberryPi, Ubuntu Concept X13s, and 
Apple / Asahi hardware.
+ xnox: Separately to amd64, this new mesa would also be useful on many
+ arm64 platforms with a lot of improvements for RaspberryPi, Ubuntu
+ Concept X13s, and Apple / Asahi hardware.
  
  I strongly request that upgrade of mesa is also considered because of
  the Arm platform improvements in Mesa 23.2.0.
+ 
+ The request is to ship rc, SRU upto final upstream GA .0 release, and
+ enforce SRU policy after that.
+ 
+ Other distributions are also shipping this Mesa RC largely due to the
+ very same reasons, thus this will align hardware compatiblity and
+ performance with other distributions launching this autumn.

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

Title:
  FFe: Mesa 23.2.0

Status in mesa package in Ubuntu:
  New

Bug description:
  Upstream still hasn't released Mesa 23.2.0 (as of Sep 19th) which is
  almost seven weeks past it's original release date. But at least we
  have an rc3 which is "only" two weeks old. Yes, we are getting close
  to mantic release but this series is something we want for Intel
  Meteor Lake support.

  This is now fresh in Debian unstable, and has been in Fedora 39 for a
  month already without any apparent drama.

  Build available at the x-staging ppa
  https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages
  (status: i386 build failed due to an upstream bug, which requires 
llvmspirvlib headers to exist even if rusticl OpenCL driver is not enabled)

  xnox: Separately to amd64, this new mesa would also be useful on many
  arm64 platforms with a lot of improvements for RaspberryPi, Ubuntu
  Concept X13s, and Apple / Asahi hardware.

  I strongly request that upgrade of mesa is also considered because of
  the Arm platform improvements in Mesa 23.2.0.

  The request is to ship rc, SRU upto final upstream GA .0 release, and
  enforce SRU policy after that.

  Other distributions are also shipping this Mesa RC largely due to the
  very same reasons, thus this will align hardware compatiblity and
  performance with other distributions launching this autumn.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/2036611/+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 2036611] Re: FFe: Mesa 23.2.0

2023-09-21 Thread Dimitri John Ledkov
** Description changed:

  Upstream still hasn't released Mesa 23.2.0 (as of Sep 19th) which is
  almost seven weeks past it's original release date. But at least we have
  an rc3 which is "only" two weeks old. Yes, we are getting close to
  mantic release but this series is something we want for Intel Meteor
  Lake support.
  
  This is now fresh in Debian unstable, and has been in Fedora 39 for a
  month already without any apparent drama.
  
  Build available at the x-staging ppa
  https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages
  (status: i386 build failed due to an upstream bug, which requires 
llvmspirvlib headers to exist even if rusticl OpenCL driver is not enabled)
+ 
+ 
+ xnox: Separately to amd64, this new mesa would also be useful on many arm64 
platforms with a lot of improvements for RaspberryPi, Ubuntu Concept X13s, and 
Apple / Asahi hardware.
+ 
+ I strongly request that upgrade of mesa is also considered because of
+ the Arm platform improvements in Mesa 23.2.0.

** Changed in: mesa (Ubuntu)
   Importance: Undecided => Critical

** Changed in: mesa (Ubuntu)
Milestone: None => ubuntu-23.10

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

Title:
  FFe: Mesa 23.2.0

Status in mesa package in Ubuntu:
  New

Bug description:
  Upstream still hasn't released Mesa 23.2.0 (as of Sep 19th) which is
  almost seven weeks past it's original release date. But at least we
  have an rc3 which is "only" two weeks old. Yes, we are getting close
  to mantic release but this series is something we want for Intel
  Meteor Lake support.

  This is now fresh in Debian unstable, and has been in Fedora 39 for a
  month already without any apparent drama.

  Build available at the x-staging ppa
  https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages
  (status: i386 build failed due to an upstream bug, which requires 
llvmspirvlib headers to exist even if rusticl OpenCL driver is not enabled)

  xnox: Separately to amd64, this new mesa would also be useful on many
  arm64 platforms with a lot of improvements for RaspberryPi, Ubuntu
  Concept X13s, and Apple / Asahi hardware.

  I strongly request that upgrade of mesa is also considered because of
  the Arm platform improvements in Mesa 23.2.0.

  The request is to ship rc, SRU upto final upstream GA .0 release, and
  enforce SRU policy after that.

  Other distributions are also shipping this Mesa RC largely due to the
  very same reasons, thus this will align hardware compatiblity and
  performance with other distributions launching this autumn.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/2036611/+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 2036885] Re: please add API to exclude things

2023-09-21 Thread Dimitri John Ledkov
** Changed in: initramfs-tools (Ubuntu)
   Importance: Undecided => Wishlist

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

Title:
  please add API to exclude things

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Please add API to exclude things

  It would be useful on Pi to say "yes include all graphics" but do
  exclude "amdgpu, nvidia" drivers and firmware related to those.

  Something along the lines of a "exclude filter list" for drivers &
  firmware.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2036885/+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 2036886] [NEW] please add api to repack initramfs

2023-09-21 Thread Dimitri John Ledkov
Public bug reported:

please add api to repack initramfs

from the results of unpackinitramfs, including all early & main dirs

** Affects: initramfs-tools (Ubuntu)
 Importance: Wishlist
 Status: New

** Changed in: initramfs-tools (Ubuntu)
   Importance: Undecided => Wishlist

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

Title:
  please add api to repack initramfs

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  please add api to repack initramfs

  from the results of unpackinitramfs, including all early & main dirs

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2036886/+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 2036885] [NEW] please add API to exclude things

2023-09-21 Thread Dimitri John Ledkov
Public bug reported:

Please add API to exclude things

It would be useful on Pi to say "yes include all graphics" but do
exclude "amdgpu, nvidia" drivers and firmware related to those.

Something along the lines of a "exclude filter list" for drivers &
firmware.

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: raspi

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

Title:
  please add API to exclude things

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Please add API to exclude things

  It would be useful on Pi to say "yes include all graphics" but do
  exclude "amdgpu, nvidia" drivers and firmware related to those.

  Something along the lines of a "exclude filter list" for drivers &
  firmware.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2036885/+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 645404] Re: Support Private PPAs

2023-08-30 Thread Dimitri John Ledkov
software-properties (0.99.39) mantic; urgency=medium

  * Add cjwatson patch to use getArchiveSubscriptionURL() for private PPAs
  * Fix getArchiveSubscriptionURL() API call and tests
  * Resolve adding private PPAs, which do not yet have a token LP: #1991553

 -- Dimitri John Ledkov   Fri, 25 Aug 2023
22:17:31 +0100

** Changed in: software-properties (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  Support Private PPAs

Status in software-properties package in Ubuntu:
  Fix Released
Status in software-properties source package in Bionic:
  Won't Fix
Status in software-properties source package in Cosmic:
  Won't Fix
Status in software-properties source package in Disco:
  Won't Fix
Status in software-properties source package in Eoan:
  Won't Fix
Status in software-properties source package in Focal:
  Won't Fix

Bug description:
  Software properties add-apt-repository currently does not support
  adding private PPAs.

  software-properties should connect to the API and observe that it gets
  permission denied trying to read the ppa. Then it can reconnect to the
  API asking for authentication, which will open a browser window where
  you can do the openid ritual. Then using that token it ought to be
  possible for it to get the password etc.

  
  ProblemType: BugDistroRelease: Ubuntu 12.04
  Package: python-software-properties 0.82.4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/645404/+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 1942260] Re: compress firmware in /lib/firmware

2023-08-29 Thread Dimitri John Ledkov
** Also affects: firmware-sof (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  compress firmware in /lib/firmware

Status in firmware-sof package in Ubuntu:
  New
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in linux-firmware package in Ubuntu:
  Fix Released
Status in linux-firmware-raspi2 package in Ubuntu:
  Confirmed
Status in firmware-sof source package in Mantic:
  New
Status in initramfs-tools source package in Mantic:
  Fix Released
Status in linux-firmware source package in Mantic:
  Fix Released
Status in linux-firmware-raspi2 source package in Mantic:
  Confirmed

Bug description:
  -- initramfs-tools

  [Impact]

   * linux supports xz compressed linux-firmware which saves disk space.
  In focal, initramfs-tools only knows how to included uncompressed
  firmware files (even when kernel supports loading compressed ones).
  Newer releases of linux-firmware may use compressed firmware files
  only, in such cases it would be nice for focal's initramfs-tools to
  support compressed firmware files in case of partial or incomplete
  upgrades (i.e. linux-firmware force installed or upgraded, without
  newer initramfs-tools). The proposed changes to initramfs-tools are
  backwards and forwards compatible, they prefer to include uncompressed
  firmware files; and if missing, include compressed firmware files in
  their uncompressed form. Thus maintaining compatibility with any
  kernels, irrespective of compressed/uncompressed firmware inputs.

  [Test Plan]

   * Compress all files shipped by linux-firmware with xz

   * Rebuild initrd

   * Check that all the same firmware files are still included in the
  initramfs, in their uncompressed form as before

  [Where problems could occur]

   * This SRU is precautionary to prevent accidental installation of
  compressed linux-firmware from generating incorrect initramfs. It
  should be noted that whilst initramfs-tools would create a compatible
  initramfs with any kernels, pre-v5.3 kernels do not support xz
  compressed firmware files at runtime. Mixing this new initramfs with
  compressed firmwares and pre 5.3 kernels may lead to expectations of
  supporting compressed firmware files with them only working at initrd
  stage and not at runtime.

  [Other Info]
  Original bug report

  Some facts:
   - The linux kernel has supported loading xz compressed firmware since 5.3
   - The size of /lib/firmware in impish is ~650Mb (and growing)
   - The compressed size of firmware could be ~230Mb

  It would be nice to install compressed firmware to save space.

  Here are the plans from the Fedora project:
  https://fedoraproject.org/wiki/Changes/CompressKernelFirmware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firmware-sof/+bug/1942260/+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 1942260] Re: compress firmware in /lib/firmware

2023-07-27 Thread Dimitri John Ledkov
** Changed in: linux-firmware (Ubuntu)
Milestone: None => ubuntu-23.10-beta

** Changed in: linux-firmware-raspi2 (Ubuntu)
Milestone: None => ubuntu-23.10

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

Title:
  compress firmware in /lib/firmware

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in linux-firmware package in Ubuntu:
  Confirmed
Status in linux-firmware-raspi2 package in Ubuntu:
  Confirmed

Bug description:
  -- initramfs-tools

  [Impact]

   * linux supports xz compressed linux-firmware which saves disk space.
  In focal, initramfs-tools only knows how to included uncompressed
  firmware files (even when kernel supports loading compressed ones).
  Newer releases of linux-firmware may use compressed firmware files
  only, in such cases it would be nice for focal's initramfs-tools to
  support compressed firmware files in case of partial or incomplete
  upgrades (i.e. linux-firmware force installed or upgraded, without
  newer initramfs-tools). The proposed changes to initramfs-tools are
  backwards and forwards compatible, they prefer to include uncompressed
  firmware files; and if missing, include compressed firmware files in
  their uncompressed form. Thus maintaining compatibility with any
  kernels, irrespective of compressed/uncompressed firmware inputs.

  [Test Plan]

   * Compress all files shipped by linux-firmware with xz

   * Rebuild initrd

   * Check that all the same firmware files are still included in the
  initramfs, in their uncompressed form as before

  [Where problems could occur]

   * This SRU is precautionary to prevent accidental installation of
  compressed linux-firmware from generating incorrect initramfs. It
  should be noted that whilst initramfs-tools would create a compatible
  initramfs with any kernels, pre-v5.3 kernels do not support xz
  compressed firmware files at runtime. Mixing this new initramfs with
  compressed firmwares and pre 5.3 kernels may lead to expectations of
  supporting compressed firmware files with them only working at initrd
  stage and not at runtime.

  [Other Info]
  Original bug report

  Some facts:
   - The linux kernel has supported loading xz compressed firmware since 5.3
   - The size of /lib/firmware in impish is ~650Mb (and growing)
   - The compressed size of firmware could be ~230Mb

  It would be nice to install compressed firmware to save space.

  Here are the plans from the Fedora project:
  https://fedoraproject.org/wiki/Changes/CompressKernelFirmware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1942260/+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 1932329] Re: Support compressed kernel modules in initramfs-tools and kernel

2023-07-26 Thread Dimitri John Ledkov
moving linux tasks to
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028568

** No longer affects: linux (Ubuntu Jammy)

** No longer affects: linux (Ubuntu)

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

Title:
  Support compressed kernel modules in initramfs-tools and kernel

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Focal:
  New
Status in initramfs-tools source package in Impish:
  Won't Fix
Status in initramfs-tools source package in Jammy:
  Fix Released

Bug description:
  --- initramfs-tools

  [Impact]

   * Initramfs-tools already supports compressed kernel modules.
  However, in focal and impish it does so inefficiently. It is always
  better to have a compressed initramfs of uncommpressed kernel modules,
  than a compressed initrd of compressed kernel modules. Thus when
  kernel module compression is turned on, it is prudent for initramfs-
  tools to pre-uncompress kernel modules when building initramfs.

  [Test Plan]

   * Compress all kernel modules with xz for a current kernel, check
  that all of them have .ko.xz extension and no .ko ones available

   * Rerun depmod

   * Update initramfs with update-initramfs -u

   * lsinitramfs contents and check that all kernel modules are present,
  and are uncompressed (.ko extension)

  [Where problems could occur]

   * This optimization for compressed kernel modules will make initramfs
  build time longer (due to decompression) whilst improving bootspeed
  (overall smaller size of the initrd).

  [Other Info]

   * Original bug report re kernel feature

  --- linux

  Symbol: MODULE_COMPRESS_ZSTD [=n]
  Type  : bool

  = Impacts to measure and observe =

  == Disk space ==

  * Inspect linux-modules-* and linux-modules-extra* deb package
  Installed-Size and Download-Size changes, i.e.

  $ apt show linux-modules-5.8.0-53-generic linux-modules-
  extra-5.8.0-53-generic  | grep -e Package: -e Size:

  Package: linux-modules-5.8.0-53-generic
  Installed-Size: 81.5 MB
  Download-Size: 15.5 MB

  Package: linux-modules-extra-5.8.0-53-generic
  Installed-Size: 215 MB
  Download-Size: 41.5 MB

  In theory, there should not be a significant change in the Download-
  size. It is desired that there is a significant reduction in
  Installed-Size. Modules take up about 300MB and normally one has upto
  three kernel version installed, resulting in about of 1GB of disk
  space that one constantly pays for.

  == Boot Speed ==

  In theory, boot speed may either improve or regress. It depends if
  disk IO is slower than decompression speed, meaning loading compressed
  modules is faster.

  Also one has to observe the changes in the initrd size. zstd(zstd)
  compression may result in slight growth, which shouldn't impact boot
  speed too much.

  = Outcomes =

  If installed size savings can be achieved without regressing bootspeed
  we should enable CONFIG_MODULE_COMPRESS_ZSTD=y by default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1932329/+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 2026273] [NEW] SRU e2fsprogs v1.47.0 for HWE reasons

2023-07-06 Thread Dimitri John Ledkov
Public bug reported:

[ Impact ]

 * orphan_file ext4 feature is available in Jammy v5.15 GA kernel
 * It is to be enabled by default in Mantic
 * fsck utility in jammy doesn't support orphan_file feature
 * as part of forwards-compatibility support it would be useful for Jammy 22.04 
LTS to be able to fsck future releases (i.e. 23.10 / 24.04)
 * as part of HWE support, users may opt-in and choose to use orphan_file in 
Jammy today, when they do so they currently loose support to fsck a given 
filesystem.

[ Test Plan ]

 * Create new ext4 filesystem with GA version of e2fsprogs and with proposed one
 * Ensure that default feature set enabled is the same (i.e. orphan_file & 
metadata_csum features are OFF)
 * Ensure that either fsck can fsck both filesystems
 * Use tune2fs to enable orphan_file feature
 * Ensure that new fsck can check such a filesystem, and that GA (v5.15) kernel 
can mount it

 * do test rebuilds of reverse-build-depends of e2fsprogs to verify to
change of API and ABI, none should FTBFS and none should gain any new
dependencies on the 1.47 symbols

[ Where problems could occur ]

 * library api/abi changes:

struct ext2_super_block size is unchanged, s_orphan_file_inum consumes
one of the s_reserved fields.

orphan_file related public APIs are added.

 * default features:

Ensure that config files are unchanged, to ensure that no new features
are enabled by default, meaning filesystems created with the upgraded
e2fsprogs in a given Ubuntu release will keep the same feature level.

[ Other Info ]
 
 * Anything else you think is useful to include
 * Anticipate questions from users, SRU, +1 maintenance, security teams and the 
Technical Board
 * and address these questions in advance

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

** Affects: e2fsprogs (Ubuntu Jammy)
 Importance: Undecided
 Status: New

** Affects: e2fsprogs (Ubuntu Kinetic)
 Importance: Undecided
 Status: New

** Affects: e2fsprogs (Ubuntu Lunar)
 Importance: Undecided
 Status: New

** Summary changed:

- SRU e2fsprogs for HWE reasons
+ SRU e2fsprogs v1.47.0 for HWE reasons

** Also affects: e2fsprogs (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: e2fsprogs (Ubuntu Kinetic)
   Importance: Undecided
   Status: New

** Also affects: e2fsprogs (Ubuntu Lunar)
   Importance: Undecided
   Status: New

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

Title:
  SRU e2fsprogs v1.47.0 for HWE reasons

Status in e2fsprogs package in Ubuntu:
  New
Status in e2fsprogs source package in Jammy:
  New
Status in e2fsprogs source package in Kinetic:
  New
Status in e2fsprogs source package in Lunar:
  New

Bug description:
  [ Impact ]

   * orphan_file ext4 feature is available in Jammy v5.15 GA kernel
   * It is to be enabled by default in Mantic
   * fsck utility in jammy doesn't support orphan_file feature
   * as part of forwards-compatibility support it would be useful for Jammy 
22.04 LTS to be able to fsck future releases (i.e. 23.10 / 24.04)
   * as part of HWE support, users may opt-in and choose to use orphan_file in 
Jammy today, when they do so they currently loose support to fsck a given 
filesystem.

  [ Test Plan ]

   * Create new ext4 filesystem with GA version of e2fsprogs and with proposed 
one
   * Ensure that default feature set enabled is the same (i.e. orphan_file & 
metadata_csum features are OFF)
   * Ensure that either fsck can fsck both filesystems
   * Use tune2fs to enable orphan_file feature
   * Ensure that new fsck can check such a filesystem, and that GA (v5.15) 
kernel can mount it

   * do test rebuilds of reverse-build-depends of e2fsprogs to verify to
  change of API and ABI, none should FTBFS and none should gain any new
  dependencies on the 1.47 symbols

  [ Where problems could occur ]

   * library api/abi changes:

  struct ext2_super_block size is unchanged, s_orphan_file_inum consumes
  one of the s_reserved fields.

  orphan_file related public APIs are added.

   * default features:

  Ensure that config files are unchanged, to ensure that no new features
  are enabled by default, meaning filesystems created with the upgraded
  e2fsprogs in a given Ubuntu release will keep the same feature level.

  [ Other Info ]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2026273/+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 1974056] Re: iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-bitwise_0 fails on s390x

2023-07-05 Thread Dimitri John Ledkov
Note this is still an issue, we just marked the given test case as
ignored on s390x going forward.

The https://launchpad.net/ubuntu/+source/iptables/1.8.7-1ubuntu6 upload:
* disabled 0002-ebtables-save-restore_0 on x86
* disabled 0009-needless-bitwise_0 on s390x

See the diff at
http://launchpadlibrarian.net/599916663/iptables_1.8.7-1ubuntu5_1.8.7-1ubuntu6.diff.gz

I will check again once we have newer iptables available.

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

Title:
  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0 fails on s390x

Status in iptables:
  Unknown
Status in Ubuntu on IBM z Systems:
  In Progress
Status in iptables package in Ubuntu:
  New

Bug description:
  In Ubuntu, we execute the full iptables shell testcases across all
  architectures.

  They seem to all pass everywhere, however

  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0

  is currently failing on s390x like so:

  command17FAIL stderr: W: [FAILED]  ././testcases/nft-
  only/0009-needless-bitwise_0: expected 0 but got 1

  i wonder if there is some endian bug, as this is currently Ubuntu's
  only big-endian architecture.

  this can be reproduced with:

  pull-lp-source iptables
  cd iptables-1.8.7/
  chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
  cd iptables/tests/shell
  sudo ./run-tests.sh --host

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1974056/+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 2025339] Re: FDE image fails to run e2fsck

2023-06-29 Thread Dimitri John Ledkov
Given new incompatible RO and RW features in ext4 that v5.15 kernels
support, imho we should SRU backport of e2fsprogs on HWE grounds.

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

Title:
  FDE image fails to run e2fsck

Status in e2fsprogs package in Ubuntu:
  New
Status in e2fsprogs source package in Jammy:
  New

Bug description:
  After installation of the FDE image, the system fails to boot due to
  e2fsck failing with:

  Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported
  feature(s): FEATURE_C12

  

  this means that Jammy fsck fails against mantic created ext4 which is
  not great

  Seems this is orphan_file feature / orphan_present

  Also need to check if grub2 supports this as it is RO_INCOMPAT
  feature.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2025339/+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 2025339] Re: FDE image fails to run e2fsck

2023-06-29 Thread Dimitri John Ledkov
** Description changed:

  After installation of the FDE image, the system fails to boot due to
  e2fsck failing with:
  
  Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported
  feature(s): FEATURE_C12
  
  
  
  this means that Jammy fsck fails against mantic created ext4 which is
  not great
+ 
+ Seems this is orphan_file feature / orphan_present
+ 
+ Also need to check if grub2 supports this as it is RO_INCOMPAT feature.

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

Title:
  FDE image fails to run e2fsck

Status in e2fsprogs package in Ubuntu:
  New
Status in e2fsprogs source package in Jammy:
  New

Bug description:
  After installation of the FDE image, the system fails to boot due to
  e2fsck failing with:

  Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported
  feature(s): FEATURE_C12

  

  this means that Jammy fsck fails against mantic created ext4 which is
  not great

  Seems this is orphan_file feature / orphan_present

  Also need to check if grub2 supports this as it is RO_INCOMPAT
  feature.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2025339/+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 2025339] Re: FDE image fails to run e2fsck

2023-06-29 Thread Dimitri John Ledkov
** Also affects: e2fsprogs (Ubuntu Jammy)
   Importance: Undecided
   Status: New

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

Title:
  FDE image fails to run e2fsck

Status in e2fsprogs package in Ubuntu:
  New
Status in e2fsprogs source package in Jammy:
  New

Bug description:
  After installation of the FDE image, the system fails to boot due to
  e2fsck failing with:

  Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported
  feature(s): FEATURE_C12

  

  this means that Jammy fsck fails against mantic created ext4 which is
  not great

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2025339/+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 2025339] Re: FDE image fails to run e2fsck

2023-06-29 Thread Dimitri John Ledkov
** Description changed:

  After installation of the FDE image, the system fails to boot due to
  e2fsck failing with:
  
- Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported 
feature(s): FEATURE_C12
- Jun 21 12:48:19 ubuntu systemd-fsck[268]: e2fsck: Get a newer version of 
e2fsck!
- Jun 21 12:48:19 ubuntu systemd-fsck[268]: ubuntu-boot: ** WARNING: 
Filesystem still has errors **
- Jun 21 12:48:19 ubuntu systemd-fsck[265]: fsck failed with exit status 12.
- Jun 21 12:48:19 ubuntu systemd-fsck[265]: Running request 
emergency.target/start/replace
- Jun 21 12:48:19 ubuntu systemd[1]: systemd-fsck@dev-vda2.service: Main 
process exited, code=exited, status=1/FAILURE
- Jun 21 12:48:19 ubuntu systemd[1]: systemd-fsck@dev-vda2.service: Failed with 
result 'exit-code'.
- Jun 21 12:48:19 ubuntu systemd[1]: Failed to start File System Check on 
/dev/vda2.
- Jun 21 12:48:19 ubuntu systemd[1]: Dependency failed for /run/mnt/ubuntu-boot.
- Jun 21 12:48:19 ubuntu systemd[1]: run-mnt-ubuntu\x2dboot.mount: Job 
run-mnt-ubuntu\x
+ Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported
+ feature(s): FEATURE_C12
+ 
+ 
+ 
+ this means that Jammy fsck fails against mantic created ext4 which is
+ not great

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

Title:
  FDE image fails to run e2fsck

Status in e2fsprogs package in Ubuntu:
  New
Status in e2fsprogs source package in Jammy:
  New

Bug description:
  After installation of the FDE image, the system fails to boot due to
  e2fsck failing with:

  Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported
  feature(s): FEATURE_C12

  

  this means that Jammy fsck fails against mantic created ext4 which is
  not great

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2025339/+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 1939537] Re: Tests in ubuntu_lxc failed with "ERROR: Couldn't find a matching image." on X-hwe and older releases

2023-06-08 Thread Dimitri John Ledkov
All done, updated states and dropped sponsors subscribers


** Changed in: lxc (Ubuntu)
   Status: Confirmed => Invalid

** Changed in: ubuntu-kernel-tests
   Status: New => Fix Released

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

Title:
  Tests in ubuntu_lxc failed with "ERROR: Couldn't find a matching
  image." on X-hwe and older releases

Status in ubuntu-kernel-tests:
  Fix Released
Status in lxc package in Ubuntu:
  Invalid
Status in lxc source package in Bionic:
  Fix Released

Bug description:
  [ Impact ]

   * The following tests fail as they try to use inexistent LXC images:
     * lxc-test-apparmor-mount
     * lxc-test-autostart
     * lxc-test-unpriv
     * lxc-test-usernic

   * Having them fixed for the affected series (for example, Bionic)
  will allow us to run the LXC test suite without maintaining local
  changes for these tests.

  [ Test Plan ]

   * Run the affected tests on an affected series (e.g. Bionic).
   * The tests should pass.

  [ Where problems could occur ]

   * The regression risk is very low and the changes only affect the
  tests so the regression scope is minimal.

  [Other info]

  Original bug report:

  Issue found on node onibi 4.15.0-142-generic #146~16.04.1

  With bug 1916087 resolved, the following tests:
    * lxc-test-apparmor-mount
    * lxc-test-autostart
    * lxc-test-unpriv
    * lxc-test-usernic

  Are now failing with:
    ERROR: Couldn't find a matching image.

  This is because with lxc version 2.0.11-0ubuntu1~16.04.3 the default target 
release is "trusty" or the system release if supported. It will be checked with:
    ubuntu-distro-info --supported

  However Xenial is an ESM series now, it won't use xenial as the target
  release but use trusty instead.

  The attempt to download trusty image will fail with this error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1939537/+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 1848587] Re: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2

2023-05-31 Thread Dimitri John Ledkov
cross test of lxd fails, but i386 is not supported under ESM and i'm not
sure if i386 cross-arch autopkgtest is valid at all.

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

Title:
  lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Fix Committed

Bug description:
  [ Impact ]

   * Test suite fails due to inexistent device (/dev/network_latency).

  [ Test Plan ]

   * Run the test suite.
   * The test should pass.

  [ Where problems could occur ]

   * The regression risk is very low, and the changes only affect the
  tests, so the regression scope is minimal.

  [ Other Info ]

  Original bug report:

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/l/lxc/20191016_150939_0f81d@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/l/lxc/20191016_152027_0f81d@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/l/lxc/20191016_150251_0f81d@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/l/lxc/20191016_150201_0f81d@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587/+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 1848587] Re: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2

2023-05-31 Thread Dimitri John Ledkov
autopkgteest & general usage of lxc 3.0.3-0ubuntu1~18.04.3 works with
host kernels on bionic's GA kernel and on hwe v5.4 kernels now.

verification done.

** 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 lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1848587

Title:
  lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Fix Committed

Bug description:
  [ Impact ]

   * Test suite fails due to inexistent device (/dev/network_latency).

  [ Test Plan ]

   * Run the test suite.
   * The test should pass.

  [ Where problems could occur ]

   * The regression risk is very low, and the changes only affect the
  tests, so the regression scope is minimal.

  [ Other Info ]

  Original bug report:

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/l/lxc/20191016_150939_0f81d@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/l/lxc/20191016_152027_0f81d@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/l/lxc/20191016_150251_0f81d@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/l/lxc/20191016_150201_0f81d@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587/+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 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

2023-05-31 Thread Dimitri John Ledkov
cross test of lxd fails, but i386 is not supported under ESM and i'm not
sure if i386 cross-arch autopkgtest is valid at all.

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

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Fix Committed

Bug description:
  [ Impact ]

   * The device_add_remove_test test fails on the affected series (e.g. Bionic).
   * Having the test fixed for the affected series (for example, Bionic) will 
allow us to run the LXC test suite without maintaining local changes for this 
test.

  [ Test Plan ]

   * Run the affected test on an affected series (e.g. Bionic).
   * The test should pass.

  [ Where problems could occur ]

   * The regression risk is very low, and the changes only affect the
  tests, so the regression scope is minimal.

  [ Other Info ]

  Upstream drop of network_latency: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c3082a674f46fe49383b157882c41dfabaa37113
  Related to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587

  Original bug report:

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1886790/+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 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

2023-05-31 Thread Dimitri John Ledkov
autopkgteest & general usage of lxc 3.0.3-0ubuntu1~18.04.3 works with
host kernels on bionic's GA kernel and on hwe v5.4 kernels now.

verification done.

** 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 lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1886790

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Fix Committed

Bug description:
  [ Impact ]

   * The device_add_remove_test test fails on the affected series (e.g. Bionic).
   * Having the test fixed for the affected series (for example, Bionic) will 
allow us to run the LXC test suite without maintaining local changes for this 
test.

  [ Test Plan ]

   * Run the affected test on an affected series (e.g. Bionic).
   * The test should pass.

  [ Where problems could occur ]

   * The regression risk is very low, and the changes only affect the
  tests, so the regression scope is minimal.

  [ Other Info ]

  Upstream drop of network_latency: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c3082a674f46fe49383b157882c41dfabaa37113
  Related to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587

  Original bug report:

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1886790/+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 1939537] Re: Tests in ubuntu_lxc failed with "ERROR: Couldn't find a matching image." on X-hwe and older releases

2023-05-31 Thread Dimitri John Ledkov
cross test of lxd fails, but i386 is not supported under ESM and i'm not
sure if i386 cross-arch autopkgtest is valid at all.

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

Title:
  Tests in ubuntu_lxc failed with "ERROR: Couldn't find a matching
  image." on X-hwe and older releases

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Confirmed
Status in lxc source package in Bionic:
  Fix Committed

Bug description:
  [ Impact ]

   * The following tests fail as they try to use inexistent LXC images:
     * lxc-test-apparmor-mount
     * lxc-test-autostart
     * lxc-test-unpriv
     * lxc-test-usernic

   * Having them fixed for the affected series (for example, Bionic)
  will allow us to run the LXC test suite without maintaining local
  changes for these tests.

  [ Test Plan ]

   * Run the affected tests on an affected series (e.g. Bionic).
   * The tests should pass.

  [ Where problems could occur ]

   * The regression risk is very low and the changes only affect the
  tests so the regression scope is minimal.

  [Other info]

  Original bug report:

  Issue found on node onibi 4.15.0-142-generic #146~16.04.1

  With bug 1916087 resolved, the following tests:
    * lxc-test-apparmor-mount
    * lxc-test-autostart
    * lxc-test-unpriv
    * lxc-test-usernic

  Are now failing with:
    ERROR: Couldn't find a matching image.

  This is because with lxc version 2.0.11-0ubuntu1~16.04.3 the default target 
release is "trusty" or the system release if supported. It will be checked with:
    ubuntu-distro-info --supported

  However Xenial is an ESM series now, it won't use xenial as the target
  release but use trusty instead.

  The attempt to download trusty image will fail with this error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1939537/+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 1939537] Re: Tests in ubuntu_lxc failed with "ERROR: Couldn't find a matching image." on X-hwe and older releases

2023-05-31 Thread Dimitri John Ledkov
autopkgteest & general usage of lxc 3.0.3-0ubuntu1~18.04.3 works with
host kernels on bionic's GA kernel and on hwe v5.4 kernels now.

verification done.

** 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 lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1939537

Title:
  Tests in ubuntu_lxc failed with "ERROR: Couldn't find a matching
  image." on X-hwe and older releases

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Confirmed
Status in lxc source package in Bionic:
  Fix Committed

Bug description:
  [ Impact ]

   * The following tests fail as they try to use inexistent LXC images:
     * lxc-test-apparmor-mount
     * lxc-test-autostart
     * lxc-test-unpriv
     * lxc-test-usernic

   * Having them fixed for the affected series (for example, Bionic)
  will allow us to run the LXC test suite without maintaining local
  changes for these tests.

  [ Test Plan ]

   * Run the affected tests on an affected series (e.g. Bionic).
   * The tests should pass.

  [ Where problems could occur ]

   * The regression risk is very low and the changes only affect the
  tests so the regression scope is minimal.

  [Other info]

  Original bug report:

  Issue found on node onibi 4.15.0-142-generic #146~16.04.1

  With bug 1916087 resolved, the following tests:
    * lxc-test-apparmor-mount
    * lxc-test-autostart
    * lxc-test-unpriv
    * lxc-test-usernic

  Are now failing with:
    ERROR: Couldn't find a matching image.

  This is because with lxc version 2.0.11-0ubuntu1~16.04.3 the default target 
release is "trusty" or the system release if supported. It will be checked with:
    ubuntu-distro-info --supported

  However Xenial is an ESM series now, it won't use xenial as the target
  release but use trusty instead.

  The attempt to download trusty image will fail with this error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1939537/+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 1848587] Re: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2

2023-05-22 Thread Dimitri John Ledkov
it must be released in bionic-updates.
bionic-proposed is insufficient.
this follows the previous SRUs that fixed adt only, which were awaiting on "an 
end-user visible sru to come in the future" which never has.
autopkgtest infrastructure has no ability to always test against proposed 
pocket, a given package, because it's test is regressed in updates.

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

Title:
  lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2

Status in lxc package in Ubuntu:
  Fix Released

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/l/lxc/20191016_150939_0f81d@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/l/lxc/20191016_152027_0f81d@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/l/lxc/20191016_150251_0f81d@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/l/lxc/20191016_150201_0f81d@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587/+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 1302192] Re: capabilities not preserved on installation

2023-05-16 Thread Dimitri John Ledkov
I thought as part of this work we agreed to always unpack tar with
xattrs, but i'm not sure how to check if this was done or in place. will
investigate.

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

Title:
  capabilities not preserved on installation

Status in attr package in Ubuntu:
  Fix Released
Status in iputils package in Ubuntu:
  Confirmed
Status in live-installer package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  Fix Released
Status in attr source package in Trusty:
  Fix Released
Status in iputils source package in Trusty:
  Confirmed
Status in live-installer source package in Trusty:
  Fix Released
Status in ubiquity source package in Trusty:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Fix Released

Bug description:
  Ping is not longer setuid root and I have to ping as root:

  [~]$ ping kubuntu.org
  ping: icmp open socket: Operation not permitted
  [~]$ sudo ping kubuntu.org
  PING kubuntu.org (91.189.94.156) 56(84) bytes of data.
  64 bytes from vostok.canonical.com (91.189.94.156): icmp_seq=1 ttl=51 
time=52.2 ms
  --- kubuntu.org ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 52.231/52.231/52.231/0.000 ms
  [~]$

  Related bugs:
   bug 1313550: ping does not work as a normal user on trusty tarball cloud 
images.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/attr/+bug/1302192/+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 2019435] Re: Default initramfs is missing qcom_geni_serial module

2023-05-12 Thread Dimitri John Ledkov
it does feel too many that it should be included by default, not sure
why the rest of the tty/serial drivers are not included, or how come
this one is not scoped under usb/hid, it is fairly small, and built on
arm64 only i think, thus it is useful to include by default - as at best
it is unlikely to impact initrd sizes much, and expanding support of
generic kernels on arm64 is very much in scope for Ubuntu.

** Project changed: initramfs-tools => initramfs-tools (Ubuntu)

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

Title:
  Default initramfs is missing qcom_geni_serial module

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Running Ubuntu 22.04 with the HWE kernel (5.19.0-38-generic
  #39~22.04.1-Ubuntu) on a Qualcomm RB5 derived product -
  https://developer.qualcomm.com/qualcomm-robotics-rb5-kit

  The platform has a USB to serial port that can be used as the Linux
  console.  However, this requires the qcom_geni_serial driver to
  operate.  That driver is available as a built module already, but only
  on the rootfs.  It is not included in the initramfs by default.

  The problem with this is that the console is activated quite late in
  boot, which reduces it's usefulness in debugging kernel/boot issues.
  Also, when it finally does come up, the console cannot operate as a
  login interface (no login prompt is provided) because the interface is
  initialized after systemd is operational.

  I can manually add the module to the initramfs by adding
  "qcom_geni_serial" to /etc/initramfs-tools/modules and running update-
  initramfs, however this is quite inconvenient.  It requires me to
  remove the storage from the platform, and modify it on another system.

  Given that the default initramfs already contains a large number of
  serial drivers, it feels like qcom_geni_serial should be included by
  default which would give an optimal "out of the box" experience on a
  number of Qualcomm based platforms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2019435/+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 2017926] [NEW] Unused content snaps not autoremoved

2023-04-27 Thread Dimitri John Ledkov
Public bug reported:

$ snap connections --all | grep gnome
content   -
gnome-3-28-1804:gnome-3-28-1804   -
content   -
gnome-3-34-1804:gnome-3-34-1804   -
content[gnome-3-38-2004]  chromium:gnome-3-38-2004 
gnome-3-38-2004:gnome-3-38-2004   -
content[gnome-3-38-2004]  firefox:gnome-3-38-2004  
gnome-3-38-2004:gnome-3-38-2004   -
content[gnome-42-2204]mattermost-desktop:gnome-42-2204 
gnome-42-2204:gnome-42-2204   -
content[gnome-42-2204]snap-store:gnome-42-2204 
gnome-42-2204:gnome-42-2204   -
content[gnome-42-2204]snapd-desktop-integration:gnome-42-2204  
gnome-42-2204:gnome-42-2204   -

my system has 4 gnome-* content snaps, that were pulled in as
dependencies. The apps that used them, have moved on to newer versions.
Something on my system must clean then up for me, for example apt
autoremoves automatically installed packages & obsolete kernels, and so
should also happen with snaps.

It can be done by snapd itself, or by something else on the classic
desktop - i.e. update-manager. Note it is easy to detect such snaps, as
it provides no apps; has content interface only; which is not plugged by
anything. If it is ever needed by any future or past revision of any
other snap it would be autoinstalled back.

On my system they take up 824M of disk space (2 revisions, of 2 unused
content snaps = 4 snaps)

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

** Affects: ubuntu-meta (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: update-notifier (Ubuntu)
 Importance: Undecided
 Status: New

** Also affects: snapd (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: update-notifier (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  $ snap connections --all | grep gnome
  content   -   
 gnome-3-28-1804:gnome-3-28-1804   -
  content   -   
 gnome-3-34-1804:gnome-3-34-1804   -
  content[gnome-3-38-2004]  chromium:gnome-3-38-2004
 gnome-3-38-2004:gnome-3-38-2004   -
  content[gnome-3-38-2004]  firefox:gnome-3-38-2004 
 gnome-3-38-2004:gnome-3-38-2004   -
  content[gnome-42-2204]mattermost-desktop:gnome-42-2204
 gnome-42-2204:gnome-42-2204   -
  content[gnome-42-2204]snap-store:gnome-42-2204
 gnome-42-2204:gnome-42-2204   -
  content[gnome-42-2204]snapd-desktop-integration:gnome-42-2204 
 gnome-42-2204:gnome-42-2204   -
  
- 
- my system has 4 gnome-* content snaps, that were pulled in as dependencies. 
The apps that used them, have moved on to newer versions. Something on my 
system must clean then up for me, for example apt autoremoves automatically 
installed packages & obsolete kernels, and so should also happen with snaps.
+ my system has 4 gnome-* content snaps, that were pulled in as
+ dependencies. The apps that used them, have moved on to newer versions.
+ Something on my system must clean then up for me, for example apt
+ autoremoves automatically installed packages & obsolete kernels, and so
+ should also happen with snaps.
  
  It can be done by snapd itself, or by something else on the classic
  desktop - i.e. update-manager. Note it is easy to detect such snaps, as
  it provides no apps; has content interface only; which is not plugged by
  anything. If it is ever needed by any future or past revision of any
  other snap it would be autoinstalled back.
+ 
+ On my system they take up 824M of disk space (2 revisions, of 2 unused
+ content snaps = 4 snaps)

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

Title:
  Unused content snaps not autoremoved

Status in snapd package in Ubuntu:
  New
Status in ubuntu-meta package in Ubuntu:
  New
Status in update-notifier package in Ubuntu:
  New

Bug description:
  $ snap connections --all | grep gnome
  content   -   
 gnome-3-28-1804:gnome-3-28-1804   -
  content   -   
 gnome-3-34-1804:gnome-3-34-1804   -
  content[gnome-3-38-2004]  

[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec

2023-04-26 Thread Dimitri John Ledkov
I'm not too sure if updates from sed1991s above are correct

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

Title:
  dev file system is mounted without nosuid or noexec

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in linux source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in linux source package in Jammy:
  Fix Released
Status in systemd source package in Jammy:
  Fix Released

Bug description:
  [ SRU TEMPLATE ]
  [ Impact ]

   * nosuid, and noexec bits are not set on /dev
   * This has the potential for nefarious actors to use this as an avenue for 
attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more 
discussion around this.
   * It is not best security practice.

  [ Test Plan ]

     1.Boot a Canonical Supplied EC2 instance
     2.Check the mount options for /dev.
     3.You will notice the lack of nosuid and noexec on /dev.

  [ Where problems could occur ]

   * As of 2022/10/06, I need to test this, but don't know how to build
  -aws flavored ubuntu kernels. Instructions welcome.  I'm holding off
  on adding SRU tags until I can actually get this tested.

   * If this is applied to non initramfs-less kernels it could potentially 
cause a regression for very old hardware that does nefarious things with 
memory.  For a larger discussion about that see:
  
https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/

   * Low risk if a driver depends on /dev allowing suid or exec this
  might prevent boot.  That being said, all kernels that have been
  booting with an initramfs have been getting nosuid, and noexec set so
  hopefully we can consider that risk fairly well tested.

  [ Other Info ]

   * Patch is accepted into 5.17, and will drop out quickly
   * Any server booting with an initramfs already has nosuid, and noexec set, 
so hopefully

  <<< ORIGINAL TEXT 

  This is similar to
  https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new.

  I discovered that my ec2 instances based off of Canonical supplied AMI
  ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without
  the nosuid option.

  https://us-east-2.console.aws.amazon.com/ec2/home?region=us-
  east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee

  My usb installed 20.04.4 home machine does not have this problem, but
  it has been installed for quite some time.  My 22.04 laptop machine
  also does not have this issue.

  Reproduce.
  Start an ec2 instance based off of ami-0a23d90349664c6ee.
  $ mount | grep devtmpfs
  nosuid is not found in the options list.

  I've checked the initrd, and /etc/init.d/udev script and all places I
  know of where dev gets mounted set nosuid, so it's non-obvious what
  boot code-path is being taken that results in nosuid missing.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: udev 245.4-4ubuntu3.18
  ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53
  Uname: Linux 5.15.0-1020-aws x86_64
  ApportVersion: 2.20.11-0ubuntu27.24
  Architecture: amd64
  CasperMD5CheckResult: skip
  CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules
  Date: Thu Oct  6 17:39:42 2022
  Ec2AMI: ami-0a23d90349664c6ee
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: us-east-2c
  Ec2InstanceType: t2.medium
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  Lsusb-t:

  Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
  MachineType: Xen HVM domU
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws 
root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 
console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 08/24/2006
  dmi.bios.release: 4.2
  dmi.bios.vendor: Xen
  dmi.bios.version: 4.2.amazon
  dmi.chassis.type: 1
  dmi.chassis.vendor: Xen
  dmi.modalias: 
dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku:
  dmi.product.name: HVM domU
  dmi.product.version: 4.2.amazon
  dmi.sys.vendor: Xen

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 2017770] [NEW] "Enter code on ubuntu.com/pro/attach" is not clickable URL like everything else

2023-04-26 Thread Dimitri John Ledkov
Public bug reported:

Enter code on ubuntu.com/pro/attach is not a clickable url.

however ubuntu.com/pro and "register new account" are.

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: "Screenshot from 2023-04-26 12-05-00.png"
   
https://bugs.launchpad.net/bugs/2017770/+attachment/5668913/+files/Screenshot%20from%202023-04-26%2012-05-00.png

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

Title:
  "Enter code on ubuntu.com/pro/attach" is not clickable URL like
  everything else

Status in software-properties package in Ubuntu:
  New

Bug description:
  Enter code on ubuntu.com/pro/attach is not a clickable url.

  however ubuntu.com/pro and "register new account" are.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2017770/+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 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)

2023-04-21 Thread Dimitri John Ledkov
vmlinuz-6.2.0-18-generic is good, so regression introduced in 6.2.0-19
abi, suspecting new apparmor stack
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2012136

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

** Also affects: apparmor (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  udev fails to make prctl() syscall with apparmor=0 (as used by maas by
  default)

Status in AppArmor:
  New
Status in MAAS:
  Triaged
Status in maas-images:
  Invalid
Status in apparmor package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  Still gathering logs and info and will update as I go.

  
  Kernel Bug / Apparmor
  reproducer

  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
  $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd 
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'

  #start the VM
  
  Starting systemd-udevd version 252.5-2ubuntu3
  Spawning shell within the initramfs

  BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs) udevadm info --export-db
  Failed to set death signal: Invalid argument

  Observe that udevadm fails to setup death signal, with in systemd code
  is this

  
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
  util.c#L1252

  if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
  if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ? 
SIGINT : SIGTERM) < 0) {
  log_full_errno(prio, errno, "Failed to set death 
signal: %m");
  _exit(EXIT_FAILURE);
  }

  
  workaround set kernel commandline to `apparmor=1`
  

  MAAS bug
  Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor. 
Even for deployment and commisioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2016908/+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 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)

2023-04-21 Thread Dimitri John Ledkov
alexsander-souza - if you can make this on per-distro basis that would
be great. Indeed empty (thus apparmor=1) should work on jammy and up,
but yes we can never know. And having it for lunar onwards would be
super nice, because yes overlayfs apparmor things got fixed a while back
and are expected to work from now on. And there are more and more things
that rely on apparmor to be there.

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

Title:
  udev fails to make prctl() syscall with apparmor=0 (as used by maas by
  default)

Status in MAAS:
  Triaged
Status in maas-images:
  Invalid
Status in linux package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  Still gathering logs and info and will update as I go.

  
  Kernel Bug / Apparmor
  reproducer

  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
  $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd 
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'

  #start the VM
  
  Starting systemd-udevd version 252.5-2ubuntu3
  Spawning shell within the initramfs

  BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs) udevadm info --export-db
  Failed to set death signal: Invalid argument

  Observe that udevadm fails to setup death signal, with in systemd code
  is this

  
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
  util.c#L1252

  if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
  if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ? 
SIGINT : SIGTERM) < 0) {
  log_full_errno(prio, errno, "Failed to set death 
signal: %m");
  _exit(EXIT_FAILURE);
  }

  
  workaround set kernel commandline to `apparmor=1`
  

  MAAS bug
  Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor. 
Even for deployment and commisioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/2016908/+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 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)

2023-04-20 Thread Dimitri John Ledkov
Lunar kernel will need SRU to be fixed up.

And separately, we could check if we can get rid of apparmor=0 for all
supported releases or not, in next mass release.

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

Title:
  udev fails to make prctl() syscall with apparmor=0 (as used by maas by
  default)

Status in MAAS:
  Triaged
Status in maas-images:
  Invalid
Status in linux package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  Still gathering logs and info and will update as I go.

  
  Kernel Bug / Apparmor
  reproducer

  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
  $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd 
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'

  #start the VM
  
  Starting systemd-udevd version 252.5-2ubuntu3
  Spawning shell within the initramfs

  BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs) udevadm info --export-db
  Failed to set death signal: Invalid argument

  Observe that udevadm fails to setup death signal, with in systemd code
  is this

  
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
  util.c#L1252

  if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
  if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ? 
SIGINT : SIGTERM) < 0) {
  log_full_errno(prio, errno, "Failed to set death 
signal: %m");
  _exit(EXIT_FAILURE);
  }

  
  workaround set kernel commandline to `apparmor=1`
  

  MAAS bug
  Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor. 
Even for deployment and commisioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/2016908/+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 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)

2023-04-20 Thread Dimitri John Ledkov
Now about those bugs, it is true that apparmor and overlayfs used to not
play along.

Depending on support matrix we can attempt to turn apparmor back on.

Equally it is buggy that Ubuntu kernel does not work with apparmor
turned off.

It would be nice to investigate if we can at least enable apparmor for
some target series.

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

Title:
  udev fails to make prctl() syscall with apparmor=0 (as used by maas by
  default)

Status in MAAS:
  Triaged
Status in maas-images:
  Invalid
Status in linux package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  Still gathering logs and info and will update as I go.

  
  Kernel Bug / Apparmor
  reproducer

  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
  $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd 
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'

  #start the VM
  
  Starting systemd-udevd version 252.5-2ubuntu3
  Spawning shell within the initramfs

  BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs) udevadm info --export-db
  Failed to set death signal: Invalid argument

  Observe that udevadm fails to setup death signal, with in systemd code
  is this

  
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
  util.c#L1252

  if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
  if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ? 
SIGINT : SIGTERM) < 0) {
  log_full_errno(prio, errno, "Failed to set death 
signal: %m");
  _exit(EXIT_FAILURE);
  }

  
  workaround set kernel commandline to `apparmor=1`
  

  MAAS bug
  Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor. 
Even for deployment and commisioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/2016908/+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 2016908] Re: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs

2023-04-20 Thread Dimitri John Ledkov
** Description changed:

  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which I
  don't believe was part of the 20230319 serial. I don't have access to
  the maas server, so I can't directly check any log files.
  
  MAAS Version: 3.3.2
  
  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.
  
+ Still gathering logs and info and will update as I go.
  
- Still gathering logs and info and will update as I go.
+ 
+ 
+ Kernel Bug / Apparmor
+ reproducer
+ 
+ $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
+ $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
+ $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd 
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
+ 
+ 
+ #start the VM
+ 
+ Starting systemd-udevd version 252.5-2ubuntu3
+ Spawning shell within the initramfs
+ 
+ 
+ BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
+ Enter 'help' for a list of built-in commands.
+ 
+ (initramfs) udevadm info --export-db
+ Failed to set death signal: Invalid argument
+ 
+ Observe that udevadm fails to setup death signal, with in systemd code
+ is this
+ 
+ 
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
+ util.c#L1252
+ 
+ if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
+ if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ? 
SIGINT : SIGTERM) < 0) {
+ log_full_errno(prio, errno, "Failed to set death 
signal: %m");
+ _exit(EXIT_FAILURE);
+ }
+ 
+ 
+ 
+ MAAS bug
+ Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor. 
Even for deployment and commisioning.

** Changed in: linux (Ubuntu)
   Status: Incomplete => Triaged

** Changed in: maas-images
   Status: Incomplete => Invalid

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

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

** Summary changed:

- Unable to deploy hosts with lunar images after 20230319 - fails to connect 
and download squashfs
+ udev fails to make prctl() syscall with apparmor=0 (as used by maas by 
default)

** Description changed:

  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which I
  don't believe was part of the 20230319 serial. I don't have access to
  the maas server, so I can't directly check any log files.
  
  MAAS Version: 3.3.2
  
  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.
  
  Still gathering logs and info and will update as I go.
  
- 
  
  Kernel Bug / Apparmor
  reproducer
  
  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
  $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd 
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
  
- 
  #start the VM
  
  Starting systemd-udevd version 252.5-2ubuntu3
  Spawning shell within the initramfs
- 
  
  BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) 

[Touch-packages] [Bug 2016908] Re: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs

2023-04-20 Thread Dimitri John Ledkov
horay i managed to reproduce it locally.

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

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

Title:
  Unable to deploy hosts with lunar images after 20230319 - fails to
  connect and download squashfs

Status in maas-images:
  Incomplete
Status in linux package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  
  Still gathering logs and info and will update as I go.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2016908/+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 2016908] Re: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs

2023-04-20 Thread Dimitri John Ledkov
I am annoyed that i cannot reproduce this locally outside of MAAS.

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

Title:
  Unable to deploy hosts with lunar images after 20230319 - fails to
  connect and download squashfs

Status in maas-images:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  
  Still gathering logs and info and will update as I go.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2016908/+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 1973734] Re: FTBFS on riscv64 in focal

2023-03-30 Thread Dimitri John Ledkov
@brian

I'm sorry, but with block-proposed-focal set it means that affected
users on riscv64 don't have uptodata pulseaudio.

can we please release this?

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

Title:
  FTBFS on riscv64 in focal

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * FTBFS on riscv64 in focal in unittest of volume test
   * Disable that unit test, as later releases do not run unittests on riscv64, 
and it's better to have up to date pulseaudio on riscv64 (with many security 
fixes), even if it doesn't completely correctly work.

  [Test Plan]

   * autopkgtests pass
   * riscv64 build is successful

  [Where problems could occur]

   * volume-test probably indicates that one can't set volume correctly
  on riscv64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1973734/+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 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"

2023-03-09 Thread Dimitri John Ledkov
> The syslog-ng profile needs flags=(attach_disconnected) added to it

I failed to reproduce this with syslog-ng, but i guess i didn't
configure syslog-ng correctly to attempt attaching to /dev/log

I am also not sure of os-prober usage of logger is correct, and if it
actually wants to use that all, or if it should simply use journald
only, or nothing at all.

Reading attach_disconnected sounds scary, i'm not sure what os-prober
can do better here. bind-mount /dev/log socket into it's new mount
namespace?

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

Title:
  os-prober exits prematurely with "logger: socket /dev/log: Protocol
  wrong type for socket"

Status in AppArmor Profiles:
  New
Status in os-prober package in Ubuntu:
  Fix Released
Status in rsyslog package in Ubuntu:
  New

Bug description:
  Failure occurs on Ubuntu 16.04 with the apparmor-
  profiles-2.10.95-0ubuntu2.10 package installed.

  Running update-grub will run /usr/bin/os-prober, which spews about a
  dozen of the following line to stderr:

  logger: socket /dev/log: Protocol wrong type for socket

  … but fails to report the existence of some installed operating
  systems as expected.

  Furthermore, /var/log/messages contains:

  kernel: audit: type=1400 audit(1556043066.679:11460):
  apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
  disconnected path" error=-13 profile="syslog-ng" name="dev/log"
  pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
  ouid=0

  
  Here is a stripped-down skeleton of the /usr/bin/os-prober script, which 
demonstrates the problem:

  #!/bin/sh
  set -e -x
  
  newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
  }
  
  log() {
logger -t "$(basename "$0")" "$@"
  }
  
  debug() {
log "debug: $@"
  }
  
  ls -l /dev/log
  debug "Hello world"
  newns "$@"

  The expected behavior is that it should write "debug: os-prober-
  testcase Hello world" to /var/log/messages twice.  However, it only
  succeeds in writing "Hello world" once.  After the script respawns
  itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
  second attempt to write to /dev/log fails as described above.

  Since the os-prober Bash script runs with the -e flag, any error, even
  just a logging error, causes the script to terminate prematurely.
  (Arguably, the log() function should call `logger -t "$(basename
  "$0")" "$@" || :` so that logging failures aren't fatal.)

  
  The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change

  profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
  }

  to

  profile syslog-ng /{usr/,}sbin/syslog-ng 
flags=(complain,attach_disconnected) {
…
  }

  … then run `aa-complain sbin.syslog-ng` and `service syslog-ng
  restart`, before running update-grub again.  I assume that similar
  fixes would be required for the other logging daemons.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+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 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"

2023-03-07 Thread Dimitri John Ledkov
Steps i can reproduce:

wget https://bugs.launchpad.net/ubuntu/+source/os-
prober/+bug/1826294/+attachment/5652492/+files/reproducer.sh

chmod +x reproducer.sh

sudo journalctl -f -e &

clear

sudo ./reproducer.sh

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

Title:
  os-prober exits prematurely with "logger: socket /dev/log: Protocol
  wrong type for socket"

Status in AppArmor Profiles:
  New
Status in os-prober package in Ubuntu:
  New
Status in rsyslog package in Ubuntu:
  New

Bug description:
  Failure occurs on Ubuntu 16.04 with the apparmor-
  profiles-2.10.95-0ubuntu2.10 package installed.

  Running update-grub will run /usr/bin/os-prober, which spews about a
  dozen of the following line to stderr:

  logger: socket /dev/log: Protocol wrong type for socket

  … but fails to report the existence of some installed operating
  systems as expected.

  Furthermore, /var/log/messages contains:

  kernel: audit: type=1400 audit(1556043066.679:11460):
  apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
  disconnected path" error=-13 profile="syslog-ng" name="dev/log"
  pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
  ouid=0

  
  Here is a stripped-down skeleton of the /usr/bin/os-prober script, which 
demonstrates the problem:

  #!/bin/sh
  set -e -x
  
  newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
  }
  
  log() {
logger -t "$(basename "$0")" "$@"
  }
  
  debug() {
log "debug: $@"
  }
  
  ls -l /dev/log
  debug "Hello world"
  newns "$@"

  The expected behavior is that it should write "debug: os-prober-
  testcase Hello world" to /var/log/messages twice.  However, it only
  succeeds in writing "Hello world" once.  After the script respawns
  itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
  second attempt to write to /dev/log fails as described above.

  Since the os-prober Bash script runs with the -e flag, any error, even
  just a logging error, causes the script to terminate prematurely.
  (Arguably, the log() function should call `logger -t "$(basename
  "$0")" "$@" || :` so that logging failures aren't fatal.)

  
  The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change

  profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
  }

  to

  profile syslog-ng /{usr/,}sbin/syslog-ng 
flags=(complain,attach_disconnected) {
…
  }

  … then run `aa-complain sbin.syslog-ng` and `service syslog-ng
  restart`, before running update-grub again.  I assume that similar
  fixes would be required for the other logging daemons.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+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 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"

2023-03-07 Thread Dimitri John Ledkov
This is Ubuntu desktop install. rsyslog.service is active and running,
systemd-journald-dev-log.socket is running.

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

Title:
  os-prober exits prematurely with "logger: socket /dev/log: Protocol
  wrong type for socket"

Status in AppArmor Profiles:
  New
Status in os-prober package in Ubuntu:
  New
Status in rsyslog package in Ubuntu:
  New

Bug description:
  Failure occurs on Ubuntu 16.04 with the apparmor-
  profiles-2.10.95-0ubuntu2.10 package installed.

  Running update-grub will run /usr/bin/os-prober, which spews about a
  dozen of the following line to stderr:

  logger: socket /dev/log: Protocol wrong type for socket

  … but fails to report the existence of some installed operating
  systems as expected.

  Furthermore, /var/log/messages contains:

  kernel: audit: type=1400 audit(1556043066.679:11460):
  apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
  disconnected path" error=-13 profile="syslog-ng" name="dev/log"
  pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
  ouid=0

  
  Here is a stripped-down skeleton of the /usr/bin/os-prober script, which 
demonstrates the problem:

  #!/bin/sh
  set -e -x
  
  newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
  }
  
  log() {
logger -t "$(basename "$0")" "$@"
  }
  
  debug() {
log "debug: $@"
  }
  
  ls -l /dev/log
  debug "Hello world"
  newns "$@"

  The expected behavior is that it should write "debug: os-prober-
  testcase Hello world" to /var/log/messages twice.  However, it only
  succeeds in writing "Hello world" once.  After the script respawns
  itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
  second attempt to write to /dev/log fails as described above.

  Since the os-prober Bash script runs with the -e flag, any error, even
  just a logging error, causes the script to terminate prematurely.
  (Arguably, the log() function should call `logger -t "$(basename
  "$0")" "$@" || :` so that logging failures aren't fatal.)

  
  The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change

  profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
  }

  to

  profile syslog-ng /{usr/,}sbin/syslog-ng 
flags=(complain,attach_disconnected) {
…
  }

  … then run `aa-complain sbin.syslog-ng` and `service syslog-ng
  restart`, before running update-grub again.  I assume that similar
  fixes would be required for the other logging daemons.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+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 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"

2023-03-07 Thread Dimitri John Ledkov
** Attachment added: "reproducer.sh"
   
https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1826294/+attachment/5652492/+files/reproducer.sh

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

Title:
  os-prober exits prematurely with "logger: socket /dev/log: Protocol
  wrong type for socket"

Status in AppArmor Profiles:
  New
Status in os-prober package in Ubuntu:
  New
Status in rsyslog package in Ubuntu:
  New

Bug description:
  Failure occurs on Ubuntu 16.04 with the apparmor-
  profiles-2.10.95-0ubuntu2.10 package installed.

  Running update-grub will run /usr/bin/os-prober, which spews about a
  dozen of the following line to stderr:

  logger: socket /dev/log: Protocol wrong type for socket

  … but fails to report the existence of some installed operating
  systems as expected.

  Furthermore, /var/log/messages contains:

  kernel: audit: type=1400 audit(1556043066.679:11460):
  apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
  disconnected path" error=-13 profile="syslog-ng" name="dev/log"
  pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
  ouid=0

  
  Here is a stripped-down skeleton of the /usr/bin/os-prober script, which 
demonstrates the problem:

  #!/bin/sh
  set -e -x
  
  newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
  }
  
  log() {
logger -t "$(basename "$0")" "$@"
  }
  
  debug() {
log "debug: $@"
  }
  
  ls -l /dev/log
  debug "Hello world"
  newns "$@"

  The expected behavior is that it should write "debug: os-prober-
  testcase Hello world" to /var/log/messages twice.  However, it only
  succeeds in writing "Hello world" once.  After the script respawns
  itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
  second attempt to write to /dev/log fails as described above.

  Since the os-prober Bash script runs with the -e flag, any error, even
  just a logging error, causes the script to terminate prematurely.
  (Arguably, the log() function should call `logger -t "$(basename
  "$0")" "$@" || :` so that logging failures aren't fatal.)

  
  The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change

  profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
  }

  to

  profile syslog-ng /{usr/,}sbin/syslog-ng 
flags=(complain,attach_disconnected) {
…
  }

  … then run `aa-complain sbin.syslog-ng` and `service syslog-ng
  restart`, before running update-grub again.  I assume that similar
  fixes would be required for the other logging daemons.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+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 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"

2023-03-07 Thread Dimitri John Ledkov
yeah i get apparmor="DENIED" info="Failed name loookup - disconnected
path", which breaks os-prober.

** Changed in: os-prober (Ubuntu)
   Importance: Undecided => Critical

** Also affects: rsyslog (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: rsyslog (Ubuntu)
   Importance: Undecided => Critical

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

Title:
  os-prober exits prematurely with "logger: socket /dev/log: Protocol
  wrong type for socket"

Status in AppArmor Profiles:
  New
Status in os-prober package in Ubuntu:
  New
Status in rsyslog package in Ubuntu:
  New

Bug description:
  Failure occurs on Ubuntu 16.04 with the apparmor-
  profiles-2.10.95-0ubuntu2.10 package installed.

  Running update-grub will run /usr/bin/os-prober, which spews about a
  dozen of the following line to stderr:

  logger: socket /dev/log: Protocol wrong type for socket

  … but fails to report the existence of some installed operating
  systems as expected.

  Furthermore, /var/log/messages contains:

  kernel: audit: type=1400 audit(1556043066.679:11460):
  apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
  disconnected path" error=-13 profile="syslog-ng" name="dev/log"
  pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
  ouid=0

  
  Here is a stripped-down skeleton of the /usr/bin/os-prober script, which 
demonstrates the problem:

  #!/bin/sh
  set -e -x
  
  newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
  }
  
  log() {
logger -t "$(basename "$0")" "$@"
  }
  
  debug() {
log "debug: $@"
  }
  
  ls -l /dev/log
  debug "Hello world"
  newns "$@"

  The expected behavior is that it should write "debug: os-prober-
  testcase Hello world" to /var/log/messages twice.  However, it only
  succeeds in writing "Hello world" once.  After the script respawns
  itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
  second attempt to write to /dev/log fails as described above.

  Since the os-prober Bash script runs with the -e flag, any error, even
  just a logging error, causes the script to terminate prematurely.
  (Arguably, the log() function should call `logger -t "$(basename
  "$0")" "$@" || :` so that logging failures aren't fatal.)

  
  The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change

  profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
  }

  to

  profile syslog-ng /{usr/,}sbin/syslog-ng 
flags=(complain,attach_disconnected) {
…
  }

  … then run `aa-complain sbin.syslog-ng` and `service syslog-ng
  restart`, before running update-grub again.  I assume that similar
  fixes would be required for the other logging daemons.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+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 2009239] [NEW] Updating base-files at point releases is pointless, misleading, and causes confusion and anxiety

2023-03-03 Thread Dimitri John Ledkov
Public bug reported:

Updating base-files at point releases is pointless, misleading, and
causes confusing and anxiety

Can we please stop updating base-files at point releases?

Building new installer media, and calling it with a new .N number is
good, and helps to differentiate what the initial state the machine
roughly was, given that ultimately the serial # of the installer media
is what matters.

Updating base-files on the installed system => not so much. As it is an
artificial line in the sand that doesn't change anything to the systems,
that are continuously upgrading. The upgrade of base-files package,
doesn't require to refresh snaps to latest revisions; install debs of
latest versions; nor is anything else happening to force that (i.e.
copying all packages from -updates to -security, like debian does).

But it does cause confusion and anxiety among enterprise customers, who
notice an update to base-files and a change of prompts, and suddenly
demand to revert back from .2 release to .1. Which is understandable,
since point releases in other operating systems have longer timespan,
and are allowed to remain on an older substream for longer, and require
admin actions to upgrade. Which is not the case with Ubuntu. Our interim
releases, are actually closer to what windows/rhel call point releases.
Since they are distinct, one can skip them, and they have a different
time window. Our LTS is just a single stream of updates, which is
continiously maintained, and thus it should always be recognized on the
installed systems as "24.04 LTS".

references:

Windows 10 https://learn.microsoft.com/en-
us/lifecycle/products/windows-10-home-and-pro note how windows 10
support multiple year/half releases, which are a track one can stay on
for a long time, even as a new one is already out.

Rhel point release timeframes
https://access.redhat.com/support/policy/updates/errata#viii notice how
every other point release is supported for up to 4 years, and is a track
one can stay on for that period of time.

Whereas Ubuntu LTS is a single track, that one cannot get off. There
isn't a point release subtrack.

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Status: New

** Summary changed:

- Updating base-files at point releases is pointless, misleading, and causes 
confusing and anxiety
+ Updating base-files at point releases is pointless, misleading, and causes 
confusion and anxiety

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

Title:
  Updating base-files at point releases is pointless, misleading, and
  causes confusion and anxiety

Status in base-files package in Ubuntu:
  New

Bug description:
  Updating base-files at point releases is pointless, misleading, and
  causes confusing and anxiety

  Can we please stop updating base-files at point releases?

  Building new installer media, and calling it with a new .N number is
  good, and helps to differentiate what the initial state the machine
  roughly was, given that ultimately the serial # of the installer media
  is what matters.

  Updating base-files on the installed system => not so much. As it is
  an artificial line in the sand that doesn't change anything to the
  systems, that are continuously upgrading. The upgrade of base-files
  package, doesn't require to refresh snaps to latest revisions; install
  debs of latest versions; nor is anything else happening to force that
  (i.e. copying all packages from -updates to -security, like debian
  does).

  But it does cause confusion and anxiety among enterprise customers,
  who notice an update to base-files and a change of prompts, and
  suddenly demand to revert back from .2 release to .1. Which is
  understandable, since point releases in other operating systems have
  longer timespan, and are allowed to remain on an older substream for
  longer, and require admin actions to upgrade. Which is not the case
  with Ubuntu. Our interim releases, are actually closer to what
  windows/rhel call point releases. Since they are distinct, one can
  skip them, and they have a different time window. Our LTS is just a
  single stream of updates, which is continiously maintained, and thus
  it should always be recognized on the installed systems as "24.04
  LTS".

  references:

  Windows 10 https://learn.microsoft.com/en-
  us/lifecycle/products/windows-10-home-and-pro note how windows 10
  support multiple year/half releases, which are a track one can stay on
  for a long time, even as a new one is already out.

  Rhel point release timeframes
  https://access.redhat.com/support/policy/updates/errata#viii notice
  how every other point release is supported for up to 4 years, and is a
  track one can stay on for that period of time.

  Whereas Ubuntu LTS is a single track, that one cannot get off. There
  isn't a point release subtrack.

To manage notifications 

[Touch-packages] [Bug 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

2023-02-24 Thread Dimitri John Ledkov
sponsored into unapproved queue

** Changed in: lxc (Ubuntu Bionic)
   Status: Triaged => In Progress

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

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  In Progress

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1886790/+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 1992513] Re: apt will not install nvidia-driver-470-server if nvidia-driver-450-server is installed and out of date

2023-02-22 Thread Dimitri John Ledkov
One should use ubuntu-drivers CLI or Additional Drivers GUI to install
or switch nvidia graphics stacks from one major series to another. It
ensures that correct matching pre-signed kernel drivers are installed
together with the right userspace (with and without gui stacks, as
needed).

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

Title:
  apt will not install nvidia-driver-470-server if nvidia-
  driver-450-server is installed and out of date

Status in apt package in Ubuntu:
  Triaged
Status in nvidia-graphics-drivers-450-server package in Ubuntu:
  New
Status in nvidia-graphics-drivers-470-server package in Ubuntu:
  New

Bug description:
  apt/jammy

  apt will refuse to install nvidia-driver-470-server if 
nvidia-driver-450-server is installed *and* out of date. I can reproduce this 
by disabling all but the jammy release pocket, installing the old n-d-450-s 
from there, and then enabling updates and trying to install n-v-470-s (where a 
new
  n-d-450-s is available):

  # libnvidia-gl-450-server has an update available
  root@dannf-apt-jammy:/var/cache# apt install --dry-run 
libnvidia-gl-470-server -o Debug::pkgProblemResolver=yes
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done

  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libnvidia-common-450-server : Conflicts: libnvidia-common
   libnvidia-common-470-server : Conflicts: libnvidia-common
  E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1992513/+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 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

2023-02-13 Thread Dimitri John Ledkov
we ought to sponosr
http://launchpadlibrarian.net/453184210/lxc_3.0.4-0ubuntu1_3.0.4-0ubuntu2.diff.gz
into bionic

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

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Triaged

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1886790/+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 2003785] [NEW] apt source exact-source-package doesn't download the requested source package

2023-01-24 Thread Dimitri John Ledkov
Public bug reported:

apt source exact-source-package doesn't download the right source
package


when specifying source package, i expect the exact source package to be 
downloaded.


example:

$ apt source linux-lowlatency => incorrectly downloads linux-meta-lowlatency
$ apt source --only-source linux-lowlatency => is very counter intuitive but 
downloads linux-lowlatency source package

Please default to downloading exact source package by default first, and
offer binary->source resolution separately.

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

** Summary changed:

- apt source exact-source-package doesn't download the right source package
+ apt source exact-source-package doesn't download the requested source package

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

Title:
  apt source exact-source-package doesn't download the requested source
  package

Status in apt package in Ubuntu:
  New

Bug description:
  apt source exact-source-package doesn't download the right source
  package

  
  when specifying source package, i expect the exact source package to be 
downloaded.

  
  example:

  $ apt source linux-lowlatency => incorrectly downloads linux-meta-lowlatency
  $ apt source --only-source linux-lowlatency => is very counter intuitive but 
downloads linux-lowlatency source package

  Please default to downloading exact source package by default first,
  and offer binary->source resolution separately.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003785/+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 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes

2023-01-24 Thread Dimitri John Ledkov
@sil2100 marked out test case in the bug report more clearly.

** Description changed:

  This is *probably* the wrong package, but it's the best I can figure for
  this, so here goes.
  
  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5,
  UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB
  disk space . OS is Ubuntu Desktop, Kinetic Final ISO.
+ 
+ [Testcase]
+ 
+ tl;dr encrypted-zfs, firstboot, `systemctl daemon-reload` must not
+ unmount half of mountpoints, ie. /var/lib.
  
  Steps to reproduce:
  
  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.
  
  Expected result: The package database should be updated normally.
  
  Actual result: You are presented with the following errors at the end of
  the apt output:
  
  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
- E: Problem opening 
+ E: Problem opening
  E: The package lists or status file could not be parsed or opened.
  
+ Notes: Switching to a TTY will print a crash error message related to
+ the same missing /var/lib/dpkg/status file. Running "sudo touch
+ /var/lib/dpkg/status" will allow "sudo apt update" to function and fix
+ the crashed process in the TTY.
  
- Notes: Switching to a TTY will print a crash error message related to the 
same missing /var/lib/dpkg/status file. Running "sudo touch 
/var/lib/dpkg/status" will allow "sudo apt update" to function and fix the 
crashed process in the TTY.
+ [End Testcase]
  
  Once you log in, you'll notice that Firefox is missing (bug #1993279),
  and you will likely be presented with a ton of error messages and other
  scary junk. At least one of those error messages was related to update-
  manager in my experience, and another one was from "check-new-release-
  gtk".
  
  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: zsys (not installed)
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 18 09:55:27 2022
  InstallationDate: Installed on 2022-10-18 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no username)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zsys
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  ZFS + Encryption installations of Ubuntu Desktop do not come up
  correctly on first boot, systemd unmounts many of the zfs volumes

Status in Ubuntu Manual Tests:
  New
Status in Release Notes for Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in ubiquity package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zsys package in Ubuntu:
  Invalid
Status in ubiquity source package in Jammy:
  Triaged

Bug description:
  This is *probably* the wrong package, but it's the best I can figure
  for this, so here goes.

  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core
  i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM,
  50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO.

  [Testcase]

  tl;dr encrypted-zfs, firstboot, `systemctl daemon-reload` must not
  unmount half of mountpoints, ie. /var/lib.

  Steps to reproduce:

  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.

  Expected result: The package database should be updated normally.

  Actual result: You are presented with the following errors at the end
  of the apt output:

  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
  E: Problem opening
  E: The package lists or status file could not be parsed or opened.

  Notes: Switching to a TTY will print a crash 

[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes

2023-01-24 Thread Dimitri John Ledkov
https://launchpad.net/ubuntu/jammy/+queue?queue_state=1_text=ubiquity

** Also affects: ubiquity (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: zfs-linux (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: snapd (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: zsys (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** No longer affects: snapd (Ubuntu Jammy)

** No longer affects: systemd (Ubuntu Jammy)

** Changed in: ubiquity (Ubuntu Jammy)
   Importance: Undecided => High

** Changed in: ubiquity (Ubuntu Jammy)
   Status: New => Triaged

** Changed in: ubiquity (Ubuntu Jammy)
Milestone: None => ubuntu-22.04.2

** No longer affects: zfs-linux (Ubuntu Jammy)

** No longer affects: zsys (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/1993318

Title:
  ZFS + Encryption installations of Ubuntu Desktop do not come up
  correctly on first boot, systemd unmounts many of the zfs volumes

Status in Ubuntu Manual Tests:
  New
Status in Release Notes for Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in ubiquity package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zsys package in Ubuntu:
  Invalid
Status in ubiquity source package in Jammy:
  Triaged

Bug description:
  This is *probably* the wrong package, but it's the best I can figure
  for this, so here goes.

  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core
  i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM,
  50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO.

  Steps to reproduce:

  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.

  Expected result: The package database should be updated normally.

  Actual result: You are presented with the following errors at the end
  of the apt output:

  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
  E: Problem opening 
  E: The package lists or status file could not be parsed or opened.

  
  Notes: Switching to a TTY will print a crash error message related to the 
same missing /var/lib/dpkg/status file. Running "sudo touch 
/var/lib/dpkg/status" will allow "sudo apt update" to function and fix the 
crashed process in the TTY.

  Once you log in, you'll notice that Firefox is missing (bug #1993279),
  and you will likely be presented with a ton of error messages and
  other scary junk. At least one of those error messages was related to
  update-manager in my experience, and another one was from "check-new-
  release-gtk".

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: zsys (not installed)
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 18 09:55:27 2022
  InstallationDate: Installed on 2022-10-18 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no username)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zsys
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1993318/+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 2003701] Re: PKCS7: Message signed outside of X.509 validity window

2023-01-23 Thread Dimitri John Ledkov
The best we can do, is to take notAfter time of the signing certificate
and add that as the signingTime, which will then be used by the Sign
command as given.

This will ensure the signature is within valid time-series.

I don't see an easy openssl API to sign things without any signature
timestamp.

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

Title:
  PKCS7: Message signed outside of X.509 validity window

Status in openssl package in Ubuntu:
  New
Status in sbsigntool package in Ubuntu:
  New

Bug description:
  When signing UEFI applications, the signature includes signing
  timestamp.

  Kernels, upon kexec, check that message signature is within the
  validity of the X.509 signing certificate.

  When using original canonical kernel team test key, I no longer can
  kexec kernels, as the test key has expired.

  UEFI specifications in general ignore signing time.

  IMHO we should remove / not include signing timestamp in the UEFI
  signatures to avoid this.

  ---

  i guess openssl needs to provide ability to create signatures without
  signingtime attribute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003701/+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 2003701] Re: PKCS7: Message signed outside of X.509 validity window

2023-01-23 Thread Dimitri John Ledkov
setting PKCS7_NOATTR is not enough, as that only removes the smime
capabilities signed attribute, whilst signature timestamp remains.

--- ./regular.text  2023-01-23 11:42:49.992929526 +
+++ noattr.text 2023-01-23 11:42:59.288981639 +
@@ -128,7 +128,7 @@
 
 object: signingTime (1.2.840.113549.1.9.5)
 set:
-  UTCTIME:Jan 23 11:41:20 2023 GMT
+  UTCTIME:Jan 23 11:41:53 2023 GMT
 
 object: messageDigest (1.2.840.113549.1.9.4)
 set:
@@ -136,56 +136,32 @@
  - f8 cf 89 70 c1 6c 14 26-6d 56 c1 25 96   ...p.l.%.
 000d - ce 74 11 77 a0 36 47 4d-3b 28 bf 7f 5b   .t.w.6GM;(..[
 001a - 1e b6 04 ed 21 f8!.
-
-object: S/MIME Capabilities (1.2.840.113549.1.9.15)
-set:
-  SEQUENCE:
-0:d=0  hl=2 l= 106 cons: SEQUENCE  
-2:d=1  hl=2 l=  11 cons:  SEQUENCE  
-4:d=2  hl=2 l=   9 prim:   OBJECT:aes-256-cbc
-   15:d=1  hl=2 l=  11 cons:  SEQUENCE  
-   17:d=2  hl=2 l=   9 prim:   OBJECT:aes-192-cbc
-   28:d=1  hl=2 l=  11 cons:  SEQUENCE  
-   30:d=2  hl=2 l=   9 prim:   OBJECT:aes-128-cbc
-   41:d=1  hl=2 l=  10 cons:  SEQUENCE  
-   43:d=2  hl=2 l=   8 prim:   OBJECT:des-ede3-cbc
-   53:d=1  hl=2 l=  14 cons:  SEQUENCE  
-   55:d=2  hl=2 l=   8 prim:   OBJECT:rc2-cbc
-   65:d=2  hl=2 l=   2 prim:   INTEGER   :80
-   69:d=1  hl=2 l=  13 cons:  SEQUENCE  
-   71:d=2  hl=2 l=   8 prim:   OBJECT:rc2-cbc
-   81:d=2  hl=2 l=   1 prim:   INTEGER   :40
-   84:d=1  hl=2 l=   7 cons:  SEQUENCE  
-   86:d=2  hl=2 l=   5 prim:   OBJECT:des-cbc
-   93:d=1  hl=2 l=  13 cons:  SEQUENCE  
-   95:d=2  hl=2 l=   8 prim:   OBJECT:rc2-cbc
-  105:d=2  hl=2 l=   1 prim:   INTEGER   :28
 digest_enc_alg: 


** Description changed:

  When signing UEFI applications, the signature includes signing
  timestamp.
  
  Kernels, upon kexec, check that message signature is within the validity
  of the X.509 signing certificate.
  
  When using original canonical kernel team test key, I no longer can
  kexec kernels, as the test key has expired.
  
  UEFI specifications in general ignore signing time.
  
  IMHO we should remove / not include signing timestamp in the UEFI
  signatures to avoid this.
+ 
+ ---
+ 
+ i guess openssl needs to provide ability to create signatures without
+ signingtime attribute.

** Also affects: openssl (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  PKCS7: Message signed outside of X.509 validity window

Status in openssl package in Ubuntu:
  New
Status in sbsigntool package in Ubuntu:
  New

Bug description:
  When signing UEFI applications, the signature includes signing
  timestamp.

  Kernels, upon kexec, check that message signature is within the
  validity of the X.509 signing certificate.

  When using original canonical kernel team test key, I no longer can
  kexec kernels, as the test key has expired.

  UEFI specifications in general ignore signing time.

  IMHO we should remove / not include signing timestamp in the UEFI
  signatures to avoid this.

  ---

  i guess openssl needs to provide ability to create signatures without
  signingtime attribute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003701/+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 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes

2023-01-16 Thread Dimitri John Ledkov
** Changed in: snapd (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  ZFS + Encryption installations of Ubuntu Desktop do not come up
  correctly on first boot, systemd unmounts many of the zfs volumes

Status in Ubuntu Manual Tests:
  New
Status in Release Notes for Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in ubiquity package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zsys package in Ubuntu:
  Invalid

Bug description:
  This is *probably* the wrong package, but it's the best I can figure
  for this, so here goes.

  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core
  i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM,
  50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO.

  Steps to reproduce:

  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.

  Expected result: The package database should be updated normally.

  Actual result: You are presented with the following errors at the end
  of the apt output:

  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
  E: Problem opening 
  E: The package lists or status file could not be parsed or opened.

  
  Notes: Switching to a TTY will print a crash error message related to the 
same missing /var/lib/dpkg/status file. Running "sudo touch 
/var/lib/dpkg/status" will allow "sudo apt update" to function and fix the 
crashed process in the TTY.

  Once you log in, you'll notice that Firefox is missing (bug #1993279),
  and you will likely be presented with a ton of error messages and
  other scary junk. At least one of those error messages was related to
  update-manager in my experience, and another one was from "check-new-
  release-gtk".

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: zsys (not installed)
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 18 09:55:27 2022
  InstallationDate: Installed on 2022-10-18 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no username)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zsys
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1993318/+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 1975587] Re: systemd: fix test-execute autotest failure with kernel 5.15 in focal

2022-11-18 Thread Dimitri John Ledkov
In the triggered logs

PASS: test-execute

is present with new kernel and new systemd

-env=ADT_TEST_TRIGGERS=linux-meta-hwe-5.15/5.15.0.53.59~20.04.21 linux-
hwe-5.15/5.15.0-53.59~20.04.1 linux-signed-hwe-5.15/5.15.0-53.59~20.04.1
systemd/245.4-4ubuntu3.19'

https://autopkgtest.ubuntu.com/results/autopkgtest-
focal/focal/amd64/s/systemd/20221118_144307_c3504@/log.gz

there are other failures, i.e. seccomp, which will need to be address
separately.

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

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

Title:
  systemd: fix test-execute autotest failure with kernel 5.15 in focal

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  test-execute autotest is failing in focal with kernel 5.15. This is
  because the following kernel commit changed the ABI for ioprio:

  e70344c05995 ("block: fix default IO priority handling")

  Previously setting IOPRIO_CLASS_NONE for a process would report
  IOPRIO_CLASS_NONE back. But starting with 5.15 it reports
  IOPRIO_CLASS_BE instead.

  [Test case]

  Run systemd autopkgtest and check for the test-execute result.

  [Fix]

  Change test/test-execute/exec-ioschedulingclass-none.service to
  recognize both "none" and "best-effort" as valid returned strings from
  ionice.

  This change is already available in jammy and above.

  [Regression potential]

  We may see regressions in systemd autopkgtest, we won't introduce any
  potential regressions in systemd itself, because this is only
  affecting the specific unit test.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1975587/+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 1975587] Re: systemd: fix test-execute autotest failure with kernel 5.15 in focal

2022-11-18 Thread Dimitri John Ledkov
all autopkgtests now pass https://people.canonical.com/~ubuntu-
archive/proposed-migration/focal/update_excuses.html#systemd

now testing if the new testcase is fixed with v5.15 kernels in focal.

Test request submitted.

Result history
https://autopkgtest.ubuntu.com/packages/systemd/focal/amd64
arch
amd64
package
systemd
release
focal
requester
xnox
triggers
['linux-meta-hwe-5.15/5.15.0.53.59~20.04.21', 
'linux-hwe-5.15/5.15.0-53.59~20.04.1', 
'linux-signed-hwe-5.15/5.15.0-53.59~20.04.1', 'systemd/245.4-4ubuntu3.19']

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

Title:
  systemd: fix test-execute autotest failure with kernel 5.15 in focal

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  test-execute autotest is failing in focal with kernel 5.15. This is
  because the following kernel commit changed the ABI for ioprio:

  e70344c05995 ("block: fix default IO priority handling")

  Previously setting IOPRIO_CLASS_NONE for a process would report
  IOPRIO_CLASS_NONE back. But starting with 5.15 it reports
  IOPRIO_CLASS_BE instead.

  [Test case]

  Run systemd autopkgtest and check for the test-execute result.

  [Fix]

  Change test/test-execute/exec-ioschedulingclass-none.service to
  recognize both "none" and "best-effort" as valid returned strings from
  ionice.

  This change is already available in jammy and above.

  [Regression potential]

  We may see regressions in systemd autopkgtest, we won't introduce any
  potential regressions in systemd itself, because this is only
  affecting the specific unit test.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1975587/+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 1973734] Re: FTBFS on riscv64 in focal

2022-11-18 Thread Dimitri John Ledkov
imho focal users on riscv64 deserve new pulseaudio

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

Title:
  FTBFS on riscv64 in focal

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * FTBFS on riscv64 in focal in unittest of volume test
   * Disable that unit test, as later releases do not run unittests on riscv64, 
and it's better to have up to date pulseaudio on riscv64 (with many security 
fixes), even if it doesn't completely correctly work.

  [Test Plan]

   * autopkgtests pass
   * riscv64 build is successful

  [Where problems could occur]

   * volume-test probably indicates that one can't set volume correctly
  on riscv64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1973734/+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 1973734] Re: FTBFS on riscv64 in focal

2022-11-18 Thread Dimitri John Ledkov
build successful
https://launchpad.net/ubuntu/+source/pulseaudio/1:13.99.1-1ubuntu3.14/+build/23853226

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

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

Title:
  FTBFS on riscv64 in focal

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * FTBFS on riscv64 in focal in unittest of volume test
   * Disable that unit test, as later releases do not run unittests on riscv64, 
and it's better to have up to date pulseaudio on riscv64 (with many security 
fixes), even if it doesn't completely correctly work.

  [Test Plan]

   * autopkgtests pass
   * riscv64 build is successful

  [Where problems could occur]

   * volume-test probably indicates that one can't set volume correctly
  on riscv64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1973734/+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 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes

2022-10-19 Thread Dimitri John Ledkov
https://code.launchpad.net/~xnox/ubiquity/+git/ubiquity/+merge/431831
should solve first boot post-install.

However, I don't think that will solve booting snapshot, or whenever on-
disk cached is missing/corrupted/out of date, and one tries to boot.

Seems quite scary.

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

Title:
  ZFS + Encryption installations of Ubuntu Desktop do not come up
  correctly on first boot, systemd unmounts many of the zfs volumes

Status in snapd package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New
Status in ubiquity package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  New
Status in zsys package in Ubuntu:
  Invalid

Bug description:
  This is *probably* the wrong package, but it's the best I can figure
  for this, so here goes.

  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core
  i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM,
  50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO.

  Steps to reproduce:

  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.

  Expected result: The package database should be updated normally.

  Actual result: You are presented with the following errors at the end
  of the apt output:

  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
  E: Problem opening 
  E: The package lists or status file could not be parsed or opened.

  
  Notes: Switching to a TTY will print a crash error message related to the 
same missing /var/lib/dpkg/status file. Running "sudo touch 
/var/lib/dpkg/status" will allow "sudo apt update" to function and fix the 
crashed process in the TTY.

  Once you log in, you'll notice that Firefox is missing (bug #1993279),
  and you will likely be presented with a ton of error messages and
  other scary junk. At least one of those error messages was related to
  update-manager in my experience, and another one was from "check-new-
  release-gtk".

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: zsys (not installed)
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 18 09:55:27 2022
  InstallationDate: Installed on 2022-10-18 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no username)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zsys
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+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 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes

2022-10-18 Thread Dimitri John Ledkov
on first boot /etc/zfs/zfs-list.cache/rboot /etc/zfs/zfs-
list.cache/bpool are either missing or empty.

this causes daemon-reload to go bananzas, as zfs generator runs for the
first time and generates many essential mount units. After that if cache
is populated, generators on boot & daemon-reload produces the same units
and everything and everyone is happy.

I wonder if installer could copy zfs-list.cache/ into target system.

Or I wonder if our zfs-mount-generator(8) in ubuntu is out of date
(because of zsys support).

Or if there has been some systemd regression.

I wonder if we can make zfs-mount-generator do nothing; if on first boot
there were no cache files to process.

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

Title:
  ZFS + Encryption installations of Ubuntu Desktop do not come up
  correctly on first boot, systemd unmounts many of the zfs volumes

Status in snapd package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New
Status in ubiquity package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  New
Status in zsys package in Ubuntu:
  Invalid

Bug description:
  This is *probably* the wrong package, but it's the best I can figure
  for this, so here goes.

  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core
  i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM,
  50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO.

  Steps to reproduce:

  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.

  Expected result: The package database should be updated normally.

  Actual result: You are presented with the following errors at the end
  of the apt output:

  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
  E: Problem opening 
  E: The package lists or status file could not be parsed or opened.

  
  Notes: Switching to a TTY will print a crash error message related to the 
same missing /var/lib/dpkg/status file. Running "sudo touch 
/var/lib/dpkg/status" will allow "sudo apt update" to function and fix the 
crashed process in the TTY.

  Once you log in, you'll notice that Firefox is missing (bug #1993279),
  and you will likely be presented with a ton of error messages and
  other scary junk. At least one of those error messages was related to
  update-manager in my experience, and another one was from "check-new-
  release-gtk".

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: zsys (not installed)
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 18 09:55:27 2022
  InstallationDate: Installed on 2022-10-18 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no username)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zsys
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+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 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager

2022-10-18 Thread Dimitri John Ledkov
subsequent boots are fine.

i wonder if we have a race somewhere, for example. On first boot zfs
cache is out of date. And zfs mount generator doesn't generate mounts
for all the mounted file systems.

then the first daemon-reload ever, will happen after zfs cache is
populated and the zfs volumes are emitted for the first time.

maybe something like mounting all subvolumes should happen from initrd.
as part of pivot root.

or at least building zfs cache, such that first boot's generators run is
correct.

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

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

Title:
  ZFS + Encryption installations of Ubuntu Desktop suffer various severe
  problems related to the package manager

Status in snapd package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New
Status in ubiquity package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  New
Status in zsys package in Ubuntu:
  Invalid

Bug description:
  This is *probably* the wrong package, but it's the best I can figure
  for this, so here goes.

  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core
  i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM,
  50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO.

  Steps to reproduce:

  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.

  Expected result: The package database should be updated normally.

  Actual result: You are presented with the following errors at the end
  of the apt output:

  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
  E: Problem opening 
  E: The package lists or status file could not be parsed or opened.

  
  Notes: Switching to a TTY will print a crash error message related to the 
same missing /var/lib/dpkg/status file. Running "sudo touch 
/var/lib/dpkg/status" will allow "sudo apt update" to function and fix the 
crashed process in the TTY.

  Once you log in, you'll notice that Firefox is missing (bug #1993279),
  and you will likely be presented with a ton of error messages and
  other scary junk. At least one of those error messages was related to
  update-manager in my experience, and another one was from "check-new-
  release-gtk".

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: zsys (not installed)
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 18 09:55:27 2022
  InstallationDate: Installed on 2022-10-18 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no username)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zsys
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+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 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager

2022-10-18 Thread Dimitri John Ledkov
1) doing first boot of encrypted zfs kinetic, edit boot cmdline to
include:

systemd.mask=snapd.service systemd.snapd.seeded.service
systemd.mask=snapd.socket

crutially this prevents snapd seeding to complete which calls systemctl
daemon-relaod.

system boots normally

2) login into tty and check mounts (mount | grep zfs | wc => is 17)

3) systemctl daemon-reload => causes issues with -.mount and stops a
bunch of stuff, and reastarts gdm, and unmounts a bunch of stuff.

4) login into tty, and check mounts, there are now just 7 zfs mounts

5) do $ sudo zfs mount -a => to get back to 17 mounts.

somehow something systemd does not like upon doing daemon-reload.



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

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

** Changed in: systemd (Ubuntu)
   Importance: Undecided => Critical

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

Title:
  ZFS + Encryption installations of Ubuntu Desktop suffer various severe
  problems related to the package manager

Status in snapd package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  New
Status in ubiquity package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Incomplete
Status in zsys package in Ubuntu:
  Invalid

Bug description:
  This is *probably* the wrong package, but it's the best I can figure
  for this, so here goes.

  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core
  i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM,
  50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO.

  Steps to reproduce:

  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.

  Expected result: The package database should be updated normally.

  Actual result: You are presented with the following errors at the end
  of the apt output:

  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
  E: Problem opening 
  E: The package lists or status file could not be parsed or opened.

  
  Notes: Switching to a TTY will print a crash error message related to the 
same missing /var/lib/dpkg/status file. Running "sudo touch 
/var/lib/dpkg/status" will allow "sudo apt update" to function and fix the 
crashed process in the TTY.

  Once you log in, you'll notice that Firefox is missing (bug #1993279),
  and you will likely be presented with a ton of error messages and
  other scary junk. At least one of those error messages was related to
  update-manager in my experience, and another one was from "check-new-
  release-gtk".

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: zsys (not installed)
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 18 09:55:27 2022
  InstallationDate: Installed on 2022-10-18 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no username)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zsys
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+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 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager

2022-10-18 Thread Dimitri John Ledkov
** Attachment added: "system.journal"
   
https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1993318/+attachment/5624966/+files/system.journal

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: snapd (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  ZFS + Encryption installations of Ubuntu Desktop suffer various severe
  problems related to the package manager

Status in snapd package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in ubiquity package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  New
Status in zsys package in Ubuntu:
  Invalid

Bug description:
  This is *probably* the wrong package, but it's the best I can figure
  for this, so here goes.

  Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core
  i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM,
  50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO.

  Steps to reproduce:

  1. Boot the Ubuntu desktop ISO.
  2. Select "Install Ubuntu" and proceed with the installation process.
  3. When you get to the "Installation type" screen, select "Advanced Options", 
and enable ZFS + Encryption.
  4. Proceed with the rest of the installation as normal.
  5. Reboot into the newly installed system.
  6. Log in.
  7. Run "sudo apt update" in a terminal.

  Expected result: The package database should be updated normally.

  Actual result: You are presented with the following errors at the end
  of the apt output:

  Reading package lists... Error!
  E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or 
directory)
  E: Could not open file  - open (2: No such file or directory)
  E: Problem opening 
  E: The package lists or status file could not be parsed or opened.

  
  Notes: Switching to a TTY will print a crash error message related to the 
same missing /var/lib/dpkg/status file. Running "sudo touch 
/var/lib/dpkg/status" will allow "sudo apt update" to function and fix the 
crashed process in the TTY.

  Once you log in, you'll notice that Firefox is missing (bug #1993279),
  and you will likely be presented with a ton of error messages and
  other scary junk. At least one of those error messages was related to
  update-manager in my experience, and another one was from "check-new-
  release-gtk".

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: zsys (not installed)
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 18 09:55:27 2022
  InstallationDate: Installed on 2022-10-18 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no username)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: zsys
  UpgradeStatus: No upgrade log present (probably fresh install)

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


  1   2   3   4   5   6   7   8   9   10   >