date:20221027

[Touch-packages] [Bug 1981385] Re: initrd lacks modules to mount boot image from http boot

2022-10-27 Thread Dan Bungert

** Changed in: initramfs-tools (Ubuntu Jammy)
   Status: Triaged => In Progress

** Changed in: initramfs-tools (Ubuntu Jammy)
 Assignee: Dan Bungert (dbungert) => (unassigned)

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

Title:
  initrd lacks modules to mount boot image from http boot

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Jammy:
  In Progress

Bug description:
  [ Impact ]

   * If you use UEFI http boot to boot an image (rather than an EFI
 executable) and get all the way to a normal userspace, you can
 access the boot image as /dev/pmem0. But this is not accessible in
 the initrd; presumably some modules are missing.
   * This is desirable because then you can just feed an installer ISO to
 a machine via http boot and the installer just works as normal
   * Add support for physical pmem devices, and simulation thereof with
 the memmap kernel command line parameter
   * The initrd is larger

  [ Test Plan ]

   * unpack an initrd on a Jammy system with the generic kernel
 metapackage with unmkinitramfs
   * observe that the directories kernel/drivers/{nvdimm,dax,acpi/nfit}
 are not present
   * install the updated initramfs-tools packages from proposed
   * again unpack an initrd on a Jammy system with the generic kernel
 metapackage with unmkinitramfs
   * observe that the directories kernel/drivers/{nvdimm,dax,acpi/nfit}
 are present now
   * reboot to confirm that the system still boots
   * modify /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT to contain a
 memmap entry - memmap=1G!4G seems to work on many systems over 4G of
 RAM, or do `dmesg | grep BIOS-e820` to observe the memory regions
 and select a usable one. 
   * update-grub and reboot again
   * a /dev/pmem device should now be present on the system

  [ Where problems could occur ]

   * The growth of the files in /boot will accelerate issues for users
 who have a dedicated boot partition that is not large enough

  [ Other Info ]

   * Details on the memmap kernel command line parameter:
 https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
   * PMEM simulation with memmap:
 
https://docs.pmem.io/persistent-memory/getting-started-guide/creating-development-environments/linux-environments/linux-memmap

  
  [ Original Bug Description ]

  If you use UEFI http boot to boot an image (rather than an EFI
  executable) and get all the way to a normal userspace, you can access
  the boot image as /dev/pmem0. But this is not accessible in the
  initrd; presumably some modules are missing. Dimitri added some
  modules that are clearly going to be necessary (kernel/drivers/nvdimm)
  in 0.140ubuntu14 and I added kernel/drivers/dax too in local
  experiments but this appears not to be enough to get it to appear.

  This is desirable because then you can just feed an installer ISO to a
  machine via http boot and the installer just works as normal (the
  speed and, uh, quality, of the implementation of HTTP in a given
  machine's firmware may mean this isn't always the best option but it
  would be nice if it worked in case someone's machine actually does
  this well).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1981385/+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 1995015] Re: Logitech Brio LED doesn't light up with 22.10

2022-10-27 Thread Ubuntu Foundations Team Bug Bot

** Package changed: ubuntu => alsa-driver (Ubuntu)

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

Title:
  Logitech Brio LED doesn't light up with 22.10

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  The LED light on my Logitech Brio webcam no longer lights up when the
  camera is active.

  When I exit an app that uses camera, the LED will illuminate for about
  a half second before turning off again.

  This behavior began after upgrading from Ubuntu 22.04 to 22.10.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu7
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  brett  2437 F wireplumber
   /dev/snd/pcmC0D0c:   brett  2434 F...m pipewire
   /dev/snd/controlC1:  brett  2437 F wireplumber
   /dev/snd/seq:brett  2434 F pipewire
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Oct 27 12:42:56 2022
  InstallationDate: Installed on 2021-12-16 (314 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: alsa-driver
  Symptom: audio
  UpgradeStatus: Upgraded to kinetic on 2022-10-22 (5 days ago)
  dmi.bios.date: 09/13/2022
  dmi.bios.release: 1.15
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.15.0
  dmi.board.name: 0Y4GNJ
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A02
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.15.0:bd09/13/2022:br1.15:svnDellInc.:pnXPS139300:pvr:rvnDellInc.:rn0Y4GNJ:rvrA02:cvnDellInc.:ct10:cvr:sku096D:
  dmi.product.family: XPS
  dmi.product.name: XPS 13 9300
  dmi.product.sku: 096D
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1995015/+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 1977499] Re: BUG IN UBUNTU 22.10 KINETIC KUDU: Audio Does Not Work Properly And Video Playback Is Very Laggy

2022-10-27 Thread Launchpad Bug Tracker

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

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

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

Title:
  BUG IN UBUNTU 22.10 KINETIC KUDU: Audio Does Not Work Properly And
  Video Playback Is Very Laggy

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  I had recently upgraded from Ubuntu 22.04 LTS Jammy Jellyfish To Ubuntu 22.10 
Kinetic Kudu (Development Branch) and i found 2 NEW Problems with it...
  1) Audio does not work at all
  2) Video playback is very laggy and not as smooth as before
  When i played a video,The playback was so laggy making me want to smash the 
screen and there was no audio at all like seriously,I am seeing this problem 
ever since I've upgraded to Ubuntu 22.10 Kinetic Kudu (Development 
Branch),Please Ubuntu Team fix this problem!

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: pulseaudio 1:15.99.1+dfsg1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30
  Uname: Linux 5.15.0-27-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  rasth   F pipewire-media-
   /dev/snd/seq:rasth  1110 F pipewire
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jun  3 05:52:08 2022
  InstallationDate: Installed on 2022-06-03 (0 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Alpha amd64 (20220602)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  SourcePackage: pulseaudio
  Symptom: audio
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/12/2020
  dmi.bios.release: 4.6
  dmi.bios.vendor: Phoenix Technologies LTD
  dmi.bios.version: 6.00
  dmi.board.name: 440BX Desktop Reference Platform
  dmi.board.vendor: Intel Corporation
  dmi.board.version: None
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 1
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.ec.firmware.release: 0.0
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd11/12/2020:br4.6:efr0.0:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:sku:
  dmi.product.name: VMware Virtual Platform
  dmi.product.version: None
  dmi.sys.vendor: VMware, Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1977499/+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 1995015] [NEW] Logitech Brio LED doesn't light up with 22.10

2022-10-27 Thread Launchpad Bug Tracker

You have been subscribed to a public bug:

The LED light on my Logitech Brio webcam no longer lights up when the
camera is active.

When I exit an app that uses camera, the LED will illuminate for about a
half second before turning off again.

This behavior began after upgrading from Ubuntu 22.04 to 22.10.

ProblemType: Bug
DistroRelease: Ubuntu 22.10
Package: alsa-base 1.0.25+dfsg-0ubuntu7
ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
Uname: Linux 5.19.0-21-generic x86_64
ApportVersion: 2.23.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/controlC0:  brett  2437 F wireplumber
 /dev/snd/pcmC0D0c:   brett  2434 F...m pipewire
 /dev/snd/controlC1:  brett  2437 F wireplumber
 /dev/snd/seq:brett  2434 F pipewire
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct 27 12:42:56 2022
InstallationDate: Installed on 2021-12-16 (314 days ago)
InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
RebootRequiredPkgs: Error: path contained symlinks.
SourcePackage: alsa-driver
Symptom: audio
UpgradeStatus: Upgraded to kinetic on 2022-10-22 (5 days ago)
dmi.bios.date: 09/13/2022
dmi.bios.release: 1.15
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.15.0
dmi.board.name: 0Y4GNJ
dmi.board.vendor: Dell Inc.
dmi.board.version: A02
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: 
dmi:bvnDellInc.:bvr1.15.0:bd09/13/2022:br1.15:svnDellInc.:pnXPS139300:pvr:rvnDellInc.:rn0Y4GNJ:rvrA02:cvnDellInc.:ct10:cvr:sku096D:
dmi.product.family: XPS
dmi.product.name: XPS 13 9300
dmi.product.sku: 096D
dmi.sys.vendor: Dell Inc.

** Affects: alsa-driver (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug kinetic wayland-session
-- 
Logitech Brio LED doesn't light up with 22.10
https://bugs.launchpad.net/bugs/1995015
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to alsa-driver in Ubuntu.

-- 
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 1981385] Re: initrd lacks modules to mount boot image from http boot

2022-10-27 Thread Dan Bungert

** Description changed:

