[Touch-packages] [Bug 1843099] Re: Unattended upgrades does not work on shutdown
I'll give it a shot and report back. However the code in u-s-s is checking against a FD as if it's an errval or retval and so if it's >0, it bails when it's a legit FD. Either way - I'll try to do this tomorrow and report back. -- 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/1843099 Title: Unattended upgrades does not work on shutdown Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu * Ubuntu Xenial 16.04.6 LTS 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center * 1.1ubuntu1.18.04.7~16.04.3 3) What you expected to happen * Packages to be upgraded on reboot / shutdown. 4) What happened instead * The host just rebooted. Didn't perform upgrades. No useful output either until I enabled debug logging in the systemd unit file. I'm reporting a new bug but this is very similar to #1806487 and I'm actually wondering if it resurfaced somehow. We're running Ubuntu Xenial 16.04.6 which has 1.1ubuntu1.18.04.7~16.04.3 installed. I see that #1806487 was resolved with 1.1ubuntu1.18.04.7~16.04.2. However I'm seeing similar behavior. So far I've modified systemd to see if anything stands out. I do have an strace and then just debug mode. Unless needed, simply put, this is what a reboot with debug logging looks like (i.e. unattended-upgrades-shutdown.log): 2019-09-06 09:20:04,871 DEBUG - Waiting for signal to start operation 2019-09-06 09:20:43,996 WARNING - SIGTERM or SIGHUP received, stopping unattended-upgradesonly if it is running 2019-09-06 09:20:43,996 DEBUG - Starting countdown of 25.0 minutes 2019-09-06 09:20:43,997 DEBUG - get_lock returned 7 2019-09-06 09:20:43,997 DEBUG - lock not taken I hope that helps, please let me know if you need anything else from me or if I can provide any more information. I've done this many times before, this is the first time it hasn't worked. When I patched around the end of May, all went well. My other variants worked, well mainly Trusty but that's EOL for public access. Bionic doesn't seem to have anything it needs to update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez
** Also affects: linux (Ubuntu Eoan) Importance: Low Status: Invalid ** Also affects: bluez (Ubuntu Eoan) Importance: Medium Assignee: Dan Streetman (ddstreet) Status: In Progress ** Also affects: systemd (Ubuntu Eoan) Importance: Undecided Status: Invalid ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: bluez (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: bluez (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Disco) Status: New => Invalid ** Changed in: systemd (Ubuntu Bionic) Status: New => Invalid ** Changed in: linux (Ubuntu Disco) Status: New => Invalid ** Changed in: linux (Ubuntu Bionic) Status: New => Invalid ** Changed in: bluez (Ubuntu Disco) Importance: Undecided => Medium ** Changed in: bluez (Ubuntu Disco) Status: New => In Progress ** Changed in: bluez (Ubuntu Disco) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: bluez (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: bluez (Ubuntu Bionic) Status: New => In Progress ** Changed in: bluez (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1759836 Title: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez source package in Bionic: In Progress Status in linux source package in Bionic: Invalid Status in systemd source package in Bionic: Invalid Status in bluez source package in Disco: In Progress Status in linux source package in Disco: Invalid Status in systemd source package in Disco: Invalid Status in bluez source package in Eoan: In Progress Status in linux source package in Eoan: Invalid Status in systemd source package in Eoan: Invalid Status in bluez package in Debian: New Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843508] [NEW] Apt erases console output from commands that were run prior to it.
Public bug reported: Apt is erasing the previous contents of my terminal window. The output from commands that had been run prior to running apt were entirely erased from the terminal's historical record. This is seriously bad etiquette, you should not ever take a dump all over the historical record of a terminal's output. The scroll-back feature is intentionally there so you can show a linear sequence of events. Back in the day consoles were connected directly to printers, and in fact some companies still do this for security auditing purposes, so you have to presume the terminal can only be written to... this is why it's called standard out. Overwriting is a serious no no. Also I'm not happy about apt breaking scripted execution (wtf were you thinking?), but this overwriting of the console record is a flagrant violation of proper etiquette. Please do the needful! Steps to reproduce: fio --randrepeat=1 --ioengine=libaio --direct=0 --gtod_reduce=1 --name=test --filename=test -iodepth=32 --size=32G --readwrite=randrw --rwmixread=60 --bsrange=4k-1024k --numjobs=6 --group_reporting=1 -random_distribution=zipf:0.5 --loops 3 --norandommap=1 --random_generator=lfsr --unified_rw_reporting=1 apt install --reinstall zfs-dkms ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: apt 1.6.11 ProcVersionSignature: Ubuntu 5.0.0-27.28~18.04.1-lowlatency 5.0.21 Uname: Linux 5.0.0-27-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zavl icp zlua zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 Date: Tue Sep 10 16:58:22 2019 InstallationDate: Installed on 2019-05-23 (110 days ago) InstallationMedia: Ubuntu-Server 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic third-party-packages -- 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/1843508 Title: Apt erases console output from commands that were run prior to it. Status in apt package in Ubuntu: New Bug description: Apt is erasing the previous contents of my terminal window. The output from commands that had been run prior to running apt were entirely erased from the terminal's historical record. This is seriously bad etiquette, you should not ever take a dump all over the historical record of a terminal's output. The scroll-back feature is intentionally there so you can show a linear sequence of events. Back in the day consoles were connected directly to printers, and in fact some companies still do this for security auditing purposes, so you have to presume the terminal can only be written to... this is why it's called standard out. Overwriting is a serious no no. Also I'm not happy about apt breaking scripted execution (wtf were you thinking?), but this overwriting of the console record is a flagrant violation of proper etiquette. Please do the needful! Steps to reproduce: fio --randrepeat=1 --ioengine=libaio --direct=0 --gtod_reduce=1 --name=test --filename=test -iodepth=32 --size=32G --readwrite=randrw --rwmixread=60 --bsrange=4k-1024k --numjobs=6 --group_reporting=1 -random_distribution=zipf:0.5 --loops 3 --norandommap=1 --random_generator=lfsr --unified_rw_reporting=1 apt install --reinstall zfs-dkms ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: apt 1.6.11 ProcVersionSignature: Ubuntu 5.0.0-27.28~18.04.1-lowlatency 5.0.21 Uname: Linux 5.0.0-27-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zavl icp zlua zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 Date: Tue Sep 10 16:58:22 2019 InstallationDate: Installed on 2019-05-23 (110 days ago) InstallationMedia: Ubuntu-Server 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash 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/1843508/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez
This bug was fixed in the package bluez - 5.50-0ubuntu4 --- bluez (5.50-0ubuntu4) eoan; urgency=medium * d/p/lp1759836.patch: avoid endless udev events from new bind uevents (LP: #1759836) -- Dan Streetman Tue, 10 Sep 2019 17:22:37 -0400 ** Changed in: bluez (Ubuntu Eoan) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1759836 Title: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez source package in Bionic: In Progress Status in linux source package in Bionic: Invalid Status in systemd source package in Bionic: Invalid Status in bluez source package in Disco: In Progress Status in linux source package in Disco: Invalid Status in systemd source package in Disco: Invalid Status in bluez source package in Eoan: Fix Released Status in linux source package in Eoan: Invalid Status in systemd source package in Eoan: Invalid Status in bluez package in Debian: New Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843490] Re: lxc.cgroup.devices.allow prevents unprivileged container from starting
"lxc.cgroup.devices" is meaningless for unprivileged containers as those can never create those devices anyway, so they'll only ever have access to whatever devices lxc provides and nothing more. All our own default configs specifically do not set that cgroup controller for unprivileged containers. The error you're getting specifically suggests that the cgroups that are delegated to your unprivileged users do not include the devices controller which does match what I'm seeing in /proc/self/cgroup on my system here. If you wanted to be able to write to the devices cgroup, you would need your user session to have the devices cgroup in /proc/self/cgroup point to a path that your user can write to. At which point the config should work, though still effectively be meaningless. ** Changed in: lxc (Ubuntu) Status: New => Invalid -- 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/1843490 Title: lxc.cgroup.devices.allow prevents unprivileged container from starting Status in lxc package in Ubuntu: Invalid Bug description: Adding lxc.cgroup.devices.allow directives to an unprivileged container config prevent the container from starting. These lxc-start errors look relevant: lxc-start testbox 20190910192712.171 WARN cgfsng - cgroups/cgfsng.c:get_hierarchy:204 - There is no useable devices controller lxc-start testbox 20190910192712.171 ERRORcgfsng - cgroups/cgfsng.c:cg_legacy_set_data:2191 - Failed to setup limits for the "devices" controller. The controller seems to be unused by "cgfsng" cgroup driver or not enabled on the cgroup hierarchy lxc-start testbox 20190910192712.171 WARN cgfsng - cgroups/cgfsng.c:__cg_legacy_setup_limits:2228 - Failed to set "devices.allow" to "c 10:57 rwm" It seems to me that I used lxc.cgroup.devices.allow directives without trouble a few years ago. I wonder which system upgrades broke it. To reproduce: (Note: subuid, subgid, and lxc-usernet are already configured for this user.) $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 19.04 Release: 19.04 Codename: disco $ dpkg-query --show libpam-cgfs lxc1 libpam-cgfs 3.0.3-0ubuntu1 lxc1 3.0.3-0ubuntu1 $ lxc-create -t download -n testbox -- -d ubuntu -r bionic -a amd64 The cached copy has expired, re-downloading... Setting up the GPG keyring Downloading the image index Downloading the rootfs Downloading the metadata The image cache is now ready Unpacking the rootfs --- You just created an Ubuntu bionic amd64 (20190910_07:42) container. To enable SSH, run: apt install openssh-server No default root or user password are set by LXC. $ echo "lxc.cgroup.devices.allow = c 10:57 rwm" >> lxc/testbox/config $ lxc-start -n testbox -o debug.out -l trace lxc-start: testbox: lxccontainer.c: wait_on_daemonized_start: 842 Received container state "ABORTING" instead of "RUNNING" lxc-start: testbox: tools/lxc_start.c: main: 330 The container failed to start lxc-start: testbox: tools/lxc_start.c: main: 333 To get more details, run the container in foreground mode lxc-start: testbox: tools/lxc_start.c: main: 336 Additional information can be obtained by setting the --logfile and --logpriority options $ cat debug.out lxc-start testbox 20190910192712.380 INFO confile - confile.c:set_config_idmaps:1555 - Read uid map: type u nsid 0 hostid 10 range 65536 lxc-start testbox 20190910192712.380 INFO confile - confile.c:set_config_idmaps:1555 - Read uid map: type g nsid 0 hostid 10 range 65536 lxc-start testbox 20190910192712.382 TRACEcommands - commands.c:lxc_cmd:300 - Connection refused - Command "get_init_pid" failed to connect command socket lxc-start testbox 20190910192712.383 TRACEcommands - commands.c:lxc_cmd:300 - Connection refused - Command "get_state" failed to connect command socket lxc-start testbox 20190910192712.383 TRACEstart - start.c:lxc_init_handler:748 - Created anonymous pair {4,5} of unix sockets lxc-start testbox 20190910192712.383 TRACEcommands - commands.c:lxc_cmd_init:1248 - Creating abstract unix socket "/home/ubuntu/lxc/testbox/command" lxc-start testbox 20190910192712.383 TRACEstart - start.c:lxc_init_handler:760 - Unix domain socket 6 for command server is ready lxc-start testbox 20190910192712.388 INFO lxccontainer - lxccontainer.c:do_lxcapi_start:961 - Set process title to [lxc monitor] /home/ubuntu/lxc testbox lxc-start testbox 20190910192712.392 TRACEstart - start.c:lxc_start:2052 - Doing lxc_start lxc-start testbox 20190910192712.393 INFO lsm - lsm/lsm.c:lsm_init:50 - LSM security driver AppArmor lxc-start testbox 20190910192712.393 TRACEstart - start.c:lxc_init:777 - Initialized LSM lxc-start testbox 20190910192712.395 TRACEseccomp
[Touch-packages] [Bug 1843515] [NEW] noise when browse the web
Public bug reported: there is noise for last two days it seems power or cpu fun ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18 Uname: Linux 4.15.0-62-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CompositorRunning: None Date: Tue Sep 10 18:04:50 2019 DistUpgraded: 2018-12-28 05:53:36,266 DEBUG icon theme changed, re-reading DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0623] InstallationDate: Installed on 2018-12-25 (259 days ago) InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 064e:a133 Suyin Corp. Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer Aspire 5349 ProcEnviron: PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-62-generic root=UUID=66ebe799-d994-4d80-bfe0-f65827b65871 ro quiet splash vt.handoff=1 SourcePackage: xorg UpgradeStatus: Upgraded to bionic on 2018-12-28 (256 days ago) dmi.bios.date: 09/29/2011 dmi.bios.vendor: INSYDE dmi.bios.version: V1.06 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: HMA51_HR dmi.board.vendor: Acer dmi.board.version: Base Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Chassis Manufacturer dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnINSYDE:bvrV1.06:bd09/29/2011:svnAcer:pnAspire5349:pvrV1.06:rvnAcer:rnHMA51_HR:rvrBaseBoardVersion:cvnChassisManufacturer:ct10:cvrChassisVersion: dmi.product.family: Intel_Mobile dmi.product.name: Aspire 5349 dmi.product.version: V1.06 dmi.sys.vendor: Acer version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1 version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 xserver.bootTime: Thu Dec 27 19:24:00 2018 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 732 vendor LGD xserver.version: 2:1.18.4-0ubuntu0.8 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1843515 Title: noise when browse the web Status in xorg package in Ubuntu: New Bug description: there is noise for last two days it seems power or cpu fun ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18 Uname: Linux 4.15.0-62-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CompositorRunning: None Date: Tue Sep 10 18:04:50 2019 DistUpgraded: 2018-12-28 05:53:36,266 DEBUG icon theme changed, re-reading DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0623] InstallationDate: Installed on 2018-12-25 (259 days ago) InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 064e:a133 Suyin Corp. Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer Aspire 5349 ProcEnviron: PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-62-generic root=UUID=66ebe799-d994-4d80-bfe0-f65827b65871 ro quiet splash vt.handoff=1 SourcePackage: xorg UpgradeSta
[Touch-packages] [Bug 1843515] Re: noise when browse the web
** Changed in: xorg (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1843515 Title: noise when browse the web Status in xorg package in Ubuntu: Fix Committed Bug description: there is noise for last two days it seems power or cpu fun ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18 Uname: Linux 4.15.0-62-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CompositorRunning: None Date: Tue Sep 10 18:04:50 2019 DistUpgraded: 2018-12-28 05:53:36,266 DEBUG icon theme changed, re-reading DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0623] InstallationDate: Installed on 2018-12-25 (259 days ago) InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 064e:a133 Suyin Corp. Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer Aspire 5349 ProcEnviron: PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-62-generic root=UUID=66ebe799-d994-4d80-bfe0-f65827b65871 ro quiet splash vt.handoff=1 SourcePackage: xorg UpgradeStatus: Upgraded to bionic on 2018-12-28 (256 days ago) dmi.bios.date: 09/29/2011 dmi.bios.vendor: INSYDE dmi.bios.version: V1.06 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: HMA51_HR dmi.board.vendor: Acer dmi.board.version: Base Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Chassis Manufacturer dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnINSYDE:bvrV1.06:bd09/29/2011:svnAcer:pnAspire5349:pvrV1.06:rvnAcer:rnHMA51_HR:rvrBaseBoardVersion:cvnChassisManufacturer:ct10:cvrChassisVersion: dmi.product.family: Intel_Mobile dmi.product.name: Aspire 5349 dmi.product.version: V1.06 dmi.sys.vendor: Acer version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1 version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 xserver.bootTime: Thu Dec 27 19:24:00 2018 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 732 vendor LGD xserver.version: 2:1.18.4-0ubuntu0.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1843515/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828102] Re: Regression in ModemManager
I'll accept that rationale; releasing to Disco. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1828102 Title: Regression in ModemManager Status in modemmanager package in Ubuntu: Fix Released Status in modemmanager source package in Bionic: Fix Released Status in modemmanager source package in Cosmic: Won't Fix Status in modemmanager source package in Disco: Fix Released Status in modemmanager source package in Eoan: Fix Released Bug description: [Impact] ModemManager disconnects from CDMA modem after 30 sec failing to check signal status due to incorrect error handling [Test case] connect to a cdma device without an extra AT channel (Eg. Samsung brightside phone) and modemmanager will terminate the connection [Regression potential] The patch is tiny, fixing an obvious overlook, and it only affects CDMA broadband modems, so the risk of a regression is very low. [Original description] ModemManager disconnects after ~30 sec caused by a typo in 1.8 see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615 and https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119 for details needs a SRU for cosmic and dingo patch attached yechiel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1828102/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828102] Update Released
The verification of the Stable Release Update for modemmanager has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1828102 Title: Regression in ModemManager Status in modemmanager package in Ubuntu: Fix Released Status in modemmanager source package in Bionic: Fix Released Status in modemmanager source package in Cosmic: Won't Fix Status in modemmanager source package in Disco: Fix Released Status in modemmanager source package in Eoan: Fix Released Bug description: [Impact] ModemManager disconnects from CDMA modem after 30 sec failing to check signal status due to incorrect error handling [Test case] connect to a cdma device without an extra AT channel (Eg. Samsung brightside phone) and modemmanager will terminate the connection [Regression potential] The patch is tiny, fixing an obvious overlook, and it only affects CDMA broadband modems, so the risk of a regression is very low. [Original description] ModemManager disconnects after ~30 sec caused by a typo in 1.8 see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615 and https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119 for details needs a SRU for cosmic and dingo patch attached yechiel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1828102/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1828102] Re: Regression in ModemManager
This bug was fixed in the package modemmanager - 1.10.0-1ubuntu0.19.04.1 --- modemmanager (1.10.0-1ubuntu0.19.04.1) disco; urgency=medium * debian/patches/error-propagation-fix.patch: mm-broadband-modem: Fix error propagation in CDMA service status (LP: #1828102, Upstream Issue #119). -- Till Kamppeter Mon, 13 May 2019 19:19:19 +0200 ** Changed in: modemmanager (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1828102 Title: Regression in ModemManager Status in modemmanager package in Ubuntu: Fix Released Status in modemmanager source package in Bionic: Fix Released Status in modemmanager source package in Cosmic: Won't Fix Status in modemmanager source package in Disco: Fix Released Status in modemmanager source package in Eoan: Fix Released Bug description: [Impact] ModemManager disconnects from CDMA modem after 30 sec failing to check signal status due to incorrect error handling [Test case] connect to a cdma device without an extra AT channel (Eg. Samsung brightside phone) and modemmanager will terminate the connection [Regression potential] The patch is tiny, fixing an obvious overlook, and it only affects CDMA broadband modems, so the risk of a regression is very low. [Original description] ModemManager disconnects after ~30 sec caused by a typo in 1.8 see https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1819615 and https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/119 for details needs a SRU for cosmic and dingo patch attached yechiel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1828102/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843515] Re: noise when browse the web
Is the noise visual or audible? Are you still experiencing the problem? ** Package changed: xorg (Ubuntu) => ubuntu ** Changed in: ubuntu Status: Fix Committed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1843515 Title: noise when browse the web Status in Ubuntu: Invalid Bug description: there is noise for last two days it seems power or cpu fun ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18 Uname: Linux 4.15.0-62-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 CompositorRunning: None Date: Tue Sep 10 18:04:50 2019 DistUpgraded: 2018-12-28 05:53:36,266 DEBUG icon theme changed, re-reading DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0623] InstallationDate: Installed on 2018-12-25 (259 days ago) InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 064e:a133 Suyin Corp. Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer Aspire 5349 ProcEnviron: PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-62-generic root=UUID=66ebe799-d994-4d80-bfe0-f65827b65871 ro quiet splash vt.handoff=1 SourcePackage: xorg UpgradeStatus: Upgraded to bionic on 2018-12-28 (256 days ago) dmi.bios.date: 09/29/2011 dmi.bios.vendor: INSYDE dmi.bios.version: V1.06 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: HMA51_HR dmi.board.vendor: Acer dmi.board.version: Base Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Chassis Manufacturer dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnINSYDE:bvrV1.06:bd09/29/2011:svnAcer:pnAspire5349:pvrV1.06:rvnAcer:rnHMA51_HR:rvrBaseBoardVersion:cvnChassisManufacturer:ct10:cvrChassisVersion: dmi.product.family: Intel_Mobile dmi.product.name: Aspire 5349 dmi.product.version: V1.06 dmi.sys.vendor: Acer version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1 version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 xserver.bootTime: Thu Dec 27 19:24:00 2018 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 732 vendor LGD xserver.version: 2:1.18.4-0ubuntu0.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1843515/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1668641] Re: Error message: pam_systemd(su:session): Cannot create session: Already running in a session
I'm receiving this error on 18.04.2 LTS. Will the fix for this will be backported for the LTS releases? -- 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/1668641 Title: Error message: pam_systemd(su:session): Cannot create session: Already running in a session Status in systemd package in Ubuntu: Fix Released Status in systemd package in Debian: Fix Released Bug description: Hi, here is how to reproduce this error: 1. log in to the root account with ssh 2. run "su - some_user_account" Here is what I see in the logs: Feb 28 15:21:45 xeelee su[9843]: Successful su for bonnaudl by root Feb 28 15:21:45 xeelee su[9843]: + /dev/pts/10 root:bonnaudl Feb 28 15:21:45 xeelee su[9843]: pam_unix(su:session): session opened for user bonnaudl by root(uid=0) Feb 28 15:21:45 xeelee su[9843]: pam_systemd(su:session): Cannot create session: Already running in a session Feb 28 15:21:48 xeelee su[9843]: pam_unix(su:session): session closed for user bonnaudl In another usage scenario of "su -" there is no error message and the creation of a new session: févr. 28 15:08:15 vougeot su[18962]: Successful su for bonnaudl by root févr. 28 15:08:15 vougeot su[18962]: + /dev/pts/0 root:bonnaudl févr. 28 15:08:15 vougeot su[18962]: pam_unix(su:session): session opened for user bonnaudl by bonnaudl(uid=0) févr. 28 15:08:15 vougeot systemd-logind[1162]: New session c9 of user bonnaudl. févr. 28 15:08:15 vougeot systemd[1]: Started Session c9 of user bonnaudl. févr. 28 15:08:17 vougeot su[18962]: pam_unix(su:session): session closed for user bonnaudl févr. 28 15:08:17 vougeot systemd-logind[1162]: Removed session c9. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: libpam-systemd 231-9ubuntu3 Uname: Linux 4.10.1-041001-generic x86_64 ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 CurrentDesktop: KDE Date: Tue Feb 28 15:21:09 2017 EcryptfsInUse: Yes SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1668641/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837700] Re: Dell system takes a long time to connect network with external dock
** Changed in: hwe-next 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/1837700 Title: Dell system takes a long time to connect network with external dock Status in HWE Next: Fix Released Status in OEM Priority Project: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: update for SRU process: [Impact] 1. On system featured mac passthrough, e.g., Dell/Lenovo laptop, or system occasionally install two USB ethernet with same MAC address, the system will suffer 90 seconds for network interface renaming mechanism before the last USB ethernet interface to activate. [Test Case] 1. Install ubuntu on Dell laptop. 2. Connect the Dell laptop with two Realtek 8153 USB ethernet dongle. Users can observe the last one will take 90 seconds for renaming to rename0. 3. Users can also find that the two USB ethernet have the same MAC address. [Regression Potential] To resolve the issue, drop a debian patch from systemd package. The debian patch is to revert an upstream commit to support 75-persistent-net-generator.rules udev rule. Since the udev rule is deprecated, the regression potential should be relatively low. --- Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/27/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0 dmi.board.name: 0Y7FK3 dmi.board.vendor: Dell Inc. dmi.board.version: X03 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7424 Rugged Extreme dmi.sys.vendor: Dell Inc. [1]: https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c [3]: https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules [4]: htt
[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules
237-3ubuntu10.29 - works for me (Ubuntu 18.04.3 LTS, 4.15.0-51-generic) Thank you! -- 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/1842651 Title: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70 -persistent-network.rules Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Bug description: [Impact] * Many server users upgraded from previous Ubuntu LTS series, such as 14.04 and 16.04, will be affected by this regression. * Because there is /etc/udev/rules/70-persistent-network.rules or /etc/udev/rules.d/70-persistent-net.rules generated by /lib/udev/write_net_rules left. * The previous SRU commit of LP: #1837700 doesn't cover this persistent network rule. [Test Case] * It needs to have two Ethernet devices and provides /etc/udev/rules.d/70-persistent-net.rules as below. SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", NAME="eth1" [Regression Potential] * When users upgrade to next LTS 20.04, they may also encounter this issue because Debian has dropped the same patch. * We need to figure another way to avoid this regression for next LTS 20.04. * Adding back the origial patch from Debian will casue another issue. (LP: #1837700) [Other Info] Since the latest update from udev_237-3ubuntu10.25 and systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and systemd_237-3ubuntu10.26 the renaming of network interfaces by /etc/udev/rules/70-persistent-network.rules does not work. /etc/udev/rules/70-persistent-network.rules: SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", NAME="eth1" /var/log/syslog: systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File exists When I downgrade the packages to the version with 237-3ubuntu10.25 the following messages are in /var/log/syslog: Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2: renamed from eth0 Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed from eth1 The latest version does not rename the interfaces temporary if there is a conflict! Manually installing the old packages with dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb did fix the problem temporary. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1842651/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843381] [NEW] Dell system takes a long time to connect network with external dock
Public bug reported: This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/27/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0 dmi.board.name: 0Y7FK3 dmi.board.vendor: Dell Inc. dmi.board.version: X03 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7424 Rugged Extreme dmi.sys.vendor: Dell Inc. [1]: https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c [3]: https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules [4]: https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch [5]: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/tree/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch?h=ubuntu-bionic ** Affects: oem-priority Importance: Undecided Status: New ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Also affects: systemd Importance: Undecided Status: New ** Project changed: systemd => oem-priority -- 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/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: New Bug description: This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1]
[Touch-packages] [Bug 1843383] [NEW] lxc, please bump epoch to 1
Public bug reported: A lot of stuff from Debian is bd-uninstallable because of the missing epoch on the Ubuntu package. e.g. lua-lxc, and general packages using liblxc1 at runtime (python3-lxc and something else). I think bumping epoch (whilst bad in general), would be a big improvement in this case (also MergeOMatic will stop being unhelpful with lxc merges) ** Affects: lxc (Ubuntu) Importance: Undecided Status: New -- 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/1843383 Title: lxc, please bump epoch to 1 Status in lxc package in Ubuntu: New Bug description: A lot of stuff from Debian is bd-uninstallable because of the missing epoch on the Ubuntu package. e.g. lua-lxc, and general packages using liblxc1 at runtime (python3-lxc and something else). I think bumping epoch (whilst bad in general), would be a big improvement in this case (also MergeOMatic will stop being unhelpful with lxc merges) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1843383/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837537] Re: FTBFS since lxc has different version numbers in Debian and Ubuntu
@vorlon, I did followup on your upload, by also dropping epoch on the runtime liblxc1 dependency, to avoid it being stuck again in queue... it should finally migrate now. I asked a while ago to Ubuntu lxc developers to bump epoch, and they were happy with that... not sure why they forgot, but I'm going to open a bug now. -- 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/1837537 Title: FTBFS since lxc has different version numbers in Debian and Ubuntu Status in lua-lxc package in Ubuntu: Fix Committed Status in lxc package in Ubuntu: New Bug description: The lua-lxc [1] package currently fails to build since it cannot satisfy the build dependency: lxc-dev (>= 1:3.0.2-1~exp+1). Looks like this is caused by different version numbers in Debian and Ubuntu. The latest version in Debian unstable is 1:3.1.0+really3.0.3-8 while Ubuntu eoan has 3.0.3-0ubuntu1. I believe the 1: epoch (?) is causing this issue. Presumably lua-lxc needs to be patched to allow the Ubuntu package to fulfill the build requirements. [1] https://bugs.launchpad.net/ubuntu/+source/lua-lxc/1:3.0.2-1 [2] https://bugs.launchpad.net/ubuntu/+source/lua-lxc/1:3.0.2-1/+build/16664061 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lua-lxc/+bug/1837537/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843381] Re: Dell system takes a long time to connect network with external dock
** Changed in: oem-priority Importance: Undecided => Critical ** Changed in: oem-priority Assignee: (unassigned) => Che Cheng (cktenn) -- 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/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: New Bug description: This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/27/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0 dmi.board.name: 0Y7FK3 dmi.board.vendor: Dell Inc. dmi.board.version: X03 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7424 Rugged Extreme dmi.sys.vendor: Dell Inc. [1]: https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c [3]: https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules [4]: https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch [5]: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/tree/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch?h=ubuntu-bionic To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1843381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1833801] Re: initctl: invalid command: rotate
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: rsyslog (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1833801 Title: initctl: invalid command: rotate Status in rsyslog package in Ubuntu: Confirmed Bug description: rsyslog 8.16.0-1ubuntu3.1 , Ubuntu 16.04.6 LTS the logrotate for rsyslog is a bit awry. The /etc/logrotate.d/rsyslog has this in the postrotate block: /usr/lib/rsyslog/rsyslog-rotate But when invoked (either by logrotate or manually) I get: initctl: invalid command: rotate Try `initctl --help' for more information. invoke-rc.d: initscript rsyslog, action "rotate" failed. The workaround is to change the postrotate block to what I saw in a much earlier version: postrotate service rsyslog rotate > /dev/null endscript ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: rsyslog 8.16.0-1ubuntu3.1 Uname: Linux 2.6.32-042stab127.2 x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Sat Jun 22 00:24:52 2019 ProcEnviron: TERM=screen-256color PATH=(custom, no user) LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: rsyslog UpgradeStatus: Upgraded to xenial on 2016-06-15 (1101 days ago) mtime.conffile..etc.logrotate.d.rsyslog: 2019-06-22T00:24:05.675752 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1833801/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842436] Re: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups
I added the conffile changes to the open MP. Waiting for a review before the upload .. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1842436 Title: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups Status in Ubuntu on IBM z Systems: Triaged Status in lvm2 package in Ubuntu: New Bug description: Default block-size of a file-system seems to be dependent on the volume-size. Big volume (at least ext4) does have 4k blk-size, even the underlying device with a smaller physical blk-size. The patch, avoiding define mixed-sized volume groups is now upstream in the master branch of LVM2 https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b Using this patch within the distribution is for sanity reasons. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1842436/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1779767] Re: Default cron PATH does not include /snap/bin
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: cron (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cron in Ubuntu. https://bugs.launchpad.net/bugs/1779767 Title: Default cron PATH does not include /snap/bin Status in cron package in Ubuntu: Confirmed Bug description: I recently changed from a .deb install of LXD to a snap, and was surprised that one of my crontab scripts stopped working. I see that $PATH in a cron script only contains "/usr/bin:/bin", whereas my default shell also includes "/snap/bin". It seems to me that for the best user experience with snaps, "/snap/bin" should be part of the default $PATH in cron. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: cron 3.0pl1-128.1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_40 kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_39 livepatch_livepatch_Ubuntu_4_15_0_20_21_generic_ zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Jul 2 14:30:06 2018 InstallationDate: Installed on 2017-12-20 (194 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171219) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cron UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1779767/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1779767] Re: Default cron PATH does not include /snap/bin
** Tags added: canonical-bootstack -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cron in Ubuntu. https://bugs.launchpad.net/bugs/1779767 Title: Default cron PATH does not include /snap/bin Status in cron package in Ubuntu: Confirmed Bug description: I recently changed from a .deb install of LXD to a snap, and was surprised that one of my crontab scripts stopped working. I see that $PATH in a cron script only contains "/usr/bin:/bin", whereas my default shell also includes "/snap/bin". It seems to me that for the best user experience with snaps, "/snap/bin" should be part of the default $PATH in cron. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: cron 3.0pl1-128.1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_40 kpatch_livepatch_Ubuntu_4_15_0_20_21_generic_39 livepatch_livepatch_Ubuntu_4_15_0_20_21_generic_ zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Jul 2 14:30:06 2018 InstallationDate: Installed on 2017-12-20 (194 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171219) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cron UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1779767/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842902] Re: FFe: create zfs dataset for each user automatically
This bug was fixed in the package shadow - 1:4.5-1.1ubuntu4 --- shadow (1:4.5-1.1ubuntu4) eoan; urgency=medium * debian/patches/1015_add_zsys_support.patch: - Call zsys to handle home directory if available. We call zsys to handle dataset creation for zsys system in a separate home dataset for each user on the system. This allows one to handle user dataset outside of /home and also renaming. We don't support yet deletion, as removing the dataset would remove as well every snapshot of the history, and so, revert to previous version will result in user created, but no home directory, which is unwanted. (LP: #1842902) -- Didier Roche Thu, 29 Aug 2019 15:00:07 +0200 ** Changed in: shadow (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1842902 Title: FFe: create zfs dataset for each user automatically Status in shadow package in Ubuntu: Fix Released Status in zsys package in Ubuntu: Fix Released Bug description: Part of the zsys spec is creating/associating one user dataset for each HOME user. As zsys is an official experimentation for 19.10, we would like to include this feature in a safe way, and reachable for any tool creating users (adduser, gnome-control-center, ubiquity…). Those are using useradd under the scene. For this, the proposed implementation: - patch useradd trying to execute "zsys useradd create USER HOMEDIR". If zsys isn't present or zsys returns a status code != 0 (which will be the case if the running system isn't a zsys one: pure zfs or non zfs like / on ext4), it will fallback to mkdir. Then the code does the usual chmod() - patch usermod, trying as well to execute "zsys useradd rename-home OLDHOME NEWHOME". Same failing reason (not a zsys system, not installed, OLDHOME isn't a zsys handled datasets) and fallback to rename(). Then the code does the usual chmod(). Tested with and without zsys installed, the code does what we expect. I'm attaching the shadow (useradd/usermod) patches, as you can see it's very minimal. A new ZSYS release will be needed (https://github.com/ubuntu/zsys). As you can see, there are quite some commits since the last release, but it's all baked (as usual) by a huge suite of tests (in ZFS and machine layers) with corner cases tested and such. I'm confident on that change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1842902/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843099] Re: Unattended upgrades does not work on shutdown
How do you shutdown the systemd? Do you start it from the desktop or via CLI? If via CLI do you use this command?: dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.PowerOff boolean:false ** 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/1843099 Title: Unattended upgrades does not work on shutdown Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu * Ubuntu Xenial 16.04.6 LTS 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center * 1.1ubuntu1.18.04.7~16.04.3 3) What you expected to happen * Packages to be upgraded on reboot / shutdown. 4) What happened instead * The host just rebooted. Didn't perform upgrades. No useful output either until I enabled debug logging in the systemd unit file. I'm reporting a new bug but this is very similar to #1806487 and I'm actually wondering if it resurfaced somehow. We're running Ubuntu Xenial 16.04.6 which has 1.1ubuntu1.18.04.7~16.04.3 installed. I see that #1806487 was resolved with 1.1ubuntu1.18.04.7~16.04.2. However I'm seeing similar behavior. So far I've modified systemd to see if anything stands out. I do have an strace and then just debug mode. Unless needed, simply put, this is what a reboot with debug logging looks like (i.e. unattended-upgrades-shutdown.log): 2019-09-06 09:20:04,871 DEBUG - Waiting for signal to start operation 2019-09-06 09:20:43,996 WARNING - SIGTERM or SIGHUP received, stopping unattended-upgradesonly if it is running 2019-09-06 09:20:43,996 DEBUG - Starting countdown of 25.0 minutes 2019-09-06 09:20:43,997 DEBUG - get_lock returned 7 2019-09-06 09:20:43,997 DEBUG - lock not taken I hope that helps, please let me know if you need anything else from me or if I can provide any more information. I've done this many times before, this is the first time it hasn't worked. When I patched around the end of May, all went well. My other variants worked, well mainly Trusty but that's EOL for public access. Bionic doesn't seem to have anything it needs to update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843099] Re: Unattended upgrades does not work on shutdown
... or this one for reboot?: sudo dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Reboot boolean:false -- 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/1843099 Title: Unattended upgrades does not work on shutdown Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu * Ubuntu Xenial 16.04.6 LTS 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center * 1.1ubuntu1.18.04.7~16.04.3 3) What you expected to happen * Packages to be upgraded on reboot / shutdown. 4) What happened instead * The host just rebooted. Didn't perform upgrades. No useful output either until I enabled debug logging in the systemd unit file. I'm reporting a new bug but this is very similar to #1806487 and I'm actually wondering if it resurfaced somehow. We're running Ubuntu Xenial 16.04.6 which has 1.1ubuntu1.18.04.7~16.04.3 installed. I see that #1806487 was resolved with 1.1ubuntu1.18.04.7~16.04.2. However I'm seeing similar behavior. So far I've modified systemd to see if anything stands out. I do have an strace and then just debug mode. Unless needed, simply put, this is what a reboot with debug logging looks like (i.e. unattended-upgrades-shutdown.log): 2019-09-06 09:20:04,871 DEBUG - Waiting for signal to start operation 2019-09-06 09:20:43,996 WARNING - SIGTERM or SIGHUP received, stopping unattended-upgradesonly if it is running 2019-09-06 09:20:43,996 DEBUG - Starting countdown of 25.0 minutes 2019-09-06 09:20:43,997 DEBUG - get_lock returned 7 2019-09-06 09:20:43,997 DEBUG - lock not taken I hope that helps, please let me know if you need anything else from me or if I can provide any more information. I've done this many times before, this is the first time it hasn't worked. When I patched around the end of May, all went well. My other variants worked, well mainly Trusty but that's EOL for public access. Bionic doesn't seem to have anything it needs to update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1657646] Re: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation
This bug was fixed in the package lvm2 - 2.03.02-2ubuntu6 --- lvm2 (2.03.02-2ubuntu6) eoan; urgency=medium * d/control: stop dropping thin-provisioning-tools to Suggests as it is ready to be promoted via MIR LP 1828887. Fixes usability issues of thin-provisioning-tools not being installed by default (LP: #1657646). - d/control: also add thin-provisioning-tools build-dep as configure wants it around for some checks at build time. * d/p/lp-1842436-*: Avoid creation of mixed-blocksize PV on LVM volume groups as it can cause FS corruption (LP: #1842436) -- Christian Ehrhardt Fri, 06 Sep 2019 08:23:10 +0200 ** Changed in: lvm2 (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1657646 Title: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation Status in The Ubuntu-power-systems project: Triaged Status in lvm2 package in Ubuntu: Fix Released Status in lvm2 package in Debian: New Bug description: Creating a thin pool LV is allowed even when thin-provisioning-tools is not installed. But deactivating or activating that VG fails. Since deactivating the VG usually only happens at reboot, the user might fail to notice this big problem until then. I think the lvconvert tool, used to combine the two "thin LVs" into a thin pool LV, should refuse to run if thin-provisioning-tools, or the needed scripts, aren't installed. Steps to reproduce: root@15-89:~# vgcreate vg /dev/vdb1 Volume group "vg" successfully created root@15-89:~# vgs VG #PV #LV #SN Attr VSize VFree vg 1 0 0 wz--n- 40.00g 40.00g root@15-89:~# lvcreate -n pool0 -l 90%VG vg Logical volume "pool0" created. root@15-89:~# lvcreate -n pool0meta -l 5%VG vg Logical volume "pool0meta" created. root@15-89:~# lvs LVVG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert pool0 vg -wi-a- 36.00g pool0meta vg -wi-a- 2.00g root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 100 Jun 21 14:15 ./ drwxr-xr-x 20 root root3820 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:14 vg-pool0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0meta -> ../dm-1 root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data and metadata volumes. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y Converted vg/pool0 to thin pool. root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 120 Jun 21 14:15 ./ drwxr-xr-x 20 root root3840 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0 root@15-89:~# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%S ync Convert [lvol0_pmspare] vg ewi--- 2.00g pool0 vg twi-a-tz-- 36.00g 0.00 0.01 [pool0_tdata] vg Twi-ao 36.00g [pool0_tmeta] vg ewi-ao 2.00g If you now reboot the system, all that is gone: root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:28 ./ drwxr-xr-x 19 root root3760 Jun 21 14:28 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control The same happens if you deactivate the VG (which the reboot undoubtedly triggers). It fails because of a missing /usr/sbin/thin_check which is provided by the thin-provisioning-tools package: root@15-89:~# vgchange -a n /usr/sbin/thin_check: execvp failed: No such file or directory WARNING: Integrity check of metadata for pool vg/pool0 failed. 0 logical volume(s) in volume group "vg" now active root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:29 ./ drwxr-xr-x 19 root root3760 Jun 21 14:29 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1657646/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842436] Re: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups
This bug was fixed in the package lvm2 - 2.03.02-2ubuntu6 --- lvm2 (2.03.02-2ubuntu6) eoan; urgency=medium * d/control: stop dropping thin-provisioning-tools to Suggests as it is ready to be promoted via MIR LP 1828887. Fixes usability issues of thin-provisioning-tools not being installed by default (LP: #1657646). - d/control: also add thin-provisioning-tools build-dep as configure wants it around for some checks at build time. * d/p/lp-1842436-*: Avoid creation of mixed-blocksize PV on LVM volume groups as it can cause FS corruption (LP: #1842436) -- Christian Ehrhardt Fri, 06 Sep 2019 08:23:10 +0200 ** Changed in: lvm2 (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1842436 Title: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups Status in Ubuntu on IBM z Systems: Triaged Status in lvm2 package in Ubuntu: Fix Released Bug description: Default block-size of a file-system seems to be dependent on the volume-size. Big volume (at least ext4) does have 4k blk-size, even the underlying device with a smaller physical blk-size. The patch, avoiding define mixed-sized volume groups is now upstream in the master branch of LVM2 https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b Using this patch within the distribution is for sanity reasons. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1842436/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842436] Re: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups
--- Comment From heinz-werner_se...@de.ibm.com 2019-09-10 08:02 EDT--- IBM Bugzilla status -> closed, Fix Released with Eoan ** Tags removed: targetmilestone-inin--- ** Tags added: targetmilestone-inin1910 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1842436 Title: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups Status in Ubuntu on IBM z Systems: Triaged Status in lvm2 package in Ubuntu: Fix Released Bug description: Default block-size of a file-system seems to be dependent on the volume-size. Big volume (at least ext4) does have 4k blk-size, even the underlying device with a smaller physical blk-size. The patch, avoiding define mixed-sized volume groups is now upstream in the master branch of LVM2 https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b Using this patch within the distribution is for sanity reasons. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1842436/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules
This bug was fixed in the package systemd - 240-6ubuntu5.7 --- systemd (240-6ubuntu5.7) disco; urgency=medium * d/p/d/Revert-udev-network-device-renaming-immediately-give.patch: - udev: add Revert-udev-network-device-renaming-immediately-give.patch back Dropping this patch will cause the persistent network regression. (LP: #1842651) -- Shih-Yuan Lee (FourDollars) Thu, 05 Sep 2019 19:01:29 +0800 -- 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/1842651 Title: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70 -persistent-network.rules Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Bug description: [Impact] * Many server users upgraded from previous Ubuntu LTS series, such as 14.04 and 16.04, will be affected by this regression. * Because there is /etc/udev/rules/70-persistent-network.rules or /etc/udev/rules.d/70-persistent-net.rules generated by /lib/udev/write_net_rules left. * The previous SRU commit of LP: #1837700 doesn't cover this persistent network rule. [Test Case] * It needs to have two Ethernet devices and provides /etc/udev/rules.d/70-persistent-net.rules as below. SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", NAME="eth1" [Regression Potential] * When users upgrade to next LTS 20.04, they may also encounter this issue because Debian has dropped the same patch. * We need to figure another way to avoid this regression for next LTS 20.04. * Adding back the origial patch from Debian will casue another issue. (LP: #1837700) [Other Info] Since the latest update from udev_237-3ubuntu10.25 and systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and systemd_237-3ubuntu10.26 the renaming of network interfaces by /etc/udev/rules/70-persistent-network.rules does not work. /etc/udev/rules/70-persistent-network.rules: SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", NAME="eth1" /var/log/syslog: systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File exists When I downgrade the packages to the version with 237-3ubuntu10.25 the following messages are in /var/log/syslog: Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2: renamed from eth0 Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed from eth1 The latest version does not rename the interfaces temporary if there is a conflict! Manually installing the old packages with dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb did fix the problem temporary. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1842651/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules
This bug was fixed in the package systemd - 237-3ubuntu10.29 --- systemd (237-3ubuntu10.29) bionic; urgency=medium * d/p/d/Revert-udev-network-device-renaming-immediately-give.patch: - udev: add Revert-udev-network-device-renaming-immediately-give.patch back Dropping this patch will cause the persistent network regression. (LP: #1842651) -- Shih-Yuan Lee (FourDollars) Thu, 05 Sep 2019 11:59:51 +0800 ** Changed in: systemd (Ubuntu) Status: In Progress => Fix Released ** Changed in: systemd (Ubuntu) Status: In Progress => 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/1842651 Title: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70 -persistent-network.rules Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Bug description: [Impact] * Many server users upgraded from previous Ubuntu LTS series, such as 14.04 and 16.04, will be affected by this regression. * Because there is /etc/udev/rules/70-persistent-network.rules or /etc/udev/rules.d/70-persistent-net.rules generated by /lib/udev/write_net_rules left. * The previous SRU commit of LP: #1837700 doesn't cover this persistent network rule. [Test Case] * It needs to have two Ethernet devices and provides /etc/udev/rules.d/70-persistent-net.rules as below. SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", NAME="eth1" [Regression Potential] * When users upgrade to next LTS 20.04, they may also encounter this issue because Debian has dropped the same patch. * We need to figure another way to avoid this regression for next LTS 20.04. * Adding back the origial patch from Debian will casue another issue. (LP: #1837700) [Other Info] Since the latest update from udev_237-3ubuntu10.25 and systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and systemd_237-3ubuntu10.26 the renaming of network interfaces by /etc/udev/rules/70-persistent-network.rules does not work. /etc/udev/rules/70-persistent-network.rules: SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", NAME="eth1" /var/log/syslog: systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File exists When I downgrade the packages to the version with 237-3ubuntu10.25 the following messages are in /var/log/syslog: Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2: renamed from eth0 Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed from eth1 The latest version does not rename the interfaces temporary if there is a conflict! Manually installing the old packages with dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb did fix the problem temporary. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1842651/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1657646] Re: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation
The MIR itself (bug 1828887) also got no update. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1657646 Title: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation Status in The Ubuntu-power-systems project: Triaged Status in lvm2 package in Ubuntu: Fix Released Status in lvm2 package in Debian: New Bug description: Creating a thin pool LV is allowed even when thin-provisioning-tools is not installed. But deactivating or activating that VG fails. Since deactivating the VG usually only happens at reboot, the user might fail to notice this big problem until then. I think the lvconvert tool, used to combine the two "thin LVs" into a thin pool LV, should refuse to run if thin-provisioning-tools, or the needed scripts, aren't installed. Steps to reproduce: root@15-89:~# vgcreate vg /dev/vdb1 Volume group "vg" successfully created root@15-89:~# vgs VG #PV #LV #SN Attr VSize VFree vg 1 0 0 wz--n- 40.00g 40.00g root@15-89:~# lvcreate -n pool0 -l 90%VG vg Logical volume "pool0" created. root@15-89:~# lvcreate -n pool0meta -l 5%VG vg Logical volume "pool0meta" created. root@15-89:~# lvs LVVG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert pool0 vg -wi-a- 36.00g pool0meta vg -wi-a- 2.00g root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 100 Jun 21 14:15 ./ drwxr-xr-x 20 root root3820 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:14 vg-pool0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0meta -> ../dm-1 root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data and metadata volumes. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y Converted vg/pool0 to thin pool. root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 120 Jun 21 14:15 ./ drwxr-xr-x 20 root root3840 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0 root@15-89:~# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%S ync Convert [lvol0_pmspare] vg ewi--- 2.00g pool0 vg twi-a-tz-- 36.00g 0.00 0.01 [pool0_tdata] vg Twi-ao 36.00g [pool0_tmeta] vg ewi-ao 2.00g If you now reboot the system, all that is gone: root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:28 ./ drwxr-xr-x 19 root root3760 Jun 21 14:28 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control The same happens if you deactivate the VG (which the reboot undoubtedly triggers). It fails because of a missing /usr/sbin/thin_check which is provided by the thin-provisioning-tools package: root@15-89:~# vgchange -a n /usr/sbin/thin_check: execvp failed: No such file or directory WARNING: Integrity check of metadata for pool vg/pool0 failed. 0 logical volume(s) in volume group "vg" now active root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:29 ./ drwxr-xr-x 19 root root3760 Jun 21 14:29 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1657646/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1657646] Re: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation
Hrm ?? This updated lvm2 migrated to -release with the field: Recommends: thin-provisioning-tools But I have not seen an update here that it was promoted and it really seems not in main yet: root@e:~# apt-cache policy thin-provisioning-tools thin-provisioning-tools: Candidate: 0.7.6-2.1ubuntu1 Version table: 0.7.6-2.1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu eoan/universe amd64 Packages root@e:~# apt-cache policy lvm2 lvm2: Candidate: 2.03.02-2ubuntu6 Version table: 2.03.02-2ubuntu6 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages I'm missing something, shouldn't that be a component mismatch that triggers the handling of this MIR? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1657646 Title: [20.04] Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation Status in The Ubuntu-power-systems project: Triaged Status in lvm2 package in Ubuntu: Fix Released Status in lvm2 package in Debian: New Bug description: Creating a thin pool LV is allowed even when thin-provisioning-tools is not installed. But deactivating or activating that VG fails. Since deactivating the VG usually only happens at reboot, the user might fail to notice this big problem until then. I think the lvconvert tool, used to combine the two "thin LVs" into a thin pool LV, should refuse to run if thin-provisioning-tools, or the needed scripts, aren't installed. Steps to reproduce: root@15-89:~# vgcreate vg /dev/vdb1 Volume group "vg" successfully created root@15-89:~# vgs VG #PV #LV #SN Attr VSize VFree vg 1 0 0 wz--n- 40.00g 40.00g root@15-89:~# lvcreate -n pool0 -l 90%VG vg Logical volume "pool0" created. root@15-89:~# lvcreate -n pool0meta -l 5%VG vg Logical volume "pool0meta" created. root@15-89:~# lvs LVVG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert pool0 vg -wi-a- 36.00g pool0meta vg -wi-a- 2.00g root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 100 Jun 21 14:15 ./ drwxr-xr-x 20 root root3820 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:14 vg-pool0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0meta -> ../dm-1 root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data and metadata volumes. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y Converted vg/pool0 to thin pool. root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 120 Jun 21 14:15 ./ drwxr-xr-x 20 root root3840 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0 root@15-89:~# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%S ync Convert [lvol0_pmspare] vg ewi--- 2.00g pool0 vg twi-a-tz-- 36.00g 0.00 0.01 [pool0_tdata] vg Twi-ao 36.00g [pool0_tmeta] vg ewi-ao 2.00g If you now reboot the system, all that is gone: root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:28 ./ drwxr-xr-x 19 root root3760 Jun 21 14:28 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control The same happens if you deactivate the VG (which the reboot undoubtedly triggers). It fails because of a missing /usr/sbin/thin_check which is provided by the thin-provisioning-tools package: root@15-89:~# vgchange -a n /usr/sbin/thin_check: execvp failed: No such file or directory WARNING: Integrity check of metadata for pool vg/pool0 failed. 0 logical volume(s) in volume group "vg" now active root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:29 ./ drwxr-xr-x 19 root root3760 Jun 21 14:29 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1657646/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1770940] Re: Kexec reboot doesn't work on 18.04 non-EFI system
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: kexec-tools (Ubuntu) Status: New => 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/1770940 Title: Kexec reboot doesn't work on 18.04 non-EFI system Status in kexec-tools package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Unclear whether to report it against kexec-tools or systemd. After upgrading to Ubuntu 18.04, the „systemctl kexec” command gives the following error message: Cannot find the ESP partition mount point. What's interesting is that strace shows that systemctl tries to find the EFI partition before it emits the error message, like it was expecting an EFI system. My laptop is not capable of EFI, and it wasn't a problem for previous Ubuntu releases – the „systemctl kexec” command worked fine before. Here is my systemd version: root@thinkpad:~# systemd --version systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid And my kexec-tools version is 1:2.0.16-1ubuntu1. I attached an strace output. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: kexec-tools 1:2.0.16-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun May 13 12:48:25 2018 InstallationDate: Installed on 2014-06-10 (1432 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=hu_HU.UTF-8 SHELL=/bin/bash SourcePackage: kexec-tools UpgradeStatus: Upgraded to bionic on 2018-05-12 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1770940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1770940] Re: Kexec reboot doesn't work on 18.04 non-EFI system
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu) Status: New => 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/1770940 Title: Kexec reboot doesn't work on 18.04 non-EFI system Status in kexec-tools package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Unclear whether to report it against kexec-tools or systemd. After upgrading to Ubuntu 18.04, the „systemctl kexec” command gives the following error message: Cannot find the ESP partition mount point. What's interesting is that strace shows that systemctl tries to find the EFI partition before it emits the error message, like it was expecting an EFI system. My laptop is not capable of EFI, and it wasn't a problem for previous Ubuntu releases – the „systemctl kexec” command worked fine before. Here is my systemd version: root@thinkpad:~# systemd --version systemd 237 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid And my kexec-tools version is 1:2.0.16-1ubuntu1. I attached an strace output. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: kexec-tools 1:2.0.16-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun May 13 12:48:25 2018 InstallationDate: Installed on 2014-06-10 (1432 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=hu_HU.UTF-8 SHELL=/bin/bash SourcePackage: kexec-tools UpgradeStatus: Upgraded to bionic on 2018-05-12 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1770940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843430] [NEW] FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared
Public bug reported: We hit this on a rebuild in Eoan dhcp.c: In function ‘dhcp_packet’: dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); did you mean ‘SIOCGARP’? 182 | if (ioctl(fd, SIOCGSTAMP, &tv) == 0) | ^~ | SIOCGARP This seems much like the fix in the (not yet released) upstream repo: => http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3052ce208acf602f0163166dcefb7330d537cedb "Fix build after y2038 changes in glib. SIOCGSTAMP is defined in linux/sockios.h, not asm/sockios.h now." ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1843430 Title: FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared Status in dnsmasq package in Ubuntu: New Bug description: We hit this on a rebuild in Eoan dhcp.c: In function ‘dhcp_packet’: dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); did you mean ‘SIOCGARP’? 182 | if (ioctl(fd, SIOCGSTAMP, &tv) == 0) | ^~ | SIOCGARP This seems much like the fix in the (not yet released) upstream repo: => http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3052ce208acf602f0163166dcefb7330d537cedb "Fix build after y2038 changes in glib. SIOCGSTAMP is defined in linux/sockios.h, not asm/sockios.h now." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1843430/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843430] Re: FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared
** Merge proposal linked: https://code.launchpad.net/~paelzer/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/372548 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1843430 Title: FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared Status in dnsmasq package in Ubuntu: New Bug description: We hit this on a rebuild in Eoan dhcp.c: In function ‘dhcp_packet’: dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); did you mean ‘SIOCGARP’? 182 | if (ioctl(fd, SIOCGSTAMP, &tv) == 0) | ^~ | SIOCGARP This seems much like the fix in the (not yet released) upstream repo: => http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3052ce208acf602f0163166dcefb7330d537cedb "Fix build after y2038 changes in glib. SIOCGSTAMP is defined in linux/sockios.h, not asm/sockios.h now." Failed build log: https://launchpadlibrarian.net/441262561 /buildlog_ubuntu-eoan-amd64.dnsmasq_2.80-1ubuntu1_BUILDING.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1843430/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843430] Re: FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared
Test build worked, opened an MP [1] and a test PPA [2] [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/372548 [2]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1843430-ftbfs-dnsmasq ** Description changed: We hit this on a rebuild in Eoan dhcp.c: In function ‘dhcp_packet’: dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); did you mean ‘SIOCGARP’? - 182 | if (ioctl(fd, SIOCGSTAMP, &tv) == 0) - | ^~ - | SIOCGARP - + 182 | if (ioctl(fd, SIOCGSTAMP, &tv) == 0) + | ^~ + | SIOCGARP This seems much like the fix in the (not yet released) upstream repo: => http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3052ce208acf602f0163166dcefb7330d537cedb "Fix build after y2038 changes in glib. SIOCGSTAMP is defined in linux/sockios.h, not asm/sockios.h now." + + Failed build log: https://launchpadlibrarian.net/441262561 + /buildlog_ubuntu-eoan-amd64.dnsmasq_2.80-1ubuntu1_BUILDING.txt.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1843430 Title: FTBFS in Eoan due to new glibc - error: ‘SIOCGSTAMP’ undeclared Status in dnsmasq package in Ubuntu: New Bug description: We hit this on a rebuild in Eoan dhcp.c: In function ‘dhcp_packet’: dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); did you mean ‘SIOCGARP’? 182 | if (ioctl(fd, SIOCGSTAMP, &tv) == 0) | ^~ | SIOCGARP This seems much like the fix in the (not yet released) upstream repo: => http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3052ce208acf602f0163166dcefb7330d537cedb "Fix build after y2038 changes in glib. SIOCGSTAMP is defined in linux/sockios.h, not asm/sockios.h now." Failed build log: https://launchpadlibrarian.net/441262561 /buildlog_ubuntu-eoan-amd64.dnsmasq_2.80-1ubuntu1_BUILDING.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1843430/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842436] Re: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups
** Changed in: ubuntu-z-systems Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1842436 Title: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups Status in Ubuntu on IBM z Systems: Fix Released Status in lvm2 package in Ubuntu: Fix Released Bug description: Default block-size of a file-system seems to be dependent on the volume-size. Big volume (at least ext4) does have 4k blk-size, even the underlying device with a smaller physical blk-size. The patch, avoiding define mixed-sized volume groups is now upstream in the master branch of LVM2 https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b Using this patch within the distribution is for sanity reasons. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1842436/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1483751] Re: Issues traversing a sftp server when files or folders contain the character "]"
I filed https://bugzilla.mindrot.org/show_bug.cgi?id=3069 upstream ** Bug watch added: OpenSSH Portable Bugzilla #3069 https://bugzilla.mindrot.org/show_bug.cgi?id=3069 ** Also affects: openssh via https://bugzilla.mindrot.org/show_bug.cgi?id=3069 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1483751 Title: Issues traversing a sftp server when files or folders contain the character "]" Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Triaged Bug description: I am unsure if the bug is with openssh sftp client or within openssh- sftp-server When traversing an sftp server, I encounter issues for files and, in particular, directories containing the character "]". Tab completion does not escape the character in sftp shell, however, in bash it will escape the character for tab completion. If I "cd" into a directory that contains the character I cannot get any files with in that directory and I have to rename the directory outside of the sftp shell to remove the character in order to be able to correctly get files. Ex: sftp> cd Movie\ \[1080p]/ sftp> ls Movie.1080p.mp4 sftp> get Movie.1080p.mp4 File "/home/hitsuji/movies/Movie [1080p]/Movie.1080p.mp4" not found. sftp> ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: openssh-client 1:6.6p1-2ubuntu2 ProcVersionSignature: Ubuntu 3.16.0-45.60~14.04.1-generic 3.16.7-ckt14 Uname: Linux 3.16.0-45-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Tue Aug 11 14:36:00 2015 InstallationDate: Installed on 2015-05-01 (101 days ago) InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1) RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome 1:6.6p1-2ubuntu2 SSHClientVersion: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014 SourcePackage: openssh UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1483751/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727908] Re: Software & Updates application does not permit changes on the "Other Software" tab
** Changed in: gnome-shell (Ubuntu Bionic) Assignee: (unassigned) => Sebastien Bacher (seb128) ** Changed in: gnome-shell (Ubuntu) Assignee: (unassigned) => Sebastien Bacher (seb128) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1727908 Title: Software & Updates application does not permit changes on the "Other Software" tab Status in gnome-shell package in Ubuntu: Confirmed Status in software-properties package in Ubuntu: Confirmed Status in gnome-shell source package in Bionic: New Status in software-properties source package in Bionic: New Bug description: On the "Other Software" tab, I am unable to select "Canonical Partners". Similarly, the other checkboxes on the "Other Software" can not be clicked. Clicking on a checkbox has no effect, and a dialog requesting the admin password is not presented. However, activating or deactivating checkboxes on other tabs causes an authorization dialog to be presented to the user. I experience this bug in an an Xorg session. sources.list and sources.list.d have the following permissions: -rw-r--r-- 1 root root 2897 Oct 26 22:35 sources.list drwxr-xr-x 2 root root 4096 Oct 26 21:29 sources.list.d All files in sources.list.d have the following permissions as this example: -rw-r--r-- 1 root root 189 Oct 25 21:50 google-chrome.list $ lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 $ apt-cache policy software-properties-gtk software-properties-gtk: Installed: 0.96.24.17 Candidate: 0.96.24.17 Version table: *** 0.96.24.17 500 500 http://us.archive.ubuntu.com/ubuntu artful/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu artful/main i386 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: software-properties-gtk 0.96.24.17 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 NonfreeKernelModules: wl nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.7-0ubuntu3.1 Architecture: amd64 CurrentDesktop: GNOME Date: Thu Oct 26 22:45:09 2017 InstallationDate: Installed on 2017-10-26 (1 days ago) InstallationMedia: Ubuntu 17.10.0 2017.10.25 amd64 "Custom Artful Aardvark" PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1727908/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843099] Re: Unattended upgrades does not work on shutdown
Err, basically I meant to say we do it from the command line but we just use shutdown or reboot. -- 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/1843099 Title: Unattended upgrades does not work on shutdown Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu * Ubuntu Xenial 16.04.6 LTS 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center * 1.1ubuntu1.18.04.7~16.04.3 3) What you expected to happen * Packages to be upgraded on reboot / shutdown. 4) What happened instead * The host just rebooted. Didn't perform upgrades. No useful output either until I enabled debug logging in the systemd unit file. I'm reporting a new bug but this is very similar to #1806487 and I'm actually wondering if it resurfaced somehow. We're running Ubuntu Xenial 16.04.6 which has 1.1ubuntu1.18.04.7~16.04.3 installed. I see that #1806487 was resolved with 1.1ubuntu1.18.04.7~16.04.2. However I'm seeing similar behavior. So far I've modified systemd to see if anything stands out. I do have an strace and then just debug mode. Unless needed, simply put, this is what a reboot with debug logging looks like (i.e. unattended-upgrades-shutdown.log): 2019-09-06 09:20:04,871 DEBUG - Waiting for signal to start operation 2019-09-06 09:20:43,996 WARNING - SIGTERM or SIGHUP received, stopping unattended-upgradesonly if it is running 2019-09-06 09:20:43,996 DEBUG - Starting countdown of 25.0 minutes 2019-09-06 09:20:43,997 DEBUG - get_lock returned 7 2019-09-06 09:20:43,997 DEBUG - lock not taken I hope that helps, please let me know if you need anything else from me or if I can provide any more information. I've done this many times before, this is the first time it hasn't worked. When I patched around the end of May, all went well. My other variants worked, well mainly Trusty but that's EOL for public access. Bionic doesn't seem to have anything it needs to update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843099] Re: Unattended upgrades does not work on shutdown
These are all VMWare VM servers but the few physicals we have ran into the same issue. We just use /sbin/shutdown or /sbin/reboot. -- 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/1843099 Title: Unattended upgrades does not work on shutdown Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu * Ubuntu Xenial 16.04.6 LTS 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center * 1.1ubuntu1.18.04.7~16.04.3 3) What you expected to happen * Packages to be upgraded on reboot / shutdown. 4) What happened instead * The host just rebooted. Didn't perform upgrades. No useful output either until I enabled debug logging in the systemd unit file. I'm reporting a new bug but this is very similar to #1806487 and I'm actually wondering if it resurfaced somehow. We're running Ubuntu Xenial 16.04.6 which has 1.1ubuntu1.18.04.7~16.04.3 installed. I see that #1806487 was resolved with 1.1ubuntu1.18.04.7~16.04.2. However I'm seeing similar behavior. So far I've modified systemd to see if anything stands out. I do have an strace and then just debug mode. Unless needed, simply put, this is what a reboot with debug logging looks like (i.e. unattended-upgrades-shutdown.log): 2019-09-06 09:20:04,871 DEBUG - Waiting for signal to start operation 2019-09-06 09:20:43,996 WARNING - SIGTERM or SIGHUP received, stopping unattended-upgradesonly if it is running 2019-09-06 09:20:43,996 DEBUG - Starting countdown of 25.0 minutes 2019-09-06 09:20:43,997 DEBUG - get_lock returned 7 2019-09-06 09:20:43,997 DEBUG - lock not taken I hope that helps, please let me know if you need anything else from me or if I can provide any more information. I've done this many times before, this is the first time it hasn't worked. When I patched around the end of May, all went well. My other variants worked, well mainly Trusty but that's EOL for public access. Bionic doesn't seem to have anything it needs to update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838771] Re: http:Fix Host header in proxied https connections
The included autopkgtest the verifies this fix has passed for both 1.8.3 and 1.6.12 (221/256) Testcase test-proxy-connect: P P P P P P P P P P P P P P The two apport autopkgtest failures for 1.6.12 for bionic remain, they seem to be the usual launchpad timeout/unavailable issue. ** Tags removed: verification-needed verification-needed-bionic verification-needed-disco ** Tags added: verification-done verification-done-bionic verification-done-disco -- 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/1838771 Title: http:Fix Host header in proxied https connections Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Bug description: [Impact] Currently CONNECT requests use the name of the proxy as Host value, instead of the origin server's name. According to RFC 2616 "The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL." The current implementation causes problems with some proxy vendors. This commit[0] fixes this. [0] - https://salsa.debian.org/apt- team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f [Test Case] Here's one reproducer an impacted user brought to my attention: # /etc/environment http_proxy="http://internal:8080"; https_proxy="http://interal:8080"; To support application development activities in-house, I had to configure Azure CLI APT repository following the instructions from "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view =azure-cli-latest": $ sudo apt-get update $ sudo apt-get install curl apt-transport-https lsb-release gnupg $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \ $ gpg --dearmor | \ $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null $ AZ_REPO=$(lsb_release -cs) $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ AZ_REPO main" | \ $ sudo tee /etc/apt/sources.list.d/azure-cli.list $ sudo apt update In the final "apt update" command, APT respects system-wide network proxy variables and successfully fetched Canonical repository data over HTTP. However, it was unable to fetch the newly added Microsoft packages repository served via HTTPS. By using Wireshark to examine the HTTPS request made by APT, the request body reveals as: CONNECT packages.microsoft.com:443 HTTP/1.1\r\n Host: internal:8080\r\n User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n ... ... There also is an automated test case in the package that runs as part of autopkgtest that tests a scenario like this, see the commit. [Regression Potential] * Fix already in debian, and Eoan * Has been reviewed/approved by juliank * A test package (pre-sru) has been provided to an impacted user, and he confirms it solves the situation. [Other Info] # salsa $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72 1.9.0~8 # rmadison apt => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1829861] Re: handle TLS session renegotiation
There's nothing we can verify here, not having a test server for that. Two autopkgtest regressions remain for apport, but they are not regressions; they're the usual flaky communication with launchpad - launchpad 503-ing. Given that there are no regressions in other parts and the patch is unmodified from eoan, we should hopefully be fine. ** Tags removed: verification-needed verification-needed-bionic verification-needed-disco ** Tags added: verification-done verification-done-bionic verification-done-disco -- 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/1829861 Title: handle TLS session renegotiation Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Status in apt source package in Eoan: Fix Released Bug description: [Impact] TLS sessions can renegotiate keys, but APT does not support it; meaning their HTTPS connections stop working. [Test case] We don't really have a reproducer. You'd need a server that re-negotiates by path; e.g. because it requires a a certain client certificate for a certain path. We know it does not break other use cases, having run that for quite some time in eoan and Debian stretch, and the patch was tested by the patch submitter @ Akamai (see https://github.com/Debian/apt/pull/93). [Regression potential] - Could we get stuck on renegotiation? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843468] [NEW] nftables based iptables wrapper break userspace
Public bug reported: iptables just got replaced by the nftables wrappers, effectively changing all Ubuntu systems to using nftables rather than regular iptables/ip6tables/ebtables. Unfortunately those wrappers aren't perfect and don't convert every option properly, nor know about some of the available plugins for those commands. This means that unless the software using those commands are aware that those are wrappers and adapt their use, they may break at some random point in time. While nftables is clearly the way forward, just silently switching the existing native tools with the compat wrappers will lead to widespread breakage both from packages in the archive, snaps and a variety of scripts our users may be running. So far, looking around, known breakages post-nft are expected with at least Docker, Kubernetes and LXD but the same may be true with the many other packages we have that call iptables, ip6tables, ebtables or arptables today. A migration should include a proper audit of all in-archive users, see if they have a plan/patch for native nft interaction and if not, validate their use of the tools is compatible with the wrappers. We should also extend that to popular snaps / those we ship by default. Snaps make things worse as they use the tools from their base snap, which in LXD's case is currently 16.04 (soon to switch to 18.04). ** Affects: iptables (Ubuntu) Importance: Critical Status: Triaged ** Changed in: iptables (Ubuntu) Importance: Undecided => Critical ** Changed in: iptables (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1843468 Title: nftables based iptables wrapper break userspace Status in iptables package in Ubuntu: Triaged Bug description: iptables just got replaced by the nftables wrappers, effectively changing all Ubuntu systems to using nftables rather than regular iptables/ip6tables/ebtables. Unfortunately those wrappers aren't perfect and don't convert every option properly, nor know about some of the available plugins for those commands. This means that unless the software using those commands are aware that those are wrappers and adapt their use, they may break at some random point in time. While nftables is clearly the way forward, just silently switching the existing native tools with the compat wrappers will lead to widespread breakage both from packages in the archive, snaps and a variety of scripts our users may be running. So far, looking around, known breakages post-nft are expected with at least Docker, Kubernetes and LXD but the same may be true with the many other packages we have that call iptables, ip6tables, ebtables or arptables today. A migration should include a proper audit of all in-archive users, see if they have a plan/patch for native nft interaction and if not, validate their use of the tools is compatible with the wrappers. We should also extend that to popular snaps / those we ship by default. Snaps make things worse as they use the tools from their base snap, which in LXD's case is currently 16.04 (soon to switch to 18.04). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1843468/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843468] Re: nftables based iptables wrapper break userspace
Debian and RHEL are already using the new -nft iptables backend in their latest stable releases. There are still some regressions, but most (all?) are already fixed in upstream iptables git. I'd suggest updating to latest git before starting the audit. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1843468 Title: nftables based iptables wrapper break userspace Status in iptables package in Ubuntu: Triaged Bug description: iptables just got replaced by the nftables wrappers, effectively changing all Ubuntu systems to using nftables rather than regular iptables/ip6tables/ebtables. Unfortunately those wrappers aren't perfect and don't convert every option properly, nor know about some of the available plugins for those commands. This means that unless the software using those commands are aware that those are wrappers and adapt their use, they may break at some random point in time. While nftables is clearly the way forward, just silently switching the existing native tools with the compat wrappers will lead to widespread breakage both from packages in the archive, snaps and a variety of scripts our users may be running. So far, looking around, known breakages post-nft are expected with at least Docker, Kubernetes and LXD but the same may be true with the many other packages we have that call iptables, ip6tables, ebtables or arptables today. A migration should include a proper audit of all in-archive users, see if they have a plan/patch for native nft interaction and if not, validate their use of the tools is compatible with the wrappers. We should also extend that to popular snaps / those we ship by default. Snaps make things worse as they use the tools from their base snap, which in LXD's case is currently 16.04 (soon to switch to 18.04). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1843468/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] [NEW] gzip in Ubuntu Eoan results in Exec format error on WSL1
Public bug reported: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status ** Affects: gzip (Ubuntu) Importance: Undecided Status: New ** Summary changed: - gzip in Ubuntu Eoan results in Exec format error + gzip in Ubuntu Eoan results in Exec format error on WSL1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in gzip package in Ubuntu: New Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU
Sorry for the late reply. Here comes the output: KERNEL[90619.640204] remove /module/nvidia (module) UDEV [90619.659490] add /kernel/slab/:0012288 (slab) KERNEL[90619.696504] add /module/nvidia (module) KERNEL[90619.697757] add /kernel/slab/:0012288 (slab) KERNEL[90619.697792] add /bus/pci/drivers/nvidia-nvswitch (drivers) KERNEL[90619.698144] remove /bus/pci/drivers/nvidia-nvswitch (drivers) UDEV [90619.734780] add /bus/pci/drivers/nvidia-nvswitch (drivers) KERNEL[90619.760125] remove /kernel/slab/:0012288 (slab) KERNEL[90619.780134] remove /module/nvidia (module) UDEV [90619.799634] add /module/nvidia (module) UDEV [90619.863581] remove /module/nvidia (module) UDEV [90619.914399] remove /bus/pci/drivers/nvidia-nvswitch (drivers) UDEV [90619.980993] remove /kernel/slab/:0012288 (slab) KERNEL[90619.987727] add /kernel/slab/:A-256/cgroup/filp(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987765] add /kernel/slab/dentry/cgroup/dentry(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987787] add /kernel/slab/inode_cache/cgroup/inode_cache(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987807] add /kernel/slab/:A-128/cgroup/pid(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987827] add /kernel/slab/sock_inode_cache/cgroup/sock_inode_cache(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987846] add /kernel/slab/:A-0001024/cgroup/UNIX(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987873] add /kernel/slab/skbuff_head_cache/cgroup/skbuff_head_cache(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987893] add /kernel/slab/kmalloc-512/cgroup/kmalloc-512(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987918] add /kernel/slab/:A-192/cgroup/cred_jar(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987938] add /kernel/slab/mm_struct/cgroup/mm_struct(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.987956] add /kernel/slab/:A-208/cgroup/vm_area_struct(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988007] add /kernel/slab/:A-064/cgroup/anon_vma_chain(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988029] add /kernel/slab/anon_vma/cgroup/anon_vma(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988058] add /kernel/slab/kmalloc-192/cgroup/kmalloc-192(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988076] add /kernel/slab/kmalloc-1k/cgroup/kmalloc-1k(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988094] add /kernel/slab/task_struct/cgroup/task_struct(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988113] add /kernel/slab/:A-080/cgroup/task_delay_info(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988128] add /kernel/slab/:A-704/cgroup/files_cache(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988144] add /kernel/slab/sighand_cache/cgroup/sighand_cache(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.988159] add /kernel/slab/:A-0001088/cgroup/signal_cache(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.989100] add /kernel/slab/shmem_inode_cache/cgroup/shmem_inode_cache(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.989133] add /kernel/slab/:A-040/cgroup/pde_opener(351529:nvidia-persistenced.service) (cgroup) KERNEL[90619.989163] add /kernel/slab/kmalloc-4k/cgroup/kmalloc-4k(351529:nvidia-persistenced.service) (cgroup) KERNEL[90620.018974] add /module/nvidia (module) KERNEL[90620.019912] add /kernel/slab/:0012288 (slab) KERNEL[90620.019938] add /bus/pci/drivers/nvidia-nvswitch (drivers) KERNEL[90620.020631] remove /bus/pci/drivers/nvidia-nvswitch (drivers) KERNEL[90620.080127] remove /kernel/slab/:0012288 (slab) KERNEL[90620.104154] remove /module/nvidia (module) KERNEL[90620.137366] add /module/nvidia (module) KERNEL[90620.138144] add /kernel/slab/:0012288 (slab) KERNEL[90620.138175] add /bus/pci/drivers/nvidia-nvswitch (drivers) KERNEL[90620.138657] remove /bus/pci/drivers/nvidia-nvswitch (drivers) ** Attachment added: "longer log" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1759836/+attachment/5287861/+files/udevd.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1759836 Title: systemd-udevd consumes 100% of CPU Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez package in Debian: New Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in
[Touch-packages] [Bug 1843490] [NEW] lxc.cgroup.devices.allow prevents unprivileged container from starting
Public bug reported: Adding lxc.cgroup.devices.allow directives to an unprivileged container config prevent the container from starting. These lxc-start errors look relevant: lxc-start testbox 20190910192712.171 WARN cgfsng - cgroups/cgfsng.c:get_hierarchy:204 - There is no useable devices controller lxc-start testbox 20190910192712.171 ERRORcgfsng - cgroups/cgfsng.c:cg_legacy_set_data:2191 - Failed to setup limits for the "devices" controller. The controller seems to be unused by "cgfsng" cgroup driver or not enabled on the cgroup hierarchy lxc-start testbox 20190910192712.171 WARN cgfsng - cgroups/cgfsng.c:__cg_legacy_setup_limits:2228 - Failed to set "devices.allow" to "c 10:57 rwm" It seems to me that I used lxc.cgroup.devices.allow directives without trouble a few years ago. I wonder which system upgrades broke it. To reproduce: (Note: subuid, subgid, and lxc-usernet are already configured for this user.) $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 19.04 Release:19.04 Codename: disco $ dpkg-query --show libpam-cgfs lxc1 libpam-cgfs 3.0.3-0ubuntu1 lxc13.0.3-0ubuntu1 $ lxc-create -t download -n testbox -- -d ubuntu -r bionic -a amd64 The cached copy has expired, re-downloading... Setting up the GPG keyring Downloading the image index Downloading the rootfs Downloading the metadata The image cache is now ready Unpacking the rootfs --- You just created an Ubuntu bionic amd64 (20190910_07:42) container. To enable SSH, run: apt install openssh-server No default root or user password are set by LXC. $ echo "lxc.cgroup.devices.allow = c 10:57 rwm" >> lxc/testbox/config $ lxc-start -n testbox -o debug.out -l trace lxc-start: testbox: lxccontainer.c: wait_on_daemonized_start: 842 Received container state "ABORTING" instead of "RUNNING" lxc-start: testbox: tools/lxc_start.c: main: 330 The container failed to start lxc-start: testbox: tools/lxc_start.c: main: 333 To get more details, run the container in foreground mode lxc-start: testbox: tools/lxc_start.c: main: 336 Additional information can be obtained by setting the --logfile and --logpriority options $ cat debug.out lxc-start testbox 20190910192712.380 INFO confile - confile.c:set_config_idmaps:1555 - Read uid map: type u nsid 0 hostid 10 range 65536 lxc-start testbox 20190910192712.380 INFO confile - confile.c:set_config_idmaps:1555 - Read uid map: type g nsid 0 hostid 10 range 65536 lxc-start testbox 20190910192712.382 TRACEcommands - commands.c:lxc_cmd:300 - Connection refused - Command "get_init_pid" failed to connect command socket lxc-start testbox 20190910192712.383 TRACEcommands - commands.c:lxc_cmd:300 - Connection refused - Command "get_state" failed to connect command socket lxc-start testbox 20190910192712.383 TRACEstart - start.c:lxc_init_handler:748 - Created anonymous pair {4,5} of unix sockets lxc-start testbox 20190910192712.383 TRACEcommands - commands.c:lxc_cmd_init:1248 - Creating abstract unix socket "/home/ubuntu/lxc/testbox/command" lxc-start testbox 20190910192712.383 TRACEstart - start.c:lxc_init_handler:760 - Unix domain socket 6 for command server is ready lxc-start testbox 20190910192712.388 INFO lxccontainer - lxccontainer.c:do_lxcapi_start:961 - Set process title to [lxc monitor] /home/ubuntu/lxc testbox lxc-start testbox 20190910192712.392 TRACEstart - start.c:lxc_start:2052 - Doing lxc_start lxc-start testbox 20190910192712.393 INFO lsm - lsm/lsm.c:lsm_init:50 - LSM security driver AppArmor lxc-start testbox 20190910192712.393 TRACEstart - start.c:lxc_init:777 - Initialized LSM lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:458 - Added arch 2 to main seccomp context lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:466 - Removed native arch from main seccomp context lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:458 - Added arch 3 to main seccomp context lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:466 - Removed native arch from main seccomp context lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:471 - Arch 4 already present in main seccomp context lxc-start testbox 20190910192712.395 INFO seccomp - seccomp.c:parse_config_v2:759 - Processing "reject_force_umount # comment this to allow umount -f; not recommended" lxc-start testbox 20190910192712.395 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts lxc-start testbox 20190910192712.395 INFO seccomp - seccomp.c:parse_config_v2:937 - Added native rule for arch 0 for reject_force_umount action 0(kill) lxc-start testbox 20190910192712.396 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts lxc-start testbox 20190910192712.396 INFO seccomp - sec
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez
** Summary changed: - systemd-udevd consumes 100% of CPU + systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1759836 Title: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez package in Debian: New Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez
> Sorry for the late reply. Here comes the output: > KERNEL[90619.640204] remove /module/nvidia (module) > KERNEL[90619.696504] add /module/nvidia (module) ok, your problem is that something is constantly adding and removing the nvidia module (and, doing other related device processing). That has nothing to do with this bug's problem, which is ONLY for udev looping due to rules in the bluez package's hid2hci rules file. I updated the bug subject to clarify that (scanning back through all the comments, I think most if not all of the discussion focuses on this specific package and rule). You do seem to be having some other problem, which probably is with the nvidia-persistenced.service, provided by the nvidia-compute-utils-NNN package (with NNN being a number). Check: $ dpkg -l | grep nvidia to see the specific package name/version on your system. I don't really know what the problem is there, but you could try removing the package (if you don't need it), or searching for and/or opening a new bug for the problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1759836 Title: systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in bluez package in Debian: New Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1552999] Re: dh_systemd_enable not able to disable on upgrade
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: init-system-helpers (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to init-system-helpers in Ubuntu. https://bugs.launchpad.net/bugs/1552999 Title: dh_systemd_enable not able to disable on upgrade Status in init-system-helpers package in Ubuntu: Confirmed Bug description: cloud-init has a service like == /lib/systemd/system/cloud-init.service == [Unit] Description=Initial cloud-init job (metadata service crawler) After=local-fs.target network-online.target cloud-init-local.service Before=sshd.service sshd-keygen.service systemd-user-sessions.service Requires=network-online.target Wants=local-fs.target cloud-init-local.service sshd.service sshd-keygen.service [Service] Type=oneshot ExecStart=/usr/bin/cloud-init init RemainAfterExit=yes TimeoutSec=0 [Install] WantedBy=multi-user.target = dh_systemd_enable created some files like: /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cloud-init.service I dont think that was necessary as 'WantedBy' in my service file, but thats fine. Later I came to want to change the 'WantedBy=' to be 'WantedBy=cloud- init.target'. When I installed the new deb, the files in /var/lib/systemd/deb-systemd-helper-enabled/ were still there so the services where running on multi-user.target when I wanted to change that. I've since added override_dh_systemd_enable: dh_systemd_enable --no-enable so i'm no longer enabling anything on install, but the files are still there. The are deleted with --purge, but I need them correctly handled on upgrade. Whats the proper way to get rid of them? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dh-systemd 1.28ubuntu2 ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2 Uname: Linux 4.4.0-8-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 3 20:56:22 2016 EcryptfsInUse: Yes InstallationDate: Installed on 2015-07-23 (225 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1) PackageArchitecture: all SourcePackage: init-system-helpers UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1552999/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843468] Re: nftables based iptables wrapper break userspace
Ah, that's good to know and we should definitely aim at refreshing nftables prior to doing any amount of testing on the wrappers. The failure I've seen for LXD specifically was around complex protocol parsing (IPv6 router advertisements I believe) through ebtables, so not a very usual thing to do, but something LXD needs to do to prevent some cases of IP spoofing between containers with isolated networking. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1843468 Title: nftables based iptables wrapper break userspace Status in iptables package in Ubuntu: Triaged Bug description: iptables just got replaced by the nftables wrappers, effectively changing all Ubuntu systems to using nftables rather than regular iptables/ip6tables/ebtables. Unfortunately those wrappers aren't perfect and don't convert every option properly, nor know about some of the available plugins for those commands. This means that unless the software using those commands are aware that those are wrappers and adapt their use, they may break at some random point in time. While nftables is clearly the way forward, just silently switching the existing native tools with the compat wrappers will lead to widespread breakage both from packages in the archive, snaps and a variety of scripts our users may be running. So far, looking around, known breakages post-nft are expected with at least Docker, Kubernetes and LXD but the same may be true with the many other packages we have that call iptables, ip6tables, ebtables or arptables today. A migration should include a proper audit of all in-archive users, see if they have a plan/patch for native nft interaction and if not, validate their use of the tools is compatible with the wrappers. We should also extend that to popular snaps / those we ship by default. Snaps make things worse as they use the tools from their base snap, which in LXD's case is currently 16.04 (soon to switch to 18.04). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1843468/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840582] Re: aa-genprof crash
This was fixed in 2.13.3-5ubuntu1 in Ubunt 19.10 ** Also affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Changed in: apparmor (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1840582 Title: aa-genprof crash Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Bug description: Hi, I run aa-genprof against an executable link (( #!/usr/bin/env ./script.sh )), that run a bash script, that run firefox bin. Because aa-genprof seems not to see the firefox run, I pressed (S)can two or three times. At the last time I have the following error: [(S)can system log for AppArmor events] / (F)inish Reading log entries from /var/log/syslog. Traceback (most recent call last): File "/usr/sbin/aa-genprof", line 163, in lp_ret = apparmor.do_logprof_pass(logmark, passno) File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 1816, in do_logprof_pass log = log_reader.read_log(logmark) File "/usr/lib/python3/dist-packages/apparmor/logparser.py", line 384, in read_log self.add_event_to_tree(event) File "/usr/lib/python3/dist-packages/apparmor/logparser.py", line 198, in add_event_to_tree e = self.parse_event_for_tree(e) File "/usr/lib/python3/dist-packages/apparmor/logparser.py", line 246, in parse_event_for_tree if profile != 'null-complain-profile' and not self.profile_exists(profile): File "/usr/lib/python3/dist-packages/apparmor/logparser.py", line 457, in profile_exists raise AppArmorBug('This should never happen, please open a bugreport!') apparmor.common.AppArmorBug: This should never happen, please open a bugreport! An unexpected error occoured! To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1840582/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843099] Re: Unattended upgrades does not work on shutdown
@cimmerian Could you please try using the commands I listed instead? You probably hit https://github.com/systemd/systemd/issues/949 ** Bug watch added: github.com/systemd/systemd/issues #949 https://github.com/systemd/systemd/issues/949 -- 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/1843099 Title: Unattended upgrades does not work on shutdown Status in unattended-upgrades package in Ubuntu: Incomplete Bug description: 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu * Ubuntu Xenial 16.04.6 LTS 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center * 1.1ubuntu1.18.04.7~16.04.3 3) What you expected to happen * Packages to be upgraded on reboot / shutdown. 4) What happened instead * The host just rebooted. Didn't perform upgrades. No useful output either until I enabled debug logging in the systemd unit file. I'm reporting a new bug but this is very similar to #1806487 and I'm actually wondering if it resurfaced somehow. We're running Ubuntu Xenial 16.04.6 which has 1.1ubuntu1.18.04.7~16.04.3 installed. I see that #1806487 was resolved with 1.1ubuntu1.18.04.7~16.04.2. However I'm seeing similar behavior. So far I've modified systemd to see if anything stands out. I do have an strace and then just debug mode. Unless needed, simply put, this is what a reboot with debug logging looks like (i.e. unattended-upgrades-shutdown.log): 2019-09-06 09:20:04,871 DEBUG - Waiting for signal to start operation 2019-09-06 09:20:43,996 WARNING - SIGTERM or SIGHUP received, stopping unattended-upgradesonly if it is running 2019-09-06 09:20:43,996 DEBUG - Starting countdown of 25.0 minutes 2019-09-06 09:20:43,997 DEBUG - get_lock returned 7 2019-09-06 09:20:43,997 DEBUG - lock not taken I hope that helps, please let me know if you need anything else from me or if I can provide any more information. I've done this many times before, this is the first time it hasn't worked. When I patched around the end of May, all went well. My other variants worked, well mainly Trusty but that's EOL for public access. Bionic doesn't seem to have anything it needs to update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1843099/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp