[Touch-packages] [Bug 1833322] Re: Please consider no more having irqbalance enabled by default (per image/use-case/TBD)

2024-02-19 Thread John Chittum
Proxying a few comments I've heard from cloud partners about uses:

There are some big companies, particularly in the streaming media and
encoding business heavily using irqbalance. _however_ our consideration
is about irqbalance enabled by default. They do heavy tuning, not
running stock values. For those customers, it'll primarily be about
workflow changes. install a package, run an extra line enabling
irqbalance, etc. I, personally, don't see that as a blocker for making
the change in 24.04. Those types of companies won't take bleeding edge,
and will likely be going through a testing and upgrade effort that takes
months, not auto-rolling to "ubuntu:latest." Least, i sure hope not :)

I'll take some followups again with partners to see if any individuals
can comment on the public bug.

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

Title:
  Please consider no more having irqbalance enabled by default (per
  image/use-case/TBD)

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in irqbalance package in Ubuntu:
  Confirmed
Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  as per https://github.com/pop-os/default-settings/issues/60

  Distribution (run cat /etc/os-release):

  $ cat /etc/os-release
  NAME="Pop!_OS"
  VERSION="19.04"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Pop!_OS 19.04"
  VERSION_ID="19.04"
  HOME_URL="https://system76.com/pop;
  SUPPORT_URL="http://support.system76.com;
  BUG_REPORT_URL="https://github.com/pop-os/pop/issues;
  PRIVACY_POLICY_URL="https://system76.com/privacy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  Related Application and/or Package Version (run apt policy $PACKAGE
  NAME):

  $ apt policy irqbalance
  irqbalance:
  Installed: 1.5.0-3ubuntu1
  Candidate: 1.5.0-3ubuntu1
  Version table:
  *** 1.5.0-3ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages
  100 /var/lib/dpkg/status

  $ apt rdepends irqbalance
  irqbalance
  Reverse Depends:
  Recommends: ubuntu-standard
  gce-compute-image-packages

  Issue/Bug Description:

  as per konkor/cpufreq#48 and
  http://konkor.github.io/cpufreq/faq/#irqbalance-detected

  irqbalance is technically not needed on desktop systems (supposedly it
  is mainly for servers), and may actually reduce performance and power
  savings. It appears to provide benefits only to server environments
  that have relatively-constant loading. If it is truly a server-
  oriented package, then it shouldn't be installed by default on a
  desktop/laptop system and shouldn't be included in desktop OS images.

  Steps to reproduce (if you know):

  This is potentially an issue with all default installs.

  Expected behavior:

  n/a

  Other Notes:

  I can safely remove it via "sudo apt purge irqbalance" without any
  apparent adverse side-effects. If someone is running a situation where
  they need it, then they always have the option of installing it from
  the repositories.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+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 2051572] Re: Always preseed core and snapd snap in server seed

2024-02-16 Thread John Chittum
Based on the data, I'm in the "No" camp as well.

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

Title:
  Always preseed core and snapd snap in server seed

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

Bug description:
  In removing the LXD snap from preseeding in the server seed for Ubuntu
  24.04 as part LP #2051346 [1] we also removed the snapd snap and the
  core22 snap.

  This means that are subsequent snap install, like LXD, will take much
  longer than expected for a non minimized image.

  Time taken to install LXD snap using the lxd-installer package without
  snapd and core22 preinstalled/seeded

  ```
  ubuntu@cloudimg:~$ time sudo lxd --version
  Installing LXD snap, please be patient.
  5.19

  real  0m29.107s
  user  0m0.006s
  sys   0m0.005s
  ```

  Time taken to install LXD snap using the lxd-installer package with
  snapd and core22 already installed.

  ```
  ubuntu@cloudimg:~$ time sudo lxd --version
  Installing LXD snap, please be patient.
  5.19

  real  0m15.034s
  user  0m0.005s
  sys   0m0.005s
  ```

  This is a significant difference and for a workload we intend to
  remain as a core tested and tracked workload. As such I propose we re-
  introduce core22 and snapd snaps to our seed.

  LXD do intend to move to the core24 snap as their base as I'm sure
  snapd does too so when that does happen we need to update the
  preseeded core snap.

  This bug is to track the work of making that change in the server seed
  @ https://git.launchpad.net/~ubuntu-core-dev/ubuntu-
  seeds/+git/ubuntu/tree/server#n69

  [1] https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2051346

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2051572/+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 2051572] Re: Always preseed core and snapd snap in server seed

2024-02-15 Thread John Chittum
I agree with vorlon in general. It is a bit odd to not be seeding snapd
by default, since snaps are a recognized package format. preseeding
snapd will bring in its base, but there's no guarantee that base will
match any other snaps.

Flip side is that somewhere back in history, it was decided that in a
system without any other snaps preseeded, that having the snapd deb,
which exists to bootstrap itself into a snapd snap, was the right
choice. so let's narrow the cases we know of:

* pre-installed systems with no other snaps pre-seeded

That limits itself, right now, to cloud-images "downloads" (the qcow,
ova, etc). Right now the cloud team sees a fairly long time in running
`lxd` commands, as we specifically have a mandate to ensure `lxd` is
operating well on our cloud-images.

what we don't know right now

* boot time differences with adding the snaps back in (from old reading it 
looks anywhere from 3-5s, which is a nice little gain)
* the amount of time/slow down for `lxd` booting from `lxd-installer` in a "no 
snaps pre-seeded" setting
* the _usage_ and _expectation_ about the speed here. We definitely support 
running lxd on cloud-images. and we know it is a use case. but we don't know if 
this is a "many users" or "a couple users," and we don't know their 
expectations regarding speed. We may be able to roll out with good 
documentation letting everyone know what the change is, what to expect, etc. 

The more info we can gather on our side for time cost the better.
getting some data comparisons across the following would be good:

* boot times w/ and w/o preseeded snaps
* lxd launch time with no preseeded, snapd + it's core snap preseeded, and 
"other cloud cases that have preseeded snaps" (thinking like ec2 or oracle that 
have snapped cloud agents)

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

Title:
  Always preseed core and snapd snap in server seed

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

Bug description:
  In removing the LXD snap from preseeding in the server seed for Ubuntu
  24.04 as part LP #2051346 [1] we also removed the snapd snap and the
  core22 snap.

  This means that are subsequent snap install, like LXD, will take much
  longer than expected for a non minimized image.

  Time taken to install LXD snap using the lxd-installer package without
  snapd and core22 preinstalled/seeded

  ```
  ubuntu@cloudimg:~$ time sudo lxd --version
  Installing LXD snap, please be patient.
  5.19

  real  0m29.107s
  user  0m0.006s
  sys   0m0.005s
  ```

  Time taken to install LXD snap using the lxd-installer package with
  snapd and core22 already installed.

  ```
  ubuntu@cloudimg:~$ time sudo lxd --version
  Installing LXD snap, please be patient.
  5.19

  real  0m15.034s
  user  0m0.005s
  sys   0m0.005s
  ```

  This is a significant difference and for a workload we intend to
  remain as a core tested and tracked workload. As such I propose we re-
  introduce core22 and snapd snaps to our seed.

  LXD do intend to move to the core24 snap as their base as I'm sure
  snapd does too so when that does happen we need to update the
  preseeded core snap.

  This bug is to track the work of making that change in the server seed
  @ https://git.launchpad.net/~ubuntu-core-dev/ubuntu-
  seeds/+git/ubuntu/tree/server#n69

  [1] https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2051346

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2051572/+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-10 Thread John Chittum
Marking cloud-images and maas-images as fixed with the roll of util-
linux, and confirmation from fginther

** Changed in: maas-images
   Status: Confirmed => Fix Released

** Changed in: cloud-images
   Status: New => 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/2037417

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

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

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: Mantic 6.5.0-7 kernel causes regression in LXD container usage

2023-10-06 Thread John Chittum
Repeating a bit with a Jammy container (hence new comment)

### PRE CONDITION

this is using the custom Mantic VM _and_ has
apparmor_restrict_unprivileged_unconfined disabled

sudo bash -c "echo 0 >
/proc/sys/kernel/apparmor_restrict_unprivileged_unconfined"

1. start a jammy container

lxc launch ubuntu:jammy
Creating the instance
Instance name is: alive-bee   
Starting alive-bee

2. see some apparmor denies in journal

Oct 06 12:32:57 mantic-cust-vm kernel: audit: type=1400 
audit(1696595577.647:954): apparmor="DENIED" operation="mount" class="mount" 
info="failed flags match" error=-13 
profile="lxd-alive-bee_" 
name="/run/systemd/unit-root/proc/" pid=5421 comm="(d-logind)" fstype="proc" 
srcname="proc" flags="rw, nosuid, nodev, noexec"
Oct 06 12:33:01 mantic-cust-vm kernel: kauditd_printk_skb: 20 callbacks 
suppressed
Oct 06 12:33:01 mantic-cust-vm kernel: audit: type=1400 
audit(1696595581.539:975): apparmor="DENIED" operation="file_inherit" 
class="file" namespace="root//lxd-alive-bee_" 
profile="snap.lxd.hook.install" name="/apparmor/.null" pid=5538 
comm="snap-exec" requested_mask="wr" denied_mask="wr" fsuid=100 ouid=0
Oct 06 12:33:03 mantic-cust-vm kernel: audit: type=1400 
audit(1696595583.771:976): apparmor="DENIED" operation="file_inherit" 
class="net" namespace="root//lxd-alive-bee_" 
profile="/snap/snapd/20092/usr/lib/snapd/snap-confine" pid=5784 
comm="snap-confine" family="netlink" sock_type="raw" protocol=15 
requested_mask="send receive" denied_mask="send receive"
Oct 06 12:33:03 mantic-cust-vm kernel: audit: type=1400 
audit(1696595583.779:977): apparmor="DENIED" operation="file_inherit" 
class="file" namespace="root//lxd-alive-bee_" 
profile="snap.lxd.hook.configure" name="/apparmor/.null" pid=5784 
comm="snap-exec" requested_mask="wr" denied_mask="wr" fsuid=100 ouid=0
Oct 06 12:33:03 mantic-cust-vm kernel: audit: type=1400 
audit(1696595583.791:978): apparmor="DENIED" operation="file_inherit" 
class="file" namespace="root//lxd-alive-bee_" 
profile="/snap/snapd/20092/usr/lib/snapd/snap-confine" name="/apparmor/.null" 
pid=5784 comm="aa-exec" requested_mask="wr" denied_mask="wr" fsuid=100 
ouid=0
Oct 06 12:33:04 mantic-cust-vm kernel: audit: type=1400 
audit(1696595584.007:979): apparmor="DENIED" operation="mount" class="mount" 
info="failed flags match" error=-13 
profile="lxd-alive-bee_" 
name="/run/systemd/unit-root/proc/" pid=5933 comm="(imedated)" fstype="proc" 
srcname="proc" flags="rw, nosuid, nodev, noexec"

3. snap changes is Done