+ [ Impact ]
+ 
+  * If you use UEFI http boot to boot an image (rather than an EFI
+executable) and get all the way to a normal userspace, you can
+access the boot image as /dev/pmem0. But this is not accessible in
+the initrd; presumably some modules are missing.
+  * This is desirable because then you can just feed an installer ISO to
+a machine via http boot and the installer just works as normal
+  * Add support for physical pmem devices, and simulation thereof with
+the memmap kernel command line parameter
+  * The initrd is larger
+ 
+ [ Test Plan ]
+ 
+  * unpack an initrd on a Jammy system with the generic kernel
+metapackage with unmkinitramfs
+  * observe that the directories kernel/drivers/{nvdimm,dax,acpi/nfit}
+are not present
+  * install the updated initramfs-tools packages from proposed
+  * again unpack an initrd on a Jammy system with the generic kernel
+metapackage with unmkinitramfs
+  * observe that the directories kernel/drivers/{nvdimm,dax,acpi/nfit}
+are present now
+  * reboot to confirm that the system still boots
+  * modify /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT to contain a
+memmap entry - memmap=1G!4G seems to work on many systems over 4G of
+RAM, or do `dmesg | grep BIOS-e820` to observe the memory regions
+and select a usable one. 
+  * update-grub and reboot again
+  * a /dev/pmem device should now be present on the system
+ 
+ [ Where problems could occur ]
+ 
+  * The growth of the files in /boot will accelerate issues for users
+who have a dedicated boot partition that is not large enough
+ 
+ [ Other Info ]
+ 
+  * Details on the memmap kernel command line parameter:
+https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
+  * PMEM simulation with memmap:
+
https://docs.pmem.io/persistent-memory/getting-started-guide/creating-development-environments/linux-environments/linux-memmap
+ 
+ 
+ [ Original Bug Description ]
+ 
  If you use UEFI http boot to boot an image (rather than an EFI
  executable) and get all the way to a normal userspace, you can access
  the boot image as /dev/pmem0. But this is not accessible in the initrd;
  presumably some modules are missing. Dimitri added some modules that are
  clearly going to be necessary (kernel/drivers/nvdimm) in 0.140ubuntu14
  and I added kernel/drivers/dax too in local experiments but this appears
  not to be enough to get it to appear.
  
  This is desirable because then you can just feed an installer ISO to a
  machine via http boot and the installer just works as normal (the speed
  and, uh, quality, of the implementation of HTTP in a given machine's
  firmware may mean this isn't always the best option but it would be nice
  if it worked in case someone's machine actually does this well).

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

Title:
  initrd lacks modules to mount boot image from http boot

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Jammy:
  Triaged

Bug description:
  [ Impact ]

   * If you use UEFI http boot to boot an image (rather than an EFI
 executable) and get all the way to a normal userspace, you can
 access the boot image as /dev/pmem0. But this is not accessible in
 the initrd; presumably some modules are missing.
   * This is desirable because then you can just feed an installer ISO to
 a machine via http boot and the installer just works as normal
   * Add support for physical pmem devices, and simulation thereof with
 the memmap kernel command line parameter
   * The initrd is larger

  [ Test Plan ]

   * unpack an initrd on a Jammy system with the generic kernel
 metapackage with unmkinitramfs
   * observe that the directories kernel/drivers/{nvdimm,dax,acpi/nfit}
 are not present
   * install the updated initramfs-tools packages from proposed
   * again unpack an initrd on a Jammy system with the generic kernel
 metapackage with unmkinitramfs
   * observe that the directories kernel/drivers/{nvdimm,dax,acpi/nfit}
 are present now
   * reboot to confirm that the system still boots
   * modify /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT to contain a
 memmap entry - memmap=1G!4G seems to work on many systems over 4G of
 RAM, or do `dmesg | grep BIOS-e820` to observe the memory regions
 and select a usable one. 
   * update-grub and reboot again
   * a /dev/pmem device should now be present on the system

  [ Where problems could occur ]

   * The growth of the files in /boot will accelerate issues for users
 who have a dedicated boot partition that is not large enough

  [ Other Info ]

   * Details on the memmap kernel command line parameter:
 https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
   * PMEM

[Touch-packages] [Bug 1988796] Re: Incorrect rendering triggered by cairo CAIRO_OPERATOR_SATURATE with subpixel positioning

2022-10-27 Thread Athos Ribeiro

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

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

Title:
  Incorrect rendering triggered by cairo CAIRO_OPERATOR_SATURATE with
  subpixel positioning

Status in pixman package in Ubuntu:
  Fix Released
Status in pixman source package in Focal:
  Fix Committed

Bug description:
  [ Impact ]

  OpenSlide (libopenslide0 in Ubuntu) uses Cairo as its rendering
  backend, always with CAIRO_OPERATOR_SATURATE and sometimes with
  subpixel positioning (when reading certain file formats), and Cairo in
  turn invokes this code. As a result, some slides incorrectly render
  with large blank spaces and with some pixels rendered on top of other
  pixels. This effectively makes OpenSlide unusable for several of the
  file formats it supports. No workaround is believed possible within
  the OpenSlide codebase.

  [ Test Plan ]

  Compile and run the pixman.c test program uploaded to this bug. It
  should report "OK".

  [ Where problems could occur ]

  Problems would show up as incorrect pixel output from software that
  renders via Cairo or pixman.

  [ Other Info ]

  While I'm not a pixman expert, it appears that the change should only
  affect the broken code path, and it seems unlikely that anything else
  depends on the incorrect math fixed by this patch. This bug hasn't
  previously been reported in Ubuntu, which may imply that this code
  path is not exercised by other packages in the distro.

  The affected source file has had no further commits upstream since
  this patch was applied in April 2019, and some basic commit grepping
  didn't turn up any followup fixes elsewhere in the tree.

  [ Original message ]

  pixman 0.38.4-0ubuntu1 in focal (and actually pixman 0.38.x generally)
  has a regression that causes incorrect rendering in some
  circumstances.  This can be triggered by the use of cairo with
  CAIRO_OPERATOR_SATURATE and subpixel positioning, and causes OpenSlide
   to produce incorrect output.

  The attached test program will print "Failed" if the bug exists, or
  "OK" if it doesn't.

  This is fixed upstream in
  https://gitlab.freedesktop.org/pixman/pixman/-/commit/8256c235, which
  is in pixman 0.40.0.

  See https://github.com/openslide/openslide/issues/278 for more
  context.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/1988796/+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 1993572] Re: samba profile: missing rule for mkdir /var/cache/samba/printing

2022-10-27 Thread Christian Boltz

Submitted as https://gitlab.com/apparmor/apparmor/-/merge_requests/937

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

Title:
  samba profile: missing rule for mkdir /var/cache/samba/printing

Status in apparmor package in Ubuntu:
  New

Bug description:
  After the fix for bug #1990692, one more rule is needed it seems.

  I put all samba profiles in enforce mode, and when I ran that final
  rpcclient command, got an error and an apparmor denied message:

  Prep:
  sudo apt install apparmor-profiles apparmor-utils apparmor-profiles-extra
  sudo apt install samba smbclient cups cups-client

  Set a password for the samba "root" user:
  printf "root\nroot\n" | sudo smbpasswd -a root

  Create a fake printer:
  sudo lpadmin -p testprinter -E -v /dev/null

  Check it's there:
  sudo lpstat -l -p testprinter

  $ rpcclient -Uroot%root localhost -c 'getprinter testprinter 2'
  cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe spoolss failed with error 
NT_STATUS_CONNECTION_DISCONNECTED
  do_cmd: Could not initialise spoolss. Error was 
NT_STATUS_CONNECTION_DISCONNECTED

  [qua out 19 14:42:36 2022] audit: type=1400 audit(1666201357.627:342):
  apparmor="DENIED" operation="mkdir" class="file" namespace="root//lxd-
  k-samba-apparmor_" profile="samba-rpcd-
  spoolss" name="/var/cache/samba/printing/" pid=129107
  comm="rpcd_spoolss" requested_mask="c" denied_mask="c" fsuid=100
  ouid=100

  And indeed, that directory wasn't created:
  $ l /var/cache/samba/printing
  ls: cannot access '/var/cache/samba/printing': No such file or directory
  $ l /var/cache/samba/
  total 16K
  drwxr-xr-x 1 root root   48 Oct 19 17:42 .
  drwxr-xr-x 1 root root  170 Oct 19 17:41 ..
  -rw-r--r-- 1 root root  166 Oct 19 17:42 browse.dat
  -rw-r--r-- 1 root root 8.7K Oct 19 17:42 smbprofile.tdb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1993572/+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 1981385] Re: initrd lacks modules to mount boot image from http boot

2022-10-27 Thread Dan Bungert

** Changed in: initramfs-tools (Ubuntu Jammy)
 Assignee: (unassigned) => Dan Bungert (dbungert)

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

Title:
  initrd lacks modules to mount boot image from http boot

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Jammy:
  Triaged

