[Touch-packages] [Bug 1848587] Re: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2
it must be released in bionic-updates. bionic-proposed is insufficient. this follows the previous SRUs that fixed adt only, which were awaiting on "an end-user visible sru to come in the future" which never has. autopkgtest infrastructure has no ability to always test against proposed pocket, a given package, because it's test is regressed in updates. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1848587 Title: lxc 3.0.4-0ubuntu1 ADT test failure with linux 5.4.0-1.2 Status in lxc package in Ubuntu: Fix Released Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/amd64/l/lxc/20191016_150939_0f81d@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/arm64/l/lxc/20191016_152027_0f81d@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/l/lxc/20191016_150251_0f81d@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/l/lxc/20191016_150201_0f81d@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1848587/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1302192] Re: capabilities not preserved on installation
I thought as part of this work we agreed to always unpack tar with xattrs, but i'm not sure how to check if this was done or in place. will investigate. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1302192 Title: capabilities not preserved on installation Status in attr package in Ubuntu: Fix Released Status in iputils package in Ubuntu: Confirmed Status in live-installer package in Ubuntu: Fix Released Status in livecd-rootfs package in Ubuntu: Fix Released Status in ubiquity package in Ubuntu: Fix Released Status in attr source package in Trusty: Fix Released Status in iputils source package in Trusty: Confirmed Status in live-installer source package in Trusty: Fix Released Status in ubiquity source package in Trusty: Fix Released Status in livecd-rootfs source package in Bionic: Fix Released Bug description: Ping is not longer setuid root and I have to ping as root: [~]$ ping kubuntu.org ping: icmp open socket: Operation not permitted [~]$ sudo ping kubuntu.org PING kubuntu.org (91.189.94.156) 56(84) bytes of data. 64 bytes from vostok.canonical.com (91.189.94.156): icmp_seq=1 ttl=51 time=52.2 ms --- kubuntu.org ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 52.231/52.231/52.231/0.000 ms [~]$ Related bugs: bug 1313550: ping does not work as a normal user on trusty tarball cloud images. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/attr/+bug/1302192/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2019435] Re: Default initramfs is missing qcom_geni_serial module
it does feel too many that it should be included by default, not sure why the rest of the tty/serial drivers are not included, or how come this one is not scoped under usb/hid, it is fairly small, and built on arm64 only i think, thus it is useful to include by default - as at best it is unlikely to impact initrd sizes much, and expanding support of generic kernels on arm64 is very much in scope for Ubuntu. ** Project changed: initramfs-tools => initramfs-tools (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2019435 Title: Default initramfs is missing qcom_geni_serial module Status in initramfs-tools package in Ubuntu: New Bug description: Running Ubuntu 22.04 with the HWE kernel (5.19.0-38-generic #39~22.04.1-Ubuntu) on a Qualcomm RB5 derived product - https://developer.qualcomm.com/qualcomm-robotics-rb5-kit The platform has a USB to serial port that can be used as the Linux console. However, this requires the qcom_geni_serial driver to operate. That driver is available as a built module already, but only on the rootfs. It is not included in the initramfs by default. The problem with this is that the console is activated quite late in boot, which reduces it's usefulness in debugging kernel/boot issues. Also, when it finally does come up, the console cannot operate as a login interface (no login prompt is provided) because the interface is initialized after systemd is operational. I can manually add the module to the initramfs by adding "qcom_geni_serial" to /etc/initramfs-tools/modules and running update- initramfs, however this is quite inconvenient. It requires me to remove the storage from the platform, and modify it on another system. Given that the default initramfs already contains a large number of serial drivers, it feels like qcom_geni_serial should be included by default which would give an optimal "out of the box" experience on a number of Qualcomm based platforms. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2019435/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2017926] [NEW] Unused content snaps not autoremoved
Public bug reported: $ snap connections --all | grep gnome content - gnome-3-28-1804:gnome-3-28-1804 - content - gnome-3-34-1804:gnome-3-34-1804 - content[gnome-3-38-2004] chromium:gnome-3-38-2004 gnome-3-38-2004:gnome-3-38-2004 - content[gnome-3-38-2004] firefox:gnome-3-38-2004 gnome-3-38-2004:gnome-3-38-2004 - content[gnome-42-2204]mattermost-desktop:gnome-42-2204 gnome-42-2204:gnome-42-2204 - content[gnome-42-2204]snap-store:gnome-42-2204 gnome-42-2204:gnome-42-2204 - content[gnome-42-2204]snapd-desktop-integration:gnome-42-2204 gnome-42-2204:gnome-42-2204 - my system has 4 gnome-* content snaps, that were pulled in as dependencies. The apps that used them, have moved on to newer versions. Something on my system must clean then up for me, for example apt autoremoves automatically installed packages & obsolete kernels, and so should also happen with snaps. It can be done by snapd itself, or by something else on the classic desktop - i.e. update-manager. Note it is easy to detect such snaps, as it provides no apps; has content interface only; which is not plugged by anything. If it is ever needed by any future or past revision of any other snap it would be autoinstalled back. On my system they take up 824M of disk space (2 revisions, of 2 unused content snaps = 4 snaps) ** Affects: snapd (Ubuntu) Importance: Undecided Status: New ** Affects: ubuntu-meta (Ubuntu) Importance: Undecided Status: New ** Affects: update-notifier (Ubuntu) Importance: Undecided Status: New ** Also affects: snapd (Ubuntu) Importance: Undecided Status: New ** Also affects: update-notifier (Ubuntu) Importance: Undecided Status: New ** Description changed: $ snap connections --all | grep gnome content - gnome-3-28-1804:gnome-3-28-1804 - content - gnome-3-34-1804:gnome-3-34-1804 - content[gnome-3-38-2004] chromium:gnome-3-38-2004 gnome-3-38-2004:gnome-3-38-2004 - content[gnome-3-38-2004] firefox:gnome-3-38-2004 gnome-3-38-2004:gnome-3-38-2004 - content[gnome-42-2204]mattermost-desktop:gnome-42-2204 gnome-42-2204:gnome-42-2204 - content[gnome-42-2204]snap-store:gnome-42-2204 gnome-42-2204:gnome-42-2204 - content[gnome-42-2204]snapd-desktop-integration:gnome-42-2204 gnome-42-2204:gnome-42-2204 - - - my system has 4 gnome-* content snaps, that were pulled in as dependencies. The apps that used them, have moved on to newer versions. Something on my system must clean then up for me, for example apt autoremoves automatically installed packages & obsolete kernels, and so should also happen with snaps. + my system has 4 gnome-* content snaps, that were pulled in as + dependencies. The apps that used them, have moved on to newer versions. + Something on my system must clean then up for me, for example apt + autoremoves automatically installed packages & obsolete kernels, and so + should also happen with snaps. It can be done by snapd itself, or by something else on the classic desktop - i.e. update-manager. Note it is easy to detect such snaps, as it provides no apps; has content interface only; which is not plugged by anything. If it is ever needed by any future or past revision of any other snap it would be autoinstalled back. + + On my system they take up 824M of disk space (2 revisions, of 2 unused + content snaps = 4 snaps) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/2017926 Title: Unused content snaps not autoremoved Status in snapd package in Ubuntu: New Status in ubuntu-meta package in Ubuntu: New Status in update-notifier package in Ubuntu: New Bug description: $ snap connections --all | grep gnome content - gnome-3-28-1804:gnome-3-28-1804 - content - gnome-3-34-1804:gnome-3-34-1804 - content[gnome-3-38-2004]
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
I'm not too sure if updates from sed1991s above are correct -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: Fix Released Status in systemd source package in Focal: Fix Released Status in linux source package in Jammy: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2017770] [NEW] "Enter code on ubuntu.com/pro/attach" is not clickable URL like everything else
Public bug reported: Enter code on ubuntu.com/pro/attach is not a clickable url. however ubuntu.com/pro and "register new account" are. ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Screenshot from 2023-04-26 12-05-00.png" https://bugs.launchpad.net/bugs/2017770/+attachment/5668913/+files/Screenshot%20from%202023-04-26%2012-05-00.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2017770 Title: "Enter code on ubuntu.com/pro/attach" is not clickable URL like everything else Status in software-properties package in Ubuntu: New Bug description: Enter code on ubuntu.com/pro/attach is not a clickable url. however ubuntu.com/pro and "register new account" are. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2017770/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)
vmlinuz-6.2.0-18-generic is good, so regression introduced in 6.2.0-19
abi, suspecting new apparmor stack
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2012136
** Also affects: apparmor
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2016908
Title:
udev fails to make prctl() syscall with apparmor=0 (as used by maas by
default)
Status in AppArmor:
New
Status in MAAS:
Triaged
Status in maas-images:
Invalid
Status in apparmor package in Ubuntu:
New
Status in linux package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Invalid
Bug description:
I'm assuming the image being used for these deploys is 20230417 or
20230417.1 based on the fact that I saw a 6.2 kernel being used which
I don't believe was part of the 20230319 serial. I don't have access
to the maas server, so I can't directly check any log files.
MAAS Version: 3.3.2
Here's where the serial log indicates it can't download the squashfs. The
full log is attached as scobee-lunar-no-squashfs.log (there are some other
console message intermixed):
no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf
/run/net6
-*.conf
::
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes,
fsverity
=yes
shfs
:: mount_squash downloading
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
4/lunar/candidate/squashfs to /root.tmp.img
Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
wget: can't connect to remote host (10.229.32.21): Network is unreachable
:: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp'
mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
done.
Still gathering logs and info and will update as I go.
Kernel Bug / Apparmor
reproducer
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
$ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
#start the VM
Starting systemd-udevd version 252.5-2ubuntu3
Spawning shell within the initramfs
BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) udevadm info --export-db
Failed to set death signal: Invalid argument
Observe that udevadm fails to setup death signal, with in systemd code
is this
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
util.c#L1252
if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ?
SIGINT : SIGTERM) < 0) {
log_full_errno(prio, errno, "Failed to set death
signal: %m");
_exit(EXIT_FAILURE);
}
workaround set kernel commandline to `apparmor=1`
MAAS bug
Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor.
Even for deployment and commisioning.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2016908/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)
alexsander-souza - if you can make this on per-distro basis that would
be great. Indeed empty (thus apparmor=1) should work on jammy and up,
but yes we can never know. And having it for lunar onwards would be
super nice, because yes overlayfs apparmor things got fixed a while back
and are expected to work from now on. And there are more and more things
that rely on apparmor to be there.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2016908
Title:
udev fails to make prctl() syscall with apparmor=0 (as used by maas by
default)
Status in MAAS:
Triaged
Status in maas-images:
Invalid
Status in linux package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Invalid
Bug description:
I'm assuming the image being used for these deploys is 20230417 or
20230417.1 based on the fact that I saw a 6.2 kernel being used which
I don't believe was part of the 20230319 serial. I don't have access
to the maas server, so I can't directly check any log files.
MAAS Version: 3.3.2
Here's where the serial log indicates it can't download the squashfs. The
full log is attached as scobee-lunar-no-squashfs.log (there are some other
console message intermixed):
no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf
/run/net6
-*.conf
::
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes,
fsverity
=yes
shfs
:: mount_squash downloading
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
4/lunar/candidate/squashfs to /root.tmp.img
Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
wget: can't connect to remote host (10.229.32.21): Network is unreachable
:: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp'
mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
done.
Still gathering logs and info and will update as I go.
Kernel Bug / Apparmor
reproducer
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
$ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
#start the VM
Starting systemd-udevd version 252.5-2ubuntu3
Spawning shell within the initramfs
BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) udevadm info --export-db
Failed to set death signal: Invalid argument
Observe that udevadm fails to setup death signal, with in systemd code
is this
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
util.c#L1252
if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ?
SIGINT : SIGTERM) < 0) {
log_full_errno(prio, errno, "Failed to set death
signal: %m");
_exit(EXIT_FAILURE);
}
workaround set kernel commandline to `apparmor=1`
MAAS bug
Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor.
Even for deployment and commisioning.
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/2016908/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)
Lunar kernel will need SRU to be fixed up.
And separately, we could check if we can get rid of apparmor=0 for all
supported releases or not, in next mass release.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2016908
Title:
udev fails to make prctl() syscall with apparmor=0 (as used by maas by
default)
Status in MAAS:
Triaged
Status in maas-images:
Invalid
Status in linux package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Invalid
Bug description:
I'm assuming the image being used for these deploys is 20230417 or
20230417.1 based on the fact that I saw a 6.2 kernel being used which
I don't believe was part of the 20230319 serial. I don't have access
to the maas server, so I can't directly check any log files.
MAAS Version: 3.3.2
Here's where the serial log indicates it can't download the squashfs. The
full log is attached as scobee-lunar-no-squashfs.log (there are some other
console message intermixed):
no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf
/run/net6
-*.conf
::
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes,
fsverity
=yes
shfs
:: mount_squash downloading
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
4/lunar/candidate/squashfs to /root.tmp.img
Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
wget: can't connect to remote host (10.229.32.21): Network is unreachable
:: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp'
mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
done.
Still gathering logs and info and will update as I go.
Kernel Bug / Apparmor
reproducer
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
$ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
#start the VM
Starting systemd-udevd version 252.5-2ubuntu3
Spawning shell within the initramfs
BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) udevadm info --export-db
Failed to set death signal: Invalid argument
Observe that udevadm fails to setup death signal, with in systemd code
is this
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
util.c#L1252
if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ?
SIGINT : SIGTERM) < 0) {
log_full_errno(prio, errno, "Failed to set death
signal: %m");
_exit(EXIT_FAILURE);
}
workaround set kernel commandline to `apparmor=1`
MAAS bug
Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor.
Even for deployment and commisioning.
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/2016908/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)
Now about those bugs, it is true that apparmor and overlayfs used to not
play along.
Depending on support matrix we can attempt to turn apparmor back on.
Equally it is buggy that Ubuntu kernel does not work with apparmor
turned off.
It would be nice to investigate if we can at least enable apparmor for
some target series.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2016908
Title:
udev fails to make prctl() syscall with apparmor=0 (as used by maas by
default)
Status in MAAS:
Triaged
Status in maas-images:
Invalid
Status in linux package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Invalid
Bug description:
I'm assuming the image being used for these deploys is 20230417 or
20230417.1 based on the fact that I saw a 6.2 kernel being used which
I don't believe was part of the 20230319 serial. I don't have access
to the maas server, so I can't directly check any log files.
MAAS Version: 3.3.2
Here's where the serial log indicates it can't download the squashfs. The
full log is attached as scobee-lunar-no-squashfs.log (there are some other
console message intermixed):
no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf
/run/net6
-*.conf
::
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes,
fsverity
=yes
shfs
:: mount_squash downloading
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
4/lunar/candidate/squashfs to /root.tmp.img
Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
wget: can't connect to remote host (10.229.32.21): Network is unreachable
:: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp'
mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
done.
Still gathering logs and info and will update as I go.
Kernel Bug / Apparmor
reproducer
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
$ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
#start the VM
Starting systemd-udevd version 252.5-2ubuntu3
Spawning shell within the initramfs
BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) udevadm info --export-db
Failed to set death signal: Invalid argument
Observe that udevadm fails to setup death signal, with in systemd code
is this
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
util.c#L1252
if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ?
SIGINT : SIGTERM) < 0) {
log_full_errno(prio, errno, "Failed to set death
signal: %m");
_exit(EXIT_FAILURE);
}
workaround set kernel commandline to `apparmor=1`
MAAS bug
Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor.
Even for deployment and commisioning.
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/2016908/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016908] Re: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs
** Description changed:
I'm assuming the image being used for these deploys is 20230417 or
20230417.1 based on the fact that I saw a 6.2 kernel being used which I
don't believe was part of the 20230319 serial. I don't have access to
the maas server, so I can't directly check any log files.
MAAS Version: 3.3.2
Here's where the serial log indicates it can't download the squashfs. The
full log is attached as scobee-lunar-no-squashfs.log (there are some other
console message intermixed):
no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf
/run/net6
-*.conf
::
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes,
fsverity
=yes
shfs
:: mount_squash downloading
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
4/lunar/candidate/squashfs to /root.tmp.img
Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
wget: can't connect to remote host (10.229.32.21): Network is unreachable
:: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp'
mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
done.
+ Still gathering logs and info and will update as I go.
- Still gathering logs and info and will update as I go.
+
+
+ Kernel Bug / Apparmor
+ reproducer
+
+ $ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
+ $ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
+ $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
+
+
+ #start the VM
+
+ Starting systemd-udevd version 252.5-2ubuntu3
+ Spawning shell within the initramfs
+
+
+ BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
+ Enter 'help' for a list of built-in commands.
+
+ (initramfs) udevadm info --export-db
+ Failed to set death signal: Invalid argument
+
+ Observe that udevadm fails to setup death signal, with in systemd code
+ is this
+
+
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
+ util.c#L1252
+
+ if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
+ if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ?
SIGINT : SIGTERM) < 0) {
+ log_full_errno(prio, errno, "Failed to set death
signal: %m");
+ _exit(EXIT_FAILURE);
+ }
+
+
+
+ MAAS bug
+ Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor.
Even for deployment and commisioning.
** Changed in: linux (Ubuntu)
Status: Incomplete => Triaged
** Changed in: maas-images
Status: Incomplete => Invalid
** Changed in: systemd (Ubuntu)
Status: New => Invalid
** Also affects: maas
Importance: Undecided
Status: New
** Summary changed:
- Unable to deploy hosts with lunar images after 20230319 - fails to connect
and download squashfs
+ udev fails to make prctl() syscall with apparmor=0 (as used by maas by
default)
** Description changed:
I'm assuming the image being used for these deploys is 20230417 or
20230417.1 based on the fact that I saw a 6.2 kernel being used which I
don't believe was part of the 20230319 serial. I don't have access to
the maas server, so I can't directly check any log files.
MAAS Version: 3.3.2
Here's where the serial log indicates it can't download the squashfs. The
full log is attached as scobee-lunar-no-squashfs.log (there are some other
console message intermixed):
no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf
/run/net6
-*.conf
::
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes,
fsverity
=yes
shfs
:: mount_squash downloading
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
4/lunar/candidate/squashfs to /root.tmp.img
Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
wget: can't connect to remote host (10.229.32.21): Network is unreachable
:: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp'
mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
done.
Still gathering logs and info and will update as I go.
-
Kernel Bug / Apparmor
reproducer
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
$ wget
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
$ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'
-
#start the VM
Starting systemd-udevd version 252.5-2ubuntu3
Spawning shell within the initramfs
-
BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1)
[Touch-packages] [Bug 2016908] Re: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs
horay i managed to reproduce it locally. ** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2016908 Title: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs Status in maas-images: Incomplete Status in linux package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: I'm assuming the image being used for these deploys is 20230417 or 20230417.1 based on the fact that I saw a 6.2 kernel being used which I don't believe was part of the 20230319 serial. I don't have access to the maas server, so I can't directly check any log files. MAAS Version: 3.3.2 Here's where the serial log indicates it can't download the squashfs. The full log is attached as scobee-lunar-no-squashfs.log (there are some other console message intermixed): no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf /run/net6 -*.conf :: root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, fsverity =yes shfs :: mount_squash downloading http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0 4/lunar/candidate/squashfs to /root.tmp.img Connecting to 10.229.32.21:5248 (10.229.32.21:5248) wget: can't connect to remote host (10.229.32.21): Network is unreachable :: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp' mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory done. Still gathering logs and info and will update as I go. To manage notifications about this bug go to: https://bugs.launchpad.net/maas-images/+bug/2016908/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016908] Re: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs
I am annoyed that i cannot reproduce this locally outside of MAAS. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2016908 Title: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs Status in maas-images: Incomplete Status in systemd package in Ubuntu: New Bug description: I'm assuming the image being used for these deploys is 20230417 or 20230417.1 based on the fact that I saw a 6.2 kernel being used which I don't believe was part of the 20230319 serial. I don't have access to the maas server, so I can't directly check any log files. MAAS Version: 3.3.2 Here's where the serial log indicates it can't download the squashfs. The full log is attached as scobee-lunar-no-squashfs.log (there are some other console message intermixed): no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf /run/net6 -*.conf :: root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi date/squa[ 206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, fsverity =yes shfs :: mount_squash downloading http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0 4/lunar/candidate/squashfs to /root.tmp.img Connecting to 10.229.32.21:5248 (10.229.32.21:5248) wget: can't connect to remote host (10.229.32.21): Network is unreachable :: mount -t squashfs -o loop '/root.tmp.img' '/root.tmp' mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory done. Still gathering logs and info and will update as I go. To manage notifications about this bug go to: https://bugs.launchpad.net/maas-images/+bug/2016908/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1973734] Re: FTBFS on riscv64 in focal
@brian I'm sorry, but with block-proposed-focal set it means that affected users on riscv64 don't have uptodata pulseaudio. can we please release this? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1973734 Title: FTBFS on riscv64 in focal Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: Fix Committed Bug description: [Impact] * FTBFS on riscv64 in focal in unittest of volume test * Disable that unit test, as later releases do not run unittests on riscv64, and it's better to have up to date pulseaudio on riscv64 (with many security fixes), even if it doesn't completely correctly work. [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * volume-test probably indicates that one can't set volume correctly on riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1973734/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"
> The syslog-ng profile needs flags=(attach_disconnected) added to it
I failed to reproduce this with syslog-ng, but i guess i didn't
configure syslog-ng correctly to attempt attaching to /dev/log
I am also not sure of os-prober usage of logger is correct, and if it
actually wants to use that all, or if it should simply use journald
only, or nothing at all.
Reading attach_disconnected sounds scary, i'm not sure what os-prober
can do better here. bind-mount /dev/log socket into it's new mount
namespace?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1826294
Title:
os-prober exits prematurely with "logger: socket /dev/log: Protocol
wrong type for socket"
Status in AppArmor Profiles:
New
Status in os-prober package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
New
Bug description:
Failure occurs on Ubuntu 16.04 with the apparmor-
profiles-2.10.95-0ubuntu2.10 package installed.
Running update-grub will run /usr/bin/os-prober, which spews about a
dozen of the following line to stderr:
logger: socket /dev/log: Protocol wrong type for socket
… but fails to report the existence of some installed operating
systems as expected.
Furthermore, /var/log/messages contains:
kernel: audit: type=1400 audit(1556043066.679:11460):
apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
disconnected path" error=-13 profile="syslog-ng" name="dev/log"
pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
ouid=0
Here is a stripped-down skeleton of the /usr/bin/os-prober script, which
demonstrates the problem:
#!/bin/sh
set -e -x
newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
}
log() {
logger -t "$(basename "$0")" "$@"
}
debug() {
log "debug: $@"
}
ls -l /dev/log
debug "Hello world"
newns "$@"
The expected behavior is that it should write "debug: os-prober-
testcase Hello world" to /var/log/messages twice. However, it only
succeeds in writing "Hello world" once. After the script respawns
itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
second attempt to write to /dev/log fails as described above.
Since the os-prober Bash script runs with the -e flag, any error, even
just a logging error, causes the script to terminate prematurely.
(Arguably, the log() function should call `logger -t "$(basename
"$0")" "$@" || :` so that logging failures aren't fatal.)
The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change
profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
}
to
profile syslog-ng /{usr/,}sbin/syslog-ng
flags=(complain,attach_disconnected) {
…
}
… then run `aa-complain sbin.syslog-ng` and `service syslog-ng
restart`, before running update-grub again. I assume that similar
fixes would be required for the other logging daemons.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"
Steps i can reproduce:
wget https://bugs.launchpad.net/ubuntu/+source/os-
prober/+bug/1826294/+attachment/5652492/+files/reproducer.sh
chmod +x reproducer.sh
sudo journalctl -f -e &
clear
sudo ./reproducer.sh
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1826294
Title:
os-prober exits prematurely with "logger: socket /dev/log: Protocol
wrong type for socket"
Status in AppArmor Profiles:
New
Status in os-prober package in Ubuntu:
New
Status in rsyslog package in Ubuntu:
New
Bug description:
Failure occurs on Ubuntu 16.04 with the apparmor-
profiles-2.10.95-0ubuntu2.10 package installed.
Running update-grub will run /usr/bin/os-prober, which spews about a
dozen of the following line to stderr:
logger: socket /dev/log: Protocol wrong type for socket
… but fails to report the existence of some installed operating
systems as expected.
Furthermore, /var/log/messages contains:
kernel: audit: type=1400 audit(1556043066.679:11460):
apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
disconnected path" error=-13 profile="syslog-ng" name="dev/log"
pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
ouid=0
Here is a stripped-down skeleton of the /usr/bin/os-prober script, which
demonstrates the problem:
#!/bin/sh
set -e -x
newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
}
log() {
logger -t "$(basename "$0")" "$@"
}
debug() {
log "debug: $@"
}
ls -l /dev/log
debug "Hello world"
newns "$@"
The expected behavior is that it should write "debug: os-prober-
testcase Hello world" to /var/log/messages twice. However, it only
succeeds in writing "Hello world" once. After the script respawns
itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
second attempt to write to /dev/log fails as described above.
Since the os-prober Bash script runs with the -e flag, any error, even
just a logging error, causes the script to terminate prematurely.
(Arguably, the log() function should call `logger -t "$(basename
"$0")" "$@" || :` so that logging failures aren't fatal.)
The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change
profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
}
to
profile syslog-ng /{usr/,}sbin/syslog-ng
flags=(complain,attach_disconnected) {
…
}
… then run `aa-complain sbin.syslog-ng` and `service syslog-ng
restart`, before running update-grub again. I assume that similar
fixes would be required for the other logging daemons.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"
This is Ubuntu desktop install. rsyslog.service is active and running,
systemd-journald-dev-log.socket is running.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1826294
Title:
os-prober exits prematurely with "logger: socket /dev/log: Protocol
wrong type for socket"
Status in AppArmor Profiles:
New
Status in os-prober package in Ubuntu:
New
Status in rsyslog package in Ubuntu:
New
Bug description:
Failure occurs on Ubuntu 16.04 with the apparmor-
profiles-2.10.95-0ubuntu2.10 package installed.
Running update-grub will run /usr/bin/os-prober, which spews about a
dozen of the following line to stderr:
logger: socket /dev/log: Protocol wrong type for socket
… but fails to report the existence of some installed operating
systems as expected.
Furthermore, /var/log/messages contains:
kernel: audit: type=1400 audit(1556043066.679:11460):
apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
disconnected path" error=-13 profile="syslog-ng" name="dev/log"
pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
ouid=0
Here is a stripped-down skeleton of the /usr/bin/os-prober script, which
demonstrates the problem:
#!/bin/sh
set -e -x
newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
}
log() {
logger -t "$(basename "$0")" "$@"
}
debug() {
log "debug: $@"
}
ls -l /dev/log
debug "Hello world"
newns "$@"
The expected behavior is that it should write "debug: os-prober-
testcase Hello world" to /var/log/messages twice. However, it only
succeeds in writing "Hello world" once. After the script respawns
itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
second attempt to write to /dev/log fails as described above.
Since the os-prober Bash script runs with the -e flag, any error, even
just a logging error, causes the script to terminate prematurely.
(Arguably, the log() function should call `logger -t "$(basename
"$0")" "$@" || :` so that logging failures aren't fatal.)
The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change
profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
}
to
profile syslog-ng /{usr/,}sbin/syslog-ng
flags=(complain,attach_disconnected) {
…
}
… then run `aa-complain sbin.syslog-ng` and `service syslog-ng
restart`, before running update-grub again. I assume that similar
fixes would be required for the other logging daemons.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"
** Attachment added: "reproducer.sh"
https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1826294/+attachment/5652492/+files/reproducer.sh
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1826294
Title:
os-prober exits prematurely with "logger: socket /dev/log: Protocol
wrong type for socket"
Status in AppArmor Profiles:
New
Status in os-prober package in Ubuntu:
New
Status in rsyslog package in Ubuntu:
New
Bug description:
Failure occurs on Ubuntu 16.04 with the apparmor-
profiles-2.10.95-0ubuntu2.10 package installed.
Running update-grub will run /usr/bin/os-prober, which spews about a
dozen of the following line to stderr:
logger: socket /dev/log: Protocol wrong type for socket
… but fails to report the existence of some installed operating
systems as expected.
Furthermore, /var/log/messages contains:
kernel: audit: type=1400 audit(1556043066.679:11460):
apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
disconnected path" error=-13 profile="syslog-ng" name="dev/log"
pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
ouid=0
Here is a stripped-down skeleton of the /usr/bin/os-prober script, which
demonstrates the problem:
#!/bin/sh
set -e -x
newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
}
log() {
logger -t "$(basename "$0")" "$@"
}
debug() {
log "debug: $@"
}
ls -l /dev/log
debug "Hello world"
newns "$@"
The expected behavior is that it should write "debug: os-prober-
testcase Hello world" to /var/log/messages twice. However, it only
succeeds in writing "Hello world" once. After the script respawns
itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
second attempt to write to /dev/log fails as described above.
Since the os-prober Bash script runs with the -e flag, any error, even
just a logging error, causes the script to terminate prematurely.
(Arguably, the log() function should call `logger -t "$(basename
"$0")" "$@" || :` so that logging failures aren't fatal.)
The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change
profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
}
to
profile syslog-ng /{usr/,}sbin/syslog-ng
flags=(complain,attach_disconnected) {
…
}
… then run `aa-complain sbin.syslog-ng` and `service syslog-ng
restart`, before running update-grub again. I assume that similar
fixes would be required for the other logging daemons.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1826294] Re: os-prober exits prematurely with "logger: socket /dev/log: Protocol wrong type for socket"
yeah i get apparmor="DENIED" info="Failed name loookup - disconnected
path", which breaks os-prober.
** Changed in: os-prober (Ubuntu)
Importance: Undecided => Critical
** Also affects: rsyslog (Ubuntu)
Importance: Undecided
Status: New
** Changed in: rsyslog (Ubuntu)
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1826294
Title:
os-prober exits prematurely with "logger: socket /dev/log: Protocol
wrong type for socket"
Status in AppArmor Profiles:
New
Status in os-prober package in Ubuntu:
New
Status in rsyslog package in Ubuntu:
New
Bug description:
Failure occurs on Ubuntu 16.04 with the apparmor-
profiles-2.10.95-0ubuntu2.10 package installed.
Running update-grub will run /usr/bin/os-prober, which spews about a
dozen of the following line to stderr:
logger: socket /dev/log: Protocol wrong type for socket
… but fails to report the existence of some installed operating
systems as expected.
Furthermore, /var/log/messages contains:
kernel: audit: type=1400 audit(1556043066.679:11460):
apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
disconnected path" error=-13 profile="syslog-ng" name="dev/log"
pid=28566 comm="logger" requested_mask="r" denied_mask="r" fsuid=0
ouid=0
Here is a stripped-down skeleton of the /usr/bin/os-prober script, which
demonstrates the problem:
#!/bin/sh
set -e -x
newns () {
[ "$OS_PROBER_NEWNS" ] || exec /usr/lib/os-prober/newns "$0" "$@"
}
log() {
logger -t "$(basename "$0")" "$@"
}
debug() {
log "debug: $@"
}
ls -l /dev/log
debug "Hello world"
newns "$@"
The expected behavior is that it should write "debug: os-prober-
testcase Hello world" to /var/log/messages twice. However, it only
succeeds in writing "Hello world" once. After the script respawns
itself with /usr/lib/os-prober/newns (which is like `unshare -m`), the
second attempt to write to /dev/log fails as described above.
Since the os-prober Bash script runs with the -e flag, any error, even
just a logging error, causes the script to terminate prematurely.
(Arguably, the log() function should call `logger -t "$(basename
"$0")" "$@" || :` so that logging failures aren't fatal.)
The fix, for me, is to edit /etc/apparmor.d/sbin.syslog-ng, and change
profile syslog-ng /{usr/,}sbin/syslog-ng flags=(complain) {\
…
}
to
profile syslog-ng /{usr/,}sbin/syslog-ng
flags=(complain,attach_disconnected) {
…
}
… then run `aa-complain sbin.syslog-ng` and `service syslog-ng
restart`, before running update-grub again. I assume that similar
fixes would be required for the other logging daemons.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor-profiles/+bug/1826294/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2009239] [NEW] Updating base-files at point releases is pointless, misleading, and causes confusion and anxiety
Public bug reported: Updating base-files at point releases is pointless, misleading, and causes confusing and anxiety Can we please stop updating base-files at point releases? Building new installer media, and calling it with a new .N number is good, and helps to differentiate what the initial state the machine roughly was, given that ultimately the serial # of the installer media is what matters. Updating base-files on the installed system => not so much. As it is an artificial line in the sand that doesn't change anything to the systems, that are continuously upgrading. The upgrade of base-files package, doesn't require to refresh snaps to latest revisions; install debs of latest versions; nor is anything else happening to force that (i.e. copying all packages from -updates to -security, like debian does). But it does cause confusion and anxiety among enterprise customers, who notice an update to base-files and a change of prompts, and suddenly demand to revert back from .2 release to .1. Which is understandable, since point releases in other operating systems have longer timespan, and are allowed to remain on an older substream for longer, and require admin actions to upgrade. Which is not the case with Ubuntu. Our interim releases, are actually closer to what windows/rhel call point releases. Since they are distinct, one can skip them, and they have a different time window. Our LTS is just a single stream of updates, which is continiously maintained, and thus it should always be recognized on the installed systems as "24.04 LTS". references: Windows 10 https://learn.microsoft.com/en- us/lifecycle/products/windows-10-home-and-pro note how windows 10 support multiple year/half releases, which are a track one can stay on for a long time, even as a new one is already out. Rhel point release timeframes https://access.redhat.com/support/policy/updates/errata#viii notice how every other point release is supported for up to 4 years, and is a track one can stay on for that period of time. Whereas Ubuntu LTS is a single track, that one cannot get off. There isn't a point release subtrack. ** Affects: base-files (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Updating base-files at point releases is pointless, misleading, and causes confusing and anxiety + Updating base-files at point releases is pointless, misleading, and causes confusion and anxiety -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-files in Ubuntu. https://bugs.launchpad.net/bugs/2009239 Title: Updating base-files at point releases is pointless, misleading, and causes confusion and anxiety Status in base-files package in Ubuntu: New Bug description: Updating base-files at point releases is pointless, misleading, and causes confusing and anxiety Can we please stop updating base-files at point releases? Building new installer media, and calling it with a new .N number is good, and helps to differentiate what the initial state the machine roughly was, given that ultimately the serial # of the installer media is what matters. Updating base-files on the installed system => not so much. As it is an artificial line in the sand that doesn't change anything to the systems, that are continuously upgrading. The upgrade of base-files package, doesn't require to refresh snaps to latest revisions; install debs of latest versions; nor is anything else happening to force that (i.e. copying all packages from -updates to -security, like debian does). But it does cause confusion and anxiety among enterprise customers, who notice an update to base-files and a change of prompts, and suddenly demand to revert back from .2 release to .1. Which is understandable, since point releases in other operating systems have longer timespan, and are allowed to remain on an older substream for longer, and require admin actions to upgrade. Which is not the case with Ubuntu. Our interim releases, are actually closer to what windows/rhel call point releases. Since they are distinct, one can skip them, and they have a different time window. Our LTS is just a single stream of updates, which is continiously maintained, and thus it should always be recognized on the installed systems as "24.04 LTS". references: Windows 10 https://learn.microsoft.com/en- us/lifecycle/products/windows-10-home-and-pro note how windows 10 support multiple year/half releases, which are a track one can stay on for a long time, even as a new one is already out. Rhel point release timeframes https://access.redhat.com/support/policy/updates/errata#viii notice how every other point release is supported for up to 4 years, and is a track one can stay on for that period of time. Whereas Ubuntu LTS is a single track, that one cannot get off. There isn't a point release subtrack. To manage notifications
[Touch-packages] [Bug 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)
sponsored into unapproved queue ** Changed in: lxc (Ubuntu Bionic) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1886790 Title: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test) Status in ubuntu-kernel-tests: New Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Bionic: In Progress Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz The failing test seems to be: FAIL: lxc-tests: lxc-test-device-add-remove (0s) --- Adding /dev/network_latency to the container (device_add_remove_test) failed... --- This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note that this testcase is successful on Focal with the same kernel version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1886790/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1992513] Re: apt will not install nvidia-driver-470-server if nvidia-driver-450-server is installed and out of date
One should use ubuntu-drivers CLI or Additional Drivers GUI to install or switch nvidia graphics stacks from one major series to another. It ensures that correct matching pre-signed kernel drivers are installed together with the right userspace (with and without gui stacks, as needed). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1992513 Title: apt will not install nvidia-driver-470-server if nvidia- driver-450-server is installed and out of date Status in apt package in Ubuntu: Triaged Status in nvidia-graphics-drivers-450-server package in Ubuntu: New Status in nvidia-graphics-drivers-470-server package in Ubuntu: New Bug description: apt/jammy apt will refuse to install nvidia-driver-470-server if nvidia-driver-450-server is installed *and* out of date. I can reproduce this by disabling all but the jammy release pocket, installing the old n-d-450-s from there, and then enabling updates and trying to install n-v-470-s (where a new n-d-450-s is available): # libnvidia-gl-450-server has an update available root@dannf-apt-jammy:/var/cache# apt install --dry-run libnvidia-gl-470-server -o Debug::pkgProblemResolver=yes Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libnvidia-common-450-server : Conflicts: libnvidia-common libnvidia-common-470-server : Conflicts: libnvidia-common E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1992513/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)
we ought to sponosr http://launchpadlibrarian.net/453184210/lxc_3.0.4-0ubuntu1_3.0.4-0ubuntu2.diff.gz into bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1886790 Title: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test) Status in ubuntu-kernel-tests: New Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Bionic: Triaged Bug description: Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz The failing test seems to be: FAIL: lxc-tests: lxc-test-device-add-remove (0s) --- Adding /dev/network_latency to the container (device_add_remove_test) failed... --- This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note that this testcase is successful on Focal with the same kernel version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1886790/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2003785] [NEW] apt source exact-source-package doesn't download the requested source package
Public bug reported: apt source exact-source-package doesn't download the right source package when specifying source package, i expect the exact source package to be downloaded. example: $ apt source linux-lowlatency => incorrectly downloads linux-meta-lowlatency $ apt source --only-source linux-lowlatency => is very counter intuitive but downloads linux-lowlatency source package Please default to downloading exact source package by default first, and offer binary->source resolution separately. ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Summary changed: - apt source exact-source-package doesn't download the right source package + apt source exact-source-package doesn't download the requested source package -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/2003785 Title: apt source exact-source-package doesn't download the requested source package Status in apt package in Ubuntu: New Bug description: apt source exact-source-package doesn't download the right source package when specifying source package, i expect the exact source package to be downloaded. example: $ apt source linux-lowlatency => incorrectly downloads linux-meta-lowlatency $ apt source --only-source linux-lowlatency => is very counter intuitive but downloads linux-lowlatency source package Please default to downloading exact source package by default first, and offer binary->source resolution separately. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003785/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes
@sil2100 marked out test case in the bug report more clearly. ** Description changed: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. + + [Testcase] + + tl;dr encrypted-zfs, firstboot, `systemctl daemon-reload` must not + unmount half of mountpoints, ie. /var/lib. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) - E: Problem opening + E: Problem opening E: The package lists or status file could not be parsed or opened. + Notes: Switching to a TTY will print a crash error message related to + the same missing /var/lib/dpkg/status file. Running "sudo touch + /var/lib/dpkg/status" will allow "sudo apt update" to function and fix + the crashed process in the TTY. - Notes: Switching to a TTY will print a crash error message related to the same missing /var/lib/dpkg/status file. Running "sudo touch /var/lib/dpkg/status" will allow "sudo apt update" to function and fix the crashed process in the TTY. + [End Testcase] Once you log in, you'll notice that Firefox is missing (bug #1993279), and you will likely be presented with a ton of error messages and other scary junk. At least one of those error messages was related to update- manager in my experience, and another one was from "check-new-release- gtk". ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: zsys (not installed) ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Oct 18 09:55:27 2022 InstallationDate: Installed on 2022-10-18 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018) ProcEnviron: TERM=xterm-256color PATH=(custom, no username) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: zsys UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1993318 Title: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes Status in Ubuntu Manual Tests: New Status in Release Notes for Ubuntu: Fix Released Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in ubiquity package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Confirmed Status in zsys package in Ubuntu: Invalid Status in ubiquity source package in Jammy: Triaged Bug description: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. [Testcase] tl;dr encrypted-zfs, firstboot, `systemctl daemon-reload` must not unmount half of mountpoints, ie. /var/lib. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. Notes: Switching to a TTY will print a crash
[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes
https://launchpad.net/ubuntu/jammy/+queue?queue_state=1_text=ubiquity ** Also affects: ubiquity (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: zfs-linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: snapd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: zsys (Ubuntu Jammy) Importance: Undecided Status: New ** No longer affects: snapd (Ubuntu Jammy) ** No longer affects: systemd (Ubuntu Jammy) ** Changed in: ubiquity (Ubuntu Jammy) Importance: Undecided => High ** Changed in: ubiquity (Ubuntu Jammy) Status: New => Triaged ** Changed in: ubiquity (Ubuntu Jammy) Milestone: None => ubuntu-22.04.2 ** No longer affects: zfs-linux (Ubuntu Jammy) ** No longer affects: zsys (Ubuntu Jammy) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1993318 Title: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes Status in Ubuntu Manual Tests: New Status in Release Notes for Ubuntu: Fix Released Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in ubiquity package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Confirmed Status in zsys package in Ubuntu: Invalid Status in ubiquity source package in Jammy: Triaged Bug description: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. Notes: Switching to a TTY will print a crash error message related to the same missing /var/lib/dpkg/status file. Running "sudo touch /var/lib/dpkg/status" will allow "sudo apt update" to function and fix the crashed process in the TTY. Once you log in, you'll notice that Firefox is missing (bug #1993279), and you will likely be presented with a ton of error messages and other scary junk. At least one of those error messages was related to update-manager in my experience, and another one was from "check-new- release-gtk". ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: zsys (not installed) ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Oct 18 09:55:27 2022 InstallationDate: Installed on 2022-10-18 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018) ProcEnviron: TERM=xterm-256color PATH=(custom, no username) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: zsys UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1993318/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2003701] Re: PKCS7: Message signed outside of X.509 validity window
The best we can do, is to take notAfter time of the signing certificate and add that as the signingTime, which will then be used by the Sign command as given. This will ensure the signature is within valid time-series. I don't see an easy openssl API to sign things without any signature timestamp. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2003701 Title: PKCS7: Message signed outside of X.509 validity window Status in openssl package in Ubuntu: New Status in sbsigntool package in Ubuntu: New Bug description: When signing UEFI applications, the signature includes signing timestamp. Kernels, upon kexec, check that message signature is within the validity of the X.509 signing certificate. When using original canonical kernel team test key, I no longer can kexec kernels, as the test key has expired. UEFI specifications in general ignore signing time. IMHO we should remove / not include signing timestamp in the UEFI signatures to avoid this. --- i guess openssl needs to provide ability to create signatures without signingtime attribute. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003701/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2003701] Re: PKCS7: Message signed outside of X.509 validity window
setting PKCS7_NOATTR is not enough, as that only removes the smime capabilities signed attribute, whilst signature timestamp remains. --- ./regular.text 2023-01-23 11:42:49.992929526 + +++ noattr.text 2023-01-23 11:42:59.288981639 + @@ -128,7 +128,7 @@ object: signingTime (1.2.840.113549.1.9.5) set: - UTCTIME:Jan 23 11:41:20 2023 GMT + UTCTIME:Jan 23 11:41:53 2023 GMT object: messageDigest (1.2.840.113549.1.9.4) set: @@ -136,56 +136,32 @@ - f8 cf 89 70 c1 6c 14 26-6d 56 c1 25 96 ...p.l.%. 000d - ce 74 11 77 a0 36 47 4d-3b 28 bf 7f 5b .t.w.6GM;(..[ 001a - 1e b6 04 ed 21 f8!. - -object: S/MIME Capabilities (1.2.840.113549.1.9.15) -set: - SEQUENCE: -0:d=0 hl=2 l= 106 cons: SEQUENCE -2:d=1 hl=2 l= 11 cons: SEQUENCE -4:d=2 hl=2 l= 9 prim: OBJECT:aes-256-cbc - 15:d=1 hl=2 l= 11 cons: SEQUENCE - 17:d=2 hl=2 l= 9 prim: OBJECT:aes-192-cbc - 28:d=1 hl=2 l= 11 cons: SEQUENCE - 30:d=2 hl=2 l= 9 prim: OBJECT:aes-128-cbc - 41:d=1 hl=2 l= 10 cons: SEQUENCE - 43:d=2 hl=2 l= 8 prim: OBJECT:des-ede3-cbc - 53:d=1 hl=2 l= 14 cons: SEQUENCE - 55:d=2 hl=2 l= 8 prim: OBJECT:rc2-cbc - 65:d=2 hl=2 l= 2 prim: INTEGER :80 - 69:d=1 hl=2 l= 13 cons: SEQUENCE - 71:d=2 hl=2 l= 8 prim: OBJECT:rc2-cbc - 81:d=2 hl=2 l= 1 prim: INTEGER :40 - 84:d=1 hl=2 l= 7 cons: SEQUENCE - 86:d=2 hl=2 l= 5 prim: OBJECT:des-cbc - 93:d=1 hl=2 l= 13 cons: SEQUENCE - 95:d=2 hl=2 l= 8 prim: OBJECT:rc2-cbc - 105:d=2 hl=2 l= 1 prim: INTEGER :28 digest_enc_alg: ** Description changed: When signing UEFI applications, the signature includes signing timestamp. Kernels, upon kexec, check that message signature is within the validity of the X.509 signing certificate. When using original canonical kernel team test key, I no longer can kexec kernels, as the test key has expired. UEFI specifications in general ignore signing time. IMHO we should remove / not include signing timestamp in the UEFI signatures to avoid this. + + --- + + i guess openssl needs to provide ability to create signatures without + signingtime attribute. ** Also affects: openssl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2003701 Title: PKCS7: Message signed outside of X.509 validity window Status in openssl package in Ubuntu: New Status in sbsigntool package in Ubuntu: New Bug description: When signing UEFI applications, the signature includes signing timestamp. Kernels, upon kexec, check that message signature is within the validity of the X.509 signing certificate. When using original canonical kernel team test key, I no longer can kexec kernels, as the test key has expired. UEFI specifications in general ignore signing time. IMHO we should remove / not include signing timestamp in the UEFI signatures to avoid this. --- i guess openssl needs to provide ability to create signatures without signingtime attribute. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003701/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes
** Changed in: snapd (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1993318 Title: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes Status in Ubuntu Manual Tests: New Status in Release Notes for Ubuntu: Fix Released Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in ubiquity package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Confirmed Status in zsys package in Ubuntu: Invalid Bug description: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. Notes: Switching to a TTY will print a crash error message related to the same missing /var/lib/dpkg/status file. Running "sudo touch /var/lib/dpkg/status" will allow "sudo apt update" to function and fix the crashed process in the TTY. Once you log in, you'll notice that Firefox is missing (bug #1993279), and you will likely be presented with a ton of error messages and other scary junk. At least one of those error messages was related to update-manager in my experience, and another one was from "check-new- release-gtk". ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: zsys (not installed) ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Oct 18 09:55:27 2022 InstallationDate: Installed on 2022-10-18 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018) ProcEnviron: TERM=xterm-256color PATH=(custom, no username) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: zsys UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1993318/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1975587] Re: systemd: fix test-execute autotest failure with kernel 5.15 in focal
In the triggered logs
PASS: test-execute
is present with new kernel and new systemd
-env=ADT_TEST_TRIGGERS=linux-meta-hwe-5.15/5.15.0.53.59~20.04.21 linux-
hwe-5.15/5.15.0-53.59~20.04.1 linux-signed-hwe-5.15/5.15.0-53.59~20.04.1
systemd/245.4-4ubuntu3.19'
https://autopkgtest.ubuntu.com/results/autopkgtest-
focal/focal/amd64/s/systemd/20221118_144307_c3504@/log.gz
there are other failures, i.e. seccomp, which will need to be address
separately.
** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1975587
Title:
systemd: fix test-execute autotest failure with kernel 5.15 in focal
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Fix Committed
Bug description:
[Impact]
test-execute autotest is failing in focal with kernel 5.15. This is
because the following kernel commit changed the ABI for ioprio:
e70344c05995 ("block: fix default IO priority handling")
Previously setting IOPRIO_CLASS_NONE for a process would report
IOPRIO_CLASS_NONE back. But starting with 5.15 it reports
IOPRIO_CLASS_BE instead.
[Test case]
Run systemd autopkgtest and check for the test-execute result.
[Fix]
Change test/test-execute/exec-ioschedulingclass-none.service to
recognize both "none" and "best-effort" as valid returned strings from
ionice.
This change is already available in jammy and above.
[Regression potential]
We may see regressions in systemd autopkgtest, we won't introduce any
potential regressions in systemd itself, because this is only
affecting the specific unit test.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1975587/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1975587] Re: systemd: fix test-execute autotest failure with kernel 5.15 in focal
all autopkgtests now pass https://people.canonical.com/~ubuntu-
archive/proposed-migration/focal/update_excuses.html#systemd
now testing if the new testcase is fixed with v5.15 kernels in focal.
Test request submitted.
Result history
https://autopkgtest.ubuntu.com/packages/systemd/focal/amd64
arch
amd64
package
systemd
release
focal
requester
xnox
triggers
['linux-meta-hwe-5.15/5.15.0.53.59~20.04.21',
'linux-hwe-5.15/5.15.0-53.59~20.04.1',
'linux-signed-hwe-5.15/5.15.0-53.59~20.04.1', 'systemd/245.4-4ubuntu3.19']
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1975587
Title:
systemd: fix test-execute autotest failure with kernel 5.15 in focal
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Fix Committed
Bug description:
[Impact]
test-execute autotest is failing in focal with kernel 5.15. This is
because the following kernel commit changed the ABI for ioprio:
e70344c05995 ("block: fix default IO priority handling")
Previously setting IOPRIO_CLASS_NONE for a process would report
IOPRIO_CLASS_NONE back. But starting with 5.15 it reports
IOPRIO_CLASS_BE instead.
[Test case]
Run systemd autopkgtest and check for the test-execute result.
[Fix]
Change test/test-execute/exec-ioschedulingclass-none.service to
recognize both "none" and "best-effort" as valid returned strings from
ionice.
This change is already available in jammy and above.
[Regression potential]
We may see regressions in systemd autopkgtest, we won't introduce any
potential regressions in systemd itself, because this is only
affecting the specific unit test.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1975587/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1973734] Re: FTBFS on riscv64 in focal
imho focal users on riscv64 deserve new pulseaudio -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1973734 Title: FTBFS on riscv64 in focal Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: Fix Committed Bug description: [Impact] * FTBFS on riscv64 in focal in unittest of volume test * Disable that unit test, as later releases do not run unittests on riscv64, and it's better to have up to date pulseaudio on riscv64 (with many security fixes), even if it doesn't completely correctly work. [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * volume-test probably indicates that one can't set volume correctly on riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1973734/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1973734] Re: FTBFS on riscv64 in focal
build successful https://launchpad.net/ubuntu/+source/pulseaudio/1:13.99.1-1ubuntu3.14/+build/23853226 ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1973734 Title: FTBFS on riscv64 in focal Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: Fix Committed Bug description: [Impact] * FTBFS on riscv64 in focal in unittest of volume test * Disable that unit test, as later releases do not run unittests on riscv64, and it's better to have up to date pulseaudio on riscv64 (with many security fixes), even if it doesn't completely correctly work. [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * volume-test probably indicates that one can't set volume correctly on riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1973734/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes
https://code.launchpad.net/~xnox/ubiquity/+git/ubiquity/+merge/431831 should solve first boot post-install. However, I don't think that will solve booting snapshot, or whenever on- disk cached is missing/corrupted/out of date, and one tries to boot. Seems quite scary. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1993318 Title: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes Status in snapd package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Status in ubiquity package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: New Status in zsys package in Ubuntu: Invalid Bug description: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. Notes: Switching to a TTY will print a crash error message related to the same missing /var/lib/dpkg/status file. Running "sudo touch /var/lib/dpkg/status" will allow "sudo apt update" to function and fix the crashed process in the TTY. Once you log in, you'll notice that Firefox is missing (bug #1993279), and you will likely be presented with a ton of error messages and other scary junk. At least one of those error messages was related to update-manager in my experience, and another one was from "check-new- release-gtk". ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: zsys (not installed) ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Oct 18 09:55:27 2022 InstallationDate: Installed on 2022-10-18 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018) ProcEnviron: TERM=xterm-256color PATH=(custom, no username) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: zsys UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes
on first boot /etc/zfs/zfs-list.cache/rboot /etc/zfs/zfs- list.cache/bpool are either missing or empty. this causes daemon-reload to go bananzas, as zfs generator runs for the first time and generates many essential mount units. After that if cache is populated, generators on boot & daemon-reload produces the same units and everything and everyone is happy. I wonder if installer could copy zfs-list.cache/ into target system. Or I wonder if our zfs-mount-generator(8) in ubuntu is out of date (because of zsys support). Or if there has been some systemd regression. I wonder if we can make zfs-mount-generator do nothing; if on first boot there were no cache files to process. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1993318 Title: ZFS + Encryption installations of Ubuntu Desktop do not come up correctly on first boot, systemd unmounts many of the zfs volumes Status in snapd package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Status in ubiquity package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: New Status in zsys package in Ubuntu: Invalid Bug description: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. Notes: Switching to a TTY will print a crash error message related to the same missing /var/lib/dpkg/status file. Running "sudo touch /var/lib/dpkg/status" will allow "sudo apt update" to function and fix the crashed process in the TTY. Once you log in, you'll notice that Firefox is missing (bug #1993279), and you will likely be presented with a ton of error messages and other scary junk. At least one of those error messages was related to update-manager in my experience, and another one was from "check-new- release-gtk". ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: zsys (not installed) ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Oct 18 09:55:27 2022 InstallationDate: Installed on 2022-10-18 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018) ProcEnviron: TERM=xterm-256color PATH=(custom, no username) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: zsys UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager
subsequent boots are fine. i wonder if we have a race somewhere, for example. On first boot zfs cache is out of date. And zfs mount generator doesn't generate mounts for all the mounted file systems. then the first daemon-reload ever, will happen after zfs cache is populated and the zfs volumes are emitted for the first time. maybe something like mounting all subvolumes should happen from initrd. as part of pivot root. or at least building zfs cache, such that first boot's generators run is correct. ** Changed in: zfs-linux (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1993318 Title: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager Status in snapd package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Status in ubiquity package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: New Status in zsys package in Ubuntu: Invalid Bug description: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. Notes: Switching to a TTY will print a crash error message related to the same missing /var/lib/dpkg/status file. Running "sudo touch /var/lib/dpkg/status" will allow "sudo apt update" to function and fix the crashed process in the TTY. Once you log in, you'll notice that Firefox is missing (bug #1993279), and you will likely be presented with a ton of error messages and other scary junk. At least one of those error messages was related to update-manager in my experience, and another one was from "check-new- release-gtk". ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: zsys (not installed) ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Oct 18 09:55:27 2022 InstallationDate: Installed on 2022-10-18 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018) ProcEnviron: TERM=xterm-256color PATH=(custom, no username) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: zsys UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager
1) doing first boot of encrypted zfs kinetic, edit boot cmdline to include: systemd.mask=snapd.service systemd.snapd.seeded.service systemd.mask=snapd.socket crutially this prevents snapd seeding to complete which calls systemctl daemon-relaod. system boots normally 2) login into tty and check mounts (mount | grep zfs | wc => is 17) 3) systemctl daemon-reload => causes issues with -.mount and stops a bunch of stuff, and reastarts gdm, and unmounts a bunch of stuff. 4) login into tty, and check mounts, there are now just 7 zfs mounts 5) do $ sudo zfs mount -a => to get back to 17 mounts. somehow something systemd does not like upon doing daemon-reload. ** Changed in: snapd (Ubuntu) Status: New => Incomplete ** Changed in: zfs-linux (Ubuntu) Status: New => Incomplete ** Changed in: systemd (Ubuntu) Importance: Undecided => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1993318 Title: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager Status in snapd package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Status in ubiquity package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Incomplete Status in zsys package in Ubuntu: Invalid Bug description: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. Notes: Switching to a TTY will print a crash error message related to the same missing /var/lib/dpkg/status file. Running "sudo touch /var/lib/dpkg/status" will allow "sudo apt update" to function and fix the crashed process in the TTY. Once you log in, you'll notice that Firefox is missing (bug #1993279), and you will likely be presented with a ton of error messages and other scary junk. At least one of those error messages was related to update-manager in my experience, and another one was from "check-new- release-gtk". ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: zsys (not installed) ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Oct 18 09:55:27 2022 InstallationDate: Installed on 2022-10-18 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018) ProcEnviron: TERM=xterm-256color PATH=(custom, no username) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: zsys UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1993318] Re: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager
** Attachment added: "system.journal" https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1993318/+attachment/5624966/+files/system.journal ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Also affects: snapd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1993318 Title: ZFS + Encryption installations of Ubuntu Desktop suffer various severe problems related to the package manager Status in snapd package in Ubuntu: New Status in systemd package in Ubuntu: New Status in ubiquity package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: New Status in zsys package in Ubuntu: Invalid Bug description: This is *probably* the wrong package, but it's the best I can figure for this, so here goes. Hardware: Kubuntu Focus XE, 32 GB RAM, 1 TB SSD, 11th Gen Intel Core i5, UEFI, no secure boot. Testing done in GNOME Boxes, BIOS, 4 GB RAM, 50 GB disk space . OS is Ubuntu Desktop, Kinetic Final ISO. Steps to reproduce: 1. Boot the Ubuntu desktop ISO. 2. Select "Install Ubuntu" and proceed with the installation process. 3. When you get to the "Installation type" screen, select "Advanced Options", and enable ZFS + Encryption. 4. Proceed with the rest of the installation as normal. 5. Reboot into the newly installed system. 6. Log in. 7. Run "sudo apt update" in a terminal. Expected result: The package database should be updated normally. Actual result: You are presented with the following errors at the end of the apt output: Reading package lists... Error! E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory) E: Could not open file - open (2: No such file or directory) E: Problem opening E: The package lists or status file could not be parsed or opened. Notes: Switching to a TTY will print a crash error message related to the same missing /var/lib/dpkg/status file. Running "sudo touch /var/lib/dpkg/status" will allow "sudo apt update" to function and fix the crashed process in the TTY. Once you log in, you'll notice that Firefox is missing (bug #1993279), and you will likely be presented with a ton of error messages and other scary junk. At least one of those error messages was related to update-manager in my experience, and another one was from "check-new- release-gtk". ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: zsys (not installed) ProcVersionSignature: Ubuntu 5.19.0-21.21-generic 5.19.7 Uname: Linux 5.19.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Oct 18 09:55:27 2022 InstallationDate: Installed on 2022-10-18 (0 days ago) InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Release amd64 (20221018) ProcEnviron: TERM=xterm-256color PATH=(custom, no username) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: zsys UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1993318/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
initramfs-tools also mounts /dev with nosuid, without noexec > mount -t devtmpfs -o nosuid,mode=0755 udev /dev I believe all of these should be the same, thus kernel can mount /dev with nosuid, but should not mount it with noexec. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: In Progress Status in systemd source package in Focal: Invalid Status in linux source package in Jammy: In Progress Status in systemd source package in Jammy: Invalid Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
./src/nspawn/nspawn-mount.c missing NO_EXEC on /dev ./src/shared/mount-setup.c missing NO_EXEC on /dev when booting containers ** Changed in: systemd (Ubuntu) Status: Invalid => 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/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: In Progress Status in systemd source package in Focal: Invalid Status in linux source package in Jammy: In Progress Status in systemd source package in Jammy: Invalid Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
./src/nspawn/nspawn-mount.c missing NO_EXEC on /dev ./src/shared/mount-setup.c missing NO_EXEC on /dev when booting containers -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: In Progress Status in systemd source package in Focal: Invalid Status in linux source package in Jammy: In Progress Status in systemd source package in Jammy: Invalid Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
@juliank please test initrd-less boot; for example lxc launch --vm which uses linux-kvm flavour booted without initrd. There are differences of the mount options as applied by initramfs- tools; systemd; and kernel itself. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990187] Re: systemd-resolved recommends libnss-resolve in kinetic, pulls it into minimal system where it was explicitly excluded before
we do not need or want libnss-resolve anymore, because we created stub- resolv.conf which exports 1) local nameserver resolver 2) with correct options 3) and search domains. We only needed libnss-resolve back when we dind't have /run/systemd/resolve/stub-resolv.conf -- 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/1990187 Title: systemd-resolved recommends libnss-resolve in kinetic, pulls it into minimal system where it was explicitly excluded before Status in systemd package in Ubuntu: Fix Released Bug description: In kinetic, systemd-resolved now Recommends: libnss-resolve, pulling it into the ubuntu-minimal seed. In the past we briefly had libnss-resolve seeded (between xenial and bionic LTSes but not in any LTS) but it was removed because: - it was redundant; /etc/resolv.conf was consistent and correct. - its presence could mask wrong DNS configuration resulting in difficult-to-debug differences in behavior between applications that did use nss_resolved via /etc/nsswitch.conf and those that did not (examples: i386 binaries that could not use nss_resolved because it was not installed; statically-linked go implementations that parsed /etc/resolve.conf directly and did not load NSS modules) This new recommends was noticed specifically because of some broken kinetic container images where /etc/resolv.conf was broken (empty) and *some* applications still worked via nss but others failed by trying to use the DNS protocol directly. (I.e.: 2nd point above) I believe systemd-resolved should drop its recommends on libnss- resolve for Ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1990187/+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 1920640] Re: EXPKEYSIG C8CAB6595FDFF622 Ubuntu Debug Symbol Archive Automatic Signing Key (2016)
I can add maintainer script to check and remove expired copies of 0xC8CAB6595FDFF622 and then like print a message that one needs to install ubuntu-dbgsym-keyring Unfortunately, I cannot automatically ask apt to install ubuntu-dbgsym- keyring if expired dbgsym key is detected on disk =/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-keyring in Ubuntu. https://bugs.launchpad.net/bugs/1920640 Title: EXPKEYSIG C8CAB6595FDFF622 Ubuntu Debug Symbol Archive Automatic Signing Key (2016) Status in ubuntu-keyring package in Ubuntu: Fix Released Status in ubuntu-keyring source package in Bionic: Fix Released Status in ubuntu-keyring source package in Focal: Fix Released Status in ubuntu-keyring source package in Groovy: Fix Released Status in ubuntu-keyring source package in Hirsute: Fix Released Bug description: [Impact] * Cannot update apt metadata from ddebs.ubuntu.com whilst using ubuntu-dbgsym-keyring package [Test Plan] * Install ubuntu-dbgsym-keyring package * Add ddebs.ubuntu.com repository for your release * sudo apt update must be successful * Install ubuntu-dbgsym-keyring package * Install and use `apt-key list` and check that there is no expiry on the dbgsym key I.e. bad output /etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg - pub rsa4096 2016-03-21 [SC] [expired: 2021-03-20] F2ED C64D C5AE E1F6 B9C6 21F0 C8CA B659 5FDF F622 uid [ expired] Ubuntu Debug Symbol Archive Automatic Signing Key (2016) Good output has no [date] in the pub line. [Where problems could occur] * At the moment the signature was bumped by one year * Meaning this issue will occur again in 2022 * Instead the key must be set to not expire & new round of SRUs issued [Other Info] * Original bug report The public key used by the debugging symbols repository /usr/share/keyrings/ubuntu-dbgsym-keyring.gpg from the package ubuntu- dbgsym-keyring expired. $ apt policy ubuntu-dbgsym-keyring ubuntu-dbgsym-keyring: Installed: 2020.02.11.2 Candidate: 2020.02.11.2 Version table: *** 2020.02.11.2 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://archive.ubuntu.com/ubuntu focal/main i386 Packages 100 /var/lib/dpkg/status $ gpg --no-default-keyring --keyring /usr/share/keyrings/ubuntu-dbgsym-keyring.gpg --list-keys /usr/share/keyrings/ubuntu-dbgsym-keyring.gpg - pub rsa4096 2016-03-21 [SC] [expired: 2021-03-20] F2EDC64DC5AEE1F6B9C621F0C8CAB6595FDFF622 uid [ expired] Ubuntu Debug Symbol Archive Automatic Signing Key (2016) Error message on "apt update": E: The repository 'http://ddebs.ubuntu.com bionic-updates Release' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. W: GPG error: http://ddebs.ubuntu.com bionic Release: The following signatures were invalid: EXPKEYSIG C8CAB6595FDFF622 Ubuntu Debug Symbol Archive Automatic Signing Key (2016) E: The repository 'http://ddebs.ubuntu.com bionic Release' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. W: GPG error: http://ddebs.ubuntu.com bionic-proposed Release: The following signatures were invalid: EXPKEYSIG C8CAB6595FDFF622 Ubuntu Debug Symbol Archive Automatic Signing Key (2016) E: The repository 'http://ddebs.ubuntu.com bionic-proposed Release' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1920640/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1975587] Re: systemd: fix test-execute autotest failure with kernel 5.15 in focal
Used systemd packaging repo's ./debian/git-cherry-pick and gbp dch + gbp
tag to convert the cherry-pick request into a typical looking systemd
sru backport.
Submitted merge proposal to https://code.launchpad.net/~ubuntu-core-
dev/ubuntu/+source/systemd/+git/systemd/+merge/429491
will ask for review and/or will upload it to proposed shortly.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1975587
Title:
systemd: fix test-execute autotest failure with kernel 5.15 in focal
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
In Progress
Bug description:
[Impact]
test-execute autotest is failing in focal with kernel 5.15. This is
because the following kernel commit changed the ABI for ioprio:
e70344c05995 ("block: fix default IO priority handling")
Previously setting IOPRIO_CLASS_NONE for a process would report
IOPRIO_CLASS_NONE back. But starting with 5.15 it reports
IOPRIO_CLASS_BE instead.
[Test case]
Run systemd autopkgtest and check for the test-execute result.
[Fix]
Change test/test-execute/exec-ioschedulingclass-none.service to
recognize both "none" and "best-effort" as valid returned strings from
ionice.
This change is already available in jammy and above.
[Regression potential]
We may see regressions in systemd autopkgtest, we won't introduce any
potential regressions in systemd itself, because this is only
affecting the specific unit test.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1975587/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966849] Re: gzip exec format error under WSL1
** Description changed: + [Impact] + + * Optimization features included in jammy cause atypical alignment of + LOAD ELF sections. This in turn causes failure to execute binaries on + WSL1. Upstream have since integrated the optimization features included + in jammy, but also reverted alignment to a previously used one. This + also results in working binary under WSL1. + + * Cherry-pick upstream applied revert to alignment to resolve running + gzip under WSL1. + + [Test Plan] + + * Use powershell to set default WSL version to 1 + + * Deploy WSL1, unpack and use updated gzip package + + * gzip --version should execute correctly under WSL 1 + + [Where problems could occur] + + * I cannot tell why performance improvement patches introduced + alignment change, and if revert of the alignment change affects the + performance. Note that this change aligns the codebase closer to what + kinetic & upstream now are. + + [Other Info] + + * This bug fix is upstream commit https://git.savannah.gnu.org/cgit/gzip.git/commit/gzip.c?id=23a870d14a49803c6d2579071886c1acf497c9d1 + + --- + gzip version 1.10-4ubuntu3 fails to run under WSL1 on Windows 19044.1620, making WSL pretty much unusable. bash: /usr/bin/gzip: cannot execute binary file: Exec format error ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gzip 1.10-4ubuntu3 ProcVersionSignature: Microsoft 4.4.0-19041.1237-Microsoft 4.4.35 Uname: Linux 4.4.0-19041-Microsoft x86_64 ApportVersion: 2.20.11-0ubuntu79 Architecture: amd64 CasperMD5CheckResult: unknown Date: Tue Mar 29 06:40:33 2022 ProcEnviron: - TERM=xterm-256color - PATH=(custom, no user) - LANG=pl_PL.UTF-8 - SHELL=/usr/bin/fish + TERM=xterm-256color + PATH=(custom, no user) + LANG=pl_PL.UTF-8 + SHELL=/usr/bin/fish SourcePackage: gzip UpgradeStatus: No upgrade log present (probably fresh install) ** Also affects: gzip (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: gzip (Ubuntu Kinetic) Importance: Undecided Status: Confirmed ** Changed in: gzip (Ubuntu Jammy) Status: New => In Progress ** Changed in: gzip (Ubuntu Kinetic) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1966849 Title: gzip exec format error under WSL1 Status in gzip: New Status in gzip package in Ubuntu: Fix Released Status in gzip source package in Jammy: In Progress Status in gzip source package in Kinetic: Fix Released Bug description: [Impact] * Optimization features included in jammy cause atypical alignment of LOAD ELF sections. This in turn causes failure to execute binaries on WSL1. Upstream have since integrated the optimization features included in jammy, but also reverted alignment to a previously used one. This also results in working binary under WSL1. * Cherry-pick upstream applied revert to alignment to resolve running gzip under WSL1. [Test Plan] * Use powershell to set default WSL version to 1 * Deploy WSL1, unpack and use updated gzip package * gzip --version should execute correctly under WSL 1 [Where problems could occur] * I cannot tell why performance improvement patches introduced alignment change, and if revert of the alignment change affects the performance. Note that this change aligns the codebase closer to what kinetic & upstream now are. [Other Info] * This bug fix is upstream commit https://git.savannah.gnu.org/cgit/gzip.git/commit/gzip.c?id=23a870d14a49803c6d2579071886c1acf497c9d1 --- gzip version 1.10-4ubuntu3 fails to run under WSL1 on Windows 19044.1620, making WSL pretty much unusable. bash: /usr/bin/gzip: cannot execute binary file: Exec format error ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gzip 1.10-4ubuntu3 ProcVersionSignature: Microsoft 4.4.0-19041.1237-Microsoft 4.4.35 Uname: Linux 4.4.0-19041-Microsoft x86_64 ApportVersion: 2.20.11-0ubuntu79 Architecture: amd64 CasperMD5CheckResult: unknown Date: Tue Mar 29 06:40:33 2022 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=pl_PL.UTF-8 SHELL=/usr/bin/fish SourcePackage: gzip UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gzip/+bug/1966849/+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 1958055] Re: sudo apport-kde is in a different design (stripped XDG_CURRENT_DESKTOP)
i wonder if things work fine if called with pkexec. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1958055 Title: sudo apport-kde is in a different design (stripped XDG_CURRENT_DESKTOP) Status in sudo package in Ubuntu: Confirmed Bug description: Running ubuntu-bug as normal user has the correct theme (see screenshots attached to bug #1881640), but running "sudo ubuntu-bug" has a different, non-matching theme (see attached screenshot). This problem can be reproduce by running a KDE application on Ubuntu Desktop (GNOME): 1. Launch ubuntu-22.04-desktop-amd64.iso 2. Install apport-kde 3. Run: /usr/share/apport/apport-kde -f 4. Run: sudo /usr/share/apport/apport-kde -f 5. Compare both windows. They have different icons and font size. Same result with KDE: 1. Use kubuntu-22.04-desktop-amd64.iso 2. Run ubuntu-bug -f 3. Run: sudo ubuntu-bug -f [Analysis] Qt needs XDG_CURRENT_DESKTOP to be set to determine the correct theme, but XDG_CURRENT_DESKTOP is not in the list of environment variables to preserve (and not in env_keep in /etc/sudoers). [Workaround] Prevent sudo from dropping XDG_CURRENT_DESKTOP by running: sudo XDG_CURRENT_DESKTOP=$XDG_CURRENT_DESKTOP /usr/share/apport/apport-kde -f ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: apport 2.20.9-0ubuntu7.27 ProcVersionSignature: Ubuntu 5.4.0-94.106~18.04.1-generic 5.4.157 Uname: Linux 5.4.0-94-generic i686 ApportVersion: 2.20.9-0ubuntu7.27 Architecture: i386 CurrentDesktop: KDE Date: Sun Jan 16 05:04:24 2022 InstallationDate: Installed on 2022-01-15 (0 days ago) InstallationMedia: Kubuntu 18.04.5 LTS "Bionic Beaver" - Release i386 (20200806.1) PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1958055/+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 1973733] Re: no change rebuild to get security update out on riscv64
There was another security upload on 27th of may which is built on all arches, thus this rebuild is no longer needed. please reject cups from focal unapproved. ** Changed in: cups (Ubuntu Focal) Status: In Progress => Fix Released ** Changed in: cups (Ubuntu Focal) Status: Fix Released => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1973733 Title: no change rebuild to get security update out on riscv64 Status in cups package in Ubuntu: Fix Released Status in cups source package in Focal: Invalid Bug description: no change rebuild to get riscv64 build out [Impact] * riscv64 build of cups security update failed, and then succeeded in groovy. See https://launchpad.net/ubuntu/+source/cups/2.3.1-9ubuntu1.1 * it means that focal-updates & focal-security are lacking a security update of cups on riscv64 * do a no change rebuild of cups as an SRU to get updated cups package out on focal [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * As usual, no change rebuilds of packages may introduce miss builds. [Other Info] * currently snap review tooling reports that cups has CVEs on riscv64 when one builds base:core20 snaps for riscv64. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1973733/+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 1973733] Re: no change rebuild to get security update out on riscv64
Ah - is it that the same version is now built and published in Groovy and we can't safely copy the binary backwards? => correct. I didn't check if we can or cannot safely copy the binary backwards, but imho we should not. This is not going via focal-security, because the security issue has already been fixed on all other arches, and riscv64 currently has best effort security support. I don't want to trigger cups security upgrade for $everyone, just because of the fix missing on riscv64 only. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1973733 Title: no change rebuild to get security update out on riscv64 Status in cups package in Ubuntu: Fix Released Status in cups source package in Focal: In Progress Bug description: no change rebuild to get riscv64 build out [Impact] * riscv64 build of cups security update failed, and then succeeded in groovy. See https://launchpad.net/ubuntu/+source/cups/2.3.1-9ubuntu1.1 * it means that focal-updates & focal-security are lacking a security update of cups on riscv64 * do a no change rebuild of cups as an SRU to get updated cups package out on focal [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * As usual, no change rebuilds of packages may introduce miss builds. [Other Info] * currently snap review tooling reports that cups has CVEs on riscv64 when one builds base:core20 snaps for riscv64. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1973733/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974056] Re: iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-bitwise_0 fails on s390x
** Tags added: rls-kk-incoming ** Description changed: In Ubuntu, we execute the full iptables shell testcases across all architectures. They seem to all pass everywhere, however iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless- bitwise_0 is currently failing on s390x like so: command17FAIL stderr: W: [FAILED] ././testcases/nft- only/0009-needless-bitwise_0: expected 0 but got 1 i wonder if there is some endian bug, as this is currently Ubuntu's only big-endian architecture. + + this can be reproduced with: + + pull-lp-source iptables + cd iptables-1.8.7/ + chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0 + cd iptables/tests/shell + sudo ./run-tests.sh --host -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1974056 Title: iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless- bitwise_0 fails on s390x Status in iptables: Unknown Status in iptables package in Ubuntu: New Bug description: In Ubuntu, we execute the full iptables shell testcases across all architectures. They seem to all pass everywhere, however iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless- bitwise_0 is currently failing on s390x like so: command17FAIL stderr: W: [FAILED] ././testcases/nft- only/0009-needless-bitwise_0: expected 0 but got 1 i wonder if there is some endian bug, as this is currently Ubuntu's only big-endian architecture. this can be reproduced with: pull-lp-source iptables cd iptables-1.8.7/ chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0 cd iptables/tests/shell sudo ./run-tests.sh --host To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1974056/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974056] [NEW] iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-bitwise_0 fails on s390x
Public bug reported: In Ubuntu, we execute the full iptables shell testcases across all architectures. They seem to all pass everywhere, however iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless- bitwise_0 is currently failing on s390x like so: command17FAIL stderr: W: [FAILED] ././testcases/nft- only/0009-needless-bitwise_0: expected 0 but got 1 i wonder if there is some endian bug, as this is currently Ubuntu's only big-endian architecture. ** Affects: iptables Importance: Unknown Status: Unknown ** Affects: iptables (Ubuntu) Importance: Undecided Status: New ** Tags: s390x ** Bug watch added: bugzilla.netfilter.org/ #1606 http://bugzilla.netfilter.org/show_bug.cgi?id=1606 ** Also affects: iptables via http://bugzilla.netfilter.org/show_bug.cgi?id=1606 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1974056 Title: iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless- bitwise_0 fails on s390x Status in iptables: Unknown Status in iptables package in Ubuntu: New Bug description: In Ubuntu, we execute the full iptables shell testcases across all architectures. They seem to all pass everywhere, however iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless- bitwise_0 is currently failing on s390x like so: command17FAIL stderr: W: [FAILED] ././testcases/nft- only/0009-needless-bitwise_0: expected 0 but got 1 i wonder if there is some endian bug, as this is currently Ubuntu's only big-endian architecture. To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1974056/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1973734] [NEW] FTBFS on riscv64 in focal
Public bug reported: [Impact] * FTBFS on riscv64 in focal in unittest of volume test * Disable that unit test, as later releases do not run unittests on riscv64, and it's better to have up to date pulseaudio on riscv64 (with many security fixes), even if it doesn't completely correctly work. [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * volume-test probably indicates that one can't set volume correctly on riscv64 ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: pulseaudio (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: pulseaudio (Ubuntu) Status: New => Fix Released ** Also affects: pulseaudio (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1973734 Title: FTBFS on riscv64 in focal Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: New Bug description: [Impact] * FTBFS on riscv64 in focal in unittest of volume test * Disable that unit test, as later releases do not run unittests on riscv64, and it's better to have up to date pulseaudio on riscv64 (with many security fixes), even if it doesn't completely correctly work. [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * volume-test probably indicates that one can't set volume correctly on riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1973734/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1973733] [NEW] no change rebuild to get security update out on riscv64
Public bug reported: no change rebuild to get riscv64 build out [Impact] * riscv64 build of cups security update failed, and then succeeded in groovy. See https://launchpad.net/ubuntu/+source/cups/2.3.1-9ubuntu1.1 * it means that focal-updates & focal-security are lacking a security update of cups on riscv64 * do a no change rebuild of cups as an SRU to get updated cups package out on focal [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * As usual, no change rebuilds of packages may introduce miss builds. [Other Info] * currently snap review tooling reports that cups has CVEs on riscv64 when one builds base:core20 snaps for riscv64. ** Affects: cups (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: cups (Ubuntu Focal) Importance: Undecided Status: In Progress ** Summary changed: - no change rebuild to get riscv64 build out + no change rebuild to get security update out on riscv64 ** Also affects: cups (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: cups (Ubuntu) Status: New => Fix Released ** Description changed: no change rebuild to get riscv64 build out [Impact] - * riscv64 build of cups security update failed, and then succeeded in groovy - * it means that focal-updates & focal-security are lacking a security update of cups on riscv64 - * do a no change rebuild of cups as an SRU to get updated cups package out on focal + * riscv64 build of cups security update failed, and then succeeded in groovy. See https://launchpad.net/ubuntu/+source/cups/2.3.1-9ubuntu1.1 + * it means that focal-updates & focal-security are lacking a security update of cups on riscv64 + * do a no change rebuild of cups as an SRU to get updated cups package out on focal [Test Plan] - * autopkgtests pass - * riscv64 build is successful + * autopkgtests pass + * riscv64 build is successful [Where problems could occur] - * As usual, no change rebuilds of packages may introduce miss builds. + * As usual, no change rebuilds of packages may introduce miss builds. [Other Info] - - * currently snap review tooling reports that cups has CVEs on riscv64 when one builds base:core20 snaps for riscv64. + + * currently snap review tooling reports that cups has CVEs on riscv64 + when one builds base:core20 snaps for riscv64. ** Changed in: cups (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1973733 Title: no change rebuild to get security update out on riscv64 Status in cups package in Ubuntu: Fix Released Status in cups source package in Focal: In Progress Bug description: no change rebuild to get riscv64 build out [Impact] * riscv64 build of cups security update failed, and then succeeded in groovy. See https://launchpad.net/ubuntu/+source/cups/2.3.1-9ubuntu1.1 * it means that focal-updates & focal-security are lacking a security update of cups on riscv64 * do a no change rebuild of cups as an SRU to get updated cups package out on focal [Test Plan] * autopkgtests pass * riscv64 build is successful [Where problems could occur] * As usual, no change rebuilds of packages may introduce miss builds. [Other Info] * currently snap review tooling reports that cups has CVEs on riscv64 when one builds base:core20 snaps for riscv64. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1973733/+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 1962332] Re: xenial systemd fails to start if unified-only (non-hybrid) cgroup2 is mounted on jammy hosts
I've attempted to prepare naive SRUs and it doesn't get me far yet. The issue is that unified cgroups2 support in xenial's systemd is rudimental, and falls apart very quickly with none of the xenial userspace expecting or able to work correctly with unified cgroups2 setup. I fear that it will not be practical to SRU systemd into xenial to resolve this. And users on Jammy that need to launch xenial containers should continue to switch their systems to hybrid cgroups setup by using `systemd.unified_cgroup_hierarchy=false` kernel command line option on their hosts. ** Summary changed: - xenial systemd fails to start if cgroup2 is mounted + xenial systemd fails to start if unified-only (non-hybrid) cgroup2 is mounted on jammy hosts ** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, - so this is fixed already in b and later. + so this is fixed already in b and later. However that patch alone is + insufficient, does not implement hybrid group setup, and breaks a lot of + xenial userspace expectations. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. - - [backported patch] - - the backported patch adds support to mount cgroup2 (new way) in addition - to the old way (cgroup + __DEVEL_ option) and also adds a fallback to do - that when mounting cgroups1 fails (because host is already using non- - hybrid v2 cgroups). This way the default behaviour remains the same, - apart from when trying to boot xenial on latest kernels and userspace - that opts into using cgroups2-only. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- 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/1962332 Title: xenial systemd fails to start if unified-only (non-hybrid) cgroup2 is mounted on jammy hosts Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Usually we try to avoid using embedded copies of code. Is it at all
possible to convert some of the affected packages to use/reuse a shared
library instead?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Incomplete
Status in bedtools package in Ubuntu:
New
Status in zlib package in Ubuntu:
Incomplete
Status in bedtools source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
New
Status in zlib source package in Impish:
New
Status in bedtools source package in Jammy:
New
Status in zlib source package in Jammy:
Incomplete
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, _len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected.
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
Reproduction: z15 only:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, _len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1961427/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. - [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. + [backported patch] + + the backported patch adds support to mount cgroup2 (new way) in addition + to the old way (cgroup + __DEVEL_ option) and also adds a fallback to do + that when mounting cgroups1 fails (because host is already using non- + hybrid v2 cgroups). This way the default behaviour remains the same, + apart from when trying to boot xenial on latest kernels and userspace + that opts into using cgroups2-only. + [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [backported patch] the backported patch adds support to mount cgroup2 (new way) in
[Touch-packages] [Bug 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft
And s390x =(
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1949603
Title:
iptables-save -c shows incorrect counters with iptables-nft
Status in iptables package in Ubuntu:
Fix Released
Status in iptables source package in Impish:
Fix Committed
Status in iptables source package in Jammy:
Fix Released
Bug description:
[Impact]
Starting with Impish I noticed that the kernel selftest xfrm_policy.sh
is always failing. Initially I thought it was a kernel issue, but
debugging further I found that the reason is that with Impish we're
using iptables-nft by default instead of iptables-legacy.
This test (./tools/testing/selftests/net/xfrm_policy.sh in the kernel
source directory) is creating a bunch of network namespaces and
checking the iptables counters for the defined policies, in particular
this is the interesting part:
check_ipt_policy_count()
{
ns=$1
ip netns exec $ns iptables-save -c |grep policy | ( read c rest
ip netns exec $ns iptables -Z
if [ x"$c" = x'[0:0]' ]; then
exit 0
elif [ x"$c" = x ]; then
echo "ERROR: No counters"
ret=1
exit 111
else
exit 1
fi
)
}
If I use iptables-nft the counters are never [0:0] as they should be,
so the test is failing. With iptables-legacy they are [0:0] and the
test is passing.
[Test case]
tools/testing/selftests/net/xfrm_policy.sh from the Linux kernel
source code.
[Fix]
Apply iptables upstream commit:
5f1fcace ("iptables-nft: fix -Z option")
In this way also with iptables-nft the counters are reported
correctly.
[Regression potential]
We may require other upstream commits now that the -Z option is
working properly with iptables-nft.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1949603/+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 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft
The newly enabled autopkgtest appears to regress on i386 =/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1949603
Title:
iptables-save -c shows incorrect counters with iptables-nft
Status in iptables package in Ubuntu:
Fix Released
Status in iptables source package in Impish:
Fix Committed
Status in iptables source package in Jammy:
Fix Released
Bug description:
[Impact]
Starting with Impish I noticed that the kernel selftest xfrm_policy.sh
is always failing. Initially I thought it was a kernel issue, but
debugging further I found that the reason is that with Impish we're
using iptables-nft by default instead of iptables-legacy.
This test (./tools/testing/selftests/net/xfrm_policy.sh in the kernel
source directory) is creating a bunch of network namespaces and
checking the iptables counters for the defined policies, in particular
this is the interesting part:
check_ipt_policy_count()
{
ns=$1
ip netns exec $ns iptables-save -c |grep policy | ( read c rest
ip netns exec $ns iptables -Z
if [ x"$c" = x'[0:0]' ]; then
exit 0
elif [ x"$c" = x ]; then
echo "ERROR: No counters"
ret=1
exit 111
else
exit 1
fi
)
}
If I use iptables-nft the counters are never [0:0] as they should be,
so the test is failing. With iptables-legacy they are [0:0] and the
test is passing.
[Test case]
tools/testing/selftests/net/xfrm_policy.sh from the Linux kernel
source code.
[Fix]
Apply iptables upstream commit:
5f1fcace ("iptables-nft: fix -Z option")
In this way also with iptables-nft the counters are reported
correctly.
[Regression potential]
We may require other upstream commits now that the -Z option is
working properly with iptables-nft.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1949603/+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 1933491] Re: kmod add zstd support
# dpkg-query -W kmod kmod27-1ubuntu2 # modinfo ./zstd.ko.zst modinfo: ERROR: Module alias ./zstd.ko.zst not found. upgraded to new kmod: # dpkg-query -W kmod kmod27-1ubuntu2.1 # modinfo ./zstd.ko.zst filename: /lib/modules/5.4.0-109-generic/kernel/crypto/./zstd.ko.zst alias: crypto-zstd alias: zstd description:Zstd Compression Algorithm license:GPL srcversion: C007A20DBED7E012AF5A0A8 depends:zstd_compress retpoline: Y intree: Y name: zstd vermagic: 5.4.0-109-generic SMP mod_unload modversions sig_id: PKCS#7 signer: Build time autogenerated kernel key sig_key:2E:88:51:F0:25:CE:CD:BB:F2:FC:76:4E:F5:71:F2:A4:3F:3E:DC:F3 sig_hashalgo: sha512 signature: 62:91:50:E8:5F:FA:96:05:E8:CA:F4:9F:03:0A:5A:56:04:02:37:2D: 06:56:A8:A7:40:02:95:61:78:5F:F3:73:8B:EB:EA:FB:62:F6:B1:B7: 68:4F:A7:87:88:44:E1:85:41:C9:ED:BB:CD:34:02:A1:3E:7A:9A:E8: D8:24:84:94:64:D3:9F:FE:A7:3A:91:10:F3:90:B1:E7:71:25:26:BA: B8:CE:B8:59:E1:B9:DD:C0:0C:82:E3:9B:96:CF:E5:DB:BD:8F:77:11: 87:E4:BB:BC:84:57:49:A3:D8:CE:D6:33:25:86:35:50:67:B5:0A:13: 26:08:4D:66:E9:97:70:B5:F6:87:69:D2:89:EA:2A:40:38:30:88:AA: AD:ED:6C:0A:51:1E:62:E4:F1:13:47:8F:0B:AF:FB:53:A9:74:82:52: 78:53:F2:8D:4D:DB:15:5C:76:4F:9A:77:C0:7F:6E:87:16:B3:DB:FD: C7:D6:C6:8E:14:D1:A6:F0:0B:03:4C:33:68:E8:75:29:93:E6:4F:AE: 43:6D:90:4D:32:4B:A1:42:C1:AD:99:7C:C3:E2:B9:48:E6:F5:0D:DF: 2F:09:C2:46:A6:98:55:47:16:92:EF:28:AB:41:9E:4D:E8:03:2C:21: AF:21:CD:13:1D:C5:A3:FE:03:99:12:03:88:9E:65:1A:82:85:2B:71: DD:EB:F8:7E:C3:B8:84:A1:AD:25:25:DC:FD:58:77:1A:CE:EA:F8:04: C2:E1:DF:AB:A1:17:00:26:96:E5:FA:3F:84:CC:98:ED:31:E2:A0:2F: E6:7D:20:13:D1:57:8C:AA:74:2D:04:7C:48:34:E0:7B:DF:3C:F6:66: 4D:7A:E9:EF:5D:ED:66:7D:87:D6:98:2F:F7:92:3F:C7:CD:16:7B:D0: CE:B4:5B:A3:D9:9A:79:72:23:47:49:E0:69:B2:ED:44:E8:7F:7C:D6: 12:BB:66:A7:5E:F6:0D:2C:9B:7B:DA:8E:76:A9:66:B1:71:44:12:30: 83:DB:09:EE:4C:28:93:BD:50:51:E5:67:C3:B3:79:1C:27:86:82:02: 21:B9:EB:59:54:99:A9:93:02:D3:32:F5:D0:43:05:62:ED:C6:E9:4B: F9:09:9D:40:A2:83:74:25:65:30:BF:59:3A:42:64:28:94:9C:34:79: 42:59:81:22:CE:D0:80:56:A4:65:F8:A0:11:20:0F:A9:F2:F6:52:8C: D1:04:F6:D8:09:D0:D4:66:6E:21:12:AB:68:FD:34:1C:59:AF:9F:E9: AD:5C:A5:6F:AC:51:80:41:4C:62:28:A1:51:5B:C9:E0:C1:17:44:F1: A2:92:1E:39:00:07:96:E6:90:D9:CC:94 ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1933491 Title: kmod add zstd support Status in kmod package in Ubuntu: Fix Released Status in kmod source package in Focal: Fix Committed Status in kmod source package in Impish: Fix Released Status in kmod source package in Jammy: Fix Released Status in kmod package in Debian: New Bug description: [Impact] * To safe diskspace, upcoming devel series / hwe kernels may turn on zstd kernel module compression. Kmod since impish support zstd support. But in order to keep hwe kernels at parity, or allow inspecting jammy modules from focal host, it would be beneficial for kmod in focal to support zstd compressed modules. [Test Plan] * Pick any kernel module * Compress it with zstd: $ zstd *.ko * Check that modinfo can read it: $ modinfo *.ko.zst [Where problems could occur] * kmod will gain a new dependecy on libzstd1, however it should already be present, because dpkg in focal depends on libzstd1 already. * initramfs-tools already supports compressed modules, but in focal at the moment it does so in an inefficient manner (regresses bootspeed), this has been improved in https://launchpad.net/ubuntu/+source/initramfs-tools/0.140ubuntu8 and is yet to be SRUed into Focal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1933491/+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 1933491] Re: kmod add zstd support
initramfs-tools ADT test passed on retry. the kernel tests mentioned above are now for EOL kernels that have since all rolled to 5.13. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1933491 Title: kmod add zstd support Status in kmod package in Ubuntu: Fix Released Status in kmod source package in Focal: Fix Committed Status in kmod source package in Impish: Fix Released Status in kmod source package in Jammy: Fix Released Status in kmod package in Debian: New Bug description: [Impact] * To safe diskspace, upcoming devel series / hwe kernels may turn on zstd kernel module compression. Kmod since impish support zstd support. But in order to keep hwe kernels at parity, or allow inspecting jammy modules from focal host, it would be beneficial for kmod in focal to support zstd compressed modules. [Test Plan] * Pick any kernel module * Compress it with zstd: $ zstd *.ko * Check that modinfo can read it: $ modinfo *.ko.zst [Where problems could occur] * kmod will gain a new dependecy on libzstd1, however it should already be present, because dpkg in focal depends on libzstd1 already. * initramfs-tools already supports compressed modules, but in focal at the moment it does so in an inefficient manner (regresses bootspeed), this has been improved in https://launchpad.net/ubuntu/+source/initramfs-tools/0.140ubuntu8 and is yet to be SRUed into Focal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1933491/+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 1940528] Re: curl 7.68 does not init OpenSSL correctly
1) downgraded openssl to 1.1.1f-1ubuntu2.9 such that it doesn't have double free fix that was released in https://launchpad.net/ubuntu/+source/openssl/1.1.1f-1ubuntu2.10 2) installed old pka module from commit b0f32fa05298bf9e3997ea43fc1c11b90e0d662f 3) installed focal-updates version of curl Observed double free core dump: # dpkg-query -W | grep -e 1.1.1f -e curl -e pka curl7.68.0-1ubuntu2.7 libcurl3-gnutls:arm64 7.68.0-1ubuntu2.7 libcurl4:arm64 7.68.0-1ubuntu2.7 libpka1:arm64 1.3-1 libssl-dev:arm641.1.1f-1ubuntu2.9 libssl1.1:arm64 1.1.1f-1ubuntu2.9 openssl 1.1.1f-1ubuntu2.9 # curl -o /dev/null https://start.ubuntu.com/connectivity-check.html % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance 100 576 100 5760 0 2117 0 --:--:-- --:--:-- --:--:-- 2117 double free or corruption (out) Aborted (core dumped) Upgraded to new curl: # dpkg-query -W | grep -e 1.1.1f -e curl -e pka curl7.68.0-1ubuntu2.8 libcurl3-gnutls:arm64 7.68.0-1ubuntu2.8 libcurl4:arm64 7.68.0-1ubuntu2.8 libpka1:arm64 1.3-1 libssl-dev:arm641.1.1f-1ubuntu2.9 libssl1.1:arm64 1.1.1f-1ubuntu2.9 openssl 1.1.1f-1ubuntu2.9 # curl -o /dev/null https://start.ubuntu.com/connectivity-check.html % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance 100 576 100 5760 0 1894 0 --:--:-- --:--:-- --:--:-- 1888 Observed success without any double-free or segfault in openssl. Although this particular issue has already been fixed in openssl, it still makes sense to release this update of curl which includes correct openssl engine API usage. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1940528 Title: curl 7.68 does not init OpenSSL correctly Status in curl package in Ubuntu: Fix Released Status in curl source package in Bionic: New Status in curl source package in Focal: Fix Committed Bug description: [Impact] * curl 7.68 does not correctly use OpenSSL 1.1.0+ api to init OpenSSL global state prior to executing any OpenSSL APIs. This may lead to duplicate engine initiation, which upon engine unload may cause use- after-free or double-free of any methods that engine installs. This has been fixed in curl 7.74 by correctly calling OpenSSL init api prior to any other calls to OpenSSL apis. [Test Plan] * This should be reproducible with any engines that allocate & register methods, and free them upon engine unload. Then use curl with openssl backend to test for corrupted stack. * I.e. on arm64, compile and configure pka engine from https://github.com/Mellanox/pka/commit/b0f32fa05298bf9e3997ea43fc1c11b90e0d662f (i.e. without the double-free protections proposed in https://github.com/Mellanox/pka/pull/37 ) on any arm64 hardware, there is no need for the engine to actually work or have access to anything, as the issue is reproducible when engine is enabled but cannot be effectively used. * curl any https website ... PKA_DEV: pka_dev_open_ring_vfio: error: failed to get ring 50 device name PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance 100 338 100 3380 0 3520 0 --:--:-- --:--:-- --:--:-- 3520 (exit status 0) is good output from fixed curl. Whereas: PKA_ENGINE: PKA instance is invalid PKA_ENGINE: failed to retrieve valid instance 100 338 100 3380 0 1169 0 --:--:-- --:--:-- --:--:-- 1169 Segmentation fault (core dumped) (exit status non-zero) is bad output from currently broken curl. [Where problems could occur] * Correctly calling OpenSSL init function prior to any other OpenSSL apis
[Touch-packages] [Bug 1968912] Re: vim.tiny reports 'E1187: Failed to source defaults.vim' on execution in default install
It seems that view, as provided by vim.tiny now attempts to load defaults.vim, which is shipped in the large vim-runtime package. All vims depend on vim-common. It would seem to me that we should move defaults.vim from vim-runtime to vim-common. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to vim in Ubuntu. https://bugs.launchpad.net/bugs/1968912 Title: vim.tiny reports 'E1187: Failed to source defaults.vim' on execution in default install Status in vim package in Ubuntu: New Bug description: Ubuntu 22.04 When running vim.tiny it says: $ vim.tiny E1187: Failed to source defaults.vim Press ENTER or type command to continue This is due to the defaults.vim file not being available. If you just run it as vi $ vi this message does not appear as vim.tiny runs in compatibility mode. I found mention of this issue in: https://github.com/grml/grml-etc-core/issues/99 The defaults.vim file is provided by the package vim-runtime. I'm unsure what the issue is, if something needs to be in /etc/vim/vimrc.tiny or a /etc/vim/vimrc needs to be provided dpkg claims vimrc is in vim-common, but no file is installed for me from that package, or if vim-runtime needs to be a required package for vim-tiny $ dpkg -S /etc/vim/vimrc vim-common: /etc/vim/vimrc $ ls -al /etc/vim/vimrc ls: cannot access '/etc/vim/vimrc': No such file or directory I discovered this because my .selected-editor was vim.tiny after running crontab -e $ crontab -e Select an editor. To change later, run 'select-editor'. 1. /bin/nano< easiest 2. /usr/bin/vim.tiny 3. /bin/ed ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: vim-tiny 2:8.2.3995-1ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-1005.5-raspi 5.15.30 Uname: Linux 5.15.0-1005-raspi aarch64 ApportVersion: 2.20.11-0ubuntu81 Architecture: arm64 CasperMD5CheckResult: unknown Date: Wed Apr 13 11:56:35 2022 ImageMediaBuild: 20201022 ProcEnviron: TERM=screen PATH=(custom, no user) LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: vim UpgradeStatus: Upgraded to jammy on 2022-04-09 (4 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1968912/+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 1967593] Re: kernel modules going missing after reboot
** Also affects: ubuntu-meta (Ubuntu) Importance: Undecided Status: New ** Changed in: ubuntu-meta (Ubuntu) Importance: Undecided => Critical ** Changed in: ubuntu-meta (Ubuntu) Milestone: None => ubuntu-22.04 ** Tags added: rls-ff-incoming ** Tags removed: rls-ff-incoming ** Tags added: rls-jj-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1967593 Title: kernel modules going missing after reboot Status in cloud-initramfs-tools package in Ubuntu: Confirmed Status in linux-kvm package in Ubuntu: New Status in linux-lowlatency package in Ubuntu: New Status in ubuntu-meta package in Ubuntu: New Bug description: EDIT: There are no accurate results in the package search, but it is for the kernel shown below Linux 5.15.0-23-generic x86_64. Also for the low latency kernel and other versions 5.4, 5.13, 5.14, 5.17. So it is not kernel specific. It must be a problem with configuration, but reinstalling doesnt fix it. EDIT2: it turns out this is caused by the cloud-initramfs-copymods package mounting over modules locations. Removed it and reinstalled kernel modules package (extras didnt seem necessary, but probably prudent too). This affects several different kernels I've tried in 22.04. This post basically sums it up: https://unix.stackexchange.com/questions/405146/removed-lib-modules-folder-after-every-reboot detailed answer: https://unix.stackexchange.com/a/499580/346155 And this one from upgrading from 20.04 to 22.04: https://askubuntu.com/questions/1400470/kernel-module-not-getting-installed-after-upgrade Basically, for some reason the kernel modules are being mounted over after reboot. My image was built on top of a cloud-init image, but removing the recommeded package "cloud-initramfs-copymods" that mounts over modules didnt work for me. Adding the snd_hda_intel module to the boot config /etc/initramfs-tools/modules did fix my issue for this module. But how many others will not be available? --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu80 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: user 2189 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: KDE DistroRelease: Ubuntu 22.04 IwConfig: lono wireless extensions. enp1s0no wireless extensions. virbr0no wireless extensions. Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) Package: linux (not installed) ProcFB: 0 virtio_gpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-23-generic root=UUID=5d51cbd2-a1de-48f6-b8b6-00709c787fa0 ro ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27 RelatedPackageVersions: linux-restricted-modules-5.15.0-23-generic N/A linux-backports-modules-5.15.0-23-generic N/A linux-firmware 20220329.git681281e4-0ubuntu1 RfKill: Tags: jammy uec-images Uname: Linux 5.15.0-23-generic x86_64 UpgradeStatus: Upgraded to jammy on 2022-04-01 (1 days ago) UserGroups: libvirt sudo WifiSyslog: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.release: 0.0 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2:sku: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu80 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: user 2189 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: KDE DistroRelease: Ubuntu 22.04 IwConfig: lono wireless extensions. enp1s0no wireless extensions. virbr0no wireless extensions. Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device
[Touch-packages] [Bug 1949603] Re: iptables-save -c shows incorrect counters with iptables-nft
** Changed in: iptables (Ubuntu Impish)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1949603
Title:
iptables-save -c shows incorrect counters with iptables-nft
Status in iptables package in Ubuntu:
Fix Released
Status in iptables source package in Impish:
In Progress
Status in iptables source package in Jammy:
Fix Released
Bug description:
[Impact]
Starting with Impish I noticed that the kernel selftest xfrm_policy.sh
is always failing. Initially I thought it was a kernel issue, but
debugging further I found that the reason is that with Impish we're
using iptables-nft by default instead of iptables-legacy.
This test (./tools/testing/selftests/net/xfrm_policy.sh in the kernel
source directory) is creating a bunch of network namespaces and
checking the iptables counters for the defined policies, in particular
this is the interesting part:
check_ipt_policy_count()
{
ns=$1
ip netns exec $ns iptables-save -c |grep policy | ( read c rest
ip netns exec $ns iptables -Z
if [ x"$c" = x'[0:0]' ]; then
exit 0
elif [ x"$c" = x ]; then
echo "ERROR: No counters"
ret=1
exit 111
else
exit 1
fi
)
}
If I use iptables-nft the counters are never [0:0] as they should be,
so the test is failing. With iptables-legacy they are [0:0] and the
test is passing.
[Test case]
tools/testing/selftests/net/xfrm_policy.sh from the Linux kernel
source code.
[Fix]
Apply iptables upstream commit:
5f1fcace ("iptables-nft: fix -Z option")
In this way also with iptables-nft the counters are reported
correctly.
[Regression potential]
We may require other upstream commits now that the -Z option is
working properly with iptables-nft.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1949603/+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 1965293] Re: systemd/248.3-1ubuntu8.2 ADT test failure (tests-in-lxd) with linux/5.13.0-37.42
** Tags added: rls-ii-incoming ** Tags added: rls-jj-incoming -- 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/1965293 Title: systemd/248.3-1ubuntu8.2 ADT test failure (tests-in-lxd) with linux/5.13.0-37.42 Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Status in linux source package in Impish: Incomplete Status in systemd source package in Impish: New Bug description: This is a scripted bug report about ADT failures while running systemd tests for linux/5.13.0-37.42 on impish. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/s/systemd/20220317_104248_4bc6b@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/arm64/s/systemd/20220316_141606_ab727@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/s/systemd/20220317_110143_b6ced@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/s/systemd/20220317_103032_3d4bf@/log.gz The "tests-in-lxd" testcase is failing with all kernels in Impish: test_no_failed (__main__.ServicesTest) No failed units ... journal for failed service snap-lxd-22662.mount --- -- Journal begins at Thu 2022-03-17 09:54:14 UTC, ends at Thu 2022-03-17 10:01:49 UTC. -- Mar 17 10:01:43 autopkgtest-lxd-oolwau systemd[1]: Mounting Mount unit for lxd, revision 22662... Mar 17 10:01:43 autopkgtest-lxd-oolwau mount[91]: mount: /snap/lxd/22662: mount failed: Operation not permitted. Mar 17 10:01:43 autopkgtest-lxd-oolwau systemd[1]: snap-lxd-22662.mount: Mount process exited, code=exited, status=1/FAILURE Mar 17 10:01:43 autopkgtest-lxd-oolwau systemd[1]: snap-lxd-22662.mount: Failed with result 'exit-code'. Mar 17 10:01:43 autopkgtest-lxd-oolwau systemd[1]: Failed to mount Mount unit for lxd, revision 22662. journal for failed service snap-snapd-15177.mount --- -- Journal begins at Thu 2022-03-17 09:54:14 UTC, ends at Thu 2022-03-17 10:01:49 UTC. -- Mar 17 10:01:43 autopkgtest-lxd-oolwau systemd[1]: Mounting Mount unit for snapd, revision 15177... Mar 17 10:01:43 autopkgtest-lxd-oolwau mount[92]: mount: /snap/snapd/15177: mount failed: Operation not permitted. Mar 17 10:01:43 autopkgtest-lxd-oolwau systemd[1]: snap-snapd-15177.mount: Mount process exited, code=exited, status=1/FAILURE Mar 17 10:01:43 autopkgtest-lxd-oolwau systemd[1]: snap-snapd-15177.mount: Failed with result 'exit-code'. Mar 17 10:01:43 autopkgtest-lxd-oolwau systemd[1]: Failed to mount Mount unit for snapd, revision 15177. FAIL [...] == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.HBv169/build.sBq/real-tree/debian/tests/boot-and-services", line 69, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['snap-lxd-22662.mount loaded failed fai[119 chars]177'] != [] First list contains 2 additional elements. First extra element 0: 'snap-lxd-22662.mount loaded failed failed Mount unit for lxd, revision 22662' + [] - ['snap-lxd-22662.mount loaded failed failed Mount unit for lxd, revision ' - '22662', - 'snap-snapd-15177.mount loaded failed failed Mount unit for snapd, revision ' - '15177'] This testcase started to fail with the latest re-spin of the kernels (uploaded on mar-16), however the only patch applied between the previous kernels and the current ones is a CVE fix which is unlikely to be causing this failure: "ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()" https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/impish/commit/?id=da5043b3ed2889300211ba35d5a7d2f3b9255d1b To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1965293/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
Backporting 099619957a0 to xenial will mean that systemd will gain ability to use cgroups2 as shipped in the xenial's ga v4.4 kernel. it will mean that xenial containers on top of bionic's ga kernel will fail to use cgroups2. however at the time it was an experimental feature which was not widely used at all, and there are likely to be very few users of it. it would be nice to if backport of 099619957a0 was done in a backwards- compatible way and allow using cgroups2 like code paths using both pre-v4.4 and v4.4+ kernels. -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. + + [workaround] + On Jammy host edit default kernel command line to include + + systemd.unified_cgroup_hierarchy=false + + update your bootloader configuration; and reboot + + then hybrid cgroups will be on the host, and one can launch xenial + container then. + [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
hm, $ lxc launch --vm ubuntu:xenial fails for me ** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. - - [workaround] - - Instead of: - $ lxc launch ubuntu:xenial - - use: - $ lxc launch --vm ubuntu:xenial - - Until this is fixed. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. + + [workaround] + + Instead of: + $ lxc launch ubuntu:xenial + + use: + $ lxc launch --vm ubuntu:xenial + + Until this is fixed. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] Instead of: $ lxc launch ubuntu:xenial use: $ lxc launch --vm ubuntu:xenial Until this is fixed. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
Irrespective of ESM status, we have always had extremely long support overlaps both backwards and forwards between ubuntu releases. At the moment, my only solution is to use lxd vms; i.e. do $ lxc launch --vm ubuntu:xenial However, I say for the sake of ease of development, testing, upgrades, migration, and bug hunting we should support xenial lxd on jammy, irrespective of xenial's status, especially since trusty lxd on jammy still works. ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] Instead of: $ lxc launch ubuntu:xenial use: $ lxc launch --vm ubuntu:xenial Until this is fixed. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1959085] Re: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption
On 21.10, zfs-linux packages 2.0.6-1ubuntu2 generate incorrect boot entries for snapshoted systems, please upgrade to 2.0.6-1ubuntu2.1. Snapshots created with the broken old version are not bootable. ** Changed in: zfs-linux (Ubuntu) Status: Incomplete => Fix Released ** Changed in: ubuntu-cdimage 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/1959085 Title: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption Status in Ubuntu CD Images: Fix Released Status in initramfs-tools package in Ubuntu: Invalid Status in zfs-linux package in Ubuntu: Fix Released Bug description: Hi, I just installed the latest Ubuntu desktop from iso file ubuntu-21.10-desktop-amd64.iso inside of VMWare workstation. I chose ZFS and native ZFS encryption of the filesystem. The installation went fine. Everything worked as expected. Then I upgraded the packages to the latest version via the Software updater. After reboot I'm stuck in the initramfs prompt. The following command fails: mount -o zfsutil -t zfs rpool/ROOT/ubuntu_gtw63h /root// Permission denied. And the system never asks me for the password to unlock the root fs. So, I'm guessing that there is something wrong with the new initramfs disk: initrd.img-5.13.0-27-generic When I reboot and select the previous version in grub: initrd.img-5.13.0-27-generic, the system asks for the password and boots without a problem. Thanks. To summarize: 1. Installed new VM using the Ubuntu iso image. Chose ZFS native encryption. Minimal install. 2. As soon as the system came up, I hit the update/upgrade prompt. Rebooted and failed to boot the new version. I didn't customize anything or installed anything extra. root@ubud01:/var# lsb_release -rd Description: Ubuntu 21.10 Release: 21.10 root@ubud01:/var# dpkg -l | grep zfs ii libzfs4linux 2.0.6-1ubuntu2 amd64OpenZFS filesystem library for Linux ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs ii zfs-zed2.0.6-1ubuntu2 amd64OpenZFS Event Daemon ii zfsutils-linux 2.0.6-1ubuntu2 amd64command-line tools to manage OpenZFS filesystems root@ubud01:/var# dpkg -l | grep init ii busybox-initramfs 1:1.30.1-6ubuntu3.1 amd64Standalone shell setup for initramfs ii cryptsetup-initramfs 2:2.3.6-0ubuntu1 all disk encryption support - initramfs integration ii gnome-initial-setup40.4-1ubuntu1 amd64Initial GNOME system setup helper ii init 1.60build1 amd64metapackage ensuring an init system is installed ii init-system-helpers1.60build1 all helper tools for all init systems ii initramfs-tools0.140ubuntu6 all generic modular initramfs generator (automation) ii initramfs-tools-bin0.140ubuntu6 amd64binaries used by initramfs-tools ii initramfs-tools-core 0.140ubuntu6 all generic modular initramfs generator (core tools) ii libatopology2:amd641.2.4-1.1ubuntu3.1 amd64shared library for handling ALSA topology definitions ii libklibc:amd64 2.0.8-6.1ubuntu2 amd64minimal libc subset for use with initramfs ii lsb-base 11.1.0ubuntu3 all Linux Standard Base init script functionality ii ncurses-base 6.2+20201114-2build1 all basic terminal type definitions ii sysvinit-utils 2.96-7ubuntu1 amd64System-V-like utilities ii xinit 1.4.1-0ubuntu3 amd64X server initialisation tool ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs root@ubud01:/var# zfs list NAME USED AVAIL REFER
[Touch-packages] [Bug 1959085] Re: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption
Ubuntu 22.04 daily images testing issues have been resolved and a new image promoted, jammy installs are now working correctly. -- 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/1959085 Title: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption Status in Ubuntu CD Images: Confirmed Status in initramfs-tools package in Ubuntu: Invalid Status in zfs-linux package in Ubuntu: Incomplete Bug description: Hi, I just installed the latest Ubuntu desktop from iso file ubuntu-21.10-desktop-amd64.iso inside of VMWare workstation. I chose ZFS and native ZFS encryption of the filesystem. The installation went fine. Everything worked as expected. Then I upgraded the packages to the latest version via the Software updater. After reboot I'm stuck in the initramfs prompt. The following command fails: mount -o zfsutil -t zfs rpool/ROOT/ubuntu_gtw63h /root// Permission denied. And the system never asks me for the password to unlock the root fs. So, I'm guessing that there is something wrong with the new initramfs disk: initrd.img-5.13.0-27-generic When I reboot and select the previous version in grub: initrd.img-5.13.0-27-generic, the system asks for the password and boots without a problem. Thanks. To summarize: 1. Installed new VM using the Ubuntu iso image. Chose ZFS native encryption. Minimal install. 2. As soon as the system came up, I hit the update/upgrade prompt. Rebooted and failed to boot the new version. I didn't customize anything or installed anything extra. root@ubud01:/var# lsb_release -rd Description: Ubuntu 21.10 Release: 21.10 root@ubud01:/var# dpkg -l | grep zfs ii libzfs4linux 2.0.6-1ubuntu2 amd64OpenZFS filesystem library for Linux ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs ii zfs-zed2.0.6-1ubuntu2 amd64OpenZFS Event Daemon ii zfsutils-linux 2.0.6-1ubuntu2 amd64command-line tools to manage OpenZFS filesystems root@ubud01:/var# dpkg -l | grep init ii busybox-initramfs 1:1.30.1-6ubuntu3.1 amd64Standalone shell setup for initramfs ii cryptsetup-initramfs 2:2.3.6-0ubuntu1 all disk encryption support - initramfs integration ii gnome-initial-setup40.4-1ubuntu1 amd64Initial GNOME system setup helper ii init 1.60build1 amd64metapackage ensuring an init system is installed ii init-system-helpers1.60build1 all helper tools for all init systems ii initramfs-tools0.140ubuntu6 all generic modular initramfs generator (automation) ii initramfs-tools-bin0.140ubuntu6 amd64binaries used by initramfs-tools ii initramfs-tools-core 0.140ubuntu6 all generic modular initramfs generator (core tools) ii libatopology2:amd641.2.4-1.1ubuntu3.1 amd64shared library for handling ALSA topology definitions ii libklibc:amd64 2.0.8-6.1ubuntu2 amd64minimal libc subset for use with initramfs ii lsb-base 11.1.0ubuntu3 all Linux Standard Base init script functionality ii ncurses-base 6.2+20201114-2build1 all basic terminal type definitions ii sysvinit-utils 2.96-7ubuntu1 amd64System-V-like utilities ii xinit 1.4.1-0ubuntu3 amd64X server initialisation tool ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs root@ubud01:/var# zfs list NAME USED AVAIL REFER MOUNTPOINT bpool 290M 542M 96K /boot bpool/BOOT 289M 542M 96K none bpool/BOOT/ubuntu_gtw63h
[Touch-packages] [Bug 1959085] Re: Ubuntu 21.10 boot stuck in initramfs
This is fixed release in pending images; which are failing installation due to other bugs. Once those bugs are resolved, and a new image is promoted, it shouldn't experience this zfs issue. So we are blocked on getting Ubuntu Desktop ISO passing the daily automated testing and getting promoted. I will separately double check that the upgrade path works correctly. ** Also affects: ubuntu-cdimage Importance: Undecided Status: New ** Changed in: zfs-linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: initramfs-tools (Ubuntu) Status: Confirmed => Invalid ** Changed in: ubuntu-cdimage Status: New => Confirmed ** Changed in: zfs-linux (Ubuntu) Status: Invalid => Incomplete ** Summary changed: - Ubuntu 21.10 boot stuck in initramfs + Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption -- 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/1959085 Title: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption Status in Ubuntu CD Images: Confirmed Status in initramfs-tools package in Ubuntu: Invalid Status in zfs-linux package in Ubuntu: Incomplete Bug description: Hi, I just installed the latest Ubuntu desktop from iso file ubuntu-21.10-desktop-amd64.iso inside of VMWare workstation. I chose ZFS and native ZFS encryption of the filesystem. The installation went fine. Everything worked as expected. Then I upgraded the packages to the latest version via the Software updater. After reboot I'm stuck in the initramfs prompt. The following command fails: mount -o zfsutil -t zfs rpool/ROOT/ubuntu_gtw63h /root// Permission denied. And the system never asks me for the password to unlock the root fs. So, I'm guessing that there is something wrong with the new initramfs disk: initrd.img-5.13.0-27-generic When I reboot and select the previous version in grub: initrd.img-5.13.0-27-generic, the system asks for the password and boots without a problem. Thanks. To summarize: 1. Installed new VM using the Ubuntu iso image. Chose ZFS native encryption. Minimal install. 2. As soon as the system came up, I hit the update/upgrade prompt. Rebooted and failed to boot the new version. I didn't customize anything or installed anything extra. root@ubud01:/var# lsb_release -rd Description: Ubuntu 21.10 Release: 21.10 root@ubud01:/var# dpkg -l | grep zfs ii libzfs4linux 2.0.6-1ubuntu2 amd64OpenZFS filesystem library for Linux ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs ii zfs-zed2.0.6-1ubuntu2 amd64OpenZFS Event Daemon ii zfsutils-linux 2.0.6-1ubuntu2 amd64command-line tools to manage OpenZFS filesystems root@ubud01:/var# dpkg -l | grep init ii busybox-initramfs 1:1.30.1-6ubuntu3.1 amd64Standalone shell setup for initramfs ii cryptsetup-initramfs 2:2.3.6-0ubuntu1 all disk encryption support - initramfs integration ii gnome-initial-setup40.4-1ubuntu1 amd64Initial GNOME system setup helper ii init 1.60build1 amd64metapackage ensuring an init system is installed ii init-system-helpers1.60build1 all helper tools for all init systems ii initramfs-tools0.140ubuntu6 all generic modular initramfs generator (automation) ii initramfs-tools-bin0.140ubuntu6 amd64binaries used by initramfs-tools ii initramfs-tools-core 0.140ubuntu6 all generic modular initramfs generator (core tools) ii libatopology2:amd641.2.4-1.1ubuntu3.1 amd64shared library for handling ALSA topology definitions ii libklibc:amd64 2.0.8-6.1ubuntu2 amd64minimal libc subset for use with initramfs ii lsb-base 11.1.0ubuntu3 all Linux Standard Base init script functionality ii ncurses-base 6.2+20201114-2build1 all basic terminal type definitions ii sysvinit-utils
[Touch-packages] [Bug 1961196] Re: apparmor autotest failure on jammy with linux 5.15
Ah, it is president's day & night time in australia. I will upload this, to unblock releasing jammy kernels. And we can revisit this once everyone is back to back this out; or get a different implementation in. Blocking kernel testing with app armor test suite is developer time critical, and prevents multiple teams from working on the next kernel. -- 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/1961196 Title: apparmor autotest failure on jammy with linux 5.15 Status in apparmor package in Ubuntu: New Status in apparmor source package in Jammy: New Bug description: [Impact] test-aa-notify is also checking if the output of `aa-notify --help` matches a specific text. However it looks like this output has changed in jammy so the autopkgtest is reporting errors like this: 05:17:31 ERROR| [stderr] === test-aa-notify.py === 05:17:31 ERROR| [stderr] .ssF. 05:17:31 ERROR| [stderr] == 05:17:31 ERROR| [stderr] FAIL: test_help_contents (__main__.AANotifyTest) 05:17:31 ERROR| [stderr] Test output of help text 05:17:31 ERROR| [stderr] -- 05:17:31 ERROR| [stderr] Traceback (most recent call last): 05:17:31 ERROR| [stderr] File "/tmp/testlibmse00lib/source/jammy/apparmor-3.0.3/utils/test/test-aa-notify.py", line 178, in test_help_contents 05:17:31 ERROR| [stderr] self.assertEqual(expected_output_is, output, result + output) 05:17:31 ERROR| [stderr] AssertionError: 'usag[189 chars]ptional arguments:\n -h, --helpsh[746 chars]de\n' != 'usag[189 chars]ptions:\n -h, --helpshow this hel[735 chars]de\n' 05:17:31 ERROR| [stderr] usage: aa-notify [-h] [-p] [--display DISPLAY] [-f FILE] [-l] [-s NUM] [-v] 05:17:31 ERROR| [stderr][-u USER] [-w NUM] [--debug] 05:17:31 ERROR| [stderr] 05:17:31 ERROR| [stderr] Display AppArmor notifications or messages for DENIED entries. 05:17:31 ERROR| [stderr] 05:17:31 ERROR| [stderr] - optional arguments: 05:17:31 ERROR| [stderr] + options: 05:17:31 ERROR| [stderr] -h, --helpshow this help message and exit 05:17:31 ERROR| [stderr] -p, --pollpoll AppArmor logs and display notifications 05:17:31 ERROR| [stderr] --display DISPLAY set the DISPLAY environment variable (might be needed if 05:17:31 ERROR| [stderr] sudo resets $DISPLAY) 05:17:31 ERROR| [stderr] -f FILE, --file FILE search FILE for AppArmor messages 05:17:31 ERROR| [stderr] -l, --since-last display stats since last login 05:17:31 ERROR| [stderr] -s NUM, --since-days NUM 05:17:31 ERROR| [stderr] show stats for last NUM days (can be used alone or with 05:17:31 ERROR| [stderr] -p) 05:17:31 ERROR| [stderr] -v, --verbose show messages with stats 05:17:31 ERROR| [stderr] -u USER, --user USER user to drop privileges to when not using sudo 05:17:31 ERROR| [stderr] -w NUM, --wait NUMwait NUM seconds before displaying notifications (with 05:17:31 ERROR| [stderr] -p) 05:17:31 ERROR| [stderr] --debug debug mode 05:17:31 ERROR| [stderr] : Got output "usage: aa-notify [-h] [-p] [--display DISPLAY] [-f FILE] [-l] [-s NUM] [-v] 05:17:31 ERROR| [stderr] [-u USER] [-w NUM] [--debug] [Test case] Simply run test-aa-notify.py from the autopkgtests. [Fix] Update the expected output returned by `aa-notify --help` in test-aa- notify.py. [Regression potential] This is just an autopkgtest, we may see regressions if the test is used with older version of apparmor-notify. With newer versions there's no risk of regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1961196/+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 1961196] Re: apparmor autotest failure on jammy with linux 5.15
@alexmurray @jjohansen When are updated apparmor going to be upload that continues to pass existing test-suites / adt? At this point failing apparmor ADT, blocks releasing all kernels in jammy, preventing development of all kernels, and prevents security kernel fixes. To unblock kernel development we need apparmor to never fail ADT testing in devel series, as new kernel is developed. We do not want to hint to ignore it, because we must never regress apparmor. Is it ok to upload the debdiff from #7 right away? Because this bug cannot wait for new upstream release of apparmor getting integrated in Ubuntu and migrating. 3 days for test-suite only fixes is too long. -- 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/1961196 Title: apparmor autotest failure on jammy with linux 5.15 Status in apparmor package in Ubuntu: New Status in apparmor source package in Jammy: New Bug description: [Impact] test-aa-notify is also checking if the output of `aa-notify --help` matches a specific text. However it looks like this output has changed in jammy so the autopkgtest is reporting errors like this: 05:17:31 ERROR| [stderr] === test-aa-notify.py === 05:17:31 ERROR| [stderr] .ssF. 05:17:31 ERROR| [stderr] == 05:17:31 ERROR| [stderr] FAIL: test_help_contents (__main__.AANotifyTest) 05:17:31 ERROR| [stderr] Test output of help text 05:17:31 ERROR| [stderr] -- 05:17:31 ERROR| [stderr] Traceback (most recent call last): 05:17:31 ERROR| [stderr] File "/tmp/testlibmse00lib/source/jammy/apparmor-3.0.3/utils/test/test-aa-notify.py", line 178, in test_help_contents 05:17:31 ERROR| [stderr] self.assertEqual(expected_output_is, output, result + output) 05:17:31 ERROR| [stderr] AssertionError: 'usag[189 chars]ptional arguments:\n -h, --helpsh[746 chars]de\n' != 'usag[189 chars]ptions:\n -h, --helpshow this hel[735 chars]de\n' 05:17:31 ERROR| [stderr] usage: aa-notify [-h] [-p] [--display DISPLAY] [-f FILE] [-l] [-s NUM] [-v] 05:17:31 ERROR| [stderr][-u USER] [-w NUM] [--debug] 05:17:31 ERROR| [stderr] 05:17:31 ERROR| [stderr] Display AppArmor notifications or messages for DENIED entries. 05:17:31 ERROR| [stderr] 05:17:31 ERROR| [stderr] - optional arguments: 05:17:31 ERROR| [stderr] + options: 05:17:31 ERROR| [stderr] -h, --helpshow this help message and exit 05:17:31 ERROR| [stderr] -p, --pollpoll AppArmor logs and display notifications 05:17:31 ERROR| [stderr] --display DISPLAY set the DISPLAY environment variable (might be needed if 05:17:31 ERROR| [stderr] sudo resets $DISPLAY) 05:17:31 ERROR| [stderr] -f FILE, --file FILE search FILE for AppArmor messages 05:17:31 ERROR| [stderr] -l, --since-last display stats since last login 05:17:31 ERROR| [stderr] -s NUM, --since-days NUM 05:17:31 ERROR| [stderr] show stats for last NUM days (can be used alone or with 05:17:31 ERROR| [stderr] -p) 05:17:31 ERROR| [stderr] -v, --verbose show messages with stats 05:17:31 ERROR| [stderr] -u USER, --user USER user to drop privileges to when not using sudo 05:17:31 ERROR| [stderr] -w NUM, --wait NUMwait NUM seconds before displaying notifications (with 05:17:31 ERROR| [stderr] -p) 05:17:31 ERROR| [stderr] --debug debug mode 05:17:31 ERROR| [stderr] : Got output "usage: aa-notify [-h] [-p] [--display DISPLAY] [-f FILE] [-l] [-s NUM] [-v] 05:17:31 ERROR| [stderr] [-u USER] [-w NUM] [--debug] [Test case] Simply run test-aa-notify.py from the autopkgtests. [Fix] Update the expected output returned by `aa-notify --help` in test-aa- notify.py. [Regression potential] This is just an autopkgtest, we may see regressions if the test is used with older version of apparmor-notify. With newer versions there's no risk of regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1961196/+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 1947311] Re: Unexpected partition growth on first boot on impish for raspberry pi
systemd stuff did either partition or fs but not both. we used the cloud initramfs implementation on the desktop, because yes, it doesn't do cloud-init. probably moving that out of the common seed will help. -- 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/1947311 Title: Unexpected partition growth on first boot on impish for raspberry pi Status in cloud-init package in Ubuntu: Invalid Status in linux-raspi package in Ubuntu: Invalid Status in ubuntu-image package in Ubuntu: New Status in ubuntu-meta package in Ubuntu: New Bug description: Hi, On Raspberry Pi since Impish, the partition always grows even if I set the following in user-data of cloud-init. growpart: mode: off devices: ['/'] I have tested this on 21.04, and it works, but is broken on 21.10. (partition always grows) I've also tested this in KVM on amd64, and it works (partition does NOT grow). This is a problem for me because I am using runcmd in cloud init to migrate my drive to LVM/LUKS, and the partitioning step fails because the drive is already full. Cheers, Noah To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1947311/+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 1960083] Re: dirname applet missing from initramfs
Downloaded the iso today doesn't mean the iso was built today, or if it contains this update. jammy installer iso are attempted to be built daily, but are only published once they pass automated smoke testing and validation. The last image that passed that was built on 2nd of February. And builds since then have been failing validation are probably toast. You can try a /pending/ image to see if this bug is fixed, but please be aware it has been failing automated testing thus it may have other issues. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/1960083 Title: dirname applet missing from initramfs Status in busybox package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Confirmed Bug description: The initramfs is currently being built without the dirname applet. This is causing issues with zfs encrypted devices, as cryptsetup is attempting to use dirname to determine the location of the system key. This results in the following error: /init: line 971: dirname: not found followed by a prompt that is missing the zpool name. For example "Please unlock disk keystore-" rather than "Please unlock disk keystore-rpool". After entering the password, the user is dropped to an initramfs shell. It appears that this was caused by a change in cryptsetup to suddenly need dirname to function properly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1960083/+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 1960083] Re: dirname applet missing from initramfs
Fix was released in busybox 1:1.30.1-7ubuntu3 and requires initramfs rebuild your screenshot clearly shows version number 1:1.30.1-7ubuntu2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/1960083 Title: dirname applet missing from initramfs Status in busybox package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Confirmed Bug description: The initramfs is currently being built without the dirname applet. This is causing issues with zfs encrypted devices, as cryptsetup is attempting to use dirname to determine the location of the system key. This results in the following error: /init: line 971: dirname: not found followed by a prompt that is missing the zpool name. For example "Please unlock disk keystore-" rather than "Please unlock disk keystore-rpool". After entering the password, the user is dropped to an initramfs shell. It appears that this was caused by a change in cryptsetup to suddenly need dirname to function properly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1960083/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work
To be fair we don't need the empty pthread in the initramfs, we only need the non-empty dynamically opened libgcc_s, but it shouldn't hurt either. -- 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/1958594 Title: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work Status in initramfs-tools package in Ubuntu: Fix Committed Status in initramfs-tools source package in Jammy: Fix Committed Bug description: [Bug description] On a jammy installation, which was upgraded from focal, after a full- upgrade and a reboot, I enter the LUKS password to decrypt the disk. Then I get the following error: libgcc_s.so.1 must be installed for pthread_exit to work After the error is shown, the system asks for the password again (which never works, always throwing the same error). [Root cause] I was able to decrypt the disk with the same password by booting from a live usb. Which allowed further investigation. The error shown in the LUKS password prompt menu comes from https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing. From https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260, we noticed that libgcc_s.so.1 is only copied if 1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or 2) copy_exec is called for a binary linked to libpthread The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup, which is linked to libargon2.so.1, which is linked to libpthread.so.0. This covers case (2) above. As a consequence, libgcc_s.so.1 is copied to the initrd image and the error reported here is not seen. However, since glibc 2.34, libpthread is shipped within glibc, and the binaries are no longer linked to libpthread.so.0. As a consequence, an argon2 package built with glibc 2.32 will no longer be linked to libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the initrd image. Triggering the reported error. This can be verified in these two argon2 builds, from the same sources, but with different glibc versions: https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610 https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217 Still lvm2 is a seeded package, which Recommends thin-provisioning- tools. thin-provisioning-tools ships a initramfs hook that calls copy_exec for /usr/sbin/pdata_tools, which is directly linked to libgcc_s.so.1. This covers the case (1) above and should suffice to ensure the boot process works properly. Since thin-provisioning-tools is just a recommends for lvm2, it could be removed from the system (and indeed, for some reason, was not present in my focal=>jammy installation). In this case, a new kernel installation should trigger the reported error. [Reproducer] - Install jammy with a LUKS encrypted disk - remove thin-provisioning-tools - perform a full-upgrade (make sure the kernel was upgraded or run update-initramfs manually) - reboot and verify you can no longer get past the decrypt password prompt screen [Workaround] A workaround for anyone affected would be to install thin- provisioning-tools and run update-initramfs. [Impact] Users upgrading from focal to jammy will eventually be locked out of their systems in case they are using LUKS encryption. [Additional information] While this issue is similar to https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551, This is a different bug, with a different root cause. Thanks to sergiodj for the pairing session on the root cause analysis. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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 1950996] Re: Missing all modules for usb nics in initrd which makes PXE boot impossible
** Changed in: initramfs-tools (Ubuntu Jammy) Status: In Progress => Fix Committed -- 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/1950996 Title: Missing all modules for usb nics in initrd which makes PXE boot impossible Status in initramfs-tools package in Ubuntu: Fix Committed Status in initramfs-tools source package in Focal: Confirmed Status in initramfs-tools source package in Hirsute: Confirmed Status in initramfs-tools source package in Impish: Confirmed Status in initramfs-tools source package in Jammy: Fix Committed Bug description: initrd taken from the live iso for PXE boot does not contain USB NIC drivers which makes PXE installation/netboot impossible via usb. This is the case on 20.04 server iso (both hwe and normal kernel/initrd) and desktop iso. "kernel/drivers/net/usb" is empty and needs to be included in the initramfs build. As most modern thin laptops lack physical rj45 ethernet this is a big issue. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.6 ProcVersionSignature: Ubuntu 5.8.0-64.72-generic 5.8.18 Uname: Linux 5.8.0-64-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Nov 15 16:47:45 2021 PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: Upgraded to focal on 2020-05-11 (552 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1950996/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work
** Changed in: initramfs-tools (Ubuntu Jammy) Status: Confirmed => Fix Committed -- 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/1958594 Title: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work Status in initramfs-tools package in Ubuntu: Fix Committed Status in initramfs-tools source package in Jammy: Fix Committed Bug description: [Bug description] On a jammy installation, which was upgraded from focal, after a full- upgrade and a reboot, I enter the LUKS password to decrypt the disk. Then I get the following error: libgcc_s.so.1 must be installed for pthread_exit to work After the error is shown, the system asks for the password again (which never works, always throwing the same error). [Root cause] I was able to decrypt the disk with the same password by booting from a live usb. Which allowed further investigation. The error shown in the LUKS password prompt menu comes from https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing. From https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260, we noticed that libgcc_s.so.1 is only copied if 1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or 2) copy_exec is called for a binary linked to libpthread The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup, which is linked to libargon2.so.1, which is linked to libpthread.so.0. This covers case (2) above. As a consequence, libgcc_s.so.1 is copied to the initrd image and the error reported here is not seen. However, since glibc 2.34, libpthread is shipped within glibc, and the binaries are no longer linked to libpthread.so.0. As a consequence, an argon2 package built with glibc 2.32 will no longer be linked to libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the initrd image. Triggering the reported error. This can be verified in these two argon2 builds, from the same sources, but with different glibc versions: https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610 https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217 Still lvm2 is a seeded package, which Recommends thin-provisioning- tools. thin-provisioning-tools ships a initramfs hook that calls copy_exec for /usr/sbin/pdata_tools, which is directly linked to libgcc_s.so.1. This covers the case (1) above and should suffice to ensure the boot process works properly. Since thin-provisioning-tools is just a recommends for lvm2, it could be removed from the system (and indeed, for some reason, was not present in my focal=>jammy installation). In this case, a new kernel installation should trigger the reported error. [Reproducer] - Install jammy with a LUKS encrypted disk - remove thin-provisioning-tools - perform a full-upgrade (make sure the kernel was upgraded or run update-initramfs manually) - reboot and verify you can no longer get past the decrypt password prompt screen [Workaround] A workaround for anyone affected would be to install thin- provisioning-tools and run update-initramfs. [Impact] Users upgrading from focal to jammy will eventually be locked out of their systems in case they are using LUKS encryption. [Additional information] While this issue is similar to https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551, This is a different bug, with a different root cause. Thanks to sergiodj for the pairing session on the root cause analysis. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work
With above, when testing I now get: Adding binary /usr/lib/initramfs-tools/bin/gcc_s1-stub Adding binary /lib/x86_64-linux-gnu/libgcc_s.so.1 Adding binary /lib/x86_64-linux-gnu/libc.so.6 Adding binary-link /usr/lib64/ld-linux-x86-64.so.2 Adding binary /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 Adding binary /lib/x86_64-linux-gnu/libpthread.so.0 which seems alright. -- 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/1958594 Title: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: [Bug description] On a jammy installation, which was upgraded from focal, after a full- upgrade and a reboot, I enter the LUKS password to decrypt the disk. Then I get the following error: libgcc_s.so.1 must be installed for pthread_exit to work After the error is shown, the system asks for the password again (which never works, always throwing the same error). [Root cause] I was able to decrypt the disk with the same password by booting from a live usb. Which allowed further investigation. The error shown in the LUKS password prompt menu comes from https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing. From https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260, we noticed that libgcc_s.so.1 is only copied if 1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or 2) copy_exec is called for a binary linked to libpthread The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup, which is linked to libargon2.so.1, which is linked to libpthread.so.0. This covers case (2) above. As a consequence, libgcc_s.so.1 is copied to the initrd image and the error reported here is not seen. However, since glibc 2.34, libpthread is shipped within glibc, and the binaries are no longer linked to libpthread.so.0. As a consequence, an argon2 package built with glibc 2.32 will no longer be linked to libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the initrd image. Triggering the reported error. This can be verified in these two argon2 builds, from the same sources, but with different glibc versions: https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610 https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217 Still lvm2 is a seeded package, which Recommends thin-provisioning- tools. thin-provisioning-tools ships a initramfs hook that calls copy_exec for /usr/sbin/pdata_tools, which is directly linked to libgcc_s.so.1. This covers the case (1) above and should suffice to ensure the boot process works properly. Since thin-provisioning-tools is just a recommends for lvm2, it could be removed from the system (and indeed, for some reason, was not present in my focal=>jammy installation). In this case, a new kernel installation should trigger the reported error. [Reproducer] - Install jammy with a LUKS encrypted disk - remove thin-provisioning-tools - perform a full-upgrade (make sure the kernel was upgraded or run update-initramfs manually) - reboot and verify you can no longer get past the decrypt password prompt screen [Workaround] A workaround for anyone affected would be to install thin- provisioning-tools and run update-initramfs. [Impact] Users upgrading from focal to jammy will eventually be locked out of their systems in case they are using LUKS encryption. [Additional information] While this issue is similar to https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551, This is a different bug, with a different root cause. Thanks to sergiodj for the pairing session on the root cause analysis. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work
$ gcc -Wl,--no-as-needed -shared -l:libpthread.so.0 -l:libgcc_s.so.1 -o bla $ ldd bla linux-vdso.so.1 (0x7ffe0e7e6000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7feeeaa32000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7feeeaa18000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7feeea7f) /lib64/ld-linux-x86-64.so.2 (0x7feeeaa7f000) might do it. -- 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/1958594 Title: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: [Bug description] On a jammy installation, which was upgraded from focal, after a full- upgrade and a reboot, I enter the LUKS password to decrypt the disk. Then I get the following error: libgcc_s.so.1 must be installed for pthread_exit to work After the error is shown, the system asks for the password again (which never works, always throwing the same error). [Root cause] I was able to decrypt the disk with the same password by booting from a live usb. Which allowed further investigation. The error shown in the LUKS password prompt menu comes from https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing. From https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260, we noticed that libgcc_s.so.1 is only copied if 1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or 2) copy_exec is called for a binary linked to libpthread The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup, which is linked to libargon2.so.1, which is linked to libpthread.so.0. This covers case (2) above. As a consequence, libgcc_s.so.1 is copied to the initrd image and the error reported here is not seen. However, since glibc 2.34, libpthread is shipped within glibc, and the binaries are no longer linked to libpthread.so.0. As a consequence, an argon2 package built with glibc 2.32 will no longer be linked to libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the initrd image. Triggering the reported error. This can be verified in these two argon2 builds, from the same sources, but with different glibc versions: https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610 https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217 Still lvm2 is a seeded package, which Recommends thin-provisioning- tools. thin-provisioning-tools ships a initramfs hook that calls copy_exec for /usr/sbin/pdata_tools, which is directly linked to libgcc_s.so.1. This covers the case (1) above and should suffice to ensure the boot process works properly. Since thin-provisioning-tools is just a recommends for lvm2, it could be removed from the system (and indeed, for some reason, was not present in my focal=>jammy installation). In this case, a new kernel installation should trigger the reported error. [Reproducer] - Install jammy with a LUKS encrypted disk - remove thin-provisioning-tools - perform a full-upgrade (make sure the kernel was upgraded or run update-initramfs manually) - reboot and verify you can no longer get past the decrypt password prompt screen [Workaround] A workaround for anyone affected would be to install thin- provisioning-tools and run update-initramfs. [Impact] Users upgrading from focal to jammy will eventually be locked out of their systems in case they are using LUKS encryption. [Additional information] While this issue is similar to https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551, This is a different bug, with a different root cause. Thanks to sergiodj for the pairing session on the root cause analysis. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work
With that branch rebased, and typpos fixed up testing locally does produce this: Adding binary /usr/lib/initramfs-tools/bin/gcc_s1-stub Adding binary /lib/x86_64-linux-gnu/libgcc_s.so.1 Adding binary /lib/x86_64-linux-gnu/libc.so.6 Adding binary-link /usr/lib64/ld-linux-x86-64.so.2 Adding binary /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 Let me see if i can force linkage with pthreads too. -- 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/1958594 Title: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: [Bug description] On a jammy installation, which was upgraded from focal, after a full- upgrade and a reboot, I enter the LUKS password to decrypt the disk. Then I get the following error: libgcc_s.so.1 must be installed for pthread_exit to work After the error is shown, the system asks for the password again (which never works, always throwing the same error). [Root cause] I was able to decrypt the disk with the same password by booting from a live usb. Which allowed further investigation. The error shown in the LUKS password prompt menu comes from https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing. From https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260, we noticed that libgcc_s.so.1 is only copied if 1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or 2) copy_exec is called for a binary linked to libpthread The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup, which is linked to libargon2.so.1, which is linked to libpthread.so.0. This covers case (2) above. As a consequence, libgcc_s.so.1 is copied to the initrd image and the error reported here is not seen. However, since glibc 2.34, libpthread is shipped within glibc, and the binaries are no longer linked to libpthread.so.0. As a consequence, an argon2 package built with glibc 2.32 will no longer be linked to libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the initrd image. Triggering the reported error. This can be verified in these two argon2 builds, from the same sources, but with different glibc versions: https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610 https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217 Still lvm2 is a seeded package, which Recommends thin-provisioning- tools. thin-provisioning-tools ships a initramfs hook that calls copy_exec for /usr/sbin/pdata_tools, which is directly linked to libgcc_s.so.1. This covers the case (1) above and should suffice to ensure the boot process works properly. Since thin-provisioning-tools is just a recommends for lvm2, it could be removed from the system (and indeed, for some reason, was not present in my focal=>jammy installation). In this case, a new kernel installation should trigger the reported error. [Reproducer] - Install jammy with a LUKS encrypted disk - remove thin-provisioning-tools - perform a full-upgrade (make sure the kernel was upgraded or run update-initramfs manually) - reboot and verify you can no longer get past the decrypt password prompt screen [Workaround] A workaround for anyone affected would be to install thin- provisioning-tools and run update-initramfs. [Impact] Users upgrading from focal to jammy will eventually be locked out of their systems in case they are using LUKS encryption. [Additional information] While this issue is similar to https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551, This is a different bug, with a different root cause. Thanks to sergiodj for the pairing session on the root cause analysis. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+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 1950996] Re: Missing all modules for usb nics in initrd which makes PXE boot impossible
** Changed in: initramfs-tools (Ubuntu Jammy) Status: Triaged => In Progress -- 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/1950996 Title: Missing all modules for usb nics in initrd which makes PXE boot impossible Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Focal: Confirmed Status in initramfs-tools source package in Hirsute: Confirmed Status in initramfs-tools source package in Impish: Confirmed Status in initramfs-tools source package in Jammy: In Progress Bug description: initrd taken from the live iso for PXE boot does not contain USB NIC drivers which makes PXE installation/netboot impossible via usb. This is the case on 20.04 server iso (both hwe and normal kernel/initrd) and desktop iso. "kernel/drivers/net/usb" is empty and needs to be included in the initramfs build. As most modern thin laptops lack physical rj45 ethernet this is a big issue. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.6 ProcVersionSignature: Ubuntu 5.8.0-64.72-generic 5.8.18 Uname: Linux 5.8.0-64-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Nov 15 16:47:45 2021 PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: Upgraded to focal on 2020-05-11 (552 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1950996/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work
We have been bitten by this before. And Last time I did proposed to do this: - create a stub binary tha tis linked with pthread and libgcc_s - copy_exec that into the initramfs https://code.launchpad.net/~xnox/ubuntu/+source/initramfs- tools/+git/initramfs-tools/+merge/385243 This ensures that at least one binary wants pthreads and libgcc_s and those things get copied into the initramfs correctly and always for the host architecture. I had to do this with a binary, because precisely like raof says we never know which architecture we need, and which hw optimized version of those libraries is needed. I feel like I should upload the above (rebased on jammy) into jammy to get this done once and for all. Kind of sad that I didn't do that 2 years ago. Which would have avoided this issue today. -- 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/1958594 Title: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: [Bug description] On a jammy installation, which was upgraded from focal, after a full- upgrade and a reboot, I enter the LUKS password to decrypt the disk. Then I get the following error: libgcc_s.so.1 must be installed for pthread_exit to work After the error is shown, the system asks for the password again (which never works, always throwing the same error). [Root cause] I was able to decrypt the disk with the same password by booting from a live usb. Which allowed further investigation. The error shown in the LUKS password prompt menu comes from https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing. From https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260, we noticed that libgcc_s.so.1 is only copied if 1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or 2) copy_exec is called for a binary linked to libpthread The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup, which is linked to libargon2.so.1, which is linked to libpthread.so.0. This covers case (2) above. As a consequence, libgcc_s.so.1 is copied to the initrd image and the error reported here is not seen. However, since glibc 2.34, libpthread is shipped within glibc, and the binaries are no longer linked to libpthread.so.0. As a consequence, an argon2 package built with glibc 2.32 will no longer be linked to libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the initrd image. Triggering the reported error. This can be verified in these two argon2 builds, from the same sources, but with different glibc versions: https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610 https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217 Still lvm2 is a seeded package, which Recommends thin-provisioning- tools. thin-provisioning-tools ships a initramfs hook that calls copy_exec for /usr/sbin/pdata_tools, which is directly linked to libgcc_s.so.1. This covers the case (1) above and should suffice to ensure the boot process works properly. Since thin-provisioning-tools is just a recommends for lvm2, it could be removed from the system (and indeed, for some reason, was not present in my focal=>jammy installation). In this case, a new kernel installation should trigger the reported error. [Reproducer] - Install jammy with a LUKS encrypted disk - remove thin-provisioning-tools - perform a full-upgrade (make sure the kernel was upgraded or run update-initramfs manually) - reboot and verify you can no longer get past the decrypt password prompt screen [Workaround] A workaround for anyone affected would be to install thin- provisioning-tools and run update-initramfs. [Impact] Users upgrading from focal to jammy will eventually be locked out of their systems in case they are using LUKS encryption. [Additional information] While this issue is similar to https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551, This is a different bug, with a different root cause. Thanks to sergiodj for the pairing session on the root cause analysis. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1958904] Re: autopkgtest is failing on jammy with "no space left on device"
Autopkgtests completed successfully on both impish and focal. ** Tags removed: verification-needed verification-needed-focal verification-needed-impish ** Tags added: verification-done verification-done-focal verification-done-impish -- 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/1958904 Title: autopkgtest is failing on jammy with "no space left on device" Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Invalid Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Impish: Fix Committed Bug description: [Impact] In debian/tests/prep-image we create an image file of 1GB, but recent jammy/focal cloud images are (barely) bigger than that, for example the current one uncompressed is 1001MB... Example of a test failure: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/i/initramfs-tools/20220126_160323_8bcd1@/log.gz Maybe we should consider to create image files of 2GB or even bigger, considering that we are only going to allocate the space that is actually needed, because we create the file using truncate. [Test Plan] Run autotestpkg tests from initramfs-tools package. The "net" test is the one that depends on the image created by 'prep-image'. The testcase should complete successfully without the temporary image running out of space. [Where problems could occur] The creation of a larger image for the tests could fail if the filesystem of the test system is low on disk space. However, as mentioned before, as the image file is created using 'truncate', only the necessary space needed to uncompress the cloudimg will be used on the filesystem. Apart from that, we assume that 2GB of free space should be available on every test system used for Ubuntu autopkgtest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958904/+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 1933491] Re: kmod add zstd support
@sil2100 --disable-test-modules \ override_dh_auto_test: + dh_auto_test --builddir=build-deb are needed together to enable building and running unittests during build. Note previously focal builds did not run unittests at all. The autoconf help text for the option says "disable building test modules during make check: cached modules will be used". What it means use the prebuilt kernel modules from the orig tarball for unittests, which works in launchpad builders. Without this option an attempt is made to rebuild test modules for the currently running kernel which is not possible or useful in launchpad. Installing linux-generic-headers and forcing the build for the current kernel in a given series is another alternative, but also not too sure if that is useful given prebuilt known/working modules for unittests are available. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1933491 Title: kmod add zstd support Status in kmod package in Ubuntu: Fix Released Status in kmod source package in Focal: New Status in kmod source package in Impish: Fix Released Status in kmod source package in Jammy: Fix Released Status in kmod package in Debian: New Bug description: [Impact] * To safe diskspace, upcoming devel series / hwe kernels may turn on zstd kernel module compression. Kmod since impish support zstd support. But in order to keep hwe kernels at parity, or allow inspecting jammy modules from focal host, it would be beneficial for kmod in focal to support zstd compressed modules. [Test Plan] * Pick any kernel module * Compress it with zstd: $ zstd *.ko * Check that modinfo can read it: $ modinfo *.ko.zst [Where problems could occur] * kmod will gain a new dependecy on libzstd1, however it should already be present, because dpkg in focal depends on libzstd1 already. * initramfs-tools already supports compressed modules, but in focal at the moment it does so in an inefficient manner (regresses bootspeed), this has been improved in https://launchpad.net/ubuntu/+source/initramfs-tools/0.140ubuntu8 and is yet to be SRUed into Focal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1933491/+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 1933491] Re: kmod add zstd support
** Bug watch added: Debian Bug tracker #990092 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990092 ** Also affects: kmod (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990092 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1933491 Title: kmod add zstd support Status in kmod package in Ubuntu: Fix Released Status in kmod source package in Focal: New Status in kmod source package in Impish: Fix Released Status in kmod source package in Jammy: Fix Released Status in kmod package in Debian: Unknown Bug description: [Impact] * To safe diskspace, upcoming devel series / hwe kernels may turn on zstd kernel module compression. Kmod since impish support zstd support. But in order to keep hwe kernels at parity, or allow inspecting jammy modules from focal host, it would be beneficial for kmod in focal to support zstd compressed modules. [Test Plan] * Pick any kernel module * Compress it with zstd: $ zstd *.ko * Check that modinfo can read it: $ modinfo *.ko.zst [Where problems could occur] * kmod will gain a new dependecy on libzstd1, however it should already be present, because dpkg in focal depends on libzstd1 already. * initramfs-tools already supports compressed modules, but in focal at the moment it does so in an inefficient manner (regresses bootspeed), this has been improved in https://launchpad.net/ubuntu/+source/initramfs-tools/0.140ubuntu8 and is yet to be SRUed into Focal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1933491/+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 1958594] Re: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work
It feels like we should just copy libgcc_s.so.1 and libpthread always. It is tiny in size and something is bound to use them. -- 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/1958594 Title: Boot error: libgcc_s.so.1 must be installed for pthread_exit to work Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: [Bug description] On a jammy installation, which was upgraded from focal, after a full- upgrade and a reboot, I enter the LUKS password to decrypt the disk. Then I get the following error: libgcc_s.so.1 must be installed for pthread_exit to work After the error is shown, the system asks for the password again (which never works, always throwing the same error). [Root cause] I was able to decrypt the disk with the same password by booting from a live usb. Which allowed further investigation. The error shown in the LUKS password prompt menu comes from https://github.com/bminor/glibc/blob/glibc-2.34/nptl/pthread_exit.c#L31-L32, which indeed shows that pthread_exit fails when libgcc_s.so.1 is missing. From https://git.launchpad.net/ubuntu/+source/initramfs-tools/tree/hook-functions?h=import/0.140ubuntu10#n260, we noticed that libgcc_s.so.1 is only copied if 1) copy_exec is called for a binary directly linked to libgcc_s.so.1, or 2) copy_exec is called for a binary linked to libpthread The cryptsetup initramfs hook, calls copy_exec for /sbin/cryptsetup, which is linked to libargon2.so.1, which is linked to libpthread.so.0. This covers case (2) above. As a consequence, libgcc_s.so.1 is copied to the initrd image and the error reported here is not seen. However, since glibc 2.34, libpthread is shipped within glibc, and the binaries are no longer linked to libpthread.so.0. As a consequence, an argon2 package built with glibc 2.32 will no longer be linked to libpthread.so.0 and libgcc_s.so.1 will no longer be copied to the initrd image. Triggering the reported error. This can be verified in these two argon2 builds, from the same sources, but with different glibc versions: https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build21.04.0/+build/21066610 https://launchpad.net/ubuntu/+source/argon2/0~20171227-0.2build22/+build/22255217 Still lvm2 is a seeded package, which Recommends thin-provisioning- tools. thin-provisioning-tools ships a initramfs hook that calls copy_exec for /usr/sbin/pdata_tools, which is directly linked to libgcc_s.so.1. This covers the case (1) above and should suffice to ensure the boot process works properly. Since thin-provisioning-tools is just a recommends for lvm2, it could be removed from the system (and indeed, for some reason, was not present in my focal=>jammy installation). In this case, a new kernel installation should trigger the reported error. [Reproducer] - Install jammy with a LUKS encrypted disk - remove thin-provisioning-tools - perform a full-upgrade (make sure the kernel was upgraded or run update-initramfs manually) - reboot and verify you can no longer get past the decrypt password prompt screen [Workaround] A workaround for anyone affected would be to install thin- provisioning-tools and run update-initramfs. [Impact] Users upgrading from focal to jammy will eventually be locked out of their systems in case they are using LUKS encryption. [Additional information] While this issue is similar to https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1861757, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551, This is a different bug, with a different root cause. Thanks to sergiodj for the pairing session on the root cause analysis. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1932329] Re: Benchmark if we can compress kernel modules
compressed modules is faster. Also one has to observe the changes in the initrd size. zstd(zstd) compression may result in slight growth, which shouldn't impact boot speed too much. = Outcomes = If installed size savings can be achieved without regressing bootspeed we should enable CONFIG_MODULE_COMPRESS_ZSTD=y by default. ** Also affects: initramfs-tools (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Jammy) Importance: Undecided Status: Fix Released ** Also affects: linux (Ubuntu Jammy) Importance: Medium Assignee: Dimitri John Ledkov (xnox) Status: In Progress ** Also affects: initramfs-tools (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu Impish) ** No longer affects: linux (Ubuntu Focal) ** Summary changed: - Benchmark if we can compress kernel modules + Support compressed kernel modules in initramfs-tools and kernel ** Description changed: --- initramfs-tools [Impact] * Initramfs-tools already supports compressed kernel modules. However, - in focal it does so inefficiently. It is always better to have a - compressed initramfs of uncommpressed kernel modules, than a compressed - initrd of compressed kernel modules. Thus when kernel module compression - is turned on, it is prudent for initramfs-tools to pre-uncompress kernel - modules when building initramfs. + in focal and impish it does so inefficiently. It is always better to + have a compressed initramfs of uncommpressed kernel modules, than a + compressed initrd of compressed kernel modules. Thus when kernel module + compression is turned on, it is prudent for initramfs-tools to pre- + uncompress kernel modules when building initramfs. [Test Plan] * Compress all kernel modules with xz for a current kernel, check that all of them have .ko.xz extension and no .ko ones available * Rerun depmod * Update initramfs with update-initramfs -u * lsinitramfs contents and check that all kernel modules are present, and are uncompressed (.ko extension) [Where problems could occur] * This optimization for compressed kernel modules will make initramfs build time longer (due to decompression) whilst improving bootspeed (overall smaller size of the initrd). [Other Info] * Original bug report re kernel feature --- linux Symbol: MODULE_COMPRESS_ZSTD [=n] Type : bool = Impacts to measure and observe = == Disk space == * Inspect linux-modules-* and linux-modules-extra* deb package Installed-Size and Download-Size changes, i.e. $ apt show linux-modules-5.8.0-53-generic linux-modules- extra-5.8.0-53-generic | grep -e Package: -e Size: Package: linux-modules-5.8.0-53-generic Installed-Size: 81.5 MB Download-Size: 15.5 MB Package: linux-modules-extra-5.8.0-53-generic Installed-Size: 215 MB Download-Size: 41.5 MB In theory, there should not be a significant change in the Download- size. It is desired that there is a significant reduction in Installed- Size. Modules take up about 300MB and normally one has upto three kernel version installed, resulting in about of 1GB of disk space that one constantly pays for. == Boot Speed == In theory, boot speed may either improve or regress. It depends if disk IO is slower than decompression speed, meaning loading compressed modules is faster. Also one has to observe the changes in the initrd size. zstd(zstd) compression may result in slight growth, which shouldn't impact boot speed too much. = Outcomes = If installed size savings can be achieved without regressing bootspeed we should enable CONFIG_MODULE_COMPRESS_ZSTD=y by default. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1932329 Title: Support compressed kernel modules in initramfs-tools and kernel Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in initramfs-tools source package in Focal: New Status in initramfs-tools source package in Impish: New Status in initramfs-tools source package in Jammy: Fix Released Status in linux source package in Jammy: In Progress Bug description: --- initramfs-tools [Impact] * Initramfs-tools already supports compressed kernel modules. However, in focal and impish it does so inefficiently. It is always better to have a compressed initramfs of uncommpressed kernel modules, than a compressed initrd of compressed kernel modules. Thus when kernel module compression is turned on, it is prudent for initramfs- tools to pre-uncompress kernel
[Touch-packages] [Bug 1942260] Re: compress firmware in /lib/firmware
** Description changed: + -- initramfs-tools + + [Impact] + + * linux supports xz compressed linux-firmware which saves disk space. + In focal, initramfs-tools only knows how to included uncompressed + firmware files (even when kernel supports loading compressed ones). + Newer releases of linux-firmware may use compressed firmware files only, + in such cases it would be nice for focal's initramfs-tools to support + compressed firmware files in case of partial or incomplete upgrades + (i.e. linux-firmware force installed or upgraded, without newer + initramfs-tools). The proposed changes to initramfs-tools are backwards + and forwards compatible, they prefer to include uncompressed firmware + files; and if missing, include compressed firmware files in their + uncompressed form. Thus maintaining compatibility with any kernels, + irrespective of compressed/uncompressed firmware inputs. + + [Test Plan] + + * Compress all files shipped by linux-firmware with xz + + * Rebuild initrd + + * Check that all the same firmware files are still included in the + initramfs, in their uncompressed form as before + + [Where problems could occur] + + * This SRU is precautionary to prevent accidental installation of + compressed linux-firmware from generating incorrect initramfs. It should + be noted that whilst initramfs-tools would create a compatible initramfs + with any kernels, pre-v5.3 kernels do not support xz compressed firmware + files at runtime. Mixing this new initramfs with compressed firmwares + and pre 5.3 kernels may lead to expectations of supporting compressed + firmware files with them only working at initrd stage and not at + runtime. + + [Other Info] + Original bug report + Some facts: - - The linux kernel has supported loading xz compressed firmware since 5.3 - - The size of /lib/firmware in impish is ~650Mb (and growing) - - The compressed size of firmware could be ~230Mb + - The linux kernel has supported loading xz compressed firmware since 5.3 + - The size of /lib/firmware in impish is ~650Mb (and growing) + - The compressed size of firmware could be ~230Mb It would be nice to install compressed firmware to save space. Here are the plans from the Fedora project: https://fedoraproject.org/wiki/Changes/CompressKernelFirmware -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1942260 Title: compress firmware in /lib/firmware Status in initramfs-tools package in Ubuntu: Fix Released Status in linux-firmware package in Ubuntu: New Status in linux-firmware-raspi2 package in Ubuntu: New Bug description: -- initramfs-tools [Impact] * linux supports xz compressed linux-firmware which saves disk space. In focal, initramfs-tools only knows how to included uncompressed firmware files (even when kernel supports loading compressed ones). Newer releases of linux-firmware may use compressed firmware files only, in such cases it would be nice for focal's initramfs-tools to support compressed firmware files in case of partial or incomplete upgrades (i.e. linux-firmware force installed or upgraded, without newer initramfs-tools). The proposed changes to initramfs-tools are backwards and forwards compatible, they prefer to include uncompressed firmware files; and if missing, include compressed firmware files in their uncompressed form. Thus maintaining compatibility with any kernels, irrespective of compressed/uncompressed firmware inputs. [Test Plan] * Compress all files shipped by linux-firmware with xz * Rebuild initrd * Check that all the same firmware files are still included in the initramfs, in their uncompressed form as before [Where problems could occur] * This SRU is precautionary to prevent accidental installation of compressed linux-firmware from generating incorrect initramfs. It should be noted that whilst initramfs-tools would create a compatible initramfs with any kernels, pre-v5.3 kernels do not support xz compressed firmware files at runtime. Mixing this new initramfs with compressed firmwares and pre 5.3 kernels may lead to expectations of supporting compressed firmware files with them only working at initrd stage and not at runtime. [Other Info] Original bug report Some facts: - The linux kernel has supported loading xz compressed firmware since 5.3 - The size of /lib/firmware in impish is ~650Mb (and growing) - The compressed size of firmware could be ~230Mb It would be nice to install compressed firmware to save space. Here are the plans from the Fedora project: https://fedoraproject.org/wiki/Changes/CompressKernelFirmware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1942260/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1933491] Re: kmod add zstd support
** Description changed: - kmod add zstd support + [Impact] - * v27+ needs patches cherrypicked from v28 + * To safe diskspace, upcoming devel series / hwe kernels may turn on + zstd kernel module compression. Kmod since impish support zstd support. + But in order to keep hwe kernels at parity, or allow inspecting jammy + modules from focal host, it would be beneficial for kmod in focal to + support zstd compressed modules. - * v28+ needs new build-time deps adjusted + [Test Plan] + + * Pick any kernel module + + * Compress it with zstd: $ zstd *.ko + + * Check that modinfo can read it: $ modinfo *.ko.zst + + [Where problems could occur] + + * kmod will gain a new dependecy on libzstd1, however it should already + be present, because dpkg in focal depends on libzstd1 already. + + * initramfs-tools already supports compressed modules, but in focal at + the moment it does so in an inefficient manner (regresses bootspeed), + this has been improved in + https://launchpad.net/ubuntu/+source/initramfs-tools/0.140ubuntu8 and is + yet to be SRUed into Focal. ** Also affects: kmod (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: kmod (Ubuntu Jammy) Importance: Undecided Status: Fix Released ** Also affects: kmod (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: kmod (Ubuntu Impish) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1933491 Title: kmod add zstd support Status in kmod package in Ubuntu: Fix Released Status in kmod source package in Focal: New Status in kmod source package in Impish: Fix Released Status in kmod source package in Jammy: Fix Released Bug description: [Impact] * To safe diskspace, upcoming devel series / hwe kernels may turn on zstd kernel module compression. Kmod since impish support zstd support. But in order to keep hwe kernels at parity, or allow inspecting jammy modules from focal host, it would be beneficial for kmod in focal to support zstd compressed modules. [Test Plan] * Pick any kernel module * Compress it with zstd: $ zstd *.ko * Check that modinfo can read it: $ modinfo *.ko.zst [Where problems could occur] * kmod will gain a new dependecy on libzstd1, however it should already be present, because dpkg in focal depends on libzstd1 already. * initramfs-tools already supports compressed modules, but in focal at the moment it does so in an inefficient manner (regresses bootspeed), this has been improved in https://launchpad.net/ubuntu/+source/initramfs-tools/0.140ubuntu8 and is yet to be SRUed into Focal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1933491/+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 1958904] Re: autopkgtest is failing on jammy with "no space left on device"
I wonder if I should have included feature backports to support compressed kernel modules & coompressed firmware files https://launchpad.net/ubuntu/+source/initramfs-tools/0.140ubuntu8 This would be actually useful, and would allow us to enable compressed kernel modules for jammy and hwe-5.15 when it lands in focal. -- 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/1958904 Title: autopkgtest is failing on jammy with "no space left on device" Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Invalid Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Impish: Fix Committed Bug description: [Impact] In debian/tests/prep-image we create an image file of 1GB, but recent jammy/focal cloud images are (barely) bigger than that, for example the current one uncompressed is 1001MB... Example of a test failure: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/i/initramfs-tools/20220126_160323_8bcd1@/log.gz Maybe we should consider to create image files of 2GB or even bigger, considering that we are only going to allocate the space that is actually needed, because we create the file using truncate. [Test Plan] Run autotestpkg tests from initramfs-tools package. The "net" test is the one that depends on the image created by 'prep-image'. The testcase should complete successfully without the temporary image running out of space. [Where problems could occur] The creation of a larger image for the tests could fail if the filesystem of the test system is low on disk space. However, as mentioned before, as the image file is created using 'truncate', only the necessary space needed to uncompress the cloudimg will be used on the filesystem. Apart from that, we assume that 2GB of free space should be available on every test system used for Ubuntu autopkgtest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958904/+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 1958904] Re: autopkgtest is failing on jammy with "no space left on device"
uploaded into unapproved queue -- 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/1958904 Title: autopkgtest is failing on jammy with "no space left on device" Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Invalid Status in initramfs-tools source package in Focal: In Progress Status in initramfs-tools source package in Impish: In Progress Bug description: [Impact] In debian/tests/prep-image we create an image file of 1GB, but recent jammy/focal cloud images are (barely) bigger than that, for example the current one uncompressed is 1001MB... Example of a test failure: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/i/initramfs-tools/20220126_160323_8bcd1@/log.gz Maybe we should consider to create image files of 2GB or even bigger, considering that we are only going to allocate the space that is actually needed, because we create the file using truncate. [Test Plan] Run autotestpkg tests from initramfs-tools package. The "net" test is the one that depends on the image created by 'prep-image'. The testcase should complete successfully without the temporary image running out of space. [Where problems could occur] The creation of a larger image for the tests could fail if the filesystem of the test system is low on disk space. However, as mentioned before, as the image file is created using 'truncate', only the necessary space needed to uncompress the cloudimg will be used on the filesystem. Apart from that, we assume that 2GB of free space should be available on every test system used for Ubuntu autopkgtest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958904/+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 1958904] Re: autopkgtest is failing on jammy with "no space left on device"
@brian-murray Unfortunately, it would mean that kernel-teams adt-matrix would still need to be hinted, as it does strict adt test runs against each kernel flavour, against packages in updates only, and enforces that every kernel flavour is tested. However, I also think that this adt test may not be relevant, given that the kernel used in the qemu image is not actually the requested kernel flavour under test from adt-matrix point of view. I will sponsor these uploads, but i guess kernel team will still need to apply adt-matrix hints to make things nice. -- 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/1958904 Title: autopkgtest is failing on jammy with "no space left on device" Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Invalid Status in initramfs-tools source package in Focal: In Progress Status in initramfs-tools source package in Impish: In Progress Bug description: [Impact] In debian/tests/prep-image we create an image file of 1GB, but recent jammy/focal cloud images are (barely) bigger than that, for example the current one uncompressed is 1001MB... Example of a test failure: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/i/initramfs-tools/20220126_160323_8bcd1@/log.gz Maybe we should consider to create image files of 2GB or even bigger, considering that we are only going to allocate the space that is actually needed, because we create the file using truncate. [Test Plan] Run autotestpkg tests from initramfs-tools package. The "net" test is the one that depends on the image created by 'prep-image'. The testcase should complete successfully without the temporary image running out of space. [Where problems could occur] The creation of a larger image for the tests could fail if the filesystem of the test system is low on disk space. However, as mentioned before, as the image file is created using 'truncate', only the necessary space needed to uncompress the cloudimg will be used on the filesystem. Apart from that, we assume that 2GB of free space should be available on every test system used for Ubuntu autopkgtest. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958904/+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 1958904] Re: autopkgtest is failing on jammy with "no space left on device"
** Changed in: initramfs-tools (Ubuntu) Status: New => Fix Committed ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Critical ** Changed in: initramfs-tools (Ubuntu) Assignee: (unassigned) => Dimitri John Ledkov (xnox) -- 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/1958904 Title: autopkgtest is failing on jammy with "no space left on device" Status in initramfs-tools package in Ubuntu: Fix Committed Bug description: In debian/tests/prep-image we create an image file of 1GB, but recent jammy cloud images are (barely) bigger than that, for example the current one uncompressed is 1001MB... Maybe we should consider to create image files of 2GB or even bigger, considering that we are only going to allocate the space that is actually needed, because we create the file using truncate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958904/+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 1958676] Re: error: too early for operation, device not yet seeded or device model not acknowledged Install failed
I guess i can modify init-system-helpers again, to dump journal from the build such that we can see what is going on. ** Also affects: launchpad-buildd 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/1958676 Title: error: too early for operation, device not yet seeded or device model not acknowledged Install failed Status in launchpad-buildd: New Status in init-system-helpers package in Ubuntu: New Status in snapd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: https://launchpad.net/~ubuntu-core-service/+snap/core22/+build/1650565 New deb-systemd-invoke added functionality for systemd v250 which ubuntu does not have yet. But it also appears to break postinst calls to deb-systemd-invoke, at least as seen during snap builds in lxd containers operated by launchpad-buildd. I wonder if there is a regression in new code, or new systemd, which may warrant a revert. To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad-buildd/+bug/1958676/+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 1958676] Re: error: too early for operation, device not yet seeded or device model not acknowledged Install failed
** Summary changed: - Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. + error: too early for operation, device not yet seeded or device model not acknowledged Install failed -- 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/1958676 Title: error: too early for operation, device not yet seeded or device model not acknowledged Install failed Status in init-system-helpers package in Ubuntu: New Status in snapd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: https://launchpad.net/~ubuntu-core-service/+snap/core22/+build/1650565 New deb-systemd-invoke added functionality for systemd v250 which ubuntu does not have yet. But it also appears to break postinst calls to deb-systemd-invoke, at least as seen during snap builds in lxd containers operated by launchpad-buildd. I wonder if there is a regression in new code, or new systemd, which may warrant a revert. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1958676/+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 1958676] Re: Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142.
even with reverted init-system-helps snapd units fail to start during launchpad-buildd https://launchpad.net/~ubuntu-core-service/+snap/core22/+build/1650698 Setting up snapd (2.54.2+22.04ubuntu1) ... Created symlink /etc/systemd/system/multi-user.target.wants/snapd.apparmor.service → /lib/systemd/system/snapd.apparmor.service. Created symlink /etc/systemd/system/multi-user.target.wants/snapd.autoimport.service → /lib/systemd/system/snapd.autoimport.service. Created symlink /etc/systemd/system/multi-user.target.wants/snapd.core-fixup.service → /lib/systemd/system/snapd.core-fixup.service. Created symlink /etc/systemd/system/multi-user.target.wants/snapd.recovery-chooser-trigger.service → /lib/systemd/system/snapd.recovery-chooser-trigger.service. Created symlink /etc/systemd/system/multi-user.target.wants/snapd.seeded.service → /lib/systemd/system/snapd.seeded.service. Created symlink /etc/systemd/system/cloud-final.service.wants/snapd.seeded.service → /lib/systemd/system/snapd.seeded.service. Unit /lib/systemd/system/snapd.seeded.service is added as a dependency to a non-existent unit cloud-final.service. Created symlink /etc/systemd/system/multi-user.target.wants/snapd.service → /lib/systemd/system/snapd.service. Created symlink /etc/systemd/system/timers.target.wants/snapd.snap-repair.timer → /lib/systemd/system/snapd.snap-repair.timer. Created symlink /etc/systemd/system/sockets.target.wants/snapd.socket → /lib/systemd/system/snapd.socket. Created symlink /etc/systemd/system/final.target.wants/snapd.system-shutdown.service → /lib/systemd/system/snapd.system-shutdown.service. snapd.failure.service is a disabled or a static unit not running, not starting it. snapd.snap-repair.service is a disabled or a static unit not running, not starting it. Job failed. See "journalctl -xe" for details. A dependency job for snapd.service failed. See 'journalctl -xe' for details. A dependency job for snapd.seeded.service failed. See 'journalctl -xe' for details. Processing triggers for libc-bin (2.34-0ubuntu3) ... error: too early for operation, device not yet seeded or device model not acknowledged Install failed ** Also affects: snapd (Ubuntu) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: init-system-helpers (Ubuntu) Importance: Critical => Undecided -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to init-system-helpers in Ubuntu. https://bugs.launchpad.net/bugs/1958676 Title: Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. Status in init-system-helpers package in Ubuntu: New Status in snapd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: https://launchpad.net/~ubuntu-core-service/+snap/core22/+build/1650565 New deb-systemd-invoke added functionality for systemd v250 which ubuntu does not have yet. But it also appears to break postinst calls to deb-systemd-invoke, at least as seen during snap builds in lxd containers operated by launchpad-buildd. I wonder if there is a regression in new code, or new systemd, which may warrant a revert. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1958676/+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