root@alive-bee:~# snap changes
ID   Status  Spawn Ready   Summary
1Done9 days ago, at 02:11 UTC  today at 12:33 UTC  Initialize system 
state
2Donetoday at 12:32 UTCtoday at 12:33 UTC  Initialize device

4. cloud-init is done

root@alive-bee:~# cloud-init status
status: done


So using the latest released jammy container is also now launching 
"successfully." Unsure how the other apparmor things denies affect container 
performance. Running a quick spot check of my machine (Jammy) launching a Jammy 
container

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

[Touch-packages] [Bug 2038567] Re: Mantic 6.5.0-7 kernel causes regression in LXD container usage

2023-10-06 Thread John Chittum
on my machine (specs at the end) running Jammy as the host, and
launching a Jammy container:

1. lxc launch ubuntu:jammy test-jammy-on-jammy

from journal

Oct 06 07:36:47 j5awry-sys76 kernel: audit: type=1400 
audit(1696595807.223:51559): apparmor="DENIED" operation="mount" class="mount" 
info="failed flags match" error=-13 
profile="lxd-test-jammy-on-jammy_" 
name="/run/systemd/unit-root/proc/" pid=723735 comm="(d-logind)" fstype="proc" 
srcname="proc" flags="rw, nosuid, nodev, noexec"
Oct 06 07:36:47 j5awry-sys76 kernel: audit: type=1400 
audit(1696595807.227:51560): apparmor="DENIED" operation="mount" class="mount" 
info="failed flags match" error=-13 
profile="lxd-test-jammy-on-jammy_" 
name="/run/systemd/unit-root/tmp/" pid=723724 comm="(crub_all)" flags="rw, 
nosuid, remount, bind"
Oct 06 07:36:47 j5awry-sys76 kernel: audit: type=1400 
audit(1696595807.239:51561): apparmor="DENIED" operation="mount" class="mount" 
info="failed flags match" error=-13 
profile="lxd-test-jammy-on-jammy_" 
name="/run/systemd/unit-root/proc/" pid=723750 comm="(ostnamed)" fstype="proc" 
srcname="proc" flags="rw, nosuid, nodev, noexec"


so i get the same `mount - failed flags match` that i see above, but not the 
`file-inherit` denies.

-- 
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 --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: Mantic 6.5.0-7 kernel causes regression in LXD container usage

2023-10-06 Thread John Chittum
Did the following:

1. launched a new VM from the custom build

lxc launch mantic-20231005 --vm --device root,size=20GiB mantic-cust-vm

2. pushed squashfs and lxc metadata from same custom build

lxc file push build.output/livecd.ubuntu-cpc.squashfs mantic-cust-vm/root/
lxc file push vm/mantic-server-cloudimg-amd64-lxd.tar.xz mantic-cust-vm/root/

3. initialized lxd

lxd init --auto

3. imported into lxc

lxc image import ./mantic-server-cloudimg-amd64-lxd.tar.xz
./livecd.ubuntu-cpc.squashfs --alias mantic-cust-con

4. launched the container

lxc launch mantic-cust-con m-c-c

5. observed the DENIED ptrace

Oct 06 12:27:01 mantic-cust-vm kernel: audit: type=1400
audit(1696595221.386:113): apparmor="DENIED" operation="ptrace"
class="ptrace" profile="lxd-m-c-c_" pid=2420
comm="systemd" requested_mask="read" denied_mask="read" peer="lxd-m-c-
c_//"

6. deleted the container

lxc stop m-c-c
lxc delete m-c-c

6. disabled apparmor_restrict_unprivileged_unconfined

sudo bash -c "echo 0 >
/proc/sys/kernel/apparmor_restrict_unprivileged_unconfined"

7. launched container

lxc launch mantic-cust-con m-c-c

8. see different apparmor denied messages:

Oct 06 12:29:58 mantic-cust-vm kernel: audit: type=1400 
audit(1696595398.722:905): apparmor="DENIED" operation="mount" class="mount" 
info="failed flags match" error=-13 
profile="lxd-m-c-c_" 
name="/run/systemd/unit-root/proc/" pid=4055 comm="(d-logind)" fstype="proc" 
srcname="proc" flags="rw, nosuid, nodev, noexec"
Oct 06 12:29:58 mantic-cust-vm kernel: audit: type=1400 
audit(1696595398.766:906): apparmor="DENIED" operation="mount" class="mount" 
info="failed flags match" error=-13 
profile="lxd-m-c-c_" 
name="/run/systemd/unit-root/proc/" pid=4048 comm="(polkitd)" fstype="proc" 
srcname="proc" flags="rw, nosuid, nodev, noexec"
Oct 06 12:29:58 mantic-cust-vm kernel: audit: type=1400 
audit(1696595398.818:907): apparmor="DENIED" operation="mount" class="mount" 
info="failed flags match" error=-13 
profile="lxd-m-c-c_" 
name="/run/systemd/unit-root/proc/" pid=4071 comm="(ostnamed)" fstype="proc" 
srcname="proc" flags="rw, nosuid, nodev, noexec"
Oct 06 12:29:58 mantic-cust-vm kernel: audit: type=1400 
audit(1696595398.874:908): apparmor="STATUS" operation="profile_replace" 
info="same as current profile, skipping" 
label="lxd-m-c-c_//&:lxd-m-c-c_:unconfined"
 name="rsyslogd" pid=4062 comm="apparmor_parser"
Oct 06 12:29:59 mantic-cust-vm kernel: audit: type=1400 
audit(1696595399.106:909): apparmor="STATUS" operation="profile_replace" 
info="same as current profile, skipping" 
label="lxd-m-c-c_//&:lxd-m-c-c_:unconfined"
 name="/usr/lib/snapd/snap-confine" pid=4130 comm="apparmor_parser"
Oct 06 12:29:59 mantic-cust-vm kernel: audit: type=1400 
audit(1696595399.106:910): apparmor="STATUS" operation="profile_replace" 
info="same as current profile, skipping" 
label="lxd-m-c-c_//&:lxd-m-c-c_:unconfined"
 name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=4130 
comm="apparmor_parser"
Oct 06 12:29:59 mantic-cust-vm kernel: audit: type=1400 
audit(1696595399.482:911): apparmor="DENIED" operation="file_inherit" 
class="net" namespace="root//lxd-m-c-c_" 
profile="/usr/lib/snapd/snap-confine" pid=4146 comm="snap-confine" 
family="netlink" sock_type="raw" protocol=15 requested_mask="send receive" 
denied_mask="send receive"
Oct 06 12:29:59 mantic-cust-vm kernel: audit: type=1400 
audit(1696595399.498:912): apparmor="DENIED" operation="file_inherit" 
class="file" namespace="root//lxd-m-c-c_" 
profile="snap-update-ns.lxd" name="/apparmor/.null" pid=4157 comm="6" 
requested_mask="wr" denied_mask="wr" fsuid=100 ouid=0
Oct 06 12:29:59 mantic-cust-vm kernel: audit: type=1400 
audit(1696595399.558:913): apparmor="DENIED" operation="file_inherit" 
class="file" namespace="root//lxd-m-c-c_" 
profile="snap.lxd.hook.install" name="/apparmor/.null" pid=4146 
comm="snap-exec" requested_mask="wr" denied_mask="wr" fsuid=100 ouid=0

9. However, these are not affecting the container in the same fashion.
Snap finishes initializing, and cloud-init finishes

root@mantic-cust-vm:~# lxc shell m-c-c
root@m-c-c:~# snap changes
ID   Status  Spawn   Ready   Summary
1Doneyesterday at 21:03 UTC  today at 12:30 UTC  Initialize system state
2Donetoday at 12:29 UTC  today at 12:30 UTC  Initialize device

root@m-c-c:~# cloud-init status
status: done

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

[Touch-packages] [Bug 2038567] Re: Mantic 6.5.0-7 kernel causes regression in LXD container usage

2023-10-05 Thread John Chittum
livecd-rootfs 23.10.55 for mantic is currently migrating, and has
apparmor changes as well (mounting different features in the build
chroot). To help rule out some issues, I built a a qcow2 image and a
squashfs for mantic using livecd-rootfs 23.10.55

Running the mantic host, and launching a released jammy container

# On the mantic host VM
journalctl -f -b -k

Oct 05 21:25:26 novel-ram kernel: kauditd_printk_skb: 220 callbacks suppressed
Oct 05 21:25:26 novel-ram kernel: audit: type=1400 audit(1696541126.968:6178): 
apparmor="DENIED" operation="ptrace" class="ptrace" 
profile="lxd-current-iguana_" pid=11660 
comm="systemd" requested_mask="read" denied_mask="read" 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.036:6179): 
apparmor="DENIED" operation="signal" class="signal" 
profile="lxd-current-iguana_" pid=12656 comm="snapd" 
requested_mask="send" denied_mask="send" signal=urg 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.044:6180): 
apparmor="DENIED" operation="ptrace" class="ptrace" 
profile="lxd-current-iguana_" pid=11722 
comm="systemd-journal" requested_mask="read" denied_mask="read" 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.044:6181): 
apparmor="DENIED" operation="ptrace" class="ptrace" 
profile="lxd-current-iguana_" pid=11722 
comm="systemd-journal" requested_mask="read" denied_mask="read" 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.168:6182): 
apparmor="DENIED" operation="ptrace" class="ptrace" 
profile="lxd-current-iguana_" pid=12699 
comm="systemctl" requested_mask="read" denied_mask="read" 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.228:6183): 
apparmor="DENIED" operation="signal" class="signal" 
profile="lxd-current-iguana_" pid=11660 
comm="systemd" requested_mask="send" denied_mask="send" signal=exists 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.236:6184): 
apparmor="DENIED" operation="ptrace" class="ptrace" 
profile="lxd-current-iguana_" pid=12701 
comm="systemctl" requested_mask="read" denied_mask="read" 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.240:6185): 
apparmor="DENIED" operation="ptrace" class="ptrace" 
profile="lxd-current-iguana_" pid=12702 
comm="systemctl" requested_mask="read" denied_mask="read" 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.244:6186): 
apparmor="DENIED" operation="ptrace" class="ptrace" 
profile="lxd-current-iguana_" pid=12703 
comm="systemctl" requested_mask="read" denied_mask="read" 
peer="lxd-current-iguana_//"
Oct 05 21:25:27 novel-ram kernel: audit: type=1400 audit(1696541127.252:6187): 
apparmor="DENIED" operation="ptrace" class="ptrace" 
profile="lxd-current-iguana_" pid=12704 
comm="systemctl" requested_mask="read" denied_mask="read" 
peer="lxd-current-iguana_//"

within the mantic container:

$ snap changes
ID   Status  Spawn   Ready   Summary
1Error   today at 21:03 UTC  today at 21:14 UTC  Initialize system state
2Donetoday at 21:14 UTC  today at 21:14 UTC  Initialize device
3Error   today at 21:14 UTC  today at 21:14 UTC  Initialize system state
4Error   today at 21:19 UTC  today at 21:19 UTC  Initialize system state
5Error   today at 21:24 UTC  today at 21:30 UTC  Initialize system state

$ snap tasks 5
Status  Spawn   Ready   Summary
Donetoday at 21:24 UTC  today at 21:30 UTC  Ensure prerequisites for 
"snapd" are available
Undone  today at 21:24 UTC  today at 21:30 UTC  Prepare snap 
"/var/lib/snapd/seed/snaps/snapd_20092.snap" (20092)
Error   today at 21:24 UTC  today at 21:24 UTC  Mount snap "snapd" (20092)
Holdtoday at 21:24 UTC  today at 21:24 UTC  Copy snap "snapd" data
Holdtoday at 21:24 UTC  today at 21:24 UTC  Setup snap "snapd" (20092) 
security profiles

...

Mount snap "snapd" (20092)

2023-10-05T21:24:57Z ERROR systemctl command [reload-or-restart 
snap-snapd-20092.mount] failed with exit status 4: Failed to reload-or-restart 
snap-snapd-20092.mount: Transaction for snap-snapd-20092.mount/start is 
destructive (halt.target has 'start' job queued, but 'stop' is included in 
transaction).
See system logs and 'systemctl status snap-snapd-20092.mount' for details.

# on the mantic host
journalctl -f -b -k
Oct 05 21:30:55 novel-ram kernel: kauditd_printk_skb: 184 callbacks suppressed
Oct 05 21:30:55 novel-ram kernel: audit: type=1400 audit(1696541455.545:7246): 
apparmor="DENIED" operation="signal" class="signal" 
profile="lxd-sharing-tick_" pid=14545 comm="snap" 
requested_mask="send" denied_mask="send" signal=urg 
peer="lxd-sharing-tick_//"
Oct 05 21:30:56 novel-ram kernel: audit: type=1400 audit(1696541456.641:7247): 

[Touch-packages] [Bug 1791691] Re: PATH broken in systemd units

2023-03-15 Thread John Chittum
** Changed in: cloud-images
   Status: Confirmed => Fix Released

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

Title:
  PATH broken in systemd units

Status in cloud-images:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Bionic:
  New
Status in snapd source package in Bionic:
  In Progress
Status in initramfs-tools source package in Cosmic:
  New
Status in snapd source package in Cosmic:
  Fix Released

Bug description:
  systemd units have broken PATH in recent cloud images.
  The PATH set for them is
    PATH=:/snap/bin.
  Previously value is
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

  # cat /etc/cloud/build.info
  build_name: server
  serial: 20180906

  Booted in lxc that fails like:
  # lxc launch ubuntu-daily:cosmic c3
  # lxc exec c3 cat /run/cloud-init/result.json
  {
   "v1": {
    "datasource": null,
    "errors": [
     "Unexpected error while running command.\nCommand: ['netplan', 
'generate']\nExit code: -\nReason: [Errno 2] No such file or directory: 
b'netplan': b'netplan'\nStdout: -\nStderr: -",
     "Unexpected error while running command.\nCommand: ['netplan', 
'generate']\nExit code: -\nReason: [Errno 2] No such file or directory: 
b'netplan': b'netplan'\nStdout: -\nStderr: -",
     "('ssh-authkey-fingerprints', KeyError('getpwnam(): name not found: 
ubuntu',))"
    ]
   }
  }

  
  Related bugs:
   * bug 1771382: ds-identify: does not have expected PATH.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1791691/+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 1724623] Re: Update ubuntu cloud info

2022-12-15 Thread John Chittum
> Which component is responsible for generating /etc/cloud/build.info?
livecd-rootfs, during image creation time.

https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/build#n452

it'll have at least 1 value, serial (in the case of an OCI container),
normally 2: serial, build_name

> From my perspective add_cloud_init_data and get_ec2_data should be
shipped by cloud-init, because they access data generated by cloud-init.

I'll leave the cloud-init team to comment, but I actually disagree.
`/run/cloud-init/instance-data.json` is one of several user parseable
files generated by cloud-init. the "native" cloud-init error reporting
would be to, as smoser said (back in 2018) is to do `cloud-init collect-
logs`. That produces a tar file so it can't directly be added to the
`apport` report. I'm not against shipping the cloud-init logs along with
any cloud image based issue being reported. I'd have to dig in a little
to see how `apport` currently creates a bundle, and how easy it'd be to
add the cloud-init bundle as well. But know that we'll be delivering a
_lot_ more information in the apport bug report.

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

Title:
  Update ubuntu cloud info

Status in apport package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  New

Bug description:
  add_cloud_info() in data/general-hooks/ubuntu.py needs an overhaul.

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata.  Thus we have bugs like bug #1722946 that are 
tagged as an 'ec2-images' bug which are clearly on openstack
   - Marking all bugs that have cloud-init but no EC2 metadata source as an 
'uec-images' bug uses a name that no longer has meaning.

  Solution:
   - If cloud-init is present, check for /etc/cloud/build.info to indicate an 
Ubuntu cloud images, tag as 'cloud-images'.  Pull the build_name and serial 
from that file into the bug comments.
   - If cloud-init is present, check for the presence of 
/run/cloud-init/cloud.cfg.  Parse this yaml to determine the datasource type.  
Add the datasource used to the bug comment.

  I have filed bug #1724626 to ask cloud-init development to surface
  more information from ds-identify to help ID the cloud so that we can
  better tag/annotate the bug.  There may also be some info we can get
  to indicate the image ID on more clouds than just AWS.  At a minimum I
  would like to see dsidentify make the EC2 platform it found available
  for consumers in cloud.cfg.  This would allow us to identify AWS EC2
  from look-alike datasources so that we can tag a bug as ec2-images for
  bug really on AWS and add EC2 specific fields to the
  description/attachments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1724623/+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 1724623] Re: Update ubuntu cloud info