Bug description:
  If you use UEFI http boot to boot an image (rather than an EFI
  executable) and get all the way to a normal userspace, you can access
  the boot image as /dev/pmem0. But this is not accessible in the
  initrd; presumably some modules are missing. Dimitri added some
  modules that are clearly going to be necessary (kernel/drivers/nvdimm)
  in 0.140ubuntu14 and I added kernel/drivers/dax too in local
  experiments but this appears not to be enough to get it to appear.

  This is desirable because then you can just feed an installer ISO to a
  machine via http boot and the installer just works as normal (the
  speed and, uh, quality, of the implementation of HTTP in a given
  machine's firmware may mean this isn't always the best option but it
  would be nice if it worked in case someone's machine actually does
  this well).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1981385/+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 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface

2022-10-27 Thread Bug Watch Updater

** Changed in: initramfs-tools (Debian)
   Status: Unknown => 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/1994936

Title:
  initramfs need to mount efivarfs because kernel 6.0 deprecated
  'efivars' sysfs interface

Status in OEM Priority Project:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New
Status in initramfs-tools package in Debian:
  New

Bug description:
  [ Impact ]

  kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC
  RAID, mdadm needs initramfs to mount efivarfs instead.

  [1] The commit:
  commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741
  Author: Ard Biesheuvel 
  Date: Mon Jun 20 13:34:03 2022 +0200

  efi: vars: Remove deprecated 'efivars' sysfs interface

  [ Test Plan ]

  1. Install initramfs-tools
  2. update-initramfs -u
  3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs
  4. Check if boot script 00_mount_efivarfs exists in directory 
/tmp/extract-initramfs/main/scripts/init-top/
  5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot 
script 00_mount_efivarfs will be execute before udev.

  [ Where problems could occur ]

  Not sure if there any other tools/utilities also need to mount efivarfs as 
early as mdadm but the probability of file conflict should be very low.
  Also, there are no impact mounting efivarfs multiple times.
  mount: /sys/firmware/efi/efivars: efivarfs already mounted on 
/sys/firmware/efi/efivars.

  [ Scope ]

  Jammy, Kinetic

  [ Other Info ]

  The private bug link
  https://bugs.launchpad.net/somerville/+bug/1990231

  debian MR:
  https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1994936/+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 1993867] Re: Telegram sometimes start endless use 100% CPU

2022-10-27 Thread vodopad27

Fixed after upgrading to new version. I added this repo:
https://launchpad.net/~atareao/+archive/ubuntu/telegram


4.1.1 buggy and unusable for me.

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

Title:
  Telegram sometimes start endless use 100% CPU

Status in libvpx package in Ubuntu:
  New
Status in telegram-desktop package in Ubuntu:
  New

Bug description:
  On Ubuntu 22.04 all was fine.

  After upgrade to Ubuntu 22.10 Telegram was also updated. And
  sometimes, randomly, TG starts to use 100% CPU.

  Nothing on logs. But in starce i see a lot of these messages:
  [pid 33581] poll([{fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, 
events=POLLIN}, {fd=14, events=POLLIN}, {fd=19, events=POLLIN}, {fd=51, 
events=POLLIN}], 6, 8) = 0 (Timeout)

  
  PSA. Thousand messages.

  In normal state, when TG use 0-2% CPU, i see same messages. So, not
  related with bug.

  Please, ask me additional information, i can provide any logs.

  Today this bug occurs two times.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: telegram-desktop 4.1.1+ds-1ubuntu2
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Oct 22 01:53:36 2022
  InstallationDate: Installed on 2018-05-02 (1633 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: telegram-desktop
  UpgradeStatus: Upgraded to kinetic on 2022-10-20 (1 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1993867/+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 1993478] Re: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1

2022-10-27 Thread Nick Rosbrook

** Description changed:

+ [NOTE FOR SRU TEAM]
+ 
+ I would prefer that vorlon review the attached patch before the upload
+ is accepted. I will remove this note when that has happened.
+ 
  [Impact]
  
  Users with /etc/ssh/sshd_config's that contain ListenAddress entries
  with the port specified will not be migrated to socket-activated ssh
  correctly, or may be migrated when they should not be (e.g. if
  ListenAddress, with a port number, is specified more than once). This
  leaves users with a broken sshd configuration.
  
  [Test Plan]
  
  There are 4 tests that should be used to verify the fix:
  
  1. Upgrade to Kinetic with just one ListenAddress entry, which specifies
  port number.
  
- * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the 
following:
-   
+ * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the
+ following:
+ 
  [...defaults everywhere else...]
  
  #Port 22
  #AddressFamily any
  #ListenAddress 0.0.0.0
  #ListenAddress ::
  ListenAddress 0.0.0.0:1234
  
  [...defaults everywhere else...]
  
  * Run `systemctl restart ssh.service` and confirm that the new configuration 
works as expected.
  * Before running the upgrade, make sure -proposed is enabled.
  * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in 
/etc/update-manager/release-upgrades if needed).
  * On an affected system, ssh.socket will fail with `bad-setting` because 
/etc/systemd/system/ssh.socket.d/address.conf contains:
  
  [Socket]
  ListenStream=
  
  * On a patched system, ssh.socket will be active/listening, and
  /etc/systemd/system/ssh.socket.d/addresses.conf will contain the
  following:
  
  [Socket]
  ListenStream=
- ListenStream=0.0.0.0:1234 
+ ListenStream=0.0.0.0:1234
  
  2. Upgrade to Kinetic with multiple ListenAddress entries, each
  specifying port number.
  
- * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the 
following:
-   
+ * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the
+ following:
+ 
  [...defaults everywhere else...]
  
  #Port 22
  #AddressFamily any
  #ListenAddress 0.0.0.0
  #ListenAddress ::
  ListenAddress 0.0.0.0:1234
  ListenAddress [::]:4321
  
  [...defaults everywhere else...]
  
  * Run `systemctl restart ssh.service` and confirm that the new configuration 
works as expected.
  * Before running the upgrade, make sure -proposed is enabled.
  * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in 
/etc/update-manager/release-upgrades if needed).
  * On an affected system, migration will be attempted despite the multiple 
ListenAddress options, and ssh.socket will fail with `bad-setting` because 
/etc/systemd/system/ssh.socket.d/address.conf contains:
  
  [Socket]
  ListenStream=
  
  * On a patched system, the ListenAddress option will be parsed
  correctly, and migration will not be attempted.
  
  3. On a Kinetic system which was migrated, but with errors (e.g. test
  case #1, prior to being patched), installing the new package should
  correct the ssh.socket configuration.
  
+ * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the
+ following:
  
- * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the 
following:
-   
  [...defaults everywhere else...]
  
  #Port 22
  #AddressFamily any
  #ListenAddress 0.0.0.0
  #ListenAddress ::
  ListenAddress 0.0.0.0:1234
  
  [...defaults everywhere else...]
  
  * Run `systemctl restart ssh.service` and confirm that the new configuration 
works as expected.
  * Do NOT enable -proposed before the upgrade.
  * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in 
/etc/update-manager/release-upgrades if needed).
  * After the openssh-server configuration fails, enable -proposed, and upgrade 
openssh-server.
  
  * The ssh.socket configuration should be fixed, and 
/etc/systemd/system/ssh.socket.d/addresses.conf should contain:
  [Socket]
  ListenStream=
- ListenStream=0.0.0.0:1234 
+ ListenStream=0.0.0.0:1234
  
  4. On a Kinetic system which was incorrectly migrated to ssh socket
  activation (e.g. test case #2, prior to being patched), installing the
  new package reverts to the previous behavior.
  
- * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the 
following:
-   
+ * On a Jammy system, edit /etc/ssh/sshd_config so that it contains the
+ following:
+ 
  [...defaults everywhere else...]
  
  #Port 22
  #AddressFamily any
  #ListenAddress 0.0.0.0
  #ListenAddress ::
  ListenAddress 0.0.0.0:1234
  ListenAddress [::]:4321
  
  [...defaults everywhere else...]
  
  * Run `systemctl restart ssh.service` and confirm that the new configuration 
works as expected.
  * Do NOT enable -proposed before the upgrade.
  * Run `do-release-upgrade` to upgrade to Kinetic (setting Prompt=normal in 
/etc/update-manager/release-upgrades if needed).
  * After the openssh-server configuration fails, enable -proposed, and upgrade 
openssh-server.
  * The

[Touch-packages] [Bug 1993867] Re: Telegram sometimes start endless use 100% CPU

2022-10-27 Thread vodopad27

Another steps to reproduce:
1) Download archive
2) Unpack
3) Send gif to user\group


** Attachment added: "tild3265-6134-4566-b564-383630646239__photo.zip"
   
