[Touch-packages] [Bug 1923485] Re: unable to reconize Asgard NVME with short serial
@mwhudson also reported this issue upstream https://github.com/systemd/systemd/issues/19309 (thanks!) ** Bug watch added: github.com/systemd/systemd/issues #19309 https://github.com/systemd/systemd/issues/19309 ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1923485 Title: unable to reconize Asgard NVME with short serial Status in curtin: New Status in systemd package in Ubuntu: New Bug description: check this: https://discourse.maas.io/t/unable-to-deploy-valueerror-failed-to-find-storage-volume-id-nvme0n1/4442/4 Maybe the line os.listdir should be changed with os.walk to discover all child directories? Or maybe this is just a BUG of MAAS? To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1923485/+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 1923618] Re: upgrading systemd on groovy terminates sessions
** Also affects: systemd (Ubuntu Groovy) 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/1923618 Title: upgrading systemd on groovy terminates sessions Status in systemd package in Ubuntu: New Status in systemd source package in Groovy: New Bug description: Whenever I upgrade systemd on my groovy system, my gnome session is terminated. This is very annoying, as everything that was running on that session is terminated. NetworkManager also stops running. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923618/+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 1923472] Re: xdm fails to start on Sundays
** Package changed: systemd (Ubuntu) => xdm (Ubuntu) ** Bug watch added: Debian Bug tracker #948346 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948346 ** Also affects: xdm (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948346 Importance: Unknown Status: Unknown -- 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/1923472 Title: xdm fails to start on Sundays Status in xdm package in Ubuntu: New Status in xdm package in Debian: Unknown Bug description: On the first login of the week, xdm (1.1.11-3ubuntu2) fails to start on Ubuntu 20.04. More correctly, it does start, but exits almost immediately on signal 12. It leaves /var/run/xdm.pid behind, and also a running X server with no clients. This makes it hard to restart, for one needs to kill the X server and remove the pid file first. The cause is logrotate running during startup and killing xdm before xdm installs a handler for SIGUSR2. The issue is more fully described upstream at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948346 In passing I would comment that running logrotate so early during startup seems strange to me. Startup would surely be faster if these sort of "cron" jobs were left until it had finished? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xdm/+bug/1923472/+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 1923406] Re: sslh 1.18-1 high CPU load -> Fix available
** Package changed: systemd (Ubuntu) => sslh (Ubuntu) -- 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/1923406 Title: sslh 1.18-1 high CPU load -> Fix available Status in sslh package in Ubuntu: New Bug description: System: Ubuntu 18.04 LTS Software: sslh v1.18-1 The Problem is that the sslh-daemon causes 100% load after a while. The bug seems to be reported and fixed in december 2020 at the the ssl-project. Should be fixed in v1.21b or newer. So please backport/update the package accordingly to fix the problem for everyone. See: https://github.com/yrutschle/sslh/issues/284 And for the fix in code: https://github.com/yrutschle/sslh/commit/1e33455fe76078d97ea4ce1c8b856df2dea64c71 Workaround: We put a cronjob that kills/restarts sslhd every 3hours and after that we tried to update the binaries from source ourselves. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sslh/+bug/1923406/+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 1915502] Re: "systemd --user" fails to start for non-local users
** Also affects: systemd (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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1915502
Title:
"systemd --user" fails to start for non-local users
Status in systemd package in Ubuntu:
Incomplete
Status in systemd source package in Focal:
New
Bug description:
systemd-logind fails to start the systemd --user process for non-local
users on Ubuntu 20.04. This is a reproducible problem; all our
systems are displaying the same symptoms.
The systems are using Kerberos (Active Directory) for authentication,
and NIS for account meta-data and authorisation (groups)
A base installation is performed using the server 20.04 ISO image. No
additional packages are selected. Post-install, I run:
apt-get install tcsh nis krb5-user libpam-krb5 libnss-systemd
I set up the NIS client (supply the default domain name, check ypbind
is running and ypcat passwd is working)
I then set up /etc/krb5.conf for kerberos authentication to a domain
controller, confirm that kinit works and a kerberos ticket is issued.
I modify /etc/passwd, /etc/group and /etc/shadow, appending a "+" to
the end of each.
/etc/nsswitch.conf is modified to support compat mode, as well as
systemd:
passwd: compat systemd
group: compat systemd
shadow: compat
I can log in remotely via ssh using my NIS account and Kerberos
credentials. MY NIS meta-data looks like:
amcvey:KRB5:::Andy McVey:/home/amcvey:/bin/tcsh
(where UID and GID are replaced with values unique to the
organisation)
On login, the following occurs:
hostname:~> systemctl --user
Failed to connect to bus: No such file or directory
I put pam-systemd and systemd-logind into debug mode to get more
information:
Feb 12 09:51:32 myhostname sshd[1210]: Accepted publickey for amcvey from
[redact] port 58849 ssh2: RSA SHA256:[redact]
Feb 12 09:51:32 myhostname sshd[1210]: pam_unix(sshd:session): session opened
for user amcvey by (uid=0)
Feb 12 09:51:32 myhostname systemd-logind[903]: Got message type=method_call
sender=:1.13 destination=org.freedesktop.login1 path=/org/freedesktop/login1
interface=org.freedesktop.login1.Manager member=CreateSession cookie=2
reply_cookie=0 signature=uusussbssa(sv) error-name=n/a error-message=n/a
Feb 12 09:51:32 myhostname sshd[1210]: pam_systemd(sshd:session): pam-systemd
initializing
Feb 12 09:51:32 myhostname systemd-logind[903]: Sent message type=method_call
sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus
interface=org.freedesktop.DBus member=GetConnectionUnixUser cookie=40
reply_cookie=0 signature=s error-name=n/a error-message=n/a
Feb 12 09:51:32 myhostname sshd[1210]: pam_systemd(sshd:session): Asking
logind to create session: uid=198083 pid=1210 service=sshd type=tty class=user
desktop= seat= vtnr=0 tty= display= remote=yes remote_user=
remote_host=10.105.121.110
Feb 12 09:51:32 myhostname systemd-logind[903]: Got message
type=method_return sender=org.freedesktop.DBus destination=:1.6 path=n/a
interface=n/a member=n/a cookie=13 reply_cookie=40 signature=u error-name=n/a
error-message=n/a
Feb 12 09:51:32 myhostname sshd[1210]: pam_systemd(sshd:session): Session
limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a
runtime_max_sec=n/a
Feb 12 09:51:32 myhostname systemd-logind[903]: Sent message type=method_call
sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus
interface=org.freedesktop.DBus member=GetConnectionUnixProcessID cookie=41
reply_cookie=0 signature=s error-name=n/a error-message=n/a
Feb 12 09:51:32 myhostname sshd[1210]: pam_systemd(sshd:session): Failed to
create session: No such process
Feb 12 09:51:32 myhostname systemd-logind[903]: Got message
type=method_return sender=org.freedesktop.DBus destination=:1.6 path=n/a
interface=n/a member=n/a cookie=14 reply_cookie=41 signature=u error-name=n/a
error-message=n/a
Feb 12 09:51:32 myhostname systemd-logind[903]: Unable to connect to
/run/systemd/userdb/io.systemd.Multiplexer: No such file or directory
Feb 12 09:51:32 myhostname systemd-logind[903]: n/a: varlink: setting state
idle-client
Feb 12 09:51:32 myhostname systemd-logind[903]:
/run/systemd/userdb/io.systemd.DynamicUser: Sending message:
{"method":"io.systemd.UserDatabase.GetUserRecord","parameters":{"uid":198083,"service":"io.systemd.DynamicUser"}}
Feb 12 09:51:32 myhostname systemd-logind[903]:
/run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state idle-client
→ awaiting-reply
Feb 12 09:51:32 myhostname systemd-logind[903]:
/run/systemd/userdb/io.systemd.DynamicUser: New incoming message:
{"error":"io.systemd.UserDatabase.NoRecordFound","parameters":{}}
Feb 12 09:51:32 myhostname systemd-logind[903]:
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
** Changed in: systemd (Ubuntu Hirsute) Importance: Undecided => Wishlist ** Changed in: systemd (Ubuntu Groovy) Importance: Undecided => Wishlist ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => Wishlist ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Wishlist -- 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/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Groovy: New Status in systemd source package in Hirsute: New Status in systemd package in Debian: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+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 1918328] Re: kernel emits error "Bad value for 'hidepid'" with new systemd on old kernel
** Changed in: systemd (Ubuntu) Status: New => Confirmed ** Changed in: systemd (Ubuntu) Status: Confirmed => Triaged -- 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/1918328 Title: kernel emits error "Bad value for 'hidepid'" with new systemd on old kernel Status in systemd: Fix Released Status in systemd package in Ubuntu: Triaged Bug description: When using a newer systemd (>=247) and older kernel (<5.8), systemd attempts to mount /proc using a value for the 'hidepid' parameter that the older kernel doesn't understand, which causes the kernel to emit a warning message like: [4083297.870684] proc: Bad value for 'hidepid' This is harmless, as systemd falls back to the 'old' mount method, however the logged error message can be confusing. Since there is no ubuntu release where the newer systemd might be directly used with a kernel older than 5.8, this can only reasonably happen in a container on a older ubuntu release. For example, on a focal release with the 5.4 kernel, a hirsute container can be created, and when it starts up the host dmesg will log the kernel error messages shown above. Note that if using a lxd container, as there is a bug where lxd prevents mounting any fs (which mostly breaks systemd), you must set the 'security.nesting' parameter for the lxd container, e.g.: $ lxc launch ubuntu-daily:hirsute test-h $ lxc set config test-h security.nesting true Note that this hasn't been fixed upstream, and as it's purely cosmetic, it's possible it won't get fixed upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1918328/+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 1921696] Re: Failed to start Load/Save RF Kill Switch Status
** Changed in: systemd (Ubuntu) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Balint Reczey (rbalint) -- 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/1921696 Title: Failed to start Load/Save RF Kill Switch Status Status in systemd package in Ubuntu: In Progress Bug description: When I boot the system I get these lög messages - Failed to start Load/Save RF Kill Switch Statu - A start job for unit systemd-rfkill.service has failed and with sender systemd-rfkil Read event structure of invalid size Also happens on an Ubuntu system on the same computer. System details p-i@pi-tuf-b550m-wifi:~$ inxi -Fz System:Kernel: 5.11.0-11-generic x86_64 bits: 64 Desktop: Cinnamon 4.8.6 Distro: Ubuntu 21.04 (Hirsute Hippo) Machine: Type: Desktop System: ASUS product: N/A v: N/A serial: Mobo: ASUSTeK model: TUF GAMING B550M-PLUS (WI-FI) v: Rev X.0x serial: UEFI: American Megatrends v: 1804 date: 02/02/2021 CPU: Info: 6-Core model: AMD Ryzen 5 5600X bits: 64 type: MT MCP L2 cache: 3 MiB Speed: 2509 MHz min/max: 2200/4791 MHz Core speeds (MHz): 1: 2509 2: 2237 3: 2858 4: 2236 5: 2235 6: 2238 7: 2798 8: 2239 9: 2238 10: 2233 11: 2236 12: 2234 Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.10 driver: loaded: amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution: 2560x1440~60Hz OpenGL: renderer: AMD Radeon RX 5700 (NAVI10 DRM 3.40.0 5.11.0-11-generic LLVM 11.0.1) v: 4.6 Mesa 21.0.1 Audio: Device-1: Advanced Micro Devices [AMD/ATI] Navi 10 HDMI Audio driver: snd_hda_intel Device-2: Advanced Micro Devices [AMD] Starship/Matisse HD Audio driver: snd_hda_intel Device-3: Logitech Webcam C250 type: USB driver: snd-usb-audio,uvcvideo Sound Server: ALSA v: k5.11.0-11-generic Network: Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi IF: wlp6s0 state: down mac: Device-2: Realtek RTL8125 2.5GbE driver: r8169 IF: enp7s0 state: up speed: 1000 Mbps duplex: full mac: IF-ID-1: vmnet1 state: unknown speed: N/A duplex: N/A mac: IF-ID-2: vmnet8 state: unknown speed: N/A duplex: N/A mac: Bluetooth: Device-1: Intel AX200 Bluetooth type: USB driver: btusb Report: ID: hci0 state: up running pscan bt-v: 3.0 address: Drives:Local Storage: total: 1.36 TiB used: 97.88 GiB (7.0%) ID-1: /dev/nvme0n1 vendor: Corsair model: Force MP600 size: 465.76 GiB ID-2: /dev/nvme1n1 vendor: Kingston model: SA2000M8500G size: 465.76 GiB ID-3: /dev/sda vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB Partition: ID-1: / size: 456.96 GiB used: 97.84 GiB (21.4%) fs: ext4 dev: /dev/nvme0n1p2 ID-2: /boot/efi size: 511 MiB used: 33.3 MiB (6.5%) fs: vfat dev: /dev/nvme0n1p1 Swap: ID-1: swap-1 type: file size: 2 GiB used: 0 KiB (0.0%) file: /swapfile Sensors: System Temperatures: cpu: 35.9 C mobo: 39.0 C gpu: amdgpu temp: 40.0 C Fan Speeds (RPM): fan-1: 698 fan-2: 937 fan-3: 711 fan-7: 931 gpu: amdgpu fan: 0 Info: Processes: 372 Uptime: 13m Memory: 15.54 GiB used: 1.88 GiB (12.1%) Shell: Bash inxi: 3.3.01 p-i@pi-tuf-b550m-wifi:~$ ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: systemd 247.3-3ubuntu1 ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 Uname: Linux 5.11.0-11-generic x86_64 ApportVersion: 2.20.11-0ubuntu61 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: X-Cinnamon Date: Mon Mar 29 10:12:21 2021 InstallationDate: Installed on 2021-02-05 (51 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Alpha amd64 (20210203) MachineType: ASUS System Product Name ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-11-generic root=UUID=d37b6e75-43a0-4e56-85c1-4a6ef8e1ffc9 ro acpi_enforce_resources=lax quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-es
[Touch-packages] [Bug 1922485] Re: systemd: slice: Failed to migrate controller cgroups
The switch of the default did not happen yet in Ubuntu because snapd is not ready: LP: #1850667. The plan is switching to cgroupv2 as default in the 21.10 development cycle. ** Changed in: systemd (Ubuntu) Status: New => Triaged -- 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/1922485 Title: systemd: slice: Failed to migrate controller cgroups Status in systemd: Fix Released Status in systemd package in Ubuntu: Triaged Status in systemd package in Debian: Fix Released Bug description: Hi, during boot those error messages appear in the logs: # journalctl | grep controller [...] Apr 02 20:16:23 vougeot systemd[3155]: -.slice: Failed to migrate controller cgroups from /user.slice/user-108.slice/user@108.service, ignoring: Permission denied Apr 02 20:16:31 vougeot systemd[3512]: -.slice: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service, ignoring: Permission denied ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: systemd 247.3-3ubuntu2 Uname: Linux 5.11.11-05-lowlatency x86_64 ApportVersion: 2.20.11-0ubuntu61 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Apr 4 13:29:25 2021 MachineType: TUXEDO TUXEDO InfinityBook S 15 Gen6 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.11-05-lowlatency root=/dev/mapper/MonVolume2-UbuntuRacine ro vsyscall=none security=apparmor quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/07/2020 dmi.bios.release: 7.3 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 1.07.03RTR dmi.board.name: NS50MU dmi.board.vendor: TUXEDO dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.ec.firmware.release: 7.2 dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.03RTR:bd09/07/2020:br7.3:efr7.2:svnTUXEDO:pnTUXEDOInfinityBookS15Gen6:pvrNotApplicable:rvnTUXEDO:rnNS50MU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A: dmi.product.family: Not Applicable dmi.product.name: TUXEDO InfinityBook S 15 Gen6 dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: TUXEDO modified.conffile..etc.systemd.resolved.conf: [modified] mtime.conffile..etc.systemd.resolved.conf: 2021-04-02T13:37:46.839143 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1922485/+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 1874824] Re: pgrep reports error "cannot allocate" when run without stack limit
I've sponsored the SRUs. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1874824 Title: pgrep reports error "cannot allocate" when run without stack limit Status in procps package in Ubuntu: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Groovy: In Progress Status in procps source package in Hirsute: Fix Released Status in procps package in Debian: New Bug description: [Impact] - Users who have ulimit set high would see either slow or failed pgrep and pkill commands - Users who have ulimit set to unlimited would see failed pgrep and pkill commands - This bug occurs because the behavior of sysconf(_SC_ARG_MAX) changed with a newer version of the kernel. [Test Case] - set the ulimit to unlimited by running `ulimit -S -s unlimited` - run `pgrep bash` to see that the "cannot allocate" error is printed and the command has failed. [Where Problems Could Occur] - We have set upper and lower limits on the size of the malloc, but if further kernel versions break the call to sysconf in unexpected ways we could still see problems. [Original Description] If you have no stack limit (ulimit -S -s unlimited), any pgrep call will fail with an error: > pgrep vim pgrep: cannot allocate 4611686018427387903 bytes If you have a high stack limit (e.g. ulimit -S -s 50), pgrep is very slow: > time pgrep vim 2196 real 8.48s user 8.40s syst 0.07s busy 99% rmem 253444 The relevant upstream bug report could be: https://gitlab.com/procps-ng/procps/-/issues/152 Archlinux bug report: https://bugs.archlinux.org/task/66093 procps: Installed: 2:3.3.16-1ubuntu2 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1874824/+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 1908241] Re: README.sysctl refers to "service procps reload", which no longer works
Forwarded the fix to Debian:
https://salsa.debian.org/debian/procps/-/merge_requests/2
It is not a good time to apply it in 21.04, because we are close to the
release.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1908241
Title:
README.sysctl refers to "service procps reload", which no longer works
Status in procps package in Ubuntu:
Confirmed
Bug description:
/etc/sysctl.d/README.sysctl states:
After making any changes, please run "service procps reload" (or, from
a Debian package maintainer script "deb-systemd-invoke restart
procps.service").
However, "service procps reload" no longer works:
$ sudo service procps reload
Usage: /etc/init.d/procps {start|stop|status|restart|try-restart|force-reload}
It looks like the correct command should be "service procps force-
reload"?
Local versions:
Ubuntu 20.04.1 LTS
procps 2:3.3.16-1ubuntu2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1908241/+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 1908241] Re: README.sysctl refers to "service procps reload", which no longer works
BTW the reload was added to fix this bug: LP: #1719159.
** Changed in: procps (Ubuntu)
Importance: Undecided => Low
** Changed in: procps (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/1908241
Title:
README.sysctl refers to "service procps reload", which no longer works
Status in procps package in Ubuntu:
Confirmed
Bug description:
/etc/sysctl.d/README.sysctl states:
After making any changes, please run "service procps reload" (or, from
a Debian package maintainer script "deb-systemd-invoke restart
procps.service").
However, "service procps reload" no longer works:
$ sudo service procps reload
Usage: /etc/init.d/procps {start|stop|status|restart|try-restart|force-reload}
It looks like the correct command should be "service procps force-
reload"?
Local versions:
Ubuntu 20.04.1 LTS
procps 2:3.3.16-1ubuntu2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1908241/+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 1806076] Re: unattended-upgrade --help raises UnicodeEncodeError when stdout encoding is ascii
** Description changed: [Impact] - * unattended-upgrades --help crashes in apt.systemd.daily script when + * unattended-upgrades --help crashes in apt.systemd.daily script when locale is not in UTF-8. [Test Case] In the fixed case no crash is observed. rbalint@yogi:~$ lxc launch ubuntu:18.04 bb-lp-1806076 Creating bb-lp-1806076 Starting bb-lp-1806076 rbalint@yogi:~$ lxc shell bb-lp-1806076 mesg: ttyname failed: No such device root@bb-lp-1806076:~# apt install -yqq language-pack-ru-base The following package was automatically installed and is no longer required: libfreetype6 Use 'apt autoremove' to remove it. The following additional packages will be installed: language-pack-ru The following NEW packages will be installed: language-pack-ru language-pack-ru-base 0 upgraded, 2 newly installed, 0 to remove and 7 not upgraded. Need to get 2310 kB of archives. After this operation, 11.8 MB of additional disk space will be used. Selecting previously unselected package language-pack-ru-base. (Reading database ... 28536 files and directories currently installed.) Preparing to unpack .../language-pack-ru-base_1%3a18.04+20180712_all.deb ... Unpacking language-pack-ru-base (1:18.04+20180712) ... Selecting previously unselected package language-pack-ru. Preparing to unpack .../language-pack-ru_1%3a18.04+20180712_all.deb ... Unpacking language-pack-ru (1:18.04+20180712) ... Setting up language-pack-ru (1:18.04+20180712) ... Setting up language-pack-ru-base (1:18.04+20180712) ... Generating locales (this might take a while)... ru_RU.UTF-8... done ru_UA.UTF-8... done Generation complete. - root@bb-lp-1806076:~# echo LANG=ru_RU | tee /etc/default/locale + root@bb-lp-1806076:~# echo LANG=ru_RU | tee /etc/default/locale LANG=ru_RU root@bb-lp-1806076:~# /usr/lib/apt/apt.systemd.daily update Traceback (most recent call last): - File "/usr/bin/unattended-upgrade", line 2171, in - (options, args) = parser.parse_args() # type: ignore - File "/usr/lib/python3.6/optparse.py", line 1387, in parse_args - stop = self._process_args(largs, rargs, values) - File "/usr/lib/python3.6/optparse.py", line 1427, in _process_args - self._process_long_opt(rargs, values) - File "/usr/lib/python3.6/optparse.py", line 1501, in _process_long_opt - option.process(opt, value, values, self) - File "/usr/lib/python3.6/optparse.py", line 785, in process - self.action, self.dest, opt, value, values, parser) - File "/usr/lib/python3.6/optparse.py", line 807, in take_action - parser.print_help() - File "/usr/lib/python3.6/optparse.py", line 1647, in print_help - file.write(self.format_help()) + File "/usr/bin/unattended-upgrade", line 2171, in + (options, args) = parser.parse_args() # type: ignore + File "/usr/lib/python3.6/optparse.py", line 1387, in parse_args + stop = self._process_args(largs, rargs, values) + File "/usr/lib/python3.6/optparse.py", line 1427, in _process_args + self._process_long_opt(rargs, values) + File "/usr/lib/python3.6/optparse.py", line 1501, in _process_long_opt + option.process(opt, value, values, self) + File "/usr/lib/python3.6/optparse.py", line 785, in process + self.action, self.dest, opt, value, values, parser) + File "/usr/lib/python3.6/optparse.py", line 807, in take_action + parser.print_help() + File "/usr/lib/python3.6/optparse.py", line 1647, in print_help + file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 126-133: ordinal not in range(128) - root@bb-lp-1806076:~# echo LANG=ru_RU.UTF-8 | tee /etc/default/locale + root@bb-lp-1806076:~# echo LANG=ru_RU.UTF-8 | tee /etc/default/locale LANG=ru_RU.UTF-8 root@bb-lp-1806076:~# /usr/lib/apt/apt.systemd.daily update root@bb-lp-1806076:~# [Where problems could occur] - * Nowhere, really. The fix is setting LC_ALL=C.UFT-8 for u-u --help and + * Nowhere, really. The fix is setting LC_ALL=C.UTF-8 for u-u --help and it is processed by grep then. - [Original Bug Text] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 1.1ubuntu1.18.04.6, the problem page at https://errors.ubuntu.com/problem/b3e3265e302351558260f54ae37c7b4c193dfc95 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. Also seen in: * https://errors.ubuntu.com/problem/936bb1c75c4efe018f968a5773b820bcf52c298a -- 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/1806076 Title: unattended-upgrade --help
[Touch-packages] [Bug 1915887] Re: systemd spams the syslog about lack of native systemd unit file
Fixed in Hirsute in 247.3-2ubuntu1 . ** Changed in: systemd (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915887 Title: systemd spams the syslog about lack of native systemd unit file Status in apport package in Ubuntu: Invalid Status in fam package in Ubuntu: Invalid Status in freeradius package in Ubuntu: Invalid Status in ipfm package in Ubuntu: Invalid Status in n2n package in Ubuntu: Invalid Status in pfm package in Ubuntu: Invalid Status in shadowsocks package in Ubuntu: Invalid Status in sysfsutils package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in virtualbox package in Ubuntu: Invalid Status in xl2tpd package in Ubuntu: Invalid Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Committed Status in systemd package in Debian: Fix Released Bug description: [impact] systemd spams journal with log messages [test case] see journalctl output and search for msgs similar to those listed in original description below [regression potential] any regession would likely result in logs incorrectly not logged when detecting a problem such as lack of native unit file, or using /var/run. [scope] this is needed in f/g this is fixed upstream with commit https://salsa.debian.org/systemd- team/systemd/-/commit/0c6d90f783093fc255e529f8a33b2ed2a8e6c2d6 from debian, which is included in 247.3-2 and later so this is fixed in hirsute already (in -proposed package). these log messages aren't present in b or earlier so aren't needed in x/b [original description] systemd in hirsute spams the syslog file several times per second about services lacking native systemd unit files. Two things should happen. 1) a systemd unit file ought to be created 2) systemd should be slowed down with regards to these messages Feb 17 02:02:48 ubuntu-devel kernel: [ 289.794825] systemd-sysv-generator[7105]: SysV service '/etc/init.d/n2n' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:02:49 ubuntu-devel kernel: [ 290.165351] systemd-sysv-generator[7126]: SysV service '/etc/init.d/n2n' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:02:49 ubuntu-devel kernel: [ 291.111278] systemd-sysv-generator[7170]: SysV service '/etc/init.d/n2n' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:02:50 ubuntu-devel kernel: [ 291.507164] systemd-sysv-generator[7199]: SysV service '/etc/init.d/n2n' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.386062] systemd-sysv-generator[9909]: SysV service '/etc/init.d/fam' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.386321] systemd-sysv-generator[9909]: SysV service '/etc/init.d/xl2tpd' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.386742] systemd-sysv-generator[9909]: SysV service '/etc/init.d/ipfm' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.386767] systemd-sysv-generator[9909]: SysV service '/etc/init.d/shadowsocks' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.387281] systemd-sysv-generator[9909]: SysV service '/etc/init.d/virtualbox' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.388931] systemd-sysv-generator[9909]: SysV
[Touch-packages] [Bug 1921574] Re: package libpam-systemd:amd64 246.6-1ubuntu1.2 failed to install/upgrade: installed libpam-systemd:amd64 package post-installation script subprocess returned error ex
*** This bug is a duplicate of bug 1699360 *** https://bugs.launchpad.net/bugs/1699360 Use of uninitialized value $ret in string eq at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 134. dpkg: error processing package libpam-systemd:amd64 (--configure): installed libpam-systemd:amd64 package post-installation script subprocess returned error exit status 128 libpam-systemd.postinst is very short: --- #!/bin/sh set -e pam-auth-update --package #DEBHELPER# --- , and debhelper does not inject any script. I think the most likely cause is debconf connection with the graphical front end going away. ** This bug has been marked a duplicate of bug 1699360 package libpam-systemd:amd64 232-21ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128 -- 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/1921574 Title: package libpam-systemd:amd64 246.6-1ubuntu1.2 failed to install/upgrade: installed libpam-systemd:amd64 package post- installation script subprocess returned error exit status 128 Status in systemd package in Ubuntu: New Bug description: I have no extra information. ProblemType: Package DistroRelease: Ubuntu 20.10 Package: libpam-systemd:amd64 246.6-1ubuntu1.2 ProcVersionSignature: Ubuntu 5.8.0-44.50-generic 5.8.18 Uname: Linux 5.8.0-44-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 CasperMD5CheckResult: skip Date: Tue Mar 23 18:28:20 2021 ErrorMessage: installed libpam-systemd:amd64 package post-installation script subprocess returned error exit status 128 InstallationDate: Installed on 2020-12-07 (110 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) Python3Details: /usr/bin/python3.8, Python 3.8.6, python3-minimal, 3.8.6-0ubuntu1 PythonDetails: N/A RelatedPackageVersions: dpkg 1.20.5ubuntu2 apt 2.1.10ubuntu0.2 SourcePackage: systemd Title: package libpam-systemd:amd64 246.6-1ubuntu1.2 failed to install/upgrade: installed libpam-systemd:amd64 package post-installation script subprocess returned error exit status 128 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1921574/+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 1920781] Re: Mobile phone hotspot unusable due to systemd-resolved not liking the DNS
** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Groovy) 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/1920781 Title: Mobile phone hotspot unusable due to systemd-resolved not liking the DNS Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Status in systemd source package in Groovy: New Bug description: Seen in 20.04. Trying to connect to the internet using the mobile phone hotspot is impossible due to systemd-resolved not resolving and reporting things like: resolve call failed: DNSSEC validation failed: incompatible-server and systemd-resolved[81699]: DNSSEC validation failed for question d.3.1.b.d.e.1.e.1.6.9.e.7.8.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN PTR: no-signature DNSSEC validation failed for question b.d.e.1.e.1.6.9.e.7.8.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN DS: no-signature etc etc. Name resolution works just fine from the mobile phone. Funny thing is that the issue persists if DNSSEC is disabled via resolvectl for the interface: Link 3 (wlan0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: opportunistic DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.43.1 DNS Servers: 192.168.43.1 Systemd-resolved won't accept the issue to be reported upstream saying that a too old version of systemd is being used. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.5 ProcVersionSignature: Ubuntu 5.8.0-45.51~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-45-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.16 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Mon Mar 22 15:39:23 2021 EcryptfsInUse: Yes InstallationDate: Installed on 2020-02-16 (400 days ago) InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: SCHENKER SCHENKER_SLIM14_SSL14L19 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-45-generic root=/dev/mapper/VG_NVMe-root ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: Upgraded to focal on 2020-05-23 (303 days ago) dmi.bios.date: 10/02/2019 dmi.bios.release: 7.4 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 1.07.04RTR1 dmi.board.asset.tag: Tag 12345 dmi.board.name: N141CU dmi.board.vendor: SCHENKER dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.ec.firmware.release: 7.2 dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.04RTR1:bd10/02/2019:br7.4:efr7.2:svnSCHENKER:pnSCHENKER_SLIM14_SSL14L19:pvrNotApplicable:rvnSCHENKER:rnN141CU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A: dmi.product.family: Not Applicable dmi.product.name: SCHENKER_SLIM14_SSL14L19 dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: SCHENKER modified.conffile..etc.systemd.resolved.conf: [modified] mtime.conffile..etc.systemd.resolved.conf: 2021-02-10T11:20:21.512139 mtime.conffile..etc.systemd.sleep.conf: 2020-08-13T07:55:23.365733 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1920781/+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 1921636] Re: resolved CNAME redirect issues
** Also affects: systemd (Ubuntu Groovy) 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/1921636 Title: resolved CNAME redirect issues Status in systemd package in Ubuntu: New Status in systemd source package in Groovy: New Bug description: I am having issues loading certain websites such as linkedin.com and portions of google sites including images.google.com, hotmail.com login, etc. After looking through some logs and such I've determined that resolved is not properly following CNAMEs to an IP address. Querying the DNS server on my network directly for the info works fine. Loading the sites from other computers on the network works fine. In the #systemd IRC channel I was directed to the following two issues: https://github.com/systemd/systemd/pull/18892 https://github.com/systemd/systemd/pull/19009 System info: Ubuntu 20.10 ii systemd246.6-1ubuntu1.2 amd64system and service manager ii linux-generic 5.8.0.48.53 amd64Complete Generic Linux kernel and headers Example: [11:06:00] host static-exp1.licdn.com Host static-exp1.licdn.com not found: 2(SERVFAIL) [11:06:17] resolvectl status Global LLMNR setting: no MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no DNS Domain: rhos.bigfiber.net bigfiber.net Link 2 (enp6s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Link 3 (enp4s0f0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 10.18.1.1 DNS Servers: 10.18.1.1 DNS Domain: ~. rhos.bigfiber.net bigfiber.net Link 4 (enp4s0f1) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no [11:06:26] host static-exp1.licdn.com 10.18.1.1 Using domain server: Name: 10.18.1.1 Address: 10.18.1.1#53 Aliases: static-exp1.licdn.com is an alias for 2-01-2c3e-003d.cdx.cedexis.net. 2-01-2c3e-003d.cdx.cedexis.net is an alias for li-prod-static.azureedge.net. li-prod-static.azureedge.net is an alias for li-prod-static.afd.azureedge.net. li-prod-static.afd.azureedge.net is an alias for star-azureedge-prod.trafficmanager.net. star-azureedge-prod.trafficmanager.net is an alias for dual.t-0009.t-msedge.net. dual.t-0009.t-msedge.net is an alias for t-0009.t-msedge.net. t-0009.t-msedge.net is an alias for Edge-Prod-WSTr3.ctrl.t-0009.t-msedge.net. Edge-Prod-WSTr3.ctrl.t-0009.t-msedge.net is an alias for edge-prod-wstr3.ctrl.t-0001.trafficmanager.net. edge-prod-wstr3.ctrl.t-0001.trafficmanager.net is an alias for standard.t-0009.t-msedge.net. standard.t-0009.t-msedge.net has address 13.107.213.19 standard.t-0009.t-msedge.net has address 13.107.246.19 standard.t-0009.t-msedge.net has IPv6 address 2620:1ec:46::19 standard.t-0009.t-msedge.net has IPv6 address 2620:1ec:bdf::19 resolved debugging log is attached. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1921636/+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 1916485] Re: test -x fails inside shell scripts in containers
** Bug watch added: Debian Bug tracker #984573 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984573 ** Also affects: docker.io (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984573 Importance: Unknown Status: Unknown ** No longer affects: docker.io (Debian) ** Also affects: systemd (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984573 Importance: Unknown Status: Unknown -- 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/1916485 Title: test -x fails inside shell scripts in containers Status in docker.io package in Ubuntu: New Status in glibc package in Ubuntu: Opinion Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in docker.io source package in Xenial: New Status in libseccomp source package in Xenial: New Status in runc source package in Xenial: New Status in systemd source package in Xenial: New Status in docker.io source package in Bionic: New Status in libseccomp source package in Bionic: New Status in runc source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Committed Status in docker.io source package in Focal: New Status in libseccomp source package in Focal: New Status in runc source package in Focal: Fix Committed Status in systemd source package in Focal: Fix Committed Status in docker.io source package in Groovy: New Status in libseccomp source package in Groovy: New Status in runc source package in Groovy: Fix Committed Status in systemd source package in Groovy: Fix Released Status in docker.io source package in Hirsute: New Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: Fix Released Status in systemd source package in Hirsute: Fix Released Status in systemd package in Debian: Unknown Bug description: (SRU template for systemd) [impact] bash (and some other shells) builtin test command -x operation fails [test case] on any affected host system, start nspawn container, e.g.: $ sudo apt install systemd-container $ wget https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz $ mkdir h $ cd h $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz $ sudo systemd-nspawn Then from a bash shell, verify if test -x works: root@h:~# ls -l /usr/bin/gpg -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg root@h:~# test -x /usr/bin/gpg || echo "fail" fail [regression potential] any regression would likely occur during a syscall, most likely faccessat2(), or during other syscalls. [scope] this is needed for b/f this is fixed upstream by commit bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so this is fixed in h this was pulled into Debian at version 246.2 in commit e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g in x, the entire systemd seccomp code is completely different and the patch doesn't apply, nor does it appear to be needed, as the problem doesn't reproduce in a h container under x. [other info] this needs fixing in libseccomp as well [original description] glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all
[Touch-packages] [Bug 1404003] Re: glibc vulnerability CVE-2014-9402
** Also affects: glibc (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: eglibc (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: glibc (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: eglibc (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: glibc (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: eglibc (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: glibc (Ubuntu Xenial) Status: New => Fix Released ** Changed in: glibc (Ubuntu Bionic) Status: New => Fix Released ** Changed in: glibc (Ubuntu Focal) Status: New => Fix Released ** Changed in: glibc (Ubuntu) Status: Triaged => Fix Released ** Changed in: eglibc (Ubuntu Xenial) Status: New => Invalid ** Changed in: eglibc (Ubuntu Bionic) Status: New => Invalid ** Changed in: eglibc (Ubuntu Focal) Status: New => Invalid ** Changed in: eglibc (Ubuntu) Status: Triaged => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to eglibc in Ubuntu. https://bugs.launchpad.net/bugs/1404003 Title: glibc vulnerability CVE-2014-9402 Status in eglibc package in Ubuntu: Invalid Status in glibc package in Ubuntu: Fix Released Status in eglibc source package in Xenial: Invalid Status in glibc source package in Xenial: Fix Released Status in eglibc source package in Bionic: Invalid Status in glibc source package in Bionic: Fix Released Status in eglibc source package in Focal: Invalid Status in glibc source package in Focal: Fix Released Bug description: https://sourceware.org/bugzilla/show_bug.cgi?id=17630 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=11e3417af6e354f1942c68a271ae51e892b2814d To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1404003/+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 1920601] Re: Frequent test failures caused by networking issues on armhf runners
@laney IMO 'Confirmed' would be the accurate state since the root cause is not known. I used to be a proponent of adding more retry strings but they also cause retry lool of test failures. I think APT should retry on timeouts instead, thus adding APT as affected package. ** Also affects: apt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1920601 Title: Frequent test failures caused by networking issues on armhf runners Status in Auto Package Testing: Triaged Status in apt package in Ubuntu: New Bug description: Armhf runners have been known to have networking issues for years. A test of Focal's glibc SRU in Bileto shows that those issues did not go away. The glibc package itself is not expected to cause regression, this was just a run to confirm that. The test resuts are shown here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-4017-excuses/2021-03-20_09:25:01/4017_focal_excuses.html Out of the 114 failed tests 58 containst the 'Connection timed out' string and only test logs from armhf contain that string: $ zgrep -l 'Connection timed out' ~/.cache/ubuntu-archive-tools/focal_*.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_atk1.0_20210318_182825_daefa.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_axe-demultiplexer_20210318_183430_6b008.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_bacula_20210318_190411_e3ad7.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_dialign-t_20210318_204503_b4d94.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_elisa-player_20210318_211129_9537d.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_fyba_20210318_181755_7731e.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_gcc-7_20210318_02_4d95c.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_gcc-8_20210318_221659_0e69f.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_golang-github-mailru-easyjson_20210318_231917_67888.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_gphoto2_20210318_200015_eb767.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_gtk+3.0_20210318_235412_db3e5.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_ipmitool_20210319_003215_d03da.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_kbibtex_20210319_004639_0ac1a.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_kcptun_20210318_193309_6dcd9.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libcache-memcached-getparserxs-perl_20210319_024051_33029.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libclass-load-xs-perl_20210319_025846_01419.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libconvert-uulib-perl_20210319_034852_21cd1.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libhat-trie_20210319_060826_fd334.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libhtml-tidy5-perl_20210319_070723_05fa8.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libimager-perl_20210319_063314_b19a2.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libipc-sharelite-perl_20210319_072246_0217e.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_liblexical-var-perl_20210319_070235_4c450.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libmarpa-r2-perl_20210319_073731_f7554.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libmemcached-libmemcached-perl_20210319_011004_dbca1.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libnet-ldns-perl_20210319_081224_49912.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libnet-pcap-perl_20210319_081606_4d772.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libparams-util-perl_20210319_084831_74d13.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libperlio-eol-perl_20210319_085645_97c6c.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libperlio-layers-perl_20210319_085937_8bd70.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libsass_20210319_092518_4db37.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libsdl-perl_20210319_095502_00c8c.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libtext-bibtex-perl_20210319_105027_abf4a.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libtext-hunspell-perl_20210319_103326_4a603.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libunix-syslog-perl_20210319_111403_f4374.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libwx-scintilla-perl_20210319_114818_a6aab.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_libzstd_20210319_114737_0c4d9.gz /home/rbalint/.cache/ubuntu-archive-tools/focal_armhf_mod-gearman_20210319_132205_d41ca.gz
[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers
** Also affects: glibc (Ubuntu) Importance: Undecided Status: New ** Changed in: glibc (Ubuntu) Status: New => Opinion -- 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/1916485 Title: test -x fails inside shell scripts in containers Status in docker.io package in Ubuntu: New Status in glibc package in Ubuntu: Opinion Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in docker.io source package in Xenial: New Status in libseccomp source package in Xenial: New Status in runc source package in Xenial: New Status in systemd source package in Xenial: New Status in docker.io source package in Bionic: New Status in libseccomp source package in Bionic: New Status in runc source package in Bionic: Fix Committed Status in systemd source package in Bionic: New Status in docker.io source package in Focal: New Status in libseccomp source package in Focal: New Status in runc source package in Focal: Fix Committed Status in systemd source package in Focal: New Status in docker.io source package in Groovy: New Status in libseccomp source package in Groovy: New Status in runc source package in Groovy: Fix Committed Status in systemd source package in Groovy: Fix Released Status in docker.io source package in Hirsute: New Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: Fix Released Status in systemd source package in Hirsute: Fix Released Bug description: (SRU template for systemd) [impact] bash (and some other shells) builtin test command -x operation fails [test case] on any affected host system, start nspawn container, e.g.: $ sudo apt install systemd-container $ wget https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz $ mkdir h $ cd h $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz $ sudo systemd-nspawn Then from a bash shell, verify if test -x works: root@h:~# ls -l /usr/bin/gpg -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg root@h:~# test -x /usr/bin/gpg || echo "fail" fail [regression potential] any regression would likely occur during a syscall, most likely faccessat2(), or during other syscalls. [scope] this is needed for b/f this is fixed upstream by commit bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so this is fixed in h this was pulled into Debian at version 246.2 in commit e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g in x, the entire systemd seccomp code is completely different and the patch doesn't apply, nor does it appear to be needed, as the problem doesn't reproduce in a h container under x. [other info] this needs fixing in libseccomp as well [original description] glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce
[Touch-packages] [Bug 1907472] Re: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed
I've observed the failure in the i386 build of glibc_2.33-0ubuntu4: Linux lcy01-amd64-014 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 i686 athlon i686 GNU/Linux ... if [ -f /proc/cpuinfo ] ; then cat /proc/cpuinfo ; fi processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Opteron 23xx (Gen 3 Class Opteron) stepping: 3 microcode : 0x165 cpu MHz : 2500.048 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb lm 3dnowext 3dnow rep_good nopl cpuid extd_apicid tsc_known_freq pni cx16 x2apic popcnt hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw vmmcall bugs: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bogomips: 5000.09 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ... +-+ | Encountered regressions that don't match expected failures. | +-+ FAIL: math/test-double-libmvec-sincos FAIL: math/test-double-vlen2-sincos FAIL: math/test-float-libmvec-sincosf FAIL: math/test-float-vlen4-sincos touch /<>/stamp-dir/check_x32 CHECK SUMMARY check for check_libc passed check for check_amd64 passed check for check_x32 failed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1907472 Title: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed Status in audit package in Ubuntu: New Status in binutils package in Ubuntu: New Status in glibc package in Ubuntu: New Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- hirsute/hirsute/amd64/g/glibc/20201208_160143_17354@/log.gz -- FAIL: math/test-double-libmvec-sincos original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-double-vlen2-sincos original exit status 132 -- -- FAIL: math/test-float-libmvec-sincosf original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-float-vlen4-sincos original exit status 132 -- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1907472/+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 1806076] Re: unattended-upgrade --help raises UnicodeEncodeError when stdout encoding is ascii
** Description changed: + [Impact] + + * unattended-upgrades --help crashes in apt.systemd.daily script when + locale is not in UTF-8. + [Test Case] + + In the fixed case no crash is observed. rbalint@yogi:~$ lxc launch ubuntu:18.04 bb-lp-1806076 Creating bb-lp-1806076 Starting bb-lp-1806076 rbalint@yogi:~$ lxc shell bb-lp-1806076 mesg: ttyname failed: No such device root@bb-lp-1806076:~# apt install -yqq language-pack-ru-base The following package was automatically installed and is no longer required: libfreetype6 Use 'apt autoremove' to remove it. The following additional packages will be installed: language-pack-ru The following NEW packages will be installed: language-pack-ru language-pack-ru-base 0 upgraded, 2 newly installed, 0 to remove and 7 not upgraded. Need to get 2310 kB of archives. After this operation, 11.8 MB of additional disk space will be used. Selecting previously unselected package language-pack-ru-base. (Reading database ... 28536 files and directories currently installed.) Preparing to unpack .../language-pack-ru-base_1%3a18.04+20180712_all.deb ... Unpacking language-pack-ru-base (1:18.04+20180712) ... Selecting previously unselected package language-pack-ru. Preparing to unpack .../language-pack-ru_1%3a18.04+20180712_all.deb ... Unpacking language-pack-ru (1:18.04+20180712) ... Setting up language-pack-ru (1:18.04+20180712) ... Setting up language-pack-ru-base (1:18.04+20180712) ... Generating locales (this might take a while)... ru_RU.UTF-8... done ru_UA.UTF-8... done Generation complete. - root@bb-lp-1806076:~# env LANG=ru_RU unattended-upgrade --help | cat + + root@bb-lp-1806076:~# echo LANG=ru_RU | tee /etc/default/locale + LANG=ru_RU + root@bb-lp-1806076:~# + /usr/lib/apt/apt.systemd.daily update Traceback (most recent call last): - File "/usr/bin/unattended-upgrade", line 1983, in - (options, args) = parser.parse_args() # type: ignore - File "/usr/lib/python3.6/optparse.py", line 1387, in parse_args - stop = self._process_args(largs, rargs, values) - File "/usr/lib/python3.6/optparse.py", line 1427, in _process_args - self._process_long_opt(rargs, values) - File "/usr/lib/python3.6/optparse.py", line 1501, in _process_long_opt - option.process(opt, value, values, self) - File "/usr/lib/python3.6/optparse.py", line 785, in process - self.action, self.dest, opt, value, values, parser) - File "/usr/lib/python3.6/optparse.py", line 807, in take_action - parser.print_help() - File "/usr/lib/python3.6/optparse.py", line 1647, in print_help - file.write(self.format_help()) + File "/usr/bin/unattended-upgrade", line 2171, in + (options, args) = parser.parse_args() # type: ignore + File "/usr/lib/python3.6/optparse.py", line 1387, in parse_args + stop = self._process_args(largs, rargs, values) + File "/usr/lib/python3.6/optparse.py", line 1427, in _process_args + self._process_long_opt(rargs, values) + File "/usr/lib/python3.6/optparse.py", line 1501, in _process_long_opt + option.process(opt, value, values, self) + File "/usr/lib/python3.6/optparse.py", line 785, in process + self.action, self.dest, opt, value, values, parser) + File "/usr/lib/python3.6/optparse.py", line 807, in take_action + parser.print_help() + File "/usr/lib/python3.6/optparse.py", line 1647, in print_help + file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 126-133: ordinal not in range(128) - root@bb-lp-1806076:~# env LANG=ru_RU.UTF-8 unattended-upgrade --help | cat - Usage: unattended-upgrade [options] + root@bb-lp-1806076:~# echo LANG=ru_RU.UTF-8 | tee /etc/default/locale + LANG=ru_RU.UTF-8 + root@bb-lp-1806076:~# /usr/lib/apt/apt.systemd.daily update + root@bb-lp-1806076:~# - Options: - -h, --helpshow this help message and exit - -d, --debug print debug messages - --apt-debug make apt/libapt print verbose debug messages - -v, --verbose print info messages - --dry-run Simulation, download but do not install - --download-only Only download, do not even try to install. - --minimal-upgrade-steps - Upgrade in minimal steps (and allow interrupting with - SIGTERM + [Where problems could occur] + + * Nowhere, really. The fix is setting LC_ALL=C.UFT-8 for u-u --help and + it is processed by grep then. + [Original Bug Text] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 1.1ubuntu1.18.04.6, the problem page at https://errors.ubuntu.com/problem/b3e3265e302351558260f54ae37c7b4c193dfc95 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error
[Touch-packages] [Bug 1806076] Re: unattended-upgrade --help raises UnicodeEncodeError when stdout encoding is ascii
** Changed in: unattended-upgrades (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: New => Won't Fix -- 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/1806076 Title: unattended-upgrade --help raises UnicodeEncodeError when stdout encoding is ascii Status in apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Won't Fix Status in apt source package in Xenial: New Status in unattended-upgrades source package in Xenial: Won't Fix Status in apt source package in Bionic: Triaged Status in unattended-upgrades source package in Bionic: Won't Fix Bug description: [Test Case] rbalint@yogi:~$ lxc launch ubuntu:18.04 bb-lp-1806076 Creating bb-lp-1806076 Starting bb-lp-1806076 rbalint@yogi:~$ lxc shell bb-lp-1806076 mesg: ttyname failed: No such device root@bb-lp-1806076:~# apt install -yqq language-pack-ru-base The following package was automatically installed and is no longer required: libfreetype6 Use 'apt autoremove' to remove it. The following additional packages will be installed: language-pack-ru The following NEW packages will be installed: language-pack-ru language-pack-ru-base 0 upgraded, 2 newly installed, 0 to remove and 7 not upgraded. Need to get 2310 kB of archives. After this operation, 11.8 MB of additional disk space will be used. Selecting previously unselected package language-pack-ru-base. (Reading database ... 28536 files and directories currently installed.) Preparing to unpack .../language-pack-ru-base_1%3a18.04+20180712_all.deb ... Unpacking language-pack-ru-base (1:18.04+20180712) ... Selecting previously unselected package language-pack-ru. Preparing to unpack .../language-pack-ru_1%3a18.04+20180712_all.deb ... Unpacking language-pack-ru (1:18.04+20180712) ... Setting up language-pack-ru (1:18.04+20180712) ... Setting up language-pack-ru-base (1:18.04+20180712) ... Generating locales (this might take a while)... ru_RU.UTF-8... done ru_UA.UTF-8... done Generation complete. root@bb-lp-1806076:~# env LANG=ru_RU unattended-upgrade --help | cat Traceback (most recent call last): File "/usr/bin/unattended-upgrade", line 1983, in (options, args) = parser.parse_args() # type: ignore File "/usr/lib/python3.6/optparse.py", line 1387, in parse_args stop = self._process_args(largs, rargs, values) File "/usr/lib/python3.6/optparse.py", line 1427, in _process_args self._process_long_opt(rargs, values) File "/usr/lib/python3.6/optparse.py", line 1501, in _process_long_opt option.process(opt, value, values, self) File "/usr/lib/python3.6/optparse.py", line 785, in process self.action, self.dest, opt, value, values, parser) File "/usr/lib/python3.6/optparse.py", line 807, in take_action parser.print_help() File "/usr/lib/python3.6/optparse.py", line 1647, in print_help file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 126-133: ordinal not in range(128) root@bb-lp-1806076:~# env LANG=ru_RU.UTF-8 unattended-upgrade --help | cat Usage: unattended-upgrade [options] Options: -h, --helpshow this help message and exit -d, --debug print debug messages --apt-debug make apt/libapt print verbose debug messages -v, --verbose print info messages --dry-run Simulation, download but do not install --download-only Only download, do not even try to install. --minimal-upgrade-steps Upgrade in minimal steps (and allow interrupting with SIGTERM [Original Bug Text] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 1.1ubuntu1.18.04.6, the problem page at https://errors.ubuntu.com/problem/b3e3265e302351558260f54ae37c7b4c193dfc95 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. Also seen in: * https://errors.ubuntu.com/problem/936bb1c75c4efe018f968a5773b820bcf52c298a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1806076/+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 1916485] Re: test -x fails inside shell scripts in containers
** Changed in: glibc (Ubuntu Xenial) Status: New => Invalid ** Changed in: glibc (Ubuntu Bionic) Status: New => Invalid ** Changed in: glibc (Ubuntu Focal) Status: New => Invalid ** Changed in: glibc (Ubuntu Groovy) Status: New => 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/1916485 Title: test -x fails inside shell scripts in containers Status in docker.io package in Ubuntu: New Status in glibc package in Ubuntu: Opinion Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: New Status in systemd package in Ubuntu: Fix Released Status in docker.io source package in Xenial: New Status in glibc source package in Xenial: Invalid Status in libseccomp source package in Xenial: New Status in runc source package in Xenial: New Status in systemd source package in Xenial: New Status in docker.io source package in Bionic: New Status in glibc source package in Bionic: Invalid Status in libseccomp source package in Bionic: New Status in runc source package in Bionic: New Status in systemd source package in Bionic: New Status in docker.io source package in Focal: New Status in glibc source package in Focal: Invalid Status in libseccomp source package in Focal: New Status in runc source package in Focal: New Status in systemd source package in Focal: New Status in docker.io source package in Groovy: New Status in glibc source package in Groovy: Invalid Status in libseccomp source package in Groovy: New Status in runc source package in Groovy: New Status in systemd source package in Groovy: Fix Released Status in docker.io source package in Hirsute: New Status in glibc source package in Hirsute: Opinion Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: New Status in systemd source package in Hirsute: Fix Released Bug description: (SRU template for systemd) [impact] bash (and some other shells) builtin test command -x operation fails [test case] on any affected host system, start nspawn container, e.g.: $ sudo apt install systemd-container $ wget https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz $ mkdir h $ cd h $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz $ sudo systemd-nspawn Then from a bash shell, verify if test -x works: root@h:~# ls -l /usr/bin/gpg -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg root@h:~# test -x /usr/bin/gpg || echo "fail" fail [regression potential] any regression would likely occur during a syscall, most likely faccessat2(), or during other syscalls. [scope] this is needed for b/f this is fixed upstream by commit bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so this is fixed in h this was pulled into Debian at version 246.2 in commit e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g in x, the entire systemd seccomp code is completely different and the patch doesn't apply, nor does it appear to be needed, as the problem doesn't reproduce in a h container under x. [other info] this needs fixing in libseccomp as well [original description] glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a
[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers
Running "test -x ..." also fails in systemd-nspawn for systemd < 247, I think only the following patch needs to be SRU-d to earlier systemd versions: https://github.com/systemd/systemd/commit/bcf08acbffdee0d6360d3c31d268e73d0623e5dc ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Hirsute) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in docker.io package in Ubuntu: New Status in glibc package in Ubuntu: Opinion Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: New Status in systemd package in Ubuntu: Fix Released Status in docker.io source package in Xenial: New Status in glibc source package in Xenial: New Status in libseccomp source package in Xenial: New Status in runc source package in Xenial: New Status in systemd source package in Xenial: New Status in docker.io source package in Bionic: New Status in glibc source package in Bionic: New Status in libseccomp source package in Bionic: New Status in runc source package in Bionic: New Status in systemd source package in Bionic: New Status in docker.io source package in Focal: New Status in glibc source package in Focal: New Status in libseccomp source package in Focal: New Status in runc source package in Focal: New Status in systemd source package in Focal: New Status in docker.io source package in Groovy: New Status in glibc source package in Groovy: New Status in libseccomp source package in Groovy: New Status in runc source package in Groovy: New Status in systemd source package in Groovy: New Status in docker.io source package in Hirsute: New Status in glibc source package in Hirsute: Opinion Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: New Status in systemd source package in Hirsute: Fix Released Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1916485/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More
[Touch-packages] [Bug 1917298] Re: dbus-daemon not started after reboot
** Also affects: dbus (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (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 dbus in Ubuntu. https://bugs.launchpad.net/bugs/1917298 Title: dbus-daemon not started after reboot Status in dbus package in Ubuntu: New Status in systemd package in Ubuntu: New Status in dbus source package in Focal: New Status in systemd source package in Focal: New Bug description: In the past weeks we experienced few systems coming up without started dbus-daemon after reboots due to updates. The first occurrence happens on January 21th 2021, since this time we were experiencing 0 up to 2 machines with this issue on each reboot cycle affecting all (approx 20) Ubuntu 20.4 (Focal Fossa) LTS machines. On January 21th the machines were rebooted due to a kernel update. On January 19th there were updates for systemd (systemd:amd64 from 245.4-4ubuntu3.3 undated to 245.4-4ubuntu3.4) installed. The Symptoms seem to be: ``` root@es1:~# systemctl status dbus ● dbus.service - D-Bus System Message Bus Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled) Active: inactive (dead) TriggeredBy: ● dbus.socket Docs: man:dbus-daemon(1) ``` There is no `dbus-daemon` process running any more after reboot. The messages in /var/log/syslog: ``` Feb 24 09:21:52 runner1 kernel: [ 11.005391] systemd[1]: sockets.target: Found ordering cycle on dbus.socket/start [...] Feb 24 09:21:52 runner1 kernel: [ 11.012386] systemd[1]: sockets.target: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start ``` Jounalctl output ends with the dbus-Shutdown before reboot, and it is not updated any more. When rebooting the affected machine again, this does'nt occur again, and the dbus-daemon is started and working again. We experienced this on 4 rather different machines on 6 reboot cycles across all Ubuntu 20.4 (Focal Fossa) LTS machines till now. We are not experiencing this on other LTS releases than 20.4. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1917298/+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 1916705] Re: glib2.0 >=2.67.3 breaks include from an extern C context
** Also affects: wireshark (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1916705
Title:
glib2.0 >=2.67.3 breaks include from an extern C context
Status in glib2.0 package in Ubuntu:
Fix Released
Status in open-vm-tools package in Ubuntu:
New
Status in qemu package in Ubuntu:
Fix Released
Status in ukui-control-center package in Ubuntu:
Triaged
Status in wireshark package in Ubuntu:
New
Bug description:
qemu now breaks in Hirsute (it didn't 23h ago)
Broken:
https://launchpadlibrarian.net/524654684/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-6ubuntu1_BUILDING.txt.gz
Good before:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4471/+packages
Error:
../../disas/arm-a64.cc
In file included from /usr/include/glib-2.0/glib/gmacros.h:241,
from
/usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from /<>/qemu-5.2+dfsg/include/glib-compat.h:32,
from /<>/qemu-5.2+dfsg/include/qemu/osdep.h:126,
from ../../disas/arm-a64.cc:21:
/usr/include/c++/10/type_traits:56:3: error: template with C linkage
56 | template
| ^~~~
../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
20 | extern "C" {
| ^~
Also in disas/nanomips.cpp, ...
And indeed disas/arm-a64.cc has:
20 extern "C" {
21 #include "qemu/osdep.h"
22 #include "disas/dis-asm.h"
23 }
Through the chain of headers as reported above this gets to the templates
in /usr/include/c++/10/type_traits which fails due to that.
So C++ constructs within a C scope which is this bug.
Upstream qemu has not recently changed yet for this.
The code is the same since 2016 via commit e78490c44: "disas/arm-a64.cc:
Include osdep.h first" by Peter Maydell.
But what was different before to break it now?
To find that I was comparing Hirsute vs Hirsute-proposed ...
It is indeed failing in -proposed but working in hirsute-release.
10.2.1-20ubuntu1 : bad
repro in broken build:
$ cd /root/qemu-5.2+dfsg/b/qemu
$ c++ -Ilibcommon.fa.p -I. -I../.. -Iqapi -Itrace -Iui -Iui/shader
-I/usr/include/pixman-1 -I/usr/include/virgl -I/usr/include/libpng16
-I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libusb-1.0
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0
-I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr
-I/usr/include/PCSC -I/usr/include/slirp -fdiagnostics-color=auto -pipe -Wall
-Winvalid-pch -Wnon-virtual-dtor -std=gnu++11 -O2 -g -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -m64 -mcx16
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef
-Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -g -O2
-ffile-prefix-map=/root/qemu-5.2+dfsg=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wtype-limits
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body
-Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs
-Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -isystem
/root/qemu-5.2+dfsg/linux-headers -isystem linux-headers -iquote
/root/qemu-5.2+dfsg/tcg/i386 -iquote . -iquote /root/qemu-5.2+dfsg -iquote
/root/qemu-5.2+dfsg/accel/tcg -iquote /root/qemu-5.2+dfsg/include -iquote
/root/qemu-5.2+dfsg/disas/libvixl -pthread -fPIE -DSTRUCT_IOVEC_DEFINED
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR -MD -MQ
libcommon.fa.p/disas_nanomips.cpp.o -MF libcommon.fa.p/disas_nanomips.cpp.o.d
-o libcommon.fa.p/disas_nanomips.cpp.o -c ../../disas/nanomips.cpp
With that I have a test env...
Doko asked me to test
https://launchpad.net/ubuntu/+source/gcc-10/10.2.1-19ubuntu1/+build/20995220/+files/g++-10_10.2.1-19ubuntu1_amd64.deb
That fails as well, but also good as well as bad case have 10.10.2.1-20ubuntu1
It must be something else.
The difference were ~340 packages I was upgrading them to spot what broke it.
I eventually found glib 2.66 -> 2.67 to break it.
libglib2.0-0/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
libglib2.0-bin/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
libglib2.0-data/hirsute-proposed 2.67.4-1 all [upgradable from: 2.66.4-1]
libglib2.0-dev-bin/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
libglib2.0-dev/hirsute-proposed 2.67.4-1 amd64 [upgradable from: 2.66.4-1]
Old:
/*
* We can only use __typeof__ on GCC >= 4.8, and not when
[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers
** Changed in: docker.io (Ubuntu Hirsute) Importance: Undecided => Critical ** Changed in: glibc (Ubuntu Hirsute) Status: Triaged => Opinion -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in docker.io package in Ubuntu: New Status in glibc package in Ubuntu: Opinion Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: New Status in docker.io source package in Xenial: New Status in glibc source package in Xenial: New Status in libseccomp source package in Xenial: New Status in runc source package in Xenial: New Status in docker.io source package in Bionic: New Status in glibc source package in Bionic: New Status in libseccomp source package in Bionic: New Status in runc source package in Bionic: New Status in docker.io source package in Focal: New Status in glibc source package in Focal: New Status in libseccomp source package in Focal: New Status in runc source package in Focal: New Status in docker.io source package in Groovy: New Status in glibc source package in Groovy: New Status in libseccomp source package in Groovy: New Status in runc source package in Groovy: New Status in docker.io source package in Hirsute: New Status in glibc source package in Hirsute: Opinion Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: New Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1916485/+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 1916485] Re: test -x fails inside shell scripts in containers
** Also affects: glibc (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: runc (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: glibc (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: runc (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: glibc (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: runc (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: glibc (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: runc (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 libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in docker.io package in Ubuntu: New Status in glibc package in Ubuntu: Triaged Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: New Status in docker.io source package in Xenial: New Status in glibc source package in Xenial: New Status in libseccomp source package in Xenial: New Status in runc source package in Xenial: New Status in docker.io source package in Bionic: New Status in glibc source package in Bionic: New Status in libseccomp source package in Bionic: New Status in runc source package in Bionic: New Status in docker.io source package in Focal: New Status in glibc source package in Focal: New Status in libseccomp source package in Focal: New Status in runc source package in Focal: New Status in docker.io source package in Groovy: New Status in glibc source package in Groovy: New Status in libseccomp source package in Groovy: New Status in runc source package in Groovy: New Status in docker.io source package in Hirsute: New Status in glibc source package in Hirsute: Triaged Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: New Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl
[Touch-packages] [Bug 1917677] Re: ubuntu: ucf tracking of valid known md5sums should be limited to only those md5sums that affect a given distro release
It is highly unlikely that the configuration file on one distro is replaced with one that was shipped on a different one. It may be a bit more likely that a config file is overwritten by a variant from a previous release, but I think this is still unlikely and I believe trimming the md5sum list is not a general practice for UCF managed configuration files. As an example openssh-server ships the historical list, too: $ cat /usr/share/openssh/sshd_config.md5sum # Historical md5sums of the default /etc/ssh/sshd_config up to and including # 1:7.3p1-5. 0d06fc337cee10609d4833dc88df740f 10dc68360f6658910a98a051273de22c 11f9e107b4d13bbcabe7f8e8da734371 16c827adcff44efaca05ec5eea6383d7 2eeff28468576c3f2e538314e177687b 386c8b9079625b78f6d624ae506958ae 38fc7b31b3e3078848f0eec457d3e050 395c5e13801f9b4f17c2cb54aa634fbd ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1917677 Title: ubuntu: ucf tracking of valid known md5sums should be limited to only those md5sums that affect a given distro release Status in unattended-upgrades package in Ubuntu: New Status in unattended-upgrades source package in Bionic: New Status in unattended-upgrades source package in Focal: New Status in unattended-upgrades source package in Groovy: New Status in unattended-upgrades source package in Hirsute: New Bug description: Currently the project tracks all valid md5sums of permutations of 50unattended-upgrades.conf in a single md5sum file that contains every md5sum of every historic version of all unique distros: 50unattended-upgrades.Debian 50unattended-upgrades.Devuan 50unattended-upgrades.Raspbian 50unattended-upgrades.Ubuntu Ultimately ucf for a given packaging release should only track the applicable md5sums which are expected to be seen on that particular distribution and release. For example: On Ubuntu Bionic: valid md5sums should be limited to the md5sum of the most recent Ubuntu Xenial 50unattended-upgrades.conf and the md5sums of previous Ubuntu Bionic releases to allow Xenial->Bionic and Bionic->Bionic upgrades without prompt. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1917677/+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 1917677] Re: ubuntu: ucf tracking of valid known md5sums should be limited to only those md5sums that affect a given distro release
** Changed in: unattended-upgrades (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: unattended-upgrades (Ubuntu Hirsute) Importance: Undecided => Low ** Changed in: unattended-upgrades (Ubuntu Groovy) Importance: Undecided => Low ** Changed in: unattended-upgrades (Ubuntu Focal) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1917677 Title: ubuntu: ucf tracking of valid known md5sums should be limited to only those md5sums that affect a given distro release Status in unattended-upgrades package in Ubuntu: New Status in unattended-upgrades source package in Bionic: New Status in unattended-upgrades source package in Focal: New Status in unattended-upgrades source package in Groovy: New Status in unattended-upgrades source package in Hirsute: New Bug description: Currently the project tracks all valid md5sums of permutations of 50unattended-upgrades.conf in a single md5sum file that contains every md5sum of every historic version of all unique distros: 50unattended-upgrades.Debian 50unattended-upgrades.Devuan 50unattended-upgrades.Raspbian 50unattended-upgrades.Ubuntu Ultimately ucf for a given packaging release should only track the applicable md5sums which are expected to be seen on that particular distribution and release. For example: On Ubuntu Bionic: valid md5sums should be limited to the md5sum of the most recent Ubuntu Xenial 50unattended-upgrades.conf and the md5sums of previous Ubuntu Bionic releases to allow Xenial->Bionic and Bionic->Bionic upgrades without prompt. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1917677/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
@stgraber Thank you. I'm including the originally proposed patch in the next systemd upload and will switch to v248 when it is out to include the full fix. Most likely final v248 will be out in a few weeks. ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Balint Reczey (rbalint) -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: In Progress Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
** Changed in: systemd (Ubuntu) Status: Triaged => In Progress -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: In Progress Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1913763] Re: hyperv: unable to distinguish PTP devices
** Changed in: systemd (Ubuntu)
Status: Confirmed => Fix Committed
--
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/1913763
Title:
hyperv: unable to distinguish PTP devices
Status in systemd package in Ubuntu:
Fix Committed
Bug description:
Hyperv provides a PTP device. On system with multiple PTP devices,
services like Chrony don't have a way to know which one is which.
We would like to have a udev rule to create a symlink to the hyperv
clock. This way, services could be configured to always use this clock
no matter if it is ptp0, ptp1, etc..
For example:
```
SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+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 1913763] Re: hyperv: unable to distinguish PTP devices
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Balint Reczey (rbalint)
--
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/1913763
Title:
hyperv: unable to distinguish PTP devices
Status in systemd package in Ubuntu:
New
Bug description:
Hyperv provides a PTP device. On system with multiple PTP devices,
services like Chrony don't have a way to know which one is which.
We would like to have a udev rule to create a symlink to the hyperv
clock. This way, services could be configured to always use this clock
no matter if it is ptp0, ptp1, etc..
For example:
```
SUBSYSTEM=="ptp", ATTR{clock_name}=="hyperv", SYMLINK += "ptp_hyperv"
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913763/+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 1916485] Re: test -x fails inside shell scripts in containers
Following all the discussions fixing the container runtimes seems to be the way out of this. For runc https://github.com/opencontainers/runc/pull/2750 should be SRUd to all releases. ** Also affects: docker.io (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in docker.io package in Ubuntu: New Status in glibc package in Ubuntu: Triaged Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: New Status in docker.io source package in Hirsute: New Status in glibc source package in Hirsute: Triaged Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: New Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1916485/+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 1916485] Re: test -x fails inside shell scripts in containers
** Also affects: runc (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in glibc package in Ubuntu: Triaged Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: New Status in glibc source package in Hirsute: Triaged Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: New Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485/+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 1134036] Re: Failure when using ssh with a locale that is not configured on the server
** Description changed: [impact] The setup: 1) The user has LC_ALL set to a locale on their machine (or some other LC_* variable but it's usually LC_ALL). 2) This locale does not exist on an Ubuntu server. 3) The user sshes into the server. ssh (at least with the settings that are default on Debian and Ubuntu and Fedora) send the value of LC_ALL to the remote server, where the default settings on Ubuntu allow this to be set in the environment of the process it launches. Because we are now in a situation where LC_ALL is set to a value that is not valid for the system, various undesirable things happen, including ugly messages from cloud-init and perl complaining every time a perl process starts and the bug that the original description below describes. [test case] Configure the setup as described above. Ssh into the server and run "perl < /dev/null" and check for warnings. [regression potential] This adds a step to the startup of every login shell, which obviously is not entirely trivial. However, the new executable being invoked is very simple and even if it fails, the startup of the shell should not be inhibited. - [original description] - - If LC_ALL is not set (which seems to be the default on a few server installations I've done now), mid way through installing, you get this backtrace and then the installation just hangs. You can ctrl-c out of it but the package is left half configured. + If LC_ALL is not set (which seems to be the default on a few server + installations I've done now), mid way through installing, you get this + backtrace and then the installation just hangs. You can ctrl-c out of + it but the package is left half configured. Traceback (most recent call last): File "/usr/bin/django-admin", line 5, in management.execute_from_command_line() File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 443, in execute_from_command_line utility.execute() File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 382, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 196, in run_from_argv self.execute(*args, **options.__dict__) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 232, in execute output = self.handle(*args, **options) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 371, in handle return self.handle_noargs(**options) File "/usr/lib/python2.7/dist-packages/south/management/commands/syncdb.py", line 90, in handle_noargs syncdb.Command().execute(**options) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 232, in execute output = self.handle(*args, **options) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 371, in handle return self.handle_noargs(**options) File "/usr/lib/python2.7/dist-packages/django/core/management/commands/syncdb.py", line 57, in handle_noargs cursor = connection.cursor() File "/usr/lib/python2.7/dist-packages/django/db/backends/__init__.py", line 308, in cursor cursor = util.CursorWrapper(self._cursor(), self) File "/usr/lib/python2.7/dist-packages/django/db/backends/postgresql_psycopg2/base.py", line 177, in _cursor self.connection = Database.connect(**conn_params) File "/usr/lib/python2.7/dist-packages/psycopg2/__init__.py", line 179, in connect connection_factory=connection_factory, async=async) psycopg2.OperationalError: FATAL: password authentication failed for user "maas" FATAL: password authentication failed for user "maas" Related bugs: * bug 969462: [postgres] fails to start after install if invalid locale is set + * LP: #1916935 Major changes in sorting method upgrade 18.04->18.04.5 due to base-files change -- 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/1134036 Title: Failure when using ssh with a locale that is not configured on the server Status in base-files package in Ubuntu: Fix Released Status in maas package in Ubuntu: Invalid Status in base-files source package in Bionic: Fix Released Status in maas source package in Bionic: Invalid Bug description: [impact] The setup: 1) The user has LC_ALL set to a locale on their machine (or some other LC_* variable but it's usually LC_ALL). 2) This locale does not exist on an Ubuntu server. 3) The user sshes into the server. ssh (at least with the settings that are default on Debian and Ubuntu and Fedora) send the value of LC_ALL to the remote server, where the default settings on Ubuntu allow this to be set in the environment of the process it launches. Because
[Touch-packages] [Bug 1916935] Re: Major changes in sorting method upgrade 18.04->18.04.5 due to base-files change
@paelzer Thank you for the triaging and the detailed explanation. Since this change slipped in too long ago I don't think it should be reverted. I think Postresql could check if there was a change in sorting compared to the which the indices were created with, but this installation does not uses Postgresql from the archive so that would just be an unrelated improvement. Maybe Postgres already does that. -- 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/1916935 Title: Major changes in sorting method upgrade 18.04->18.04.5 due to base- files change Status in base-files package in Ubuntu: New Status in glibc package in Ubuntu: Invalid Status in postgresql-10 package in Ubuntu: Invalid Status in base-files source package in Bionic: New Bug description: I had an Ubuntu 18.04.0 with Postgres 9.6. Before Ubuntu upgrade following command result was: [code] vodka@ubuntu140:~$ ( echo "1-1"; echo "11" ) | LC_COLLATE=en_US.UTF-8 sort 1-1 11 [/code] But after upgrading Ubuntu 18.04 to latest release via apt upgrade (18.04.5) result of the command above totally changed: [code] vodka@ubuntu140:~$ ( echo "1-1"; echo "11" ) | LC_COLLATE=en_US.UTF-8 sort 11 1-1 [/code] Due to this our production Postgres database started work very slowly and we had a long downtime for REINDEX. Sorting method is very important for Postgres database: https://wiki.postgresql.org/wiki/Locale_data_changes Please, read "Testing collation" part. Is it normal behavior for Ubuntu? Why glibc totally changed within LTS release without 'major upgrade'? I did not expect this... ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libc-bin 2.27-3ubuntu1.4 ProcVersionSignature: Ubuntu 4.15.0-136.140-generic 4.15.18 Uname: Linux 4.15.0-136-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.23 Architecture: amd64 Date: Thu Feb 25 13:13:03 2021 Dependencies: gcc-8-base 8.4.0-1ubuntu1~18.04 libc6 2.27-3ubuntu1.4 libgcc1 1:8.4.0-1ubuntu1~18.04 InstallationDate: Installed on 2021-02-25 (0 days ago) InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: glibc UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1916935/+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 1916935] Re: Major changes in sorting method upgrade 18.04->18.04.5 due to base-files change
** Tags added: regression-update -- 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/1916935 Title: Major changes in sorting method upgrade 18.04->18.04.5 due to base- files change Status in base-files package in Ubuntu: New Status in glibc package in Ubuntu: Invalid Status in postgresql-10 package in Ubuntu: Invalid Status in base-files source package in Bionic: New Bug description: I had an Ubuntu 18.04.0 with Postgres 9.6. Before Ubuntu upgrade following command result was: [code] vodka@ubuntu140:~$ ( echo "1-1"; echo "11" ) | LC_COLLATE=en_US.UTF-8 sort 1-1 11 [/code] But after upgrading Ubuntu 18.04 to latest release via apt upgrade (18.04.5) result of the command above totally changed: [code] vodka@ubuntu140:~$ ( echo "1-1"; echo "11" ) | LC_COLLATE=en_US.UTF-8 sort 11 1-1 [/code] Due to this our production Postgres database started work very slowly and we had a long downtime for REINDEX. Sorting method is very important for Postgres database: https://wiki.postgresql.org/wiki/Locale_data_changes Please, read "Testing collation" part. Is it normal behavior for Ubuntu? Why glibc totally changed within LTS release without 'major upgrade'? I did not expect this... ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libc-bin 2.27-3ubuntu1.4 ProcVersionSignature: Ubuntu 4.15.0-136.140-generic 4.15.18 Uname: Linux 4.15.0-136-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.23 Architecture: amd64 Date: Thu Feb 25 13:13:03 2021 Dependencies: gcc-8-base 8.4.0-1ubuntu1~18.04 libc6 2.27-3ubuntu1.4 libgcc1 1:8.4.0-1ubuntu1~18.04 InstallationDate: Installed on 2021-02-25 (0 days ago) InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) SourcePackage: glibc UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1916935/+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 1915547] Re: sru unattended-upgrades ( 1.1ubuntu1.18.04.7~16.04.6 update to 1.1ubuntu1.18.04.7~16.04.7 ) Xenial
Fixed in 2.8.
** Changed in: unattended-upgrades (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1915547
Title:
sru unattended-upgrades ( 1.1ubuntu1.18.04.7~16.04.6 update to
1.1ubuntu1.18.04.7~16.04.7 ) Xenial
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
Triaged
Bug description:
== Begin SRU Template ==
[Impact]
When upgrading from trusty to xenial, we are prompted about config changes on
50unattended-upgrades with the following diff:
--- /etc/apt/apt.conf.d/50unattended-upgrades root.root 0644 2017-05-08
19:21:39
+++ /etc/apt/apt.conf.d/50unattended-upgrades.ucftmp root.root 0644
2020-02-17 18:03:38
@@ -1,11 +1,13 @@
// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
+ "${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
// Extended Security Maintenance; doesn't necessarily exist for
// every release and this system may not have it installed, but if
// available, the policy for updates is such that unattended-upgrades
// should also install from here by default.
- "${distro_id}ESM:${distro_codename}";
+ "${distro_id}ESMApps:${distro_codename}-apps-security";
+ "${distro_id}ESM:${distro_codename}-infra-security";
// "${distro_id}:${distro_codename}-updates";
// "${distro_id}:${distro_codename}-proposed";
// "${distro_id}:${distro_codename}-backports";
The reason we are presented with this diff is that the xenial package
does not contain a md5sum history file that informs ucf about all the
supported configs for 50unattended-upgrades. To fix that upgrade
problem, we are prosing the following changes on the xenial package of
unattended-upgrades:
- Add 50unattended-upgrades.md5sum file into the xenial package
- Add md5sum of the current xenial 50unattende-upgrades file into the
md5sum history file
- Modify ucf command in postinst to be aware of the md5sum history file
See the changelog entry below for a full list of changes and bugs.
[Test Case]
We have performed a manual test with a modified version of the xenial package:
https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa
Using that package, we were able to verify that the config change
prompt no longer happens from trusty to xenial.
[Regression Potential]
Since we are modifying are features on unattended-upgrades, just adding a new
file to package, we don't believe there is any regression potential
[Discussion]
== End SRU Template ==
== Changelog ==
* data: add md5sum history file on the data folder
- This file contains md5sum of several supported 50unattended-upgrades
config files
* data: add xenial md5sum of 50unattented-upgrades into md5sum file
* debian/postint: make ucf command reference the md5sum history file
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1915547/+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 1915126] Re: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally
@laney Thank you for looking into the problem. I will mark systemd-fsckd as flaky and look into the root cause later. It used to be flaky before as well. I have checked the last 10 failed runs from http://autopkgtest.ubuntu.com/packages/systemd/hirsute/amd64 , with the last one being from 2021-02-24 09:15:57 UTC: $ cat logs https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210224_091557_d5731@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210224_044536_8d27f@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210224_021229_4c845@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210224_013702_2056d@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210223_232058_6bbff@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210223_212809_c332e@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210223_145406_d6565@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210223_140557_825b0@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210223_130532_340ec@/log.gz https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210223_115952_4304b@/log.gz $ wget -q -i logs $ for i in log.gz*; do zcat $i | tail -n 40 | grep -A 16 "@@@ summary" | grep -v PASS ; done autopkgtest [09:15:42]: summary upstream FAIL timed out systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [04:45:21]: summary boot-and-servicesFAIL non-zero exit status 1 systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [02:00:12]: summary upstream FAIL timed out systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [01:23:55]: summary boot-and-servicesFAIL non-zero exit status 1 upstream FAIL timed out systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [23:20:34]: summary boot-and-servicesFAIL non-zero exit status 1 upstream FAIL non-zero exit status 1 systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [21:19:41]: summary boot-and-servicesFAIL non-zero exit status 1 upstream FAIL timed out systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [14:53:35]: summary boot-and-servicesFAIL non-zero exit status 1 upstream FAIL timed out systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [13:53:19]: summary upstream FAIL timed out systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [13:03:15]: summary upstream FAIL timed out systemd-fsckdSKIP exit status 77 and marked as skippable autopkgtest [11:59:24]: summary boot-and-servicesFAIL non-zero exit status 1 upstream FAIL non-zero exit status 1 systemd-fsckdSKIP exit status 77 and marked as skippable As you can see systemd-fsckd has been skipped in 10 out of 10 runs, but "upstream" test timed out in 7 out of the 10 runs. If you would like to help improving the failure rate caused by the infrastructure please run the systemd autopkgtests on bigger VMs. -- 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/1915126 Title: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally Status in Auto Package Testing: Incomplete Status in systemd package in Ubuntu: Invalid Bug description: Hi, I've asked yesterday on IRC but so far got no answer. I think it is right to file a bug about the current state of systemd autopkgtest to unite the efforts in regard to it. I was looking at the systemd tests for a no-change rebuild that really had no reason to now make it fail. While checking I found that as of this month (first bad test on 1st of February) most of the systemd test runs on amd64 will not pass/fail but
[Touch-packages] [Bug 1915126] Re: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally
@paelzer I haven't made changes related to the failure rate. I guess the infra got lighter load for some time. -- 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/1915126 Title: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally Status in Auto Package Testing: Incomplete Status in systemd package in Ubuntu: Invalid Bug description: Hi, I've asked yesterday on IRC but so far got no answer. I think it is right to file a bug about the current state of systemd autopkgtest to unite the efforts in regard to it. I was looking at the systemd tests for a no-change rebuild that really had no reason to now make it fail. While checking I found that as of this month (first bad test on 1st of February) most of the systemd test runs on amd64 will not pass/fail but instead in most cases time out. I've seen various people retry the case as it shows the typical symptoms of a "not the fault of the package, let us retry this" case. But it seems that won't help as the test history is rather clear. * Watch this in monospace to make more sense of it * $ check-autopkgtest-stats.sh -c 50 -p systemd -r "hirsute" -a "amd64" Check last 50 test results for src:systemd on releases 'hirsute' on architectures 'amd64' Of the 50 last tests, we had these subtest failing per release/arch: hirsute amd64 tests-in-lxd (F 2% f 0% S 0% B 12% => P 52%/) .BTTTBTT.BTBTTTBBTTT..F.. hostnamed (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. build-login(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. unit-config(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. networkd-testpy(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-locale (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-and-services (F 4% f 0% S 0% B 12% => P 50%/) .BTTTBTT.BTBTTTBBTTT...F.F... timedated (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-smoke (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. logind (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. storage(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. upstream (F 12% f 0% S 0% B 12% => P 42%/) .BTTTBTT.BTBTTTBBTTTF.F.F..FF..F. udev (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. systemd-fsckd (F 8% f 0% S 0% B 12% => P 46%/) FBTTTBTTFBTBTTTBBTTT.F..F root-unittests (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-x11-keymap (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. We see that formerly we had the known to be somewhat flaky, but otherwise working test (time goes from right to left). So we had the usual suspects of tests like upstream/systemd-fsck that failed a few times, but also working runs in between. But since February 22/24 runs failed very bad. 6 (=B) of those cases are aborting mid execution autopkgtest [22:08:58]: ERROR: testbed failure: testbed auxverb failed with exit code 255 And 16 of them timed out : failure: Timed out on waiting for ssh connection Sadly the 2/24 that didn't hard fail by that where broken by the known flaky systemd-fsckd test. Something drives this test crazy that we have to find and resolve, at the current rate nothing depending on it is likely to migrate. To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1915126/+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 1915887] Re: systemd spams the syslog about lack of native systemd unit file
** Bug watch added: Debian Bug tracker #981407 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981407 ** Also affects: systemd (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981407 Importance: Unknown Status: Unknown -- 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/1915887 Title: systemd spams the syslog about lack of native systemd unit file Status in apport package in Ubuntu: Incomplete Status in fam package in Ubuntu: Incomplete Status in freeradius package in Ubuntu: Incomplete Status in ipfm package in Ubuntu: Incomplete Status in n2n package in Ubuntu: Incomplete Status in pfm package in Ubuntu: Incomplete Status in shadowsocks package in Ubuntu: Incomplete Status in sysfsutils package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Status in virtualbox package in Ubuntu: Incomplete Status in xl2tpd package in Ubuntu: Incomplete Status in systemd package in Debian: Unknown Bug description: systemd in hirsute spams the syslog file several times per second about services lacking native systemd unit files. Two things should happen. 1) a systemd unit file ought to be created 2) systemd should be slowed down with regards to these messages Feb 17 02:02:48 ubuntu-devel kernel: [ 289.794825] systemd-sysv-generator[7105]: SysV service '/etc/init.d/n2n' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:02:49 ubuntu-devel kernel: [ 290.165351] systemd-sysv-generator[7126]: SysV service '/etc/init.d/n2n' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:02:49 ubuntu-devel kernel: [ 291.111278] systemd-sysv-generator[7170]: SysV service '/etc/init.d/n2n' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:02:50 ubuntu-devel kernel: [ 291.507164] systemd-sysv-generator[7199]: SysV service '/etc/init.d/n2n' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.386062] systemd-sysv-generator[9909]: SysV service '/etc/init.d/fam' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.386321] systemd-sysv-generator[9909]: SysV service '/etc/init.d/xl2tpd' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.386742] systemd-sysv-generator[9909]: SysV service '/etc/init.d/ipfm' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.386767] systemd-sysv-generator[9909]: SysV service '/etc/init.d/shadowsocks' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.387281] systemd-sysv-generator[9909]: SysV service '/etc/init.d/virtualbox' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.388931] systemd-sysv-generator[9909]: SysV service '/etc/init.d/sysfsutils' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.388955] systemd-sysv-generator[9909]: SysV service '/etc/init.d/apport' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Feb 17 02:05:57 ubuntu-devel kernel: [ 478.389412] systemd-sysv-generator[9909]: SysV service '/etc/init.d/freeradius' lacks a native systemd unit
[Touch-packages] [Bug 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
@seb128 please also include the fix for n-m tests failing due to MAC changes to let systemd 247.1-4ubuntu1 migrate. ** Changed in: network-manager (Ubuntu) Status: Invalid => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
Yes, the user is created using /usr/lib/sysusers.d/systemd.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/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+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 1915874] [NEW] autopkgtest fails in hirsute on armhf with glibc 2.33
Public bug reported: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/armhf/libs/libseccomp/20210214_103448_4822f@/log.gz ... autopkgtest [10:33:19]: test test-filter: [--- = ./debian/tests/data/all-3.19.filter = DEBUG: seccomp_load_filters ./debian/tests/data/all-3.19.filter Bad system call (core dumped) FAIL: expected to pass ... The problem seems to be that with the new glibc upstream version the test binaries started using statx which is not listed in the .filter files. ** Affects: libseccomp (Ubuntu) Importance: Undecided Status: New ** Tags: update-excuse ** Attachment added: "0001-Permit-statx-syscall-in-test-filter-autopkgtest.patch" https://bugs.launchpad.net/bugs/1915874/+attachment/5464259/+files/0001-Permit-statx-syscall-in-test-filter-autopkgtest.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1915874 Title: autopkgtest fails in hirsute on armhf with glibc 2.33 Status in libseccomp package in Ubuntu: New Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/armhf/libs/libseccomp/20210214_103448_4822f@/log.gz ... autopkgtest [10:33:19]: test test-filter: [--- = ./debian/tests/data/all-3.19.filter = DEBUG: seccomp_load_filters ./debian/tests/data/all-3.19.filter Bad system call (core dumped) FAIL: expected to pass ... The problem seems to be that with the new glibc upstream version the test binaries started using statx which is not listed in the .filter files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1915874/+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 1914939] Re: faccessat2 syscall needed for Docker (needs backported from libseccomp 2.4.4+)
The fix for https://github.com/seccomp/libseccomp/issues/314 seems to be needed, too, also for migrating glibc 2.33. ** Bug watch added: github.com/seccomp/libseccomp/issues #314 https://github.com/seccomp/libseccomp/issues/314 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1914939 Title: faccessat2 syscall needed for Docker (needs backported from libseccomp 2.4.4+) Status in libseccomp package in Ubuntu: Incomplete Bug description: The next release of Alpine Linux intends to use the faccessat2(2) syscall for access(3). This currently fails under Ubuntu Docker, regardless of using the separate Docker package repository, since it forbids faccessat2. This bug is similar to bug #1876055, but requests backporting of 2.4.4 instead of 2.4.3. I believe this change is likely low risk and can be applied to all supported Ubuntu versions. Alternatively, I also see in bug #1891810 that libseccomp 2.5 is being considered for backporting. This would also be acceptable for our purposes, but is obviously a higher-risk change for Ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1914939/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
@stgraber Thank you for assisting with aligning udevs's behaviour with LXD. I've added the tests-in-lxd autopkgtests to ensure catching issues in LXD earlier. I'd be happy to add more tests in systemd's autopkgtest to not let udevd regress in LXD. @xnox I don't like to idea of letting services be failed in default installs in LXD because this would result bad user experience. @seb128 could you please patch network-manager 1.28 to behave in LXC like it did in 1.26 to let it migrate and not fail in LXC with systemd 247 until the udevd behaviour is fixed in LXC? -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Invalid Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1915126] Re: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally
** Tags added: update-excuse -- 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/1915126 Title: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally Status in Auto Package Testing: New Status in systemd package in Ubuntu: Invalid Bug description: Hi, I've asked yesterday on IRC but so far got no answer. I think it is right to file a bug about the current state of systemd autopkgtest to unite the efforts in regard to it. I was looking at the systemd tests for a no-change rebuild that really had no reason to now make it fail. While checking I found that as of this month (first bad test on 1st of February) most of the systemd test runs on amd64 will not pass/fail but instead in most cases time out. I've seen various people retry the case as it shows the typical symptoms of a "not the fault of the package, let us retry this" case. But it seems that won't help as the test history is rather clear. * Watch this in monospace to make more sense of it * $ check-autopkgtest-stats.sh -c 50 -p systemd -r "hirsute" -a "amd64" Check last 50 test results for src:systemd on releases 'hirsute' on architectures 'amd64' Of the 50 last tests, we had these subtest failing per release/arch: hirsute amd64 tests-in-lxd (F 2% f 0% S 0% B 12% => P 52%/) .BTTTBTT.BTBTTTBBTTT..F.. hostnamed (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. build-login(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. unit-config(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. networkd-testpy(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-locale (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-and-services (F 4% f 0% S 0% B 12% => P 50%/) .BTTTBTT.BTBTTTBBTTT...F.F... timedated (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-smoke (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. logind (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. storage(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. upstream (F 12% f 0% S 0% B 12% => P 42%/) .BTTTBTT.BTBTTTBBTTTF.F.F..FF..F. udev (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. systemd-fsckd (F 8% f 0% S 0% B 12% => P 46%/) FBTTTBTTFBTBTTTBBTTT.F..F root-unittests (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-x11-keymap (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. We see that formerly we had the known to be somewhat flaky, but otherwise working test (time goes from right to left). So we had the usual suspects of tests like upstream/systemd-fsck that failed a few times, but also working runs in between. But since February 22/24 runs failed very bad. 6 (=B) of those cases are aborting mid execution autopkgtest [22:08:58]: ERROR: testbed failure: testbed auxverb failed with exit code 255 And 16 of them timed out : failure: Timed out on waiting for ssh connection Sadly the 2/24 that didn't hard fail by that where broken by the known flaky systemd-fsckd test. Something drives this test crazy that we have to find and resolve, at the current rate nothing depending on it is likely to migrate. To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1915126/+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 1915386] Re: package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.6 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
What happened here? Installing new version of config file /etc/logrotate.d/unattended-upgrades ... Installing new version of config file /etc/pm/sleep.d/10_unattended-upgrades-hibernate ... ]0;root@gilles-1215B-1215B: /root@gilles-1215B-1215B:/# ls[K[Kps -ef UIDPID PPID C STIME TTY TIME CMD root 1 0 0 21:32 ?00:00:09 /sbin/init I guess https://github.com/mvo5/unattended-upgrades/pull/288 will fix it if there were no local changes. ** Changed in: unattended-upgrades (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1915386 Title: package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.6 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: erreur logiciel lors ouverture session ou pour upgrade ProblemType: Package DistroRelease: Ubuntu 16.04 Package: unattended-upgrades 1.1ubuntu1.18.04.7~16.04.6 ProcVersionSignature: Ubuntu 4.4.0-201.233-generic 4.4.247 Uname: Linux 4.4.0-201-generic i686 ApportVersion: 2.20.1-0ubuntu2.30 Architecture: i386 Date: Wed Feb 10 23:01:24 2021 ErrorMessage: subprocess installed post-installation script returned error exit status 1 InstallationDate: Installed on 2021-02-10 (0 days ago) InstallationMedia: Lubuntu 14.04.1 LTS "Trusty Tahr" - Release i386 (20140722.2) PackageArchitecture: all RelatedPackageVersions: dpkg 1.18.4ubuntu1.6 apt 1.2.32ubuntu0.2 SourcePackage: unattended-upgrades Title: package unattended-upgrades 1.1ubuntu1.18.04.7~16.04.6 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.apt.apt.conf.d.50unattended-upgrades: 2020-02-17T19:03:38 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1915386/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
@stgraber or work with systemd upstream to extend the container API. -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: New Status in network-manager package in Ubuntu: New Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
@stgraber nothing should break honoring https://systemd.io/CONTAINER_INTERFACE/ and we are in constant uphill battle with systemd and other upstreams checking /sys's ro status. Detecting the init system is easy, please do it in LXD. It may make sense to allow the user to override that and force /sys readonly in LXC config, but then it is up to the user to fix failing services, the user cares about, too. ** Changed in: lxd (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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: New Status in network-manager package in Ubuntu: New Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1915126] Re: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally
There is not much to do about the failures on systemd's side. The tests are reliably passing in qemu on my i5-4670 testbed from 2013, also passing on @paelzer's presumably newer machine. This is an infra issue. The Release Team can decide if they want to hint the test and lose gating coverage, but I'm not filing the hint because IMO the test infra should be fixed. ** Changed in: systemd (Ubuntu) Status: New => 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/1915126 Title: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally Status in Auto Package Testing: New Status in systemd package in Ubuntu: Invalid Bug description: Hi, I've asked yesterday on IRC but so far got no answer. I think it is right to file a bug about the current state of systemd autopkgtest to unite the efforts in regard to it. I was looking at the systemd tests for a no-change rebuild that really had no reason to now make it fail. While checking I found that as of this month (first bad test on 1st of February) most of the systemd test runs on amd64 will not pass/fail but instead in most cases time out. I've seen various people retry the case as it shows the typical symptoms of a "not the fault of the package, let us retry this" case. But it seems that won't help as the test history is rather clear. * Watch this in monospace to make more sense of it * $ check-autopkgtest-stats.sh -c 50 -p systemd -r "hirsute" -a "amd64" Check last 50 test results for src:systemd on releases 'hirsute' on architectures 'amd64' Of the 50 last tests, we had these subtest failing per release/arch: hirsute amd64 tests-in-lxd (F 2% f 0% S 0% B 12% => P 52%/) .BTTTBTT.BTBTTTBBTTT..F.. hostnamed (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. build-login(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. unit-config(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. networkd-testpy(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-locale (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-and-services (F 4% f 0% S 0% B 12% => P 50%/) .BTTTBTT.BTBTTTBBTTT...F.F... timedated (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-smoke (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. logind (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. storage(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. upstream (F 12% f 0% S 0% B 12% => P 42%/) .BTTTBTT.BTBTTTBBTTTF.F.F..FF..F. udev (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. systemd-fsckd (F 8% f 0% S 0% B 12% => P 46%/) FBTTTBTTFBTBTTTBBTTT.F..F root-unittests (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-x11-keymap (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. We see that formerly we had the known to be somewhat flaky, but otherwise working test (time goes from right to left). So we had the usual suspects of tests like upstream/systemd-fsck that failed a few times, but also working runs in between. But since February 22/24 runs failed very bad. 6 (=B) of those cases are aborting mid execution autopkgtest [22:08:58]: ERROR: testbed failure: testbed auxverb failed with exit code 255 And 16 of them timed out : failure: Timed out on waiting for ssh connection Sadly the 2/24 that didn't hard fail by that where broken by the known flaky systemd-fsckd test. Something drives this test crazy that we have to find and resolve, at the current rate nothing depending on it is likely to migrate. To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1915126/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
@seb128 I tried remounting /sys in systemd but it created other issues. I've fixed udevd to not start in lxc in systemd, but this is all systemd can do. Please detect running udev in network-manager without assuming that rw /sys implies running udev. @ LXD devs, please check if the init to start is systemd and if so please mount /sys ro to conform to systemd's https://systemd.io/CONTAINER_INTERFACE/ or sort convince systemd upstream to include LXC in the container interface with rw /sys. ** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Also affects: lxd (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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: New Status in network-manager package in Ubuntu: New Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1915126] Re: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally
** Also affects: auto-package-testing 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/1915126 Title: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally Status in Auto Package Testing: New Status in systemd package in Ubuntu: New Bug description: Hi, I've asked yesterday on IRC but so far got no answer. I think it is right to file a bug about the current state of systemd autopkgtest to unite the efforts in regard to it. I was looking at the systemd tests for a no-change rebuild that really had no reason to now make it fail. While checking I found that as of this month (first bad test on 1st of February) most of the systemd test runs on amd64 will not pass/fail but instead in most cases time out. I've seen various people retry the case as it shows the typical symptoms of a "not the fault of the package, let us retry this" case. But it seems that won't help as the test history is rather clear. * Watch this in monospace to make more sense of it * $ check-autopkgtest-stats.sh -c 50 -p systemd -r "hirsute" -a "amd64" Check last 50 test results for src:systemd on releases 'hirsute' on architectures 'amd64' Of the 50 last tests, we had these subtest failing per release/arch: hirsute amd64 tests-in-lxd (F 2% f 0% S 0% B 12% => P 52%/) .BTTTBTT.BTBTTTBBTTT..F.. hostnamed (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. build-login(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. unit-config(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. networkd-testpy(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-locale (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-and-services (F 4% f 0% S 0% B 12% => P 50%/) .BTTTBTT.BTBTTTBBTTT...F.F... timedated (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-smoke (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. logind (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. storage(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. upstream (F 12% f 0% S 0% B 12% => P 42%/) .BTTTBTT.BTBTTTBBTTTF.F.F..FF..F. udev (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. systemd-fsckd (F 8% f 0% S 0% B 12% => P 46%/) FBTTTBTTFBTBTTTBBTTT.F..F root-unittests (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-x11-keymap (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. We see that formerly we had the known to be somewhat flaky, but otherwise working test (time goes from right to left). So we had the usual suspects of tests like upstream/systemd-fsck that failed a few times, but also working runs in between. But since February 22/24 runs failed very bad. 6 (=B) of those cases are aborting mid execution autopkgtest [22:08:58]: ERROR: testbed failure: testbed auxverb failed with exit code 255 And 16 of them timed out : failure: Timed out on waiting for ssh connection Sadly the 2/24 that didn't hard fail by that where broken by the known flaky systemd-fsckd test. Something drives this test crazy that we have to find and resolve, at the current rate nothing depending on it is likely to migrate. To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1915126/+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 1915126] Re: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally
** Merge proposal unlinked: https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/383953 -- 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/1915126 Title: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally Status in systemd package in Ubuntu: New Bug description: Hi, I've asked yesterday on IRC but so far got no answer. I think it is right to file a bug about the current state of systemd autopkgtest to unite the efforts in regard to it. I was looking at the systemd tests for a no-change rebuild that really had no reason to now make it fail. While checking I found that as of this month (first bad test on 1st of February) most of the systemd test runs on amd64 will not pass/fail but instead in most cases time out. I've seen various people retry the case as it shows the typical symptoms of a "not the fault of the package, let us retry this" case. But it seems that won't help as the test history is rather clear. * Watch this in monospace to make more sense of it * $ check-autopkgtest-stats.sh -c 50 -p systemd -r "hirsute" -a "amd64" Check last 50 test results for src:systemd on releases 'hirsute' on architectures 'amd64' Of the 50 last tests, we had these subtest failing per release/arch: hirsute amd64 tests-in-lxd (F 2% f 0% S 0% B 12% => P 52%/) .BTTTBTT.BTBTTTBBTTT..F.. hostnamed (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. build-login(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. unit-config(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. networkd-testpy(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-locale (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-and-services (F 4% f 0% S 0% B 12% => P 50%/) .BTTTBTT.BTBTTTBBTTT...F.F... timedated (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-smoke (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. logind (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. storage(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. upstream (F 12% f 0% S 0% B 12% => P 42%/) .BTTTBTT.BTBTTTBBTTTF.F.F..FF..F. udev (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. systemd-fsckd (F 8% f 0% S 0% B 12% => P 46%/) FBTTTBTTFBTBTTTBBTTT.F..F root-unittests (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-x11-keymap (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. We see that formerly we had the known to be somewhat flaky, but otherwise working test (time goes from right to left). So we had the usual suspects of tests like upstream/systemd-fsck that failed a few times, but also working runs in between. But since February 22/24 runs failed very bad. 6 (=B) of those cases are aborting mid execution autopkgtest [22:08:58]: ERROR: testbed failure: testbed auxverb failed with exit code 255 And 16 of them timed out : failure: Timed out on waiting for ssh connection Sadly the 2/24 that didn't hard fail by that where broken by the known flaky systemd-fsckd test. Something drives this test crazy that we have to find and resolve, at the current rate nothing depending on it is likely to migrate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915126/+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 1915126] Re: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally
@paelzer I seems infra issues got worse, but there is a pending review to bump systemd to big which I linked. Even in the absence of the infra issues it would have made sense to make system run big test instances, but I expect the big instances would also improve the current situation. Instead of hinting system I'd like to give a try to running it on big instances to see it it makes any difference. -- 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/1915126 Title: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally Status in systemd package in Ubuntu: New Bug description: Hi, I've asked yesterday on IRC but so far got no answer. I think it is right to file a bug about the current state of systemd autopkgtest to unite the efforts in regard to it. I was looking at the systemd tests for a no-change rebuild that really had no reason to now make it fail. While checking I found that as of this month (first bad test on 1st of February) most of the systemd test runs on amd64 will not pass/fail but instead in most cases time out. I've seen various people retry the case as it shows the typical symptoms of a "not the fault of the package, let us retry this" case. But it seems that won't help as the test history is rather clear. * Watch this in monospace to make more sense of it * $ check-autopkgtest-stats.sh -c 50 -p systemd -r "hirsute" -a "amd64" Check last 50 test results for src:systemd on releases 'hirsute' on architectures 'amd64' Of the 50 last tests, we had these subtest failing per release/arch: hirsute amd64 tests-in-lxd (F 2% f 0% S 0% B 12% => P 52%/) .BTTTBTT.BTBTTTBBTTT..F.. hostnamed (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. build-login(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. unit-config(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. networkd-testpy(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-locale (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-and-services (F 4% f 0% S 0% B 12% => P 50%/) .BTTTBTT.BTBTTTBBTTT...F.F... timedated (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-smoke (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. logind (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. storage(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. upstream (F 12% f 0% S 0% B 12% => P 42%/) .BTTTBTT.BTBTTTBBTTTF.F.F..FF..F. udev (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. systemd-fsckd (F 8% f 0% S 0% B 12% => P 46%/) FBTTTBTTFBTBTTTBBTTT.F..F root-unittests (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-x11-keymap (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. We see that formerly we had the known to be somewhat flaky, but otherwise working test (time goes from right to left). So we had the usual suspects of tests like upstream/systemd-fsck that failed a few times, but also working runs in between. But since February 22/24 runs failed very bad. 6 (=B) of those cases are aborting mid execution autopkgtest [22:08:58]: ERROR: testbed failure: testbed auxverb failed with exit code 255 And 16 of them timed out : failure: Timed out on waiting for ssh connection Sadly the 2/24 that didn't hard fail by that where broken by the known flaky systemd-fsckd test. Something drives this test crazy that we have to find and resolve, at the current rate nothing depending on it is likely to migrate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915126/+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 1915126] Re: autopkgtest times out (or fails before that) in hirsute
** Merge proposal linked: https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/383953 ** Summary changed: - autopkgtest times out (or fails before that) in hirsute + autopkgtest times out (or fails before that) in hirsute on test infra, passes locally -- 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/1915126 Title: autopkgtest times out (or fails before that) in hirsute on test infra, passes locally Status in systemd package in Ubuntu: New Bug description: Hi, I've asked yesterday on IRC but so far got no answer. I think it is right to file a bug about the current state of systemd autopkgtest to unite the efforts in regard to it. I was looking at the systemd tests for a no-change rebuild that really had no reason to now make it fail. While checking I found that as of this month (first bad test on 1st of February) most of the systemd test runs on amd64 will not pass/fail but instead in most cases time out. I've seen various people retry the case as it shows the typical symptoms of a "not the fault of the package, let us retry this" case. But it seems that won't help as the test history is rather clear. * Watch this in monospace to make more sense of it * $ check-autopkgtest-stats.sh -c 50 -p systemd -r "hirsute" -a "amd64" Check last 50 test results for src:systemd on releases 'hirsute' on architectures 'amd64' Of the 50 last tests, we had these subtest failing per release/arch: hirsute amd64 tests-in-lxd (F 2% f 0% S 0% B 12% => P 52%/) .BTTTBTT.BTBTTTBBTTT..F.. hostnamed (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. build-login(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. unit-config(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. networkd-testpy(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-locale (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-and-services (F 4% f 0% S 0% B 12% => P 50%/) .BTTTBTT.BTBTTTBBTTT...F.F... timedated (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. boot-smoke (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. logind (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. storage(F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. upstream (F 12% f 0% S 0% B 12% => P 42%/) .BTTTBTT.BTBTTTBBTTTF.F.F..FF..F. udev (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. systemd-fsckd (F 8% f 0% S 0% B 12% => P 46%/) FBTTTBTTFBTBTTTBBTTT.F..F root-unittests (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. localed-x11-keymap (F 0% f 0% S 0% B 12% => P 54%/) .BTTTBTT.BTBTTTBBTTT. We see that formerly we had the known to be somewhat flaky, but otherwise working test (time goes from right to left). So we had the usual suspects of tests like upstream/systemd-fsck that failed a few times, but also working runs in between. But since February 22/24 runs failed very bad. 6 (=B) of those cases are aborting mid execution autopkgtest [22:08:58]: ERROR: testbed failure: testbed auxverb failed with exit code 255 And 16 of them timed out : failure: Timed out on waiting for ssh connection Sadly the 2/24 that didn't hard fail by that where broken by the known flaky systemd-fsckd test. Something drives this test crazy that we have to find and resolve, at the current rate nothing depending on it is likely to migrate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915126/+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 1911059] Re: gce: 247.1-4ubuntu1 causes loss of networking
Systemd 247.3 fixes this which I'm pre-testing before upload at https://bileto.ubuntu.com/#/ticket/3840 . ETA is next week. -- 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/1911059 Title: gce: 247.1-4ubuntu1 causes loss of networking Status in systemd: Fix Released Status in systemd package in Ubuntu: New Bug description: Summary === On Hirsute, upgrading or using to systemd 247.1-4ubuntu1 causes Google Cloud instance to loose network access. Expected Result === Working network access Actual Result === After upgrade, network access is lost and serial console is filled with messages about IPv4 martian source and ll header, see below. Steps to Reproduce === 1. Launch `daily-ubuntu-2104-hirsute-v20210107` the last known good image 2. sudo apt update 3. sudo apt install systemd 4. ssh is lost The images, built with this version do not appear to be able to start networking. Logs === Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915720] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915724] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978762] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978803] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042242] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042302] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105412] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105448] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168141] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168178] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 $ journalctl --no-pager -u systemd-net -- Journal begins at Mon 2021-01-11 21:30:31 UTC, ends at Mon 2021-01-11 21:52:03 UTC. -- Jan 11 21:30:35 ubuntu systemd[1]: Starting Network Service... Jan 11 21:30:35 ubuntu systemd-networkd[413]: Enumeration completed Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Interface name change detected, ens4 has been renamed to eth0. Jan 11 21:30:35 ubuntu systemd[1]: Started Network Service. Jan 11 21:30:35 ubuntu systemd-networkd[413]: eth0: Interface name change detected, eth0 has been renamed to ens4. Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: IPv6 successfully enabled Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Link UP Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Gained carrier Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Classless static routes received from DHCP server: ignoring router option Jan 11 21:30:37 ubuntu systemd-networkd[413]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[413]: ens4: DHCPv6 lease lost Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopping Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: systemd-networkd.service: Succeeded. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopped Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Starting Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: Enumeration completed Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Started Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1911059/+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 1914278] Re: apt autoremove is not removing unused kernels
APT and u-u and marking work as designed. ** Changed in: unattended-upgrades (Ubuntu) Status: Incomplete => Invalid ** Changed in: apt (Ubuntu) Status: Incomplete => Invalid ** Summary changed: - apt autoremove is not removing unused kernels + discover is not removing unused kernels -- 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/1914278 Title: discover is not removing unused kernels Status in apt package in Ubuntu: Invalid Status in discover package in Ubuntu: New Status in packagekit package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: Invalid Bug description: With the machines I help administer, we have been finding situations where the /boot directory is filling-up beyond 3 kernels on LUKS encrypted systems. apt autoremove is not removing old kernels as expected. This may also be an issue with unattended-upgrades since I found the following line commented-out by default: // Remove unused automatically installed kernel-related packages // (kernel images, kernel headers and kernel version locked tools). // Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; We have had a system with as many as 15 kernel packages installed as a result of this not working as expected. The majority of these machines are using Discover to do their package upgrading, which uses PackageKit as its backend. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apt 2.0.4 ProcVersionSignature: Ubuntu 5.8.0-41.46~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Tue Feb 2 09:29:01 2021 InstallationDate: Installed on 2020-11-07 (87 days ago) InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914278/+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 1914409] Re: fsck integration is not flicker free
** Changed in: systemd (Ubuntu) Importance: Undecided => Wishlist -- 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/1914409 Title: fsck integration is not flicker free Status in systemd package in Ubuntu: New Bug description: Install Ubuntu desktop, with full disk LUKS encryption, on an UEFI system. On boot, ESP & rootfs will have fsck started. This flickers briefly that fsck are in progress, although most of the time both the ESP and rootfs fsck finish/exit instantly. It would be nice delaying to show fsck progress in plymouth until it takes a substantial amount of time and/or if there is progress about it. I.e. ideally it should not be shown if it takes less than a second to complete (or some other very quick threshold). As there is not enough to time to show the message that the fsck is in progress, for the human to read it, before the message is dissmissed again. One can see this as a flickerfree boot effort. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914409/+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 1914278] Re: apt autoremove is not removing unused kernels
Please install a few old kernels manually, mark them autoremovable and run u-u in verbose and debug mode. If u-u removes those kernels this is not an u-u bug. Then install those again and try removing them with apt. If apt removes those kernels than this is not an APT bug. ** Changed in: unattended-upgrades (Ubuntu) Status: New => Incomplete ** Changed in: apt (Ubuntu) Status: New => Incomplete -- 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/1914278 Title: apt autoremove is not removing unused kernels Status in apt package in Ubuntu: Incomplete Status in discover package in Ubuntu: New Status in packagekit package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: With the machines I help administer, we have been finding situations where the /boot directory is filling-up beyond 3 kernels on LUKS encrypted systems. apt autoremove is not removing old kernels as expected. This may also be an issue with unattended-upgrades since I found the following line commented-out by default: // Remove unused automatically installed kernel-related packages // (kernel images, kernel headers and kernel version locked tools). // Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; We have had a system with as many as 15 kernel packages installed as a result of this not working as expected. The majority of these machines are using Discover to do their package upgrading, which uses PackageKit as its backend. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apt 2.0.4 ProcVersionSignature: Ubuntu 5.8.0-41.46~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Tue Feb 2 09:29:01 2021 InstallationDate: Installed on 2020-11-07 (87 days ago) InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914278/+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 1914279] Re: linux from security may force reboots without complete dkms modules
This is only a linux package update process problem, and apt frontends can do nothing to prevent it. ** Changed in: unattended-upgrades (Ubuntu) Status: New => Invalid -- 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/1914279 Title: linux from security may force reboots without complete dkms modules Status in apt package in Ubuntu: Invalid Status in dkms package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in linux-meta package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in- ubuntu-desktop-installation-media/20606 We have noticed a reference to somebody not having working backport- iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8 switch. However, kernel meta switch was pushed to security pocket, but the dkms modules are all in -updates only. This may result in people automatically installing the new kernel with unatanded upgrades; dkms modules failing to build; and a reboot required flag left on disk. At this point launching update manager will not offer to install dkms modules from updates, and will guide the users to reboot. which will then cause them to boot the new kernel without the dkms modules that might be providing networking for them. Should dkms modules SRUs always getting published into -security pocket, as well as the -updates pocket? Should linux maintainer scripts prevent touching reboot required flag if any dkms modules fail to build? Should apt / unattanded-upgrades / update-manager always update dkms modules with kernels? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914279/+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 1914279] Re: linux from security may force reboots without complete dkms modules
The linux packgages need to add breaks against in-archive dkms modules failing to build with the updated kernel, thus APT and APT frontends can hold back the upgrade until all dkms package updates become ready. ** Changed in: update-manager (Ubuntu) Status: New => Invalid ** Changed in: apt (Ubuntu) Status: New => Invalid -- 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/1914279 Title: linux from security may force reboots without complete dkms modules Status in apt package in Ubuntu: Invalid Status in dkms package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in linux-meta package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in- ubuntu-desktop-installation-media/20606 We have noticed a reference to somebody not having working backport- iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8 switch. However, kernel meta switch was pushed to security pocket, but the dkms modules are all in -updates only. This may result in people automatically installing the new kernel with unatanded upgrades; dkms modules failing to build; and a reboot required flag left on disk. At this point launching update manager will not offer to install dkms modules from updates, and will guide the users to reboot. which will then cause them to boot the new kernel without the dkms modules that might be providing networking for them. Should dkms modules SRUs always getting published into -security pocket, as well as the -updates pocket? Should linux maintainer scripts prevent touching reboot required flag if any dkms modules fail to build? Should apt / unattanded-upgrades / update-manager always update dkms modules with kernels? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914279/+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 1914279] Re: linux from security may force reboots without complete dkms modules
Since this breaks systems unattended I'm marking the bug as High, but I recommend the Critical severity. ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Importance: Medium => High -- 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/1914279 Title: linux from security may force reboots without complete dkms modules Status in apt package in Ubuntu: Invalid Status in dkms package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in linux-meta package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in- ubuntu-desktop-installation-media/20606 We have noticed a reference to somebody not having working backport- iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8 switch. However, kernel meta switch was pushed to security pocket, but the dkms modules are all in -updates only. This may result in people automatically installing the new kernel with unatanded upgrades; dkms modules failing to build; and a reboot required flag left on disk. At this point launching update manager will not offer to install dkms modules from updates, and will guide the users to reboot. which will then cause them to boot the new kernel without the dkms modules that might be providing networking for them. Should dkms modules SRUs always getting published into -security pocket, as well as the -updates pocket? Should linux maintainer scripts prevent touching reboot required flag if any dkms modules fail to build? Should apt / unattanded-upgrades / update-manager always update dkms modules with kernels? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914279/+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 1914278] Re: apt autoremove is not removing unused kernels
@eeickmeyer Please run manually: sudo unattended-upgrade --verbose --debug -- 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/1914278 Title: apt autoremove is not removing unused kernels Status in apt package in Ubuntu: New Status in discover package in Ubuntu: New Status in packagekit package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: With the machines I help administer, we have been finding situations where the /boot directory is filling-up beyond 3 kernels on LUKS encrypted systems. apt autoremove is not removing old kernels as expected. This may also be an issue with unattended-upgrades since I found the following line commented-out by default: // Remove unused automatically installed kernel-related packages // (kernel images, kernel headers and kernel version locked tools). // Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; We have had a system with as many as 15 kernel packages installed as a result of this not working as expected. The majority of these machines are using Discover to do their package upgrading, which uses PackageKit as its backend. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apt 2.0.4 ProcVersionSignature: Ubuntu 5.8.0-41.46~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Tue Feb 2 09:29:01 2021 InstallationDate: Installed on 2020-11-07 (87 days ago) InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914278/+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 1914278] Re: apt autoremove is not removing unused kernels
Is unatteded-upgrade disabled on the system? $ cat /etc/apt/apt.conf.d/20auto-upgrades APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; $ apt-config dump | grep Periodic APT::Periodic ""; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::AutocleanInterval "0"; APT::Periodic::Unattended-Upgrade "1"; ** Changed in: unattended-upgrades (Ubuntu) Status: New => Incomplete -- 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/1914278 Title: apt autoremove is not removing unused kernels Status in apt package in Ubuntu: New Status in discover package in Ubuntu: New Status in packagekit package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: With the machines I help administer, we have been finding situations where the /boot directory is filling-up beyond 3 kernels on LUKS encrypted systems. apt autoremove is not removing old kernels as expected. This may also be an issue with unattended-upgrades since I found the following line commented-out by default: // Remove unused automatically installed kernel-related packages // (kernel images, kernel headers and kernel version locked tools). // Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; We have had a system with as many as 15 kernel packages installed as a result of this not working as expected. The majority of these machines are using Discover to do their package upgrading, which uses PackageKit as its backend. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apt 2.0.4 ProcVersionSignature: Ubuntu 5.8.0-41.46~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Tue Feb 2 09:29:01 2021 InstallationDate: Installed on 2020-11-07 (87 days ago) InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914278/+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 1914278] Re: apt autoremove is not removing unused kernels
The configuration file is fine, it is the default value that's commented out. Please check unattended-upgrades logs if it performed kernel removals: zgrep 'unused kernel' /var/log/unattended-upgrades/*.gz Also please check if it ran at all. ** Changed in: unattended-upgrades (Ubuntu) Status: New => Incomplete -- 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/1914278 Title: apt autoremove is not removing unused kernels Status in apt package in Ubuntu: New Status in discover package in Ubuntu: New Status in packagekit package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: New Bug description: With the machines I help administer, we have been finding situations where the /boot directory is filling-up beyond 3 kernels on LUKS encrypted systems. apt autoremove is not removing old kernels as expected. This may also be an issue with unattended-upgrades since I found the following line commented-out by default: // Remove unused automatically installed kernel-related packages // (kernel images, kernel headers and kernel version locked tools). // Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; We have had a system with as many as 15 kernel packages installed as a result of this not working as expected. The majority of these machines are using Discover to do their package upgrading, which uses PackageKit as its backend. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apt 2.0.4 ProcVersionSignature: Ubuntu 5.8.0-41.46~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Tue Feb 2 09:29:01 2021 InstallationDate: Installed on 2020-11-07 (87 days ago) InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914278/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
>From the log you linked: Get:263 http://ftpmaster.internal/ubuntu hirsute-proposed/main amd64 network-manager amd64 1.28.0-2ubuntu1 [2002 kB] ** Package changed: systemd (Ubuntu) => network-manager (Ubuntu) -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in network-manager package in Ubuntu: New Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1914062/+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 1914062] [NEW] NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
Public bug reported: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: update-excuse -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in network-manager package in Ubuntu: New Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1914062/+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 1913423] Re: getgrouplist is not thread safe with libnss_systemd
Fixed in v247 and v246.5 in Hirsute and Groovy. ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1913423 Title: getgrouplist is not thread safe with libnss_systemd Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Bug description: This upstream issue (https://github.com/systemd/systemd/issues/17007) is affecting the latest version of systemd in Ubuntu Focal. It has been fixed upstream with https://github.com/systemd/systemd/pull/17033. Can we have this patched for Focal please as it causes Mesos to randomly segfault on start. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1913423/+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 1912331] Re: Many interfaces lead to "kernel receive buffer overrun"
** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Groovy) Status: New => Fix Released ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1912331 Title: Many interfaces lead to "kernel receive buffer overrun" Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in systemd source package in Groovy: Fix Released Bug description: This is about a systemd-networkd bug, described here: https://github.com/systemd/systemd/issues/14417 There's a patch available: https://github.com/systemd/systemd/pull/16982 Can this be backported to Focal? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1912331/+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 1911059] Re: gce: 247.1-4ubuntu1 causes loss of networking
** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Balint Reczey (rbalint) -- 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/1911059 Title: gce: 247.1-4ubuntu1 causes loss of networking Status in systemd package in Ubuntu: New Bug description: Summary === On Hirsute, upgrading or using to systemd 247.1-4ubuntu1 causes Google Cloud instance to loose network access. Expected Result === Working network access Actual Result === After upgrade, network access is lost and serial console is filled with messages about IPv4 martian source and ll header, see below. Steps to Reproduce === 1. Launch `daily-ubuntu-2104-hirsute-v20210107` the last known good image 2. sudo apt update 3. sudo apt install systemd 4. ssh is lost The images, built with this version do not appear to be able to start networking. Logs === Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915720] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915724] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978762] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978803] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042242] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042302] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105412] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105448] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168141] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168178] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 $ journalctl --no-pager -u systemd-net -- Journal begins at Mon 2021-01-11 21:30:31 UTC, ends at Mon 2021-01-11 21:52:03 UTC. -- Jan 11 21:30:35 ubuntu systemd[1]: Starting Network Service... Jan 11 21:30:35 ubuntu systemd-networkd[413]: Enumeration completed Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Interface name change detected, ens4 has been renamed to eth0. Jan 11 21:30:35 ubuntu systemd[1]: Started Network Service. Jan 11 21:30:35 ubuntu systemd-networkd[413]: eth0: Interface name change detected, eth0 has been renamed to ens4. Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: IPv6 successfully enabled Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Link UP Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Gained carrier Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Classless static routes received from DHCP server: ignoring router option Jan 11 21:30:37 ubuntu systemd-networkd[413]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[413]: ens4: DHCPv6 lease lost Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopping Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: systemd-networkd.service: Succeeded. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopped Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Starting Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: Enumeration completed Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Started Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911059/+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 1911059] Re: gce: 247.1-4ubuntu1 causes loss of networking
** Changed in: systemd (Ubuntu) Assignee: Balint Reczey (rbalint) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1911059 Title: gce: 247.1-4ubuntu1 causes loss of networking Status in systemd package in Ubuntu: New Bug description: Summary === On Hirsute, upgrading or using to systemd 247.1-4ubuntu1 causes Google Cloud instance to loose network access. Expected Result === Working network access Actual Result === After upgrade, network access is lost and serial console is filled with messages about IPv4 martian source and ll header, see below. Steps to Reproduce === 1. Launch `daily-ubuntu-2104-hirsute-v20210107` the last known good image 2. sudo apt update 3. sudo apt install systemd 4. ssh is lost The images, built with this version do not appear to be able to start networking. Logs === Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915720] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915724] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978762] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978803] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042242] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042302] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105412] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105448] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168141] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168178] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 $ journalctl --no-pager -u systemd-net -- Journal begins at Mon 2021-01-11 21:30:31 UTC, ends at Mon 2021-01-11 21:52:03 UTC. -- Jan 11 21:30:35 ubuntu systemd[1]: Starting Network Service... Jan 11 21:30:35 ubuntu systemd-networkd[413]: Enumeration completed Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Interface name change detected, ens4 has been renamed to eth0. Jan 11 21:30:35 ubuntu systemd[1]: Started Network Service. Jan 11 21:30:35 ubuntu systemd-networkd[413]: eth0: Interface name change detected, eth0 has been renamed to ens4. Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: IPv6 successfully enabled Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Link UP Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Gained carrier Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Classless static routes received from DHCP server: ignoring router option Jan 11 21:30:37 ubuntu systemd-networkd[413]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[413]: ens4: DHCPv6 lease lost Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopping Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: systemd-networkd.service: Succeeded. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopped Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Starting Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: Enumeration completed Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Started Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911059/+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 1911059] Re: gce: 247.1-4ubuntu1 causes loss of networking
** Changed in: systemd (Ubuntu) Importance: Undecided => High ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Balint Reczey (rbalint) -- 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/1911059 Title: gce: 247.1-4ubuntu1 causes loss of networking Status in systemd package in Ubuntu: New Bug description: Summary === On Hirsute, upgrading or using to systemd 247.1-4ubuntu1 causes Google Cloud instance to loose network access. Expected Result === Working network access Actual Result === After upgrade, network access is lost and serial console is filled with messages about IPv4 martian source and ll header, see below. Steps to Reproduce === 1. Launch `daily-ubuntu-2104-hirsute-v20210107` the last known good image 2. sudo apt update 3. sudo apt install systemd 4. ssh is lost The images, built with this version do not appear to be able to start networking. Logs === Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915720] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915724] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978762] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978803] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042242] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042302] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105412] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105448] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168141] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168178] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 $ journalctl --no-pager -u systemd-net -- Journal begins at Mon 2021-01-11 21:30:31 UTC, ends at Mon 2021-01-11 21:52:03 UTC. -- Jan 11 21:30:35 ubuntu systemd[1]: Starting Network Service... Jan 11 21:30:35 ubuntu systemd-networkd[413]: Enumeration completed Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Interface name change detected, ens4 has been renamed to eth0. Jan 11 21:30:35 ubuntu systemd[1]: Started Network Service. Jan 11 21:30:35 ubuntu systemd-networkd[413]: eth0: Interface name change detected, eth0 has been renamed to ens4. Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: IPv6 successfully enabled Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Link UP Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Gained carrier Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Classless static routes received from DHCP server: ignoring router option Jan 11 21:30:37 ubuntu systemd-networkd[413]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[413]: ens4: DHCPv6 lease lost Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopping Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: systemd-networkd.service: Succeeded. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopped Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Starting Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: Enumeration completed Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Started Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911059/+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 1892358] Re: autopkgtest success rate dropped inhibiting proposed migration
@sil2100 Yes this bug has been recycled a bit too many times. We should open a new one when the tests become flaky. The fixes related to this bug are present in Hirsute. -- 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/1892358 Title: autopkgtest success rate dropped inhibiting proposed migration Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Bug description: [impact] autopkgtests are failing/flaky and prevent other packages from migrating to -updates [test case] check autopkgtest history [regression potential] in regard to the changed test cases, any regression would likely result in either an incorrectly passed test, or an incorrectly failed test. [scope] for systemd, this is needed for x, b, and f. tests in g appear to be mostly stable, but I've opened MR (linked from this bug) to update the tests there as well. i don't plan to update x, as it's reaching ESM in ~6 months, and backporting the test fixes is more work than just a simple code copy, since there are additional differences/changes needed in the older version of systemd (and python3). the failing/flaky tests in x have been like that forever, and people have just retried them; we can keep retrying them until x moves into ESM next year. [original description] Hi, we had such cases in the past like bug 1817721 for bionic and maybe bug 1892130 is about the same as well. There were more but I didn't want to search for all of them - what I checked is that there are no open ones clearly pointing out the recent further drop in already flaky subtests. In particular the tests "tests-in-lxd" and "systemd-fsckd" were known to be flaky before, but got even worse. Here stats of the last 40 runs, it might be a coincidences that this is after 246-2ubuntu1 landed. Could as well be any other change groovy amd64 tests-in-lxd (F 42% S 0% B 10% => P 45%/) BFFFBFF.B.F.F...FBF build-login(F 0% S 0% B 10% => P 87%/) B...B...BB. unit-config(F 0% S 0% B 10% => P 87%/) B...B...BB. networkd-testpy(F 0% S 0% B 10% => P 87%/) B...B...BB. boot-and-services (F 0% S 0% B 10% => P 87%/) B...B...BB. boot-smoke (F 0% S 0% B 10% => P 87%/) B...B...BB. logind (F 0% S 0% B 10% => P 87%/) B...B...BB. storage(F 0% S 0% B 10% => P 87%/) B...B...BB. upstream (F 35% S 0% B 10% => P 52%/) ..FFB.FFF.FFBFF.B.F.F..FFBF udev (F 0% S 0% B 10% => P 87%/) B...B...BB. systemd-fsckd (F 37% S 0% B 10% => P 50%/) BFFFB.FF...FB.F..B. root-unittests (F 0% S 0% B 10% => P 87%/) B...B...BB. ppc64el tests-in-lxd (F 25% S 0% B 0% => P 75%/) FFFFF.F. systemd-fsckd (F 35% S 0% B 0% => P 65%/) FFF...FFFFF.F..F root-unittests (F 2% S 0% B 0% => P 97%/) ..F. s390x tests-in-lxd (F 52% S 0% B 0% => P 47%/) FFF.FFF.FF....F. timedated (F 2% S 0% B 0% => P 97%/) ...F upstream (F 17% S 0% B 0% => P 82%/) .F..F.F.FFF...F. systemd-fsckd (F 32% S 0% B 0% => P 67%/) FFF..FF..F.FF..F root-unittests (F 10% S 0% B 0% => P 90%/) FFF...F. arm64 tests-in-lxd (F 40% S 0% B 2% => P 57%/) F.B...FFF.FF..F..F.FFF.F logind (F 2% S 0% B 2% => P 95%/) ..B...F. upstream (F 22% S 0% B 2% => P 75%/) ...F.FB.F.F.F..FFF.F root-unittests (F 12% S 0% B 2% => P 85%/) ..B.F...F.FF...F (I'm sure LP will make this unreadable, but is is nice in monospace) Whatever the root cause is - the success rate of these has reduced so much that the (even formerly questionable) practice of retry-until- success won't work anymore. I have run the two tests in a local VM and systemd-fsckd works there while tests-in-lxd seems to
[Touch-packages] [Bug 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.
The fix is not present in Hirsute yet, because I wanted to land them with the merge of 247.2-4 this week. OTOH this fix is fairly small, could it maybe be accepted with the condition of not releasing it until it gets fixed in Hirsute as well? -- 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/1881947 Title: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Status in systemd source package in Hirsute: In Progress Bug description: [Impact] * Autopkgtest fails due to corrupted journal file [Test Case] * Observe autopkgtest root-unittests not failing with: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. [Where problems could occur] * The change has no impact on the systemd binary packages. The relaxed test could hide a journal corruption problem, but it seems the corrupted journal files occur only on arm64 probably due to arm64 reboots being resets: LP: #1748280. [Original Bug Text] Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz [...] PASS: test-journal-enum == test-journal-flush === Root directory /var/log/journal removed. Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed. mmap cache statistics: 739 hit, 5 miss journal_file_copy_entry failed: Bad message Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. FAIL: test-journal-flush (code: 134) Aborted (core dumped) == test-journal-importer === [...] autopkgtest [07:17:29]: summary timedatedPASS hostnamedPASS localed-locale PASS localed-x11-keymap PASS logind PASS unit-config PASS storage PASS networkd-test.py PASS build-login PASS boot-and-servicesPASS udev PASS root-unittests FAIL non-zero exit status 134 upstream PASS boot-smoke PASS systemd-fsckdPASS Exit request sent. [...] To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1881947/+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 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.
@sil2100 yes, I've updated the bug description. ** Description changed: + [Impact] + + * Autopkgtest fails due to corrupted journal file + + [Test Case] + + * Observe autopkgtest root-unittests not failing with: + + Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, + function main(). Aborting. + + [Where problems could occur] + + * The change has no impact on the systemd binary packages. The relaxed + test could hide a journal corruption problem, but it seems the corrupted + journal files occur only on arm64 probably due to arm64 reboots being + resets: LP: #1748280. + + [Original Bug Text] + Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz [...] PASS: test-journal-enum == test-journal-flush === Root directory /var/log/journal removed. Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed. mmap cache statistics: 739 hit, 5 miss journal_file_copy_entry failed: Bad message Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. FAIL: test-journal-flush (code: 134) Aborted (core dumped) == test-journal-importer === [...] autopkgtest [07:17:29]: summary timedatedPASS hostnamedPASS localed-locale PASS localed-x11-keymap PASS logind PASS unit-config PASS storage PASS networkd-test.py PASS build-login PASS boot-and-servicesPASS udev PASS root-unittests FAIL non-zero exit status 134 upstream PASS boot-smoke PASS systemd-fsckdPASS Exit request sent. [...] -- 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/1881947 Title: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Status in systemd source package in Hirsute: In Progress Bug description: [Impact] * Autopkgtest fails due to corrupted journal file [Test Case] * Observe autopkgtest root-unittests not failing with: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. [Where problems could occur] * The change has no impact on the systemd binary packages. The relaxed test could hide a journal corruption problem, but it seems the corrupted journal files occur only on arm64 probably due to arm64 reboots being resets: LP: #1748280. [Original Bug Text] Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz [...] PASS: test-journal-enum == test-journal-flush === Root directory /var/log/journal removed. Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed. mmap cache statistics: 739 hit, 5 miss journal_file_copy_entry failed: Bad message Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. FAIL: test-journal-flush (code: 134) Aborted (core dumped) == test-journal-importer === [...] autopkgtest [07:17:29]: summary timedatedPASS hostnamedPASS localed-locale PASS localed-x11-keymap PASS logind PASS unit-config PASS storage PASS networkd-test.py PASS build-login PASS boot-and-servicesPASS udev PASS root-unittests FAIL non-zero exit status 134 upstream PASS boot-smoke PASS systemd-fsckdPASS Exit request sent. [...] To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1881947/+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 1803391] Re: Systemd update installation hangs in unattended-upgrades InstallOnShutdown mode
@dominic-timedicer Yes, way more likely. You can blacklist systemd in unattended-upgrades to avoid upgrading it unattended until LP:1782709 gets solved. -- 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/1803391 Title: Systemd update installation hangs in unattended-upgrades InstallOnShutdown mode Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] * Installation of latest systemd update in -security hangs with current versions of unattended-upgrades in supported releases. The u-u-side fix is tracked in LP: #1778219. [Regression Potential] * The daemons, shipped in deb:systemd, are not attempted to be restarted because despite package installation the system is in the middle of shutting down. This means that currently running daemons may be helding up open files on the filesystem, however all process are being stopped and killed as part of shutdown. Hence the worst possible regression from this, is an unclean shutdown, but even that shouldn't happen with this update. [Test Case] Reproduction: rbalint@yogi:~$ lxc launch ubuntu:18.04 uu-systemd-onshutdown Creating uu-systemd-onshutdown Starting uu-systemd-onshutdown rbalint@yogi:~$ lxc shell uu-systemd-onshutdown mesg: ttyname failed: No such device root@uu-systemd-onshutdown:~# apt update -qq 23 packages can be upgraded. Run 'apt list --upgradable' to see them. root@uu-systemd-onshutdown:~# echo 'Unattended-Upgrade::InstallOnShutdown "true";' > /etc/apt/apt.conf.d/51unattended-upgrades-on-shutdown root@uu-systemd-onshutdown:~# apt list --upgradable Listing... Done apport/bionic-updates 2.20.9-0ubuntu7.5 all [upgradable from: 2.20.9-0ubuntu7.4] gettext-base/bionic-updates,bionic-security 0.19.8.1-6ubuntu0.1 amd64 [upgradable from: 0.19.8.1-6] kmod/bionic-updates 24-1ubuntu3.1 amd64 [upgradable from: 24-1ubuntu3] libglib2.0-0/bionic-updates 2.56.3-0ubuntu0.18.04.1 amd64 [upgradable from: 2.56.2-0ubuntu0.18.04.2] libglib2.0-data/bionic-updates 2.56.3-0ubuntu0.18.04.1 all [upgradable from: 2.56.2-0ubuntu0.18.04.2] libkmod2/bionic-updates 24-1ubuntu3.1 amd64 [upgradable from: 24-1ubuntu3] libmspack0/bionic-updates,bionic-security 0.6-3ubuntu0.2 amd64 [upgradable from: 0.6-3ubuntu0.1] libnss-systemd/bionic-updates,bionic-security 237-3ubuntu10.6 amd64 [upgradable from: 237-3ubuntu10.3] libpam-systemd/bionic-updates,bionic-security 237-3ubuntu10.6 amd64 [upgradable from: 237-3ubuntu10.3] libsystemd0/bionic-updates,bionic-security 237-3ubuntu10.6 amd64 [upgradable from: 237-3ubuntu10.3] libudev1/bionic-updates,bionic-security 237-3ubuntu10.6 amd64 [upgradable from: 237-3ubuntu10.3] lxd/bionic-updates 3.0.2-0ubuntu1~18.04.1 amd64 [upgradable from: 3.0.1-0ubuntu1~18.04.1] lxd-client/bionic-updates 3.0.2-0ubuntu1~18.04.1 amd64 [upgradable from: 3.0.1-0ubuntu1~18.04.1] openssh-client/bionic-updates,bionic-security 1:7.6p1-4ubuntu0.1 amd64 [upgradable from: 1:7.6p1-4] openssh-server/bionic-updates,bionic-security 1:7.6p1-4ubuntu0.1 amd64 [upgradable from: 1:7.6p1-4] openssh-sftp-server/bionic-updates,bionic-security 1:7.6p1-4ubuntu0.1 amd64 [upgradable from: 1:7.6p1-4] python3-apport/bionic-updates 2.20.9-0ubuntu7.5 all [upgradable from: 2.20.9-0ubuntu7.4] python3-distupgrade/bionic-updates 1:18.04.28 all [upgradable from: 1:18.04.27] python3-problem-report/bionic-updates 2.20.9-0ubuntu7.5 all [upgradable from: 2.20.9-0ubuntu7.4] systemd/bionic-updates,bionic-security 237-3ubuntu10.6 amd64 [upgradable from: 237-3ubuntu10.3] systemd-sysv/bionic-updates,bionic-security 237-3ubuntu10.6 amd64 [upgradable from: 237-3ubuntu10.3] ubuntu-release-upgrader-core/bionic-updates 1:18.04.28 all [upgradable from: 1:18.04.27] udev/bionic-updates,bionic-security 237-3ubuntu10.6 amd64 [upgradable from: 237-3ubuntu10.3] root@uu-systemd-onshutdown:~# reboot Session terminated, terminating shell...Terminated root@uu-systemd- rbalint@yogi:~$ rbalint@yogi:~$ lxc shell uu-systemd-onshutdown mesg: ttyname failed: No such device root@uu-systemd-onshutdown:~# tail /var/log/unattended-upgrades/unattended-upgrades-dpkg.log Preparing to unpack .../libsystemd0_237-3ubuntu10.6_amd64.deb ... Unpacking libsystemd0:amd64 (237-3ubuntu10.6) over (237-3ubuntu10.3) ... Setting up libsystemd0:amd64 (237-3ubuntu10.6) ... Processing triggers for ureadahead (0.100.0-20) ... Processing triggers for libc-bin (2.27-3ubuntu1) ... Setting up systemd (237-3ubuntu10.6) ... Failed to try-restart systemd-networkd.service: Transaction is destructive. See system logs and
[Touch-packages] [Bug 1627564] Re: Debconf crash due to assertion failure in ensure_surface_for_gicon [gtkiconhelper.c:493] (when png loader is missing/during upgrades)
This is indeed a complex problem and it is hard to do anything
reasonable about a missing GTK frontend when debconf is not initiated
from the terminal.
OTOH I think there is an easy fix for GTK+ to always include an "image-
missing" icon at compile time, but apparently I'm not the first one
coming up with this idea, but something is still broken:
gtk/gtkiconhelper.c:494
if (destination == NULL)
{
GError *error = NULL;
destination = gtk_icon_theme_load_icon (icon_theme,
"image-missing",
width,
flags |
GTK_ICON_LOOKUP_USE_BUILTIN | GTK_ICON_LOOKUP_GENERIC_FALLBACK,
);
/* We include this image as resource, so we always have it available or
* the icontheme code is broken */
g_assert_no_error (error);
g_assert (destination);
symbolic = FALSE;
}
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to debconf in Ubuntu.
https://bugs.launchpad.net/bugs/1627564
Title:
Debconf crash due to assertion failure in ensure_surface_for_gicon
[gtkiconhelper.c:493] (when png loader is missing/during upgrades)
Status in debconf package in Ubuntu:
Confirmed
Status in gtk+3.0 package in Ubuntu:
New
Status in debconf source package in Focal:
Confirmed
Status in gtk+3.0 source package in Focal:
New
Bug description:
https://errors.ubuntu.com/problem/2b11576fed59ad23c640bc85a266cc82ec30a689
https://errors.ubuntu.com/problem/9d612b3f25168e76adb91fa4eedc301ffa632383
---
bubble opened up indicating there was a failure during the latest
update.
ProblemType: Crash
DistroRelease: Ubuntu 16.10
Package: lightdm-gtk-greeter 2.0.1-2ubuntu4
ProcVersionSignature: Ubuntu 4.8.0-16.17-generic 4.8.0-rc7
Uname: Linux 4.4.0-9136-generic i686
ApportVersion: 2.20.3-0ubuntu7
Architecture: i386
Date: Sun Sep 25 20:37:06 2016
ExecutablePath: /usr/sbin/lightdm-gtk-greeter
InstallationDate: Installed on 2016-08-04 (52 days ago)
InstallationMedia: Lubuntu 16.10 "Yakkety Yak" - Alpha i386 (20160727)
ProcCmdline: /usr/sbin/lightdm-gtk-greeter
ProcEnviron:
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/false
Signal: 6
SourcePackage: lightdm-gtk-greeter
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:
modified.conffile..etc.lightdm.lightdm-gtk-greeter.conf:
[greeter]
theme-name = Lubuntu-dark-panel
mtime.conffile..etc.lightdm.lightdm-gtk-greeter.conf:
2016-08-14T22:33:57.293011
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1627564/+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 1627564] Re: Debconf crash due to assertion failure in ensure_surface_for_gicon [gtkiconhelper.c:493] (when png loader is missing/during upgrades)
** Also affects: gtk+3.0 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1627564 Title: Debconf crash due to assertion failure in ensure_surface_for_gicon [gtkiconhelper.c:493] (when png loader is missing/during upgrades) Status in debconf package in Ubuntu: Confirmed Status in gtk+3.0 package in Ubuntu: New Status in debconf source package in Focal: Confirmed Status in gtk+3.0 source package in Focal: New Bug description: https://errors.ubuntu.com/problem/2b11576fed59ad23c640bc85a266cc82ec30a689 https://errors.ubuntu.com/problem/9d612b3f25168e76adb91fa4eedc301ffa632383 --- bubble opened up indicating there was a failure during the latest update. ProblemType: Crash DistroRelease: Ubuntu 16.10 Package: lightdm-gtk-greeter 2.0.1-2ubuntu4 ProcVersionSignature: Ubuntu 4.8.0-16.17-generic 4.8.0-rc7 Uname: Linux 4.4.0-9136-generic i686 ApportVersion: 2.20.3-0ubuntu7 Architecture: i386 Date: Sun Sep 25 20:37:06 2016 ExecutablePath: /usr/sbin/lightdm-gtk-greeter InstallationDate: Installed on 2016-08-04 (52 days ago) InstallationMedia: Lubuntu 16.10 "Yakkety Yak" - Alpha i386 (20160727) ProcCmdline: /usr/sbin/lightdm-gtk-greeter ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/false Signal: 6 SourcePackage: lightdm-gtk-greeter UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: modified.conffile..etc.lightdm.lightdm-gtk-greeter.conf: [greeter] theme-name = Lubuntu-dark-panel mtime.conffile..etc.lightdm.lightdm-gtk-greeter.conf: 2016-08-14T22:33:57.293011 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1627564/+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 1907744] Re: package unattended-upgrades 2.3ubuntu0.1 failed to install/upgrade: installed unattended-upgrades package post-installation script subprocess was killed by signal (A
*** This bug is a duplicate of bug 1627564 *** https://bugs.launchpad.net/bugs/1627564 ** This bug has been marked a duplicate of bug 1627564 Debconf crash due to assertion failure in ensure_surface_for_gicon [gtkiconhelper.c:493] (when png loader is missing/during upgrades) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1907744 Title: package unattended-upgrades 2.3ubuntu0.1 failed to install/upgrade: installed unattended-upgrades package post-installation script subprocess was killed by signal (Aborted) Status in unattended-upgrades package in Ubuntu: New Bug description: I have problems, it has disappeared programs. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: unattended-upgrades 2.3ubuntu0.1 ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65 Uname: Linux 5.4.0-54-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.13 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Dec 10 19:18:08 2020 ErrorMessage: installed unattended-upgrades package post-installation script subprocess was killed by signal (Aborted) InstallationDate: Installed on 2014-04-19 (2427 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.2 SourcePackage: unattended-upgrades Title: package unattended-upgrades 2.3ubuntu0.1 failed to install/upgrade: installed unattended-upgrades package post-installation script subprocess was killed by signal (Aborted) UpgradeStatus: Upgraded to focal on 2020-12-11 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1907744/+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 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
@mvo: Fedora switched in 2019: https://medium.com/nttlabs/cgroup-v2-596d035be4d7 Debian switched with systemd 247.2-2 https://tracker.debian.org/news/1204112/accepted-systemd-2472-2-source-into-unstable/ I was about to follow Debian in systemd, but I'm holding the switch back for now. Could you please provide a link where snapd's progress can be tracked? I plan keeping the current systemd default then for 21.04 to minimize disruption and give some more time for preparation, but I'd like to make the switch early in the 21.10 cycle to also have time to fix regressions by 21.10's release. -- 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/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in docker.io package in Ubuntu: New Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1850667/+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 1906701] Re: Please merge logrotate 3.17.0-1 (main) from Debian unstable (main)
Uploaded to Hirsute. ** Changed in: logrotate (Ubuntu) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to logrotate in Ubuntu. https://bugs.launchpad.net/bugs/1906701 Title: Please merge logrotate 3.17.0-1 (main) from Debian unstable (main) Status in logrotate package in Ubuntu: Fix Committed Bug description: Please merge logrotate 3.17.0-1 (main) from Debian unstable (main) At the time of filling this bug, the target debian unstable version is 3.17.0-2. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1906701/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
I was late, qemu migrated. ** Tags removed: block-proposed -- 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in systemd: Unknown Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: In Progress Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1908259/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
@cpaelze I've triggered the qemu autopkgtest with systemd from -proposed and it passes indeed. The problem is that allows qemu to migrate before systemd breaking all autopkgests as described in LP: #1908508. Please remove the block-proposed tag when systemd is ready to migrate. -- 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in systemd: Unknown Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: In Progress Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1908259/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
** Tags added: block-proposed -- 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in systemd: Unknown Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: In Progress Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1908259/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
** Changed in: systemd (Ubuntu) Status: New => In Progress ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Balint Reczey (rbalint) -- 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in systemd: Unknown Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: In Progress Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1908259/+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 1908136] Re: no_proxy=::1 is not honored by curl in Bionic and earlier versions
Maybe it was just a coincidence, but those regressions disappeared immediately when reverting the ::1 addition: LP: #1907959 https://autopkgtest.ubuntu.com/packages/s/samtools/bionic/amd64 LP: #1907955 https://autopkgtest.ubuntu.com/packages/r/ruby2.5/bionic/amd64 Since you are around would you be so kind and address @laney's more than wone yeare old comments in the following MR so the cowboy deployed can be dropped and does not make extra work for @laney to land fixes? https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/376587 -- 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/1908136 Title: no_proxy=::1 is not honored by curl in Bionic and earlier versions Status in Auto Package Testing: New Status in curl package in Ubuntu: Fix Released Status in curl source package in Xenial: New Status in curl source package in Bionic: New Status in curl source package in Focal: Fix Released Bug description: Bionic: env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Could not resolve proxy: foo * Closing connection 0 curl: (5) Could not resolve proxy: foo Focal: $ env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Uses proxy env variable no_proxy == '::1' * Trying ::1:80... * TCP_NODELAY set * Immediate connect fail for ::1: Network is unreachable * Closing connection 0 curl: (7) Couldn't connect to server To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1908136/+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 1908136] Re: no_proxy=::1 is not honored by curl in Bionic and earlier versions
** Tags added: rls-bb-incoming rls-x-incoming -- 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/1908136 Title: no_proxy=::1 is not honored by curl in Bionic and earlier versions Status in Auto Package Testing: New Status in curl package in Ubuntu: Fix Released Status in curl source package in Xenial: New Status in curl source package in Bionic: New Status in curl source package in Focal: Fix Released Bug description: Bionic: env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Could not resolve proxy: foo * Closing connection 0 curl: (5) Could not resolve proxy: foo Focal: $ env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Uses proxy env variable no_proxy == '::1' * Trying ::1:80... * TCP_NODELAY set * Immediate connect fail for ::1: Network is unreachable * Closing connection 0 curl: (7) Couldn't connect to server To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1908136/+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 1908136] Re: no_proxy=::1 is not honored by curl in Bionic and earlier versions
** Summary changed: - no_proxy=::1 is not honored in Bionic and earlier versions + no_proxy=::1 is not honored by curl in Bionic and earlier versions -- 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/1908136 Title: no_proxy=::1 is not honored by curl in Bionic and earlier versions Status in Auto Package Testing: New Status in curl package in Ubuntu: Fix Released Status in curl source package in Xenial: New Status in curl source package in Bionic: New Status in curl source package in Focal: Fix Released Bug description: Bionic: env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Could not resolve proxy: foo * Closing connection 0 curl: (5) Could not resolve proxy: foo Focal: $ env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Uses proxy env variable no_proxy == '::1' * Trying ::1:80... * TCP_NODELAY set * Immediate connect fail for ::1: Network is unreachable * Closing connection 0 curl: (7) Couldn't connect to server To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1908136/+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 1908136] Re: no_proxy=::1 is not honored in Bionic and earlier versions
Recently the autopkgtest infrastructure configuration has been changed to add ::1 to no_proxy. This works on Focal and up, but breaks unknown number of tests in Bionic and earlier releases. commit f3679e7609b2f03d59aca28fe7329e4228350200 Author: Steve Langasek Date: Fri Dec 4 12:00:02 2020 -0800 Include ipv6 localhost in the list of addresses not to use the proxy for. This fixes schleuder autopkgtest failure on armhf, which tries to connect to [::1]:4443 and fails because it's routed to the proxy. This failure does not affect the VM-based autopkgtest runners because containers also have some strangeness regarding binding to ::1 being treated as bindv6only=1, and schleuder's test only requires that ipv4 *or* ipv6 succeeds; but the change is appropriate across all architectures. lxc-slave-admin/setup-adt-lxc.commands | 2 +- tools/armhf-lxd-slave.userdata | 2 +- worker-config-production/worker-bos01-arm64.conf | 2 +- worker-config-production/worker-bos01-ppc64el.conf | 2 +- worker-config-production/worker-bos01-s390x.conf | 2 +- worker-config-production/worker-bos01.conf | 2 +- worker-config-production/worker-bos02-arm64.conf | 2 +- worker-config-production/worker-bos02-ppc64el.conf | 2 +- worker-config-production/worker-bos02-s390x.conf | 2 +- worker-config-production/worker-canonistack.conf | 2 +- worker-config-production/worker-lxd.conf | 2 +- worker-config-production/worker.conf | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) -- 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/1908136 Title: no_proxy=::1 is not honored in Bionic and earlier versions Status in Auto Package Testing: New Status in curl package in Ubuntu: Fix Released Status in curl source package in Xenial: New Status in curl source package in Bionic: New Status in curl source package in Focal: Fix Released Bug description: Bionic: env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Could not resolve proxy: foo * Closing connection 0 curl: (5) Could not resolve proxy: foo Focal: $ env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Uses proxy env variable no_proxy == '::1' * Trying ::1:80... * TCP_NODELAY set * Immediate connect fail for ::1: Network is unreachable * Closing connection 0 curl: (7) Couldn't connect to server To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1908136/+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 1908136] Re: no_proxy=::1 is not honored in Bionic and earlier versions
Upstream bug: https://github.com/curl/curl/issues/2353 ** Also affects: auto-package-testing Importance: Undecided Status: New -- 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/1908136 Title: no_proxy=::1 is not honored in Bionic and earlier versions Status in Auto Package Testing: New Status in curl package in Ubuntu: Fix Released Status in curl source package in Xenial: New Status in curl source package in Bionic: New Status in curl source package in Focal: Fix Released Bug description: Bionic: env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Could not resolve proxy: foo * Closing connection 0 curl: (5) Could not resolve proxy: foo Focal: $ env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Uses proxy env variable no_proxy == '::1' * Trying ::1:80... * TCP_NODELAY set * Immediate connect fail for ::1: Network is unreachable * Closing connection 0 curl: (7) Couldn't connect to server To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1908136/+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 1908136] [NEW] no_proxy=::1 is not honored in Bionic and earlier versions
Public bug reported: Bionic: env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Could not resolve proxy: foo * Closing connection 0 curl: (5) Could not resolve proxy: foo Focal: $ env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Uses proxy env variable no_proxy == '::1' * Trying ::1:80... * TCP_NODELAY set * Immediate connect fail for ::1: Network is unreachable * Closing connection 0 curl: (7) Couldn't connect to server ** Affects: auto-package-testing Importance: Undecided Status: New ** Affects: curl (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: curl (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: curl (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: curl (Ubuntu Focal) Importance: Undecided Status: Fix Released ** Also affects: curl (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: curl (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: curl (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: curl (Ubuntu Focal) Status: New => Fix Released ** Changed in: curl (Ubuntu) Status: New => Fix Released ** Bug watch added: github.com/curl/curl/issues #2353 https://github.com/curl/curl/issues/2353 -- 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/1908136 Title: no_proxy=::1 is not honored in Bionic and earlier versions Status in Auto Package Testing: New Status in curl package in Ubuntu: Fix Released Status in curl source package in Xenial: New Status in curl source package in Bionic: New Status in curl source package in Focal: Fix Released Bug description: Bionic: env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Could not resolve proxy: foo * Closing connection 0 curl: (5) Could not resolve proxy: foo Focal: $ env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html * Uses proxy env variable no_proxy == '::1' * Trying ::1:80... * TCP_NODELAY set * Immediate connect fail for ::1: Network is unreachable * Closing connection 0 curl: (7) Couldn't connect to server To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1908136/+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 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
Thank you everyone for implementing cgroup v2 support Snapd is not reported here to be fixed, but it may be: https://github.com/ubports/ubports-installer/issues/1448 @maciek-borzecki could you please confirm that snapd is fixed? Debian plans switching systemd to use cgroupv2 by default and if every package listed as affected here is ready I plan making the switch in Ubuntu, too. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943981 ** Bug watch added: github.com/ubports/ubports-installer/issues #1448 https://github.com/ubports/ubports-installer/issues/1448 ** Bug watch added: Debian Bug tracker #943981 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943981 -- 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/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in docker.io package in Ubuntu: New Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1850667/+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 1907472] Re: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed
I hoped to reproduce the issue with the help of qemu-x86_64 but it does not want to run x32 ELF. apt build-dep glibc sed -i 's/backports/proposed/' /etc/apt/sources.list apt update apt install libctf-nobfd0 libctf0 binutils-x86-64-linux-gnu libbinutils binutils binutils-common x86_64-linux-gnu-gcc-10 -mx32 test-double-libmvec-sincos-main.c -std=gnu11 -fgnu89-inline -pipe -O2 -g -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fstack-protector-strong -Wstrict-prototypes -Wold-style-definition -fmath-errno -fpie -fcf-protection -U_FORTIFY_SOURCE -lm ./a.out qemu-x86_64-static ./a.out ./a.out: Invalid ELF image for this architecture Will continue investigation tomorrow. ** Attachment added: "test-double-libmvec-sincos-main-modified.c" https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1907472/+attachment/5442310/+files/test-double-libmvec-sincos-main-modified.c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1907472 Title: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed Status in audit package in Ubuntu: New Status in binutils package in Ubuntu: New Status in glibc package in Ubuntu: New Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- hirsute/hirsute/amd64/g/glibc/20201208_160143_17354@/log.gz -- FAIL: math/test-double-libmvec-sincos original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-double-vlen2-sincos original exit status 132 -- -- FAIL: math/test-float-libmvec-sincosf original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-float-vlen4-sincos original exit status 132 -- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1907472/+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 1907472] Re: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed
It did not fail locally for me on an i5 CPU. CPU in the autopkgtest infra: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- hirsute/hirsute/amd64/c/cpuinfo/20201114_005620_e8a1d@/log.gz autopkgtest [00:55:54]: test command2: /usr/bin/cpu-info autopkgtest [00:55:54]: test command2: [--- Packages: 0: AMD Opteron 62xx class Microarchitectures: 1x Bulldozer Cores: 0: 1 processor (0), AMD Bulldozer Logical processors (System ID): 0 (0): APIC ID 0x ... Local CPU: autopkgtest [17:16:25]: test command2: /usr/bin/cpu-info autopkgtest [17:16:25]: test command2: [--- Packages: 0: Intel Core i5-4670 Microarchitectures: 4x Haswell Cores: 0: 1 processor (0), Intel Haswell 1: 1 processor (1), Intel Haswell 2: 1 processor (2), Intel Haswell 3: 1 processor (3), Intel Haswell Logical processors (System ID): 0 (0): APIC ID 0x 1 (1): APIC ID 0x0002 2 (2): APIC ID 0x0004 3 (3): APIC ID 0x0006 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1907472 Title: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed Status in audit package in Ubuntu: New Status in binutils package in Ubuntu: New Status in glibc package in Ubuntu: New Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- hirsute/hirsute/amd64/g/glibc/20201208_160143_17354@/log.gz -- FAIL: math/test-double-libmvec-sincos original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-double-vlen2-sincos original exit status 132 -- -- FAIL: math/test-float-libmvec-sincosf original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-float-vlen4-sincos original exit status 132 -- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1907472/+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 1907472] Re: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed
$ diff bulldozer-isa-info i5-isa-info 6,7c6,7 < BMI: no < BMI2: no --- > BMI: yes > BMI2: yes 10,12c10,12 < MOVBE: no < PREFETCH: yes < PREFETCHW: yes --- > MOVBE: yes > PREFETCH: no > PREFETCHW: no 28,29c28,29 < SSE4a: yes < Misaligned SSE: yes --- > SSE4a: no > Misaligned SSE: no 31,35c31,35 < FMA3: no < FMA4: yes < XOP: yes < F16C: no < AVX2: no --- > FMA3: yes > FMA4: no > XOP: no > F16C: yes > AVX2: yes 54c54 < MONITOR/MWAIT: no --- > MONITOR/MWAIT: yes 67c67 < RDRAND: no --- > RDRAND: yes 71c71 < RDTSCP: no --- > RDTSCP: yes -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1907472 Title: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed Status in audit package in Ubuntu: New Status in binutils package in Ubuntu: New Status in glibc package in Ubuntu: New Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- hirsute/hirsute/amd64/g/glibc/20201208_160143_17354@/log.gz -- FAIL: math/test-double-libmvec-sincos original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-double-vlen2-sincos original exit status 132 -- -- FAIL: math/test-float-libmvec-sincosf original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-float-vlen4-sincos original exit status 132 -- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1907472/+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