2022-12-14 Thread John Chittum
Attached is a possible patch to remedy some of the issues (and a few
other bugs i've seen in the backlog with errors re: EC2 and other
clouds). the gist:

1. change how we check if something is a cloud-image, generally
2. use /etc/cloud/build.info as a check if something is a Canonical cloud image
   2a. if it's rolled by someone else, hard to guarantee things
3. use /run/cloud-init/instance-data.json as a local store of info
   3a. this will run on most supported clouds, and provide more info

I've tried to make some graceful warning prints and error catches, along
the lines of "if it's not there, just move on."


** Patch added: "apport_cloud.patch"
   
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1724623/+attachment/5635644/+files/apport_cloud.patch

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

Title:
  Update ubuntu cloud info

Status in apport package in Ubuntu:
  New

Bug description:
  add_cloud_info() in data/general-hooks/ubuntu.py needs an overhaul.

  Issues:
   - Using the presence of cloud-init to flag an image as a cloud image is 
incorrect now that ubuntu-server includes cloud-init (and ubuntu-core images)
   - Using the presence of EC2 metadata source is incorrect as many non-EC2 
clouds provide EC2 metadata.  Thus we have bugs like bug #1722946 that are 
tagged as an 'ec2-images' bug which are clearly on openstack
   - Marking all bugs that have cloud-init but no EC2 metadata source as an 
'uec-images' bug uses a name that no longer has meaning.

  Solution:
   - If cloud-init is present, check for /etc/cloud/build.info to indicate an 
Ubuntu cloud images, tag as 'cloud-images'.  Pull the build_name and serial 
from that file into the bug comments.
   - If cloud-init is present, check for the presence of 
/run/cloud-init/cloud.cfg.  Parse this yaml to determine the datasource type.  
Add the datasource used to the bug comment.

  I have filed bug #1724626 to ask cloud-init development to surface
  more information from ds-identify to help ID the cloud so that we can
  better tag/annotate the bug.  There may also be some info we can get
  to indicate the image ID on more clouds than just AWS.  At a minimum I
  would like to see dsidentify make the EC2 platform it found available
  for consumers in cloud.cfg.  This would allow us to identify AWS EC2
  from look-alike datasources so that we can tag a bug as ec2-images for
  bug really on AWS and add EC2 specific fields to the
  description/attachments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1724623/+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 1991661] [NEW] systemd mounts /run without noexec

2022-10-04 Thread John Chittum
Public bug reported:

initramfs-tools in Bionic+, when mounting the filesystem, mounts /run
with noexec

Cloud images run without initramfs and rely on systemd for the mounts.
systemd, however, mounts /run without noexec. Snip from mount-setup.c
(either in src/core/mount-setup.c < 248 or src/shared/mount-setup.c in
>= 248 )

```
#if ENABLE_SMACK
{ "tmpfs",   "/run",  "tmpfs",  
"mode=755,smackfsroot=*" TMPFS_LIMITS_RUN, MS_NOSUID|MS_NODEV|MS_STRICTATIME,
  mac_smack_use, MNT_FATAL  },
#endif
{ "tmpfs",   "/run",  "tmpfs",  "mode=755" 
TMPFS_LIMITS_RUN,   MS_NOSUID|MS_NODEV|MS_STRICTATIME,
  NULL,  MNT_FATAL|MNT_IN_CONTAINER },
```

Originally raised in an askubuntu forum: 
https://askubuntu.com/questions/1432383/mounting-run-as-noexec/1433208

CPC hasn't received word from any partners yet, but it does constitute a
possible regression from how the system was mounted in Bionic and Focal
before moving to optimized boots in 2020/2021.

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

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

** Also affects: initramfs-tools (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/1991661

Title:
  systemd mounts /run without noexec

Status in initramfs-tools package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  initramfs-tools in Bionic+, when mounting the filesystem, mounts /run
  with noexec

  Cloud images run without initramfs and rely on systemd for the mounts.
  systemd, however, mounts /run without noexec. Snip from mount-setup.c
  (either in src/core/mount-setup.c < 248 or src/shared/mount-setup.c in
  >= 248 )

  ```
  #if ENABLE_SMACK
  { "tmpfs",   "/run",  "tmpfs",  
"mode=755,smackfsroot=*" TMPFS_LIMITS_RUN, MS_NOSUID|MS_NODEV|MS_STRICTATIME,
mac_smack_use, MNT_FATAL  },
  #endif
  { "tmpfs",   "/run",  "tmpfs",  
"mode=755" TMPFS_LIMITS_RUN,   MS_NOSUID|MS_NODEV|MS_STRICTATIME,
NULL,  MNT_FATAL|MNT_IN_CONTAINER },
  ```

  Originally raised in an askubuntu forum: 
  https://askubuntu.com/questions/1432383/mounting-run-as-noexec/1433208

  CPC hasn't received word from any partners yet, but it does constitute
  a possible regression from how the system was mounted in Bionic and
  Focal before moving to optimized boots in 2020/2021.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1991661/+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 1965180] Re: apt-add-repository requires --login for private repos, breaking automated workflows

2022-03-17 Thread John Chittum
** Tags added: rls-jj-incoming

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

Title:
  apt-add-repository requires --login for private repos, breaking
  automated workflows