https://bugs.launchpad.net/ubuntu/+source/telegram-desktop/+bug/1993867/+attachment/5627283/+files/tild3265-6134-4566-b564-383630646239__photo.zip

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

Title:
  Telegram sometimes start endless use 100% CPU

Status in libvpx package in Ubuntu:
  New
Status in telegram-desktop package in Ubuntu:
  New

Bug description:
  On Ubuntu 22.04 all was fine.

  After upgrade to Ubuntu 22.10 Telegram was also updated. And
  sometimes, randomly, TG starts to use 100% CPU.

  Nothing on logs. But in starce i see a lot of these messages:
  [pid 33581] poll([{fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, 
events=POLLIN}, {fd=14, events=POLLIN}, {fd=19, events=POLLIN}, {fd=51, 
events=POLLIN}], 6, 8) = 0 (Timeout)

  
  PSA. Thousand messages.

  In normal state, when TG use 0-2% CPU, i see same messages. So, not
  related with bug.

  Please, ask me additional information, i can provide any logs.

  Today this bug occurs two times.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: telegram-desktop 4.1.1+ds-1ubuntu2
  ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7
  Uname: Linux 5.19.0-21-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Oct 22 01:53:36 2022
  InstallationDate: Installed on 2018-05-02 (1633 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: telegram-desktop
  UpgradeStatus: Upgraded to kinetic on 2022-10-20 (1 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1993867/+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 1994146] Re: [SRU] apparmor - Focal, Jammy

2022-10-27 Thread Alex Murray

These have now been uploaded to -proposed and are sitting in UNAPPROVED:

https://launchpad.net/ubuntu/jammy/+queue?queue_state=1_text=apparmor
https://launchpad.net/ubuntu/focal/+queue?queue_state=1_text=apparmor

** Changed in: apparmor (Ubuntu Focal)
   Status: Confirmed => In Progress

** Changed in: apparmor (Ubuntu Jammy)
   Status: Confirmed => In Progress

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

Title:
  [SRU] apparmor - Focal, Jammy

Status in apparmor package in Ubuntu:
  Confirmed
Status in apparmor source package in Focal:
  In Progress
Status in apparmor source package in Jammy:
  In Progress

Bug description:
  [ Impact ]

  This is a SRU proposal for apparmor in Focal and Jammy.
  For focal, we want to SRU fixes for Bug 1964636 which introduces the
  capability upstream patches. We are also fixing Bug 1728130 and
  Bug 1993353 which are introducing full backport of abi from
  apparmor-3.0 and support for POSIX message queue rules, which are both
  a request from Honeywell.

  Note that specifically for message queue rules, we are overriding the
  abi behavior.
  Message queue mediation is not a part of the 2.13 abi we are
  pinning. Honeywell has a kernel that has message queue mediation,
  but their policy does not contain an abi specified, so when we pin the
  abi for a kernel that does not mediate message queue, it will break
  Honeywell's AppArmor policies. So we are making an exception: when abi
  is not specified in the policy, and the policy contain mqueue rules,
  we are enforcing mqueue rules. When the policy does not contain mqueue
  rules, then they are not being enforced. This is so we do not break
  Honeywell policies and we also are not breaking policies that were
  developed when there was no mqueue or abi support.

  For jammy, we are SRUing fixes for Bug 1993353 which adds message
  queue rules support. 

  
  [ Test Plan ]

  This has been extensively tested by using QA Regression Tests[1] for
  AppArmor. All tests have passed and demonstrated AppArmor to be
  working as expected. We are also adding regression tests for message
  queue rules[2] which guarantees it is working as expected.

  [1] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py
  [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858

  [ Where problems could occur ]

  The message queue rules support could cause issues for AppArmor
  policies that were developed before there was support for mqueues,
  that's why we are also backporting abi support and pinning the abi on
  parser.conf on focal. Jammy already has the abi pinned for a kernel
  that does not have support for mqueue mediation.

  [ Other Info ]

  The patches for both focal and jammy can be found at:
  https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+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 1994146] Re: [SRU] apparmor - Focal, Jammy

2022-10-27 Thread Launchpad Bug Tracker

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

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

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

Title:
  [SRU] apparmor - Focal, Jammy

Status in apparmor package in Ubuntu:
  Confirmed
Status in apparmor source package in Focal:
  Confirmed
Status in apparmor source package in Jammy:
  Confirmed

Bug description:
  [ Impact ]

  This is a SRU proposal for apparmor in Focal and Jammy.
  For focal, we want to SRU fixes for Bug 1964636 which introduces the
  capability upstream patches. We are also fixing Bug 1728130 and
  Bug 1993353 which are introducing full backport of abi from
  apparmor-3.0 and support for POSIX message queue rules, which are both
  a request from Honeywell.

  Note that specifically for message queue rules, we are overriding the
  abi behavior.
  Message queue mediation is not a part of the 2.13 abi we are
  pinning. Honeywell has a kernel that has message queue mediation,
  but their policy does not contain an abi specified, so when we pin the
  abi for a kernel that does not mediate message queue, it will break
  Honeywell's AppArmor policies. So we are making an exception: when abi
  is not specified in the policy, and the policy contain mqueue rules,
  we are enforcing mqueue rules. When the policy does not contain mqueue
  rules, then they are not being enforced. This is so we do not break
  Honeywell policies and we also are not breaking policies that were
  developed when there was no mqueue or abi support.

  For jammy, we are SRUing fixes for Bug 1993353 which adds message
  queue rules support. 

  
  [ Test Plan ]

  This has been extensively tested by using QA Regression Tests[1] for
  AppArmor. All tests have passed and demonstrated AppArmor to be
  working as expected. We are also adding regression tests for message
  queue rules[2] which guarantees it is working as expected.

  [1] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py
  [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858

  [ Where problems could occur ]

  The message queue rules support could cause issues for AppArmor
  policies that were developed before there was support for mqueues,
  that's why we are also backporting abi support and pinning the abi on
  parser.conf on focal. Jammy already has the abi pinned for a kernel
  that does not have support for mqueue mediation.

  [ Other Info ]

  The patches for both focal and jammy can be found at:
  https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+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 1994146] Re: [SRU] apparmor - Focal, Jammy

2022-10-27 Thread Launchpad Bug Tracker

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

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

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

Title:
  [SRU] apparmor - Focal, Jammy

Status in apparmor package in Ubuntu:
  Confirmed
Status in apparmor source package in Focal:
  Confirmed
Status in apparmor source package in Jammy:
  Confirmed

Bug description:
  [ Impact ]

  This is a SRU proposal for apparmor in Focal and Jammy.
  For focal, we want to SRU fixes for Bug 1964636 which introduces the
  capability upstream patches. We are also fixing Bug 1728130 and
  Bug 1993353 which are introducing full backport of abi from
  apparmor-3.0 and support for POSIX message queue rules, which are both
  a request from Honeywell.

  Note that specifically for message queue rules, we are overriding the
  abi behavior.
  Message queue mediation is not a part of the 2.13 abi we are
  pinning. Honeywell has a kernel that has message queue mediation,
  but their policy does not contain an abi specified, so when we pin the
  abi for a kernel that does not mediate message queue, it will break
  Honeywell's AppArmor policies. So we are making an exception: when abi
  is not specified in the policy, and the policy contain mqueue rules,
  we are enforcing mqueue rules. When the policy does not contain mqueue
  rules, then they are not being enforced. This is so we do not break
  Honeywell policies and we also are not breaking policies that were
  developed when there was no mqueue or abi support.

  For jammy, we are SRUing fixes for Bug 1993353 which adds message
  queue rules support. 

  
  [ Test Plan ]

  This has been extensively tested by using QA Regression Tests[1] for
  AppArmor. All tests have passed and demonstrated AppArmor to be
  working as expected. We are also adding regression tests for message
  queue rules[2] which guarantees it is working as expected.

  [1] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py
  [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858

  [ Where problems could occur ]

  The message queue rules support could cause issues for AppArmor
  policies that were developed before there was support for mqueues,
  that's why we are also backporting abi support and pinning the abi on
  parser.conf on focal. Jammy already has the abi pinned for a kernel
  that does not have support for mqueue mediation.

  [ Other Info ]

  The patches for both focal and jammy can be found at:
  https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+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 1994146] Re: [SRU] apparmor - Focal, Jammy

2022-10-27 Thread Launchpad Bug Tracker

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

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

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

Title:
  [SRU] apparmor - Focal, Jammy

Status in apparmor package in Ubuntu:
  Confirmed
Status in apparmor source package in Focal:
  Confirmed
Status in apparmor source package in Jammy:
  Confirmed

Bug description:
  [ Impact ]

  This is a SRU proposal for apparmor in Focal and Jammy.
  For focal, we want to SRU fixes for Bug 1964636 which introduces the
  capability upstream patches. We are also fixing Bug 1728130 and
  Bug 1993353 which are introducing full backport of abi from
  apparmor-3.0 and support for POSIX message queue rules, which are both
  a request from Honeywell.

  Note that specifically for message queue rules, we are overriding the
  abi behavior.
  Message queue mediation is not a part of the 2.13 abi we are
  pinning. Honeywell has a kernel that has message queue mediation,
  but their policy does not contain an abi specified, so when we pin the
  abi for a kernel that does not mediate message queue, it will break
  Honeywell's AppArmor policies. So we are making an exception: when abi
  is not specified in the policy, and the policy contain mqueue rules,
  we are enforcing mqueue rules. When the policy does not contain mqueue
  rules, then they are not being enforced. This is so we do not break
  Honeywell policies and we also are not breaking policies that were
  developed when there was no mqueue or abi support.

  For jammy, we are SRUing fixes for Bug 1993353 which adds message
  queue rules support. 

  
  [ Test Plan ]

  This has been extensively tested by using QA Regression Tests[1] for
  AppArmor. All tests have passed and demonstrated AppArmor to be
  working as expected. We are also adding regression tests for message
  queue rules[2] which guarantees it is working as expected.

  [1] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py
  [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858

  [ Where problems could occur ]

  The message queue rules support could cause issues for AppArmor
  policies that were developed before there was support for mqueues,
  that's why we are also backporting abi support and pinning the abi on
  parser.conf on focal. Jammy already has the abi pinned for a kernel
  that does not have support for mqueue mediation.

  [ Other Info ]

  The patches for both focal and jammy can be found at:
  https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+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 1993572] Re: samba profile: missing rule for mkdir /var/cache/samba/printing

2022-10-27 Thread Andreas Hasenack

Er, correct, just "w" is enough :)

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

Title:
  samba profile: missing rule for mkdir /var/cache/samba/printing

Status in apparmor package in Ubuntu:
  New

Bug description:
  After the fix for bug #1990692, one more rule is needed it seems.

  I put all samba profiles in enforce mode, and when I ran that final
  rpcclient command, got an error and an apparmor denied message:

  Prep:
  sudo apt install apparmor-profiles apparmor-utils apparmor-profiles-extra
  sudo apt install samba smbclient cups cups-client

  Set a password for the samba "root" user:
  printf "root\nroot\n" | sudo smbpasswd -a root

  Create a fake printer:
  sudo lpadmin -p testprinter -E -v /dev/null

  Check it's there:
  sudo lpstat -l -p testprinter

  $ rpcclient -Uroot%root localhost -c 'getprinter testprinter 2'
  cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe spoolss failed with error 
NT_STATUS_CONNECTION_DISCONNECTED
  do_cmd: Could not initialise spoolss. Error was 
NT_STATUS_CONNECTION_DISCONNECTED

  [qua out 19 14:42:36 2022] audit: type=1400 audit(1666201357.627:342):
  apparmor="DENIED" operation="mkdir" class="file" namespace="root//lxd-
  k-samba-apparmor_" profile="samba-rpcd-
  spoolss" name="/var/cache/samba/printing/" pid=129107
  comm="rpcd_spoolss" requested_mask="c" denied_mask="c" fsuid=100
  ouid=100

  And indeed, that directory wasn't created:
  $ l /var/cache/samba/printing
  ls: cannot access '/var/cache/samba/printing': No such file or directory
  $ l /var/cache/samba/
  total 16K
  drwxr-xr-x 1 root root   48 Oct 19 17:42 .
  drwxr-xr-x 1 root root  170 Oct 19 17:41 ..
  -rw-r--r-- 1 root root  166 Oct 19 17:42 browse.dat
  -rw-r--r-- 1 root root 8.7K Oct 19 17:42 smbprofile.tdb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1993572/+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 1994067] Re: "Windows 11 Pro" and "Ubuntu 22.04.1 LTS" are installed and up to date on the laptop. There is no hardware problem with the laptop. No sound from operating system "U

2022-10-27 Thread Marc Deslauriers

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

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

Title:
  "Windows 11 Pro" and "Ubuntu 22.04.1 LTS" are installed and up to date
  on the laptop. There is no hardware problem with the laptop. No sound
  from operating system "Ubuntu 22.04.1 LTS". But the sound comes from
  the operating system "Windows 11 Pro" without any problems.

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  "Windows 11 Pro" and "Ubuntu 22.04.1 LTS" are installed and up to date
  on the laptop. There is no hardware problem with the laptop. No sound
  from operating system "Ubuntu 22.04.1 LTS". But the sound comes from
  the operating system "Windows 11 Pro" without any problems.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: pulseaudio 1:15.99.1+dfsg1-1ubuntu2
  ProcVersionSignature: Ubuntu 5.15.0-52.58-generic 5.15.60
  Uname: Linux 5.15.0-52-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  muhammed   1749 F pulseaudio
   /dev/snd/controlC1:  muhammed   1749 F pulseaudio
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Oct 24 22:46:37 2022
  InstallationDate: Installed on 2022-10-19 (5 days ago)
  InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  SourcePackage: pulseaudio
  Symptom: audio
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/28/2021
  dmi.bios.release: 87.176
  dmi.bios.vendor: INSYDE Corp.
  dmi.bios.version: TN1V7.10_Monster
  dmi.board.asset.tag: Board Asset Tag
  dmi.board.name: Huma H5 V3.2
  dmi.board.vendor: Monster
  dmi.board.version: V20
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: Monster
  dmi.chassis.version: Chassis Version
  dmi.ec.firmware.release: 6.6
  dmi.modalias: 
dmi:bvnINSYDECorp.:bvrTN1V7.10_Monster:bd12/28/2021:br87.176:efr6.6:svnMONSTER:pnHumaH5V3.2:pvrV10:rvnMonster:rnHumaH5V3.2:rvrV20:cvnMonster:ct10:cvrChassisVersion:skuH5V32TN1156MSCD:
  dmi.product.family: HUMA
  dmi.product.name: Huma H5 V3.2
  dmi.product.sku: H5V32TN1156MSCD
  dmi.product.version: V10
  dmi.sys.vendor: MONSTER
  modified.conffile..etc.pulse.default.pa: [modified]
  mtime.conffile..etc.pulse.default.pa: 2022-10-24T22:36:17.567999

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1994067/+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 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu

2022-10-27 Thread Andy Chi

** Tags added: originate-from-1994098 stella

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

Title:
  Can't boot: "error: out of memory." immediately after the grub menu

Status in grub:
  Unknown
Status in OEM Priority Project:
  Triaged
Status in grub2-signed package in Ubuntu:
  Triaged
Status in grub2-unsigned package in Ubuntu:
  Triaged
Status in initramfs-tools package in Ubuntu:
  Won't Fix
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  [Impact]

   * In some cases, if the users’ initramfs grow bigger, then it’ll
  likely not be able to be loaded by grub2.

   * Some real cases from OEM projects:

  In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
  puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
  Also the gfxpayload=auto will remain to use 4K resolution since it’s
  what EFI POST passed.

  In this case, the grub isn't able to load initramfs because the
  grub_memalign() won't be able to get suitable memory for the larger
  file:

  ```
  #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
  #1 0x7dd7b074 in grub_malloc (size=592214020) at 
../../../grub-core/kern/mm.c:408
  #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
  at ../../../grub-core/kern/verifiers.c:150
  #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 
"/boot/initrd.img-5.17.0-1011-oem",
  type=131076) at ../../../grub-core/kern/file.c:121
  #4 0x7bcd5a30 in ?? ()
  #5 0x7fe21247 in ?? ()
  #6 0x7bc030c8 in ?? ()
  #7 0x00017fe21238 in ?? ()
  #8 0x7bcd5320 in ?? ()
  #9 0x7fe21250 in ?? ()
  #10 0x in ?? ()
  ```

  Based on grub_mm_dump, we can see the memory fragment (some parts seem
  likely be used because of 4K resolution?) and doesn’t have available
  contiguous memory for larger file as:

  ```
  grub_real_malloc(...)
  ...
  if (cur->size >= n + extra)
  ```

  Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
  guide 4.2.3[2], we can ask 32bits+ on AllocatePages().

  As most X86_64 platforms should support 64 bits addressing, we should
  extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
  memory.

   * When users grown the initramfs, then probably will get initramfs
  not found which really annoyed and impact the user experience (system
  not able to boot).

  [Test Plan]

   * detailed instructions how to reproduce the bug:

  1. Any method to grow the initramfs, such as install nvidia-driver.

  2. If developers would like to reproduce, then could dd if=/dev/random
  of=... bs=1M count=500, something like:

  ```
  $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
  #!/bin/sh

  PREREQ=""

  prereqs()
  {
  echo "$PREREQ"
  }

  case $1 in
  # get pre-requisites
  prereqs)
  prereqs
  exit 0
  ;;
  esac

  . /usr/share/initramfs-tools/hook-functions
  dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
  ```

  And then update-initramfs

   * After applying my patches, the issue is gone.

   * I did also test my test grubx64.efi in:

  1. X86_64 qemu with
  1.1. 60M initramfs + 5.15.0-37-generic kernel
  1.2. 565M initramfs + 5.17.0-1011-oem kernel

  2. Amd64 HP mobile workstation with
  2.1. 65M initramfs + 5.15.0-39-generic kernel
  2.2. 771M initramfs + 5.17.0-1011-oem kernel

  All working well.

  [Where problems could occur]

  * The changes almost in i386/efi, thus the impact will be in the i386 / 