Status in software-properties package in Ubuntu:
  New

Bug description:
  On Focal, in an automated environment (such as a launchpad builder), a
  used can do the following workflow:

  curl
  "https://keyserver.ubuntu.com/pks/lookup?op=get=0x${FINGERPRINT};
  --output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc

  apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
  ppa.launchpad.net/${REPO}/ubuntu focal main"

  Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
  Hit:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  Hit:3 http://archive.ubuntu.com/ubuntu focal-backports InRelease
  Hit:4 http://security.ubuntu.com/ubuntu focal-security InRelease
  Get:5 https://private-ppa.launchpad.net/$REPO/ubuntu focal InRelease [24.3 kB]
  Get:6 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main amd64 
Packages [3288 B] 
  Get:7 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main 
Translation-en [1892 B]  

  However, on Jammy, I get the following:

  
  curl "https://keyserver.ubuntu.com/pks/lookup?op=get=0x${FINGERPRINT}; 
--output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc

  apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
  ppa.launchpad.net/${REPO}/ubuntu jammy main"

  Repository: 'deb https://private-ppa.launchpad.net/$REPO/ubuntu jammy main'
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 105, 
in lpppa
  self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
File "/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py", line 
592, in __call__
  response, content = self.root._browser._request(
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line 
429, in _request
  raise error
  lazr.restfulclient.errors.NotFound: HTTP Error 404: Not Found
  Response headers:
  ---
  -content-encoding: gzip
  content-length: 91
  content-type: text/plain;charset=utf-8
  date: Wed, 16 Mar 2022 19:54:16 GMT
  server: gunicorn/19.8.1
  status: 404
  vary: Accept-Encoding
  x-powered-by: Zope (www.zope.org), Python (www.python.org)
  x-request-id: ec4bd7ff-f333-4543-ba91-3b7b063fab0e
  x-vcs-revision: 81acd06336f3c4be8f28a2213f7a64912593402d
  ---
  Response body:
  ---
  b"Object: , 
name: '$REPO'"
  ---

  
  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/usr/bin/apt-add-repository", line 364, in 
  sys.exit(0 if addaptrepo.main() else 1)
File "/usr/bin/apt-add-repository", line 352, in main
  self.prompt_user_shortcut(shortcut)
File "/usr/bin/apt-add-repository", line 140, in prompt_user_shortcut
  if shortcut.description:
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 117, 
in description
  return self.lpppa.description
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 109, 
in lpppa
  raise ShortcutException(msg)
  softwareproperties.shortcuthandler.ShortcutException: ERROR: ppa 
'$REPO/proposed' not found (use --login if private)

  Impish similarly breaks. Digging through changelogs, I see various
  entries in Impish forward, starting with version 0.99.0 where a
  refactor was done.

  using `--login` is not possible in an automated setup (such as a
  builder) as it starts an OAuth dance, which requires human
  interaction. this will break existing automation utilizing apt-add-
  repository for users when migrating to Jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1965180/+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 1965180] [NEW] apt-add-repository requires --login for private repos, breaking automated workflows

2022-03-16 Thread John Chittum
Public bug reported:

On Focal, in an automated environment (such as a launchpad builder), a
used can do the following workflow:

curl
"https://keyserver.ubuntu.com/pks/lookup?op=get=0x${FINGERPRINT};
--output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc

apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
ppa.launchpad.net/${REPO}/ubuntu focal main"

Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu focal-backports InRelease
Hit:4 http://security.ubuntu.com/ubuntu focal-security InRelease
Get:5 https://private-ppa.launchpad.net/$REPO/ubuntu focal InRelease [24.3 kB]
Get:6 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main amd64 Packages 
[3288 B] 
Get:7 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main Translation-en 
[1892 B]  

However, on Jammy, I get the following:


curl "https://keyserver.ubuntu.com/pks/lookup?op=get=0x${FINGERPRINT}; 
--output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc

apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
ppa.launchpad.net/${REPO}/ubuntu jammy main"

Repository: 'deb https://private-ppa.launchpad.net/$REPO/ubuntu jammy main'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 105, in 
lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
  File "/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py", line 