x86_64 EFI system.
  The other change is to modify the “grub-core/kern/efi/mm.c” but I use the 
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
  Thus it should not impact them.

  * There is a “#if defined(__x86_64__)” which intent to limit the >
  32bits code in i386 system and also

  ```
   #if defined (__code_model_large__)
  -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
  +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
  +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
   #else
   #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
  +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
   #endif
  ```

  If everything works as expected, then i386 should working good.

  If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
  4GB memory region and never be able to access.

  [Other Info]

   * Upstream grub2 bug #61058
  https://savannah.gnu.org/bugs/index.php?61058

   * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320

   * Test grubx64.efi:
  https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320

   * Test source code: https://github.com/os369510/grub2/tree/lp1842320

   * If you built the package, then test grubx64.efi is under
  “obj/monolithic/grub-efi-amd64/grubx64.efi”, in my case:

[Touch-packages] [Bug 1994697] Re: 1440x900 (3:2) resolution mismatch

2022-10-27 Thread Xargon

** Summary changed:

- 1400x900 (3:2) resolution mismatch
+ 1440x900 (3:2) resolution mismatch

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

Title:
  1440x900 (3:2) resolution mismatch

Status in xorg package in Ubuntu:
  New

Bug description:
  The listed resolution 1440x900 (3:2) it's not correct: my monitor is 16:10 
and I can see black bars.
  I suppose the real resolution is 1440x960 (3:2), but the actual 1440x900 
(16:10) is missing.

  I updated some packages today and the issue came after reboot:

  2022-10-26 16:48:06 upgrade google-chrome-stable:amd64 106.0.5249.119-1 
107.0.5304.68-1
  2022-10-26 16:48:14 upgrade tzdata:all 2022c-0ubuntu0.22.04.0 
2022e-0ubuntu0.22.04.0
  2022-10-26 16:48:14 upgrade alsa-ucm-conf:all 1.2.6.3-1ubuntu1 
1.2.6.3-1ubuntu1.1
  2022-10-26 16:48:14 upgrade docker-ce-cli:amd64 5:20.10.20~3-0~ubuntu-jammy 
5:20.10.21~3-0~ubuntu-jammy
  2022-10-26 16:48:18 upgrade docker-ce:amd64 5:20.10.20~3-0~ubuntu-jammy 
5:20.10.21~3-0~ubuntu-jammy
  2022-10-26 16:48:20 upgrade docker-ce-rootless-extras:amd64 
5:20.10.20~3-0~ubuntu-jammy 5:20.10.21~3-0~ubuntu-jammy
  2022-10-26 16:48:20 upgrade docker-compose-plugin:amd64 2.12.0~ubuntu-jammy 
2.12.2~ubuntu-jammy
  2022-10-26 16:48:21 upgrade docker-scan-plugin:amd64 0.17.0~ubuntu-jammy 
0.21.0~ubuntu-jammy
  2022-10-26 16:48:22 upgrade fwupd:amd64 1.7.5-3 1.7.9-1~22.04.1
  2022-10-26 16:48:22 upgrade libfwupdplugin5:amd64 1.7.5-3 1.7.9-1~22.04.1
  2022-10-26 16:48:22 upgrade libfwupd2:amd64 1.7.5-3 1.7.9-1~22.04.1
  2022-10-26 16:48:22 upgrade gdb:amd64 12.0.90-0ubuntu1 12.1-0ubuntu1~22.04
  2022-10-26 16:48:22 upgrade grub-efi-amd64:amd64 2.06-2ubuntu7 2.06-2ubuntu10
  2022-10-26 16:48:22 upgrade grub-efi-amd64-signed:amd64 1.180+2.06-2ubuntu7 
1.182~22.04.1+2.06-2ubuntu10
  2022-10-26 16:48:22 upgrade grub-efi-amd64-bin:amd64 2.06-2ubuntu7 
2.06-2ubuntu10
  2022-10-26 16:48:22 upgrade linux-firmware:all 
20220329.git681281e4-0ubuntu3.5 20220329.git681281e4-0ubuntu3.6
  2022-10-26 16:48:26 upgrade qemu-system-gui:amd64 1:6.2+dfsg-2ubuntu6.4 
1:6.2+dfsg-2ubuntu6.5
  2022-10-26 16:48:26 upgrade qemu-block-extra:amd64 1:6.2+dfsg-2ubuntu6.4 
1:6.2+dfsg-2ubuntu6.5
  2022-10-26 16:48:26 upgrade qemu-system-x86:amd64 1:6.2+dfsg-2ubuntu6.4 
1:6.2+dfsg-2ubuntu6.5
  2022-10-26 16:48:26 upgrade qemu-system-common:amd64 1:6.2+dfsg-2ubuntu6.4 
1:6.2+dfsg-2ubuntu6.5
  2022-10-26 16:48:26 upgrade qemu-utils:amd64 1:6.2+dfsg-2ubuntu6.4 
1:6.2+dfsg-2ubuntu6.5
  2022-10-26 16:48:26 upgrade qemu-system-data:all 1:6.2+dfsg-2ubuntu6.4 
1:6.2+dfsg-2ubuntu6.5
  2022-10-26 16:48:27 upgrade snapd:amd64 2.57.4+22.04 2.57.5+22.04
  2022-10-26 16:48:27 upgrade teamviewer:amd64 15.34.4 15.35.5
  2022-10-26 16:48:34 upgrade xserver-common:all 2:21.1.3-2ubuntu2.1 
2:21.1.3-2ubuntu2.2
  2022-10-26 16:48:34 upgrade xserver-xephyr:amd64 2:21.1.3-2ubuntu2.1 
2:21.1.3-2ubuntu2.2
  2022-10-26 16:48:35 upgrade xserver-xorg-legacy:amd64 2:21.1.3-2ubuntu2.1 
2:21.1.3-2ubuntu2.2
  2022-10-26 16:48:35 upgrade xserver-xorg-core:amd64 2:21.1.3-2ubuntu2.1 
2:21.1.3-2ubuntu2.2
  2022-10-26 16:48:35 upgrade sssd:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade python3-sss:amd64 2.6.3-1ubuntu3.1 
2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade sssd-proxy:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade sssd-krb5:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade sssd-ad:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade sssd-ldap:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade sssd-ipa:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade sssd-krb5-common:amd64 2.6.3-1ubuntu3.1 
2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade sssd-ad-common:amd64 2.6.3-1ubuntu3.1 
2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade sssd-common:amd64 2.6.3-1ubuntu3.1 
2.6.3-1ubuntu3.2
  2022-10-26 16:48:35 upgrade libnss-sss:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2
  2022-10-26 16:48:36 upgrade libpam-sss:amd64 2.6.3-1ubuntu3.1 2.6.3-1ubuntu3.2
  2022-10-26 16:48:36 upgrade libsss-certmap0:amd64 2.6.3-1ubuntu3.1 
2.6.3-1ubuntu3.2
  2022-10-26 16:48:36 upgrade libsss-nss-idmap0:amd64 2.6.3-1ubuntu3.1 
2.6.3-1ubuntu3.2
  2022-10-26 16:48:36 upgrade libsss-idmap0:amd64 2.6.3-1ubuntu3.1 
2.6.3-1ubuntu3.2
  2022-10-26 16:48:36 upgrade libipa-hbac0:amd64 2.6.3-1ubuntu3.1 
2.6.3-1ubuntu3.2
  2022-10-26 16:48:36 upgrade ovmf:all 2022.02-3 2022.02-3ubuntu0.22.04.1

  I suppose this bug is here:

  2022-10-26 16:48:34 upgrade xserver-common:all 2:21.1.3-2ubuntu2.1 
2:21.1.3-2ubuntu2.2
  2022-10-26 16:48:34 upgrade xserver-xephyr:amd64 2:21.1.3-2ubuntu2.1 
2:21.1.3-2ubuntu2.2
  2022-10-26 16:48:35 upgrade xserver-xorg-legacy:amd64 2:21.1.3-2ubuntu2.1 
2:21.1.3-2ubuntu2.2
  2022-10-26 16:48:35 upgrade xserver-xorg-core:amd64 2:21.1.3-2ubuntu2.1 
2:21.1.3-2ubuntu2.2

[Touch-packages] [Bug 1994810] Re: rsync 3.2.3 to module broken with read-only system error

2022-10-27 Thread Lukas Märdian

Hello, thanks for your report and for providing a work around right
away!

Could you please paste the exact error message when executing your
"rsync -rptoglav /tmp/test/ ::test" command? And also please paste
the output of "ls -la /etc/letsencrypt"

Thanks.

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

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

Title:
  rsync 3.2.3 to module broken with read-only system error

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  There is a issue rsyncing to a rsync module with the error: failed:
  Read-only file system (30)

  Both server are ubuntu 22.04.1 with rsync version 3.2.3-8ubuntu3

  I tried with no success "use chroot" different value options

  Permissions are OK in the end side

  Installing manually rsync package version 3.1.3-8ubuntu0.4 from ubuntu
  20 in the end side server solves the issue (without any configuration
  changes)

  Also, a workaround (both same version of rsync), is to use the following 
parameters in rsync: -e ssh
  however, this might not work for automated cron scripts.

  1) Start side server command:

  rsync -rptoglav /tmp/test/ ::test

  2) End side server configuration of rsyncd.conf:

  ===
  [test]
   path = /etc/letsencrypt
   read only = false
   uid = root
   gid = root
  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1994810/+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 1993869] Re: openssh-server cannot listen or bind to anything other than :::22 after upgrading to 22.10 from 22.04

2022-10-27 Thread Lukas Märdian

Thanks for your confirmation, closing.

** Summary changed:

- openssh-server cannot listen or bind to anything other than :::2 after 
upgrading to 22.10 from 22.04
+ openssh-server cannot listen or bind to anything other than :::22 after 
upgrading to 22.10 from 22.04

** Description changed:

  This is a bug report to separate the second issue that was reported in this 
bug report:
  https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1993478
  
  There's an issue after upgrading to 22.10 from 22.04 that prevents
- opensshd from listening to anything other than :::2. I already commented
- in the bug report I linked, so I'll just copy/paste and add some
- details. I guess.
+ opensshd from listening to anything other than :::22. I already
+ commented in the bug report I linked, so I'll just copy/paste and add
+ some details. I guess.
  
  The issue is that after upgrading, sshd doesn't use the Listen port or
  ListenAddress config from the sshd_config file or any custom config file
  that was in the sshd_config.d drop in folder anymore.
  
  Other drop in settings from sshd.config.d seem to be applied normally,
  the issue seem to be only for IP binding and custom ports.
  
  If I change Accept=no by Accept=yes in ssh.socket and reloads the socket
  unit, I can start sshd on a different port and I can also bind the IP to
  something else than ::
  
  There's an issue still, an instance of sshd is still listening to :::22
  that is not started by SSHD but by init.
  
  root@ubuntulocal:~# netstat -antp
  Active Internet connections (servers and established)
  Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
  tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 568/vsftpd
  tcp 0 0 0.0.0.0:622 0.0.0.0:* LISTEN 571/sshd: /usr/sbin
  tcp 0 272 192.168.1.225:622 192.168.1.220:2473 ESTABLISHED 1027/sshd: root@pts
  tcp6 0 0 :::22 :::* LISTEN 1/init
  
  If I reboot after changing this no to yes in ssh.socket does not survive a 
reboot and fails to load sshd with a "Failed to queue service startup job" 
error.
  Oct 21 15:41:56 ubuntulocal systemd[1]: ssh.socket: Failed to queue service 
startup job (Maybe the service file is missing or not a template unit?): 
Invalid argument
  Oct 21 15:41:56 ubuntulocal systemd[1]: ssh.socket: Failed with result 
'resources'.
  
  I had to mask/stop the sshd.socket unit and create a custom sshd service
  in /etc/systemd/system to be able start sshd on a custom port and IP.
  
- 
  chris@ubuntulocal:~$ systemctl status ssh.socket
  ● ssh.socket - OpenBSD Secure Shell server socket
-  Loaded: loaded (/lib/systemd/system/ssh.socket; enabled; preset: enabled)
-  Active: active (running) since Fri 2022-10-21 23:08:09 UTC; 1min 24s ago
-   Until: Fri 2022-10-21 23:08:09 UTC; 1min 24s ago
-Triggers: ● ssh.service
-  Listen: [::]:22 (Stream)
-   Tasks: 0 (limit: 18899)
-  Memory: 4.0K
- CPU: 418us
-  CGroup: /system.slice/ssh.socket
+  Loaded: loaded (/lib/systemd/system/ssh.socket; enabled; preset: enabled)
+  Active: active (running) since Fri 2022-10-21 23:08:09 UTC; 1min 24s ago
+   Until: Fri 2022-10-21 23:08:09 UTC; 1min 24s ago
+    Triggers: ● ssh.service
+  Listen: [::]:22 (Stream)
+   Tasks: 0 (limit: 18899)
+  Memory: 4.0K
+ CPU: 418us
+  CGroup: /system.slice/ssh.socket

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

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

Title:
  openssh-server cannot listen or bind to anything other than :::22
  after upgrading to 22.10 from 22.04

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  This is a bug report to separate the second issue that was reported in this 
bug report:
  https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1993478

  There's an issue after upgrading to 22.10 from 22.04 that prevents
  opensshd from listening to anything other than :::22. I already
  commented in the bug report I linked, so I'll just copy/paste and add
  some details. I guess.

  The issue is that after upgrading, sshd doesn't use the Listen port or
  ListenAddress config from the sshd_config file or any custom config
  file that was in the sshd_config.d drop in folder anymore.

  Other drop in settings from sshd.config.d seem to be applied normally,
  the issue seem to be only for IP binding and custom ports.

  If I change Accept=no by Accept=yes in ssh.socket and reloads the
  socket unit, I can start sshd on a different port and I can also bind
  the IP to something else than ::

  There's an issue still, an instance of sshd is still listening to
  :::22 that is not started by SSHD but by init.

  root@ubuntulocal:~# netstat -antp
  Active Internet connections (servers and established)
  Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
  tcp 0 0 0.0.0.0:21

[Touch-packages] [Bug 1774632] Re: The symbolic link /etc/resolv.conf points to the wrong file by default

2022-10-27 Thread Lukas Märdian

Ubuntu uses the local systemd-resolved DNS resolver by default.

/etc/resolv.conf being a symlink pointing to /run/systemd/resolve/stub-
resolv.conf is the correct default setting. It will redirect any DNS
request to sd-resolved's local resolver at 127.0.0.53.

This has the benefit of local caching and per-interface DNS configuration via 
sd-resolved.
Switching the symlink to /etc/resolv.conf -> /run/systemd/resolve/resolv.conf 
would make sd-resolved display the upstream DNS servers directly into the file, 
kind of a legacy/compatibility mode, loosing all the benefits of a local 
resolver. This is NOT recommended.

You can manually configure your DNS settings via netplan.io or sd-
resolved directly, as stated in comment #13. NetworkManager should
automatically detect sd-resolved and integrate nicely, some other
(legacy) tools might not integrate as nicely.

If DNS is not working for you, you can configure a fallback, e.g. Google
DNS:

$ cat /etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=8.8.8.8 2001:4860:4860::

I'm marking this bug as "Invalid". Please keep your symlink as
/etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

** Changed in: systemd (Ubuntu)
   Status: Confirmed => 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/1774632

Title:
  The symbolic link /etc/resolv.conf points to the wrong file by default

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  When using nslookup for local machine names, the local DNS was being
  ignored (not queried) and none of the local machines could be found.

  After much research and digging, it was discovered that the cause was
  the incorrect symbolic link /etc/resolv.conf file.

  The default install caused systemd-resolve to configure the link to point to 
the stub file:
  /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

  Reomving that link and pointing it to the correct file solved the DNS lookup 
issue. The correct link looks like this:
  /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

  
  Steps used to test the bug before fixing the link is to perform an nslookup 