592, in __call__
response, content = self.root._browser._request(
  File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line 
429, in _request
raise error
lazr.restfulclient.errors.NotFound: HTTP Error 404: Not Found
Response headers:
---
-content-encoding: gzip
content-length: 91
content-type: text/plain;charset=utf-8
date: Wed, 16 Mar 2022 19:54:16 GMT
server: gunicorn/19.8.1
status: 404
vary: Accept-Encoding
x-powered-by: Zope (www.zope.org), Python (www.python.org)
x-request-id: ec4bd7ff-f333-4543-ba91-3b7b063fab0e
x-vcs-revision: 81acd06336f3c4be8f28a2213f7a64912593402d
---
Response body:
---
b"Object: , 
name: '$REPO'"
---


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/apt-add-repository", line 364, in 
sys.exit(0 if addaptrepo.main() else 1)
  File "/usr/bin/apt-add-repository", line 352, in main
self.prompt_user_shortcut(shortcut)
  File "/usr/bin/apt-add-repository", line 140, in prompt_user_shortcut
if shortcut.description:
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 117, in 
description
return self.lpppa.description
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 109, in 
lpppa
raise ShortcutException(msg)
softwareproperties.shortcuthandler.ShortcutException: ERROR: ppa 
'$REPO/proposed' not found (use --login if private)

Impish similarly breaks. Digging through changelogs, I see various
entries in Impish forward, starting with version 0.99.0 where a refactor
was done.

using `--login` is not possible in an automated setup (such as a
builder) as it starts an OAuth dance, which requires human interaction.
this will break existing automation utilizing apt-add-repository for
users when migrating to Jammy

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

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

Title:
  apt-add-repository requires --login for private repos, breaking
  automated workflows

Status in software-properties package in Ubuntu:
  New

Bug description:
  On Focal, in an automated environment (such as a launchpad builder), a
  used can do the following workflow:

  curl
  "https://keyserver.ubuntu.com/pks/lookup?op=get=0x${FINGERPRINT};
  --output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc

  apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
  ppa.launchpad.net/${REPO}/ubuntu focal main"

  Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
  Hit:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  Hit:3 http://archive.ubuntu.com/ubuntu focal-backports InRelease
  Hit:4 http://security.ubuntu.com/ubuntu focal-security InRelease
  Get:5 https://private-ppa.launchpad.net/$REPO/ubuntu focal InRelease [24.3 kB]
  Get:6 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main amd64 
Packages [3288 B] 
  Get:7 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main 
Translation-en [1892 B]  

  However, on Jammy, I get the following:

  
  curl "https://keyserver.ubuntu.com/pks/lookup?op=get=0x${FINGERPRINT}; 
--output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc

  apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
  

[Touch-packages] [Bug 1871268] Re: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected

2021-01-24 Thread John Chittum
reinstall attempted today. CD image downloaded on 20210124 and USB
created via Rufus on Windows. Attempted install, indicated Install
Third-Party Drivers. Crashed at the very end, after updating packages.
hardware is a System 76 Gazelle (2019).

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

Title:
  Installation fails due to useless immediate configuration error when
  "Install Third-Party Drivers" is selected

Status in Ubuntu CD Images:
  Fix Released
Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Bionic:
  In Progress
Status in apt source package in Focal:
  Fix Released
Status in apt source package in Groovy:
  Fix Released
Status in apt package in Debian:
  Unknown

Bug description:
  [Impact]
  Installations that really succeeded would then fail because APT could not 
immediately configure a package. Which is a pointless way to fail at that 
point, because everything did work out anyway.

  We have two changes that help address this:

  * The first one stops immediately configuring multi-arch siblings
  (e.g. libc6:i386 when it's configuring libc6:amd64). This was not
  necessary, and caused all the libc6:i386 failures here.

  * The second change sort of also supersedes the first one: It just
  ignores any errors from immediate configuration, relying on the fact
  that it's checked and rectified at a later point if there are
  unconfigured packages (which is what made all those failures happen
  spuriously after having successfully installed everything).

  [Test case]
  We have one test case in EIPP format in the Debian bug 973305 which was only 
helped by the second change, not the first one. Run /usr/lib/apt/planners < 
eipp.log and check there are no errors.

  TODO: It's unclear if the APT from proposed installed in the live
  session will fix the installer, needs investigation, but would make a
  useful test case.

  [Regression potential]
  It's imaginable that we missed something somewhere and some path that checked 
for a set error doesn't check it anymore, and we report success when we hit an 
error, but it seems unlikely.

  Behavior of --simulate changes. This used to fail before as well, and
  will now only produce a warning. We don't believe that is a reason of
  concern.

  [Groovy SRU]
  The groovy SRU is a sync of the 2.1.11 micro release from Debian unstable 
which also incorporates changes to the documentation: A typo fix, replacing 
focal with groovy in examples, and minor Dutch manual pages translation updates.

  We do not have test cases for the documentation changes, and we do not
  consider there to be a huge regression potential. As long as they
  build, they should be readable - maybe some words are wrong in the
  translation, who knows.

  [Original bug report]
  Test Case
  1. Install Ubuntu Desktop on hardware with an nVidia card and select to 
install 3rd party drivers
  2. Proceed with installation

  The following error message is displayed in /var/log/syslog
  /plugininstall.py: Verifying downloads ...
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/g/gcc-defaults/gcc_9.3.0-1ubuntu2_amd64.deb: "Version: 
'9.3.0-1ubuntu2' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/libx/libxcrypt/libcrypt-dev_4.4.10-10ubuntu4_amd64.deb: 
"Version: '4.4.10-10ubuntu4' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/g/gcc-defaults/g++_9.3.0-1ubuntu2_amd64.deb: "Version: 
'9.3.0-1ubuntu2' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/z/zlib/zlib1g_1.2.11.dfsg-2ubuntu1_i386.deb: "Version: 
'1.2.11.dfsg-2ubuntu1' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/libx/libxau/libxau6_1.0.9-0ubuntu1_i386.deb: "Version: 
'1.0.9-0ubuntu1' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/libx/libxdmcp/libxdmcp6_1.1.3-0ubuntu1_i386.deb: "Version: 
'1.1.3-0ubuntu1' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/libx/libx11/libx11-6_1.6.9-2ubuntu1_i386.deb: "Version: 
'1.6.9-2ubuntu1' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/libx/libxext/libxext6_1.3.4-0ubuntu1_i386.deb: "Version: 
'1.3.4-0ubuntu1' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/l/lm-sensors/libsensors5_3.6.0-2ubuntu1_i386.deb: "Version: 
'3.6.0-2ubuntu1' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/libx/libx11/libx11-xcb1_1.6.9-2ubuntu1_i386.deb: "Version: 
'1.6.9-2ubuntu1' not found."
  /plugininstall.py: Failed to find package object for 
/cdrom//pool/main/libx/libxdamage/libxdamage1_1.1.5-1_i386.deb: "Version: 
'1.1.5-1' not found."
  /plugininstall.py: Failed to find package object for