on a local (non FQDN) machine that is in your local DNS (my router is my DNS 
server for this case) Here is an example of the incorrect output:

  $ nslookup web1

  Server: 127.0.0.53
  Address:127.0.0.53#53

  ** server can't find web1: SERVFAIL

  
  Switching the symbolic link solves the problem. Here is my solution:

  $ sudo rm -f /etc/resolv.conf
  $ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

  
  After switching the symbolic link, the nslookup functions properly.

  $ nslookup web1

  Server: 192.168.1.1
  Address:192.168.1.1#53

  Name:   web1
  Address: 192.168.1.107

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10
  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
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jun  1 05:28:41 2018
  InstallationDate: Installed on 2018-01-20 (131 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
  MachineType: Dell Inc. Inspiron 5755
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-22-generic 
root=UUID=7fe151d3-4033-4903-b356-341d9f16e124 ro acpi=force
  SourcePackage: systemd
  UpgradeStatus: Upgraded to bionic on 2018-04-28 (33 days ago)
  dmi.bios.date: 08/27/2015
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A08
  dmi.board.name: 0VY15F
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A08
  dmi.modalias: 
dmi:bvnDellInc.:bvrA08:bd08/27/2015:svnDellInc.:pnInspiron5755:pvrA08:rvnDellInc.:rn0VY15F:rvrA00:cvnDellInc.:ct8:cvrA08:
  dmi.product.name: Inspiron 5755
  dmi.product.version: A08
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1774632/+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 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface

2022-10-27 Thread Cyrus Lien

** Bug watch added: Debian Bug tracker #1003352
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003352

** Also affects: initramfs-tools (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003352
   Importance: Unknown
   Status: Unknown

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

Title:
  initramfs need to mount efivarfs because kernel 6.0 deprecated
  'efivars' sysfs interface

Status in OEM Priority Project:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New
Status in initramfs-tools package in Debian:
  Unknown

Bug description:
  [ Impact ]

  kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC
  RAID, mdadm needs initramfs to mount efivarfs instead.

  [1] The commit:
  commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741
  Author: Ard Biesheuvel 
  Date: Mon Jun 20 13:34:03 2022 +0200

  efi: vars: Remove deprecated 'efivars' sysfs interface

  [ Test Plan ]

  1. Install initramfs-tools
  2. update-initramfs -u
  3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs
  4. Check if boot script 00_mount_efivarfs exists in directory 
/tmp/extract-initramfs/main/scripts/init-top/
  5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot 
script 00_mount_efivarfs will be execute before udev.

  [ Where problems could occur ]

  Not sure if there any other tools/utilities also need to mount efivarfs as 
early as mdadm but the probability of file conflict should be very low.
  Also, there are no impact mounting efivarfs multiple times.
  mount: /sys/firmware/efi/efivars: efivarfs already mounted on 
/sys/firmware/efi/efivars.

  [ Scope ]

  Jammy, Kinetic

  [ Other Info ]

  The private bug link
  https://bugs.launchpad.net/somerville/+bug/1990231

  debian MR:
  https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1994936/+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 1994936] [NEW] initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface

2022-10-27 Thread Cyrus Lien

Public bug reported:

[ Impact ]

kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC RAID,
mdadm needs initramfs to mount efivarfs instead.

[1] The commit:
commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741
Author: Ard Biesheuvel 
Date: Mon Jun 20 13:34:03 2022 +0200

efi: vars: Remove deprecated 'efivars' sysfs interface

[ Test Plan ]

1. Install initramfs-tools
2. update-initramfs -u
3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs
4. Check if boot script 00_mount_efivarfs exists in directory 
/tmp/extract-initramfs/main/scripts/init-top/
5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot script 
00_mount_efivarfs will be execute before udev.

[ Where problems could occur ]

Not sure if there any other tools/utilities also need to mount efivarfs as 
early as mdadm but the probability of file conflict should be very low.
Also, there are no impact mounting efivarfs multiple times.
mount: /sys/firmware/efi/efivars: efivarfs already mounted on 
/sys/firmware/efi/efivars.

[ Scope ]

Jammy, Kinetic

[ Other Info ]

The private bug link https://bugs.launchpad.net/somerville/+bug/1990231

debian MR:
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66

** Affects: oem-priority
 Importance: Critical
 Assignee: Cyrus Lien (cyruslien)
 Status: Confirmed

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

** Affects: initramfs-tools (Debian)
 Importance: Unknown
 Status: Unknown


** Tags: oem-priority

** Also affects: oem-priority
   Importance: Undecided
   Status: New

** Changed in: oem-priority
   Status: New => Confirmed

** Changed in: oem-priority
   Importance: Undecided => Critical

** Changed in: oem-priority
 Assignee: (unassigned) => Cyrus Lien (cyruslien)

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

Title:
  initramfs need to mount efivarfs because kernel 6.0 deprecated
  'efivars' sysfs interface

Status in OEM Priority Project:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  New
Status in initramfs-tools package in Debian:
  Unknown

Bug description:
  [ Impact ]

  kernel 6.0 deprecated efivars sysfs interface [1]. For Intel VROC
  RAID, mdadm needs initramfs to mount efivarfs instead.

  [1] The commit:
  commit 0f5b2c69a4cbe4166ca24b76d5ada98ed2867741
  Author: Ard Biesheuvel 
  Date: Mon Jun 20 13:34:03 2022 +0200

  efi: vars: Remove deprecated 'efivars' sysfs interface

  [ Test Plan ]

  1. Install initramfs-tools
  2. update-initramfs -u
  3. unmkinitramfs initrd.img-`uname -r` /tmp/extract-initramfs
  4. Check if boot script 00_mount_efivarfs exists in directory 
/tmp/extract-initramfs/main/scripts/init-top/
  5. Check /tmp/extract-initramfs/main/scripts/init-top/ORDER if the boot 
script 00_mount_efivarfs will be execute before udev.

  [ Where problems could occur ]

  Not sure if there any other tools/utilities also need to mount efivarfs as 
early as mdadm but the probability of file conflict should be very low.
  Also, there are no impact mounting efivarfs multiple times.
  mount: /sys/firmware/efi/efivars: efivarfs already mounted on 
/sys/firmware/efi/efivars.

  [ Scope ]

  Jammy, Kinetic

  [ Other Info ]

  The private bug link
  https://bugs.launchpad.net/somerville/+bug/1990231

  debian MR:
  https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1994936/+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 1981385] Re: initrd lacks modules to mount boot image from http boot

[Touch-packages] [Bug 1995015] Re: Logitech Brio LED doesn't light up with 22.10

[Touch-packages] [Bug 1977499] Re: BUG IN UBUNTU 22.10 KINETIC KUDU: Audio Does Not Work Properly And Video Playback Is Very Laggy

[Touch-packages] [Bug 1995015] [NEW] Logitech Brio LED doesn't light up with 22.10

[Touch-packages] [Bug 1981385] Re: initrd lacks modules to mount boot image from http boot

[Touch-packages] [Bug 1988796] Re: Incorrect rendering triggered by cairo CAIRO_OPERATOR_SATURATE with subpixel positioning

[Touch-packages] [Bug 1993572] Re: samba profile: missing rule for mkdir /var/cache/samba/printing

[Touch-packages] [Bug 1981385] Re: initrd lacks modules to mount boot image from http boot

[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface

[Touch-packages] [Bug 1993867] Re: Telegram sometimes start endless use 100% CPU

[Touch-packages] [Bug 1993478] Re: package openssh-server 1:9.0p1-1ubuntu7 failed to install/upgrade: postinstall script returned 1

[Touch-packages] [Bug 1993867] Re: Telegram sometimes start endless use 100% CPU

[Touch-packages] [Bug 1994146] Re: [SRU] apparmor - Focal, Jammy

[Touch-packages] [Bug 1994146] Re: [SRU] apparmor - Focal, Jammy

[Touch-packages] [Bug 1994146] Re: [SRU] apparmor - Focal, Jammy

[Touch-packages] [Bug 1994146] Re: [SRU] apparmor - Focal, Jammy

[Touch-packages] [Bug 1993572] Re: samba profile: missing rule for mkdir /var/cache/samba/printing

[Touch-packages] [Bug 1994067] Re: "Windows 11 Pro" and "Ubuntu 22.04.1 LTS" are installed and up to date on the laptop. There is no hardware problem with the laptop. No sound from operating system "U

[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu

[Touch-packages] [Bug 1994697] Re: 1440x900 (3:2) resolution mismatch

[Touch-packages] [Bug 1994810] Re: rsync 3.2.3 to module broken with read-only system error

[Touch-packages] [Bug 1993869] Re: openssh-server cannot listen or bind to anything other than :::22 after upgrading to 22.10 from 22.04

[Touch-packages] [Bug 1774632] Re: The symbolic link /etc/resolv.conf points to the wrong file by default

[Touch-packages] [Bug 1994936] Re: initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface

[Touch-packages] [Bug 1994936] [NEW] initramfs need to mount efivarfs because kernel 6.0 deprecated 'efivars' sysfs interface

25 matches

Site Navigation

Mail list logo

Footer information