[Touch-packages] [Bug 1896577] [NEW] FFE: new upstream release 20.2 and migrate to llvm 11
Public bug reported: Mesa 20.2.0 has been delayed by upstream, but we still want it in 20.10. It's currrently at rc4, final was supposed to be out a month ago. The packaging in debian also migrates to use llvm 11. ** Affects: mesa (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1896577 Title: FFE: new upstream release 20.2 and migrate to llvm 11 Status in mesa package in Ubuntu: New Bug description: Mesa 20.2.0 has been delayed by upstream, but we still want it in 20.10. It's currrently at rc4, final was supposed to be out a month ago. The packaging in debian also migrates to use llvm 11. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1896577/+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 1798954] Re: Some go warnings are showing up
Marked this bug as invalid because Cosmic is not supported anymore. Thanks. -- 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/1798954 Title: Some go warnings are showing up Status in apt package in Ubuntu: Invalid Bug description: Steps to reproduce -- 1. Type `sudo LANG="ru_RU.UTF-8" apt install `. 2. Observe output Expected behaviour -- No errors Actual behaviour Errors are showing up. Please locate "apt regression bug.txt" attachment System information -- vitalkanev@fisher:~$ lsb_release -a && echo && uname -a && echo && LANG=C apt policy apt No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.10 Release:18.10 Codename: cosmic Linux fisher 4.18.0-10-generic #11-Ubuntu SMP Thu Oct 11 15:13:55 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux apt: Installed: 1.7.0 Candidate: 1.7.0 Version table: *** 1.7.0 500 500 http://archive.ubuntu.com/ubuntu cosmic/main amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: apt 1.7.0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: KDE Date: Sat Oct 20 14:29:39 2018 InstallationDate: Installed on 2018-10-19 (0 days ago) InstallationMedia: Kubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) 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/1798954/+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 1798954] Re: Some go warnings are showing up
Marked this bug as invalid because Cosmic is not supported anymore. Thanks. ** Changed in: apt (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1798954 Title: Some go warnings are showing up Status in apt package in Ubuntu: Invalid Bug description: Steps to reproduce -- 1. Type `sudo LANG="ru_RU.UTF-8" apt install `. 2. Observe output Expected behaviour -- No errors Actual behaviour Errors are showing up. Please locate "apt regression bug.txt" attachment System information -- vitalkanev@fisher:~$ lsb_release -a && echo && uname -a && echo && LANG=C apt policy apt No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.10 Release:18.10 Codename: cosmic Linux fisher 4.18.0-10-generic #11-Ubuntu SMP Thu Oct 11 15:13:55 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux apt: Installed: 1.7.0 Candidate: 1.7.0 Version table: *** 1.7.0 500 500 http://archive.ubuntu.com/ubuntu cosmic/main amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: apt 1.7.0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: KDE Date: Sat Oct 20 14:29:39 2018 InstallationDate: Installed on 2018-10-19 (0 days ago) InstallationMedia: Kubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) 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/1798954/+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 1892290] Re: PXE load Focal initrd.img-5.4.0-42-generic always timeout
Similar bug: https://bugzilla.redhat.com/show_bug.cgi?id=1869987
I've tried boot by cmdline, looks the same issue.
grub> linux vmlinuz-5.4.0-47-generic
grub> echo $?
0
grub> initrd initrd.img-5.4.0-47-generic
error: timeout reading `initrd.img-5.4.0-47-generic'.
grub> echo $?
28
It looks like it is caused by Commit 781b3e5efc3 (tftp: Do not use priority
queue) .
And bellow upstream commit can fix it.
commit a6838bbc6726ad624bd2b94991f690b8e9d23c69
Author: Javier Martinez Canillas
Date: Thu Sep 10 17:17:57 2020 +0200
tftp: Roll-over block counter to prevent data packets timeouts
Commit 781b3e5efc3 (tftp: Do not use priority queue) caused a regression
when fetching files over TFTP whose size is bigger than 65535 * block size.
grub> linux /images/pxeboot/vmlinuz
grub> echo $?
0
grub> initrd /images/pxeboot/initrd.img
error: timeout reading '/images/pxeboot/initrd.img'.
grub> echo $?
28
It is caused by the block number counter being a 16-bit field, which leads
to a maximum file size of ((1 << 16) - 1) * block size. Because GRUB sets
the block size to 1024 octets (by using the TFTP Blocksize Option from RFC
2348 [0]), the maximum file size that can be transferred is 67107840 bytes.
The TFTP PROTOCOL (REVISION 2) RFC 1350 [1] does not mention what a client
should do when a file size is bigger than the maximum, but most TFTP hosts
support the block number counter to be rolled over. That is, acking a data
packet with a block number of 0 is taken as if the 65356th block was acked.
It was working before because the block counter roll-over was happening due
an overflow. But that got fixed by the mentioned commit, which led to the
regression when attempting to fetch files larger than the maximum size.
To allow TFTP file transfers of unlimited size again, re-introduce a block
counter roll-over so the data packets are acked preventing the timeouts.
[0]: https://tools.ietf.org/html/rfc2348
[1]: https://tools.ietf.org/html/rfc1350
Fixes: 781b3e5efc3 (tftp: Do not use priority queue)
Suggested-by: Peter Jones
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Kiper
** Bug watch added: Red Hat Bugzilla #1869987
https://bugzilla.redhat.com/show_bug.cgi?id=1869987
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1892290
Title:
PXE load Focal initrd.img-5.4.0-42-generic always timeout
Status in grub2 package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Bug description:
PXE booting Focal initrd always gets a timeout, but PXE booting Bionic initrd
works
error: timeout reading `initrd.img-5.4.0-42-generic'.
grub.cfg
menuentry "boot_iscsi" {
linux vmlinuz-5.4.0-42-generic ...
initrd initrd.img-5.4.0-42-generic
}
grub, kernel and initrd get from Focal boot dir
$ cp /usr/lib/grub/arm64-efi-signed/grubnetaa64.efi.signed
~/tftproot/grubaa64.efi
$ cp /boot/vmlinuz-5.4.0-42-generic ~/tftproot/
$ cp /boot/initrd.img-5.4.0-42-generic ~/tftproot/
hardware
Real aarch64 server or qemu-system-aarch64 machine
software
$ apt search grub-efi-arm64
Sorting... Done
Full Text Search... Done
grub-efi-arm64/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64
[installed]
GRand Unified Bootloader, version 2 (ARM64 UEFI version)
grub-efi-arm64-bin/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64
[installed,automatic]
GRand Unified Bootloader, version 2 (ARM64 UEFI modules)
grub-efi-arm64-dbg/focal-updates,focal-security 2.04-1ubuntu26.2 arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI debug files)
grub-efi-arm64-signed/focal-updates,focal-security,now
1.142.4+2.04-1ubuntu26.2 arm64 [installed]
GRand Unified Bootloader, version 2 (EFI-ARM64 version, signed)
grub-efi-arm64-signed-template/focal-updates,focal-security 2.04-1ubuntu26.2
arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI signing template)
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04 LTS
Release:20.04
Codename: focal
$ uname -a
Linux j12-d05-07 5.4.0-42-generic #1 SMP Tue Jul 7 02:48:00 GMT 2020 aarch64
aarch64 aarch64 GNU/Linux
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1892290/+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
Re: [Touch-packages] [Bug 232172] Re: MASTER no wlan option for pppoe configuration
Hey, no idea. As in the last 5 years pppoe as connection method has been overtaken by new router types and broadband connections are (i guess almost nowhere) paid by time anymore, so the need to connect and disconnect every time is no longer required. I can check, though, if the issue has been resolved. On Mon, Sep 21, 2020 at 9:29 PM 林博仁(Buo-ren, Lin) <232...@bugs.launchpad.net> wrote: > > Hello! Is this bug still reproducible in the recent Ubuntu > release(20.04)? > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/232172 > > Title: > MASTER no wlan option for pppoe configuration > > To manage notifications about this bug go to: > https://bugs.launchpad.net/network-manager/+bug/232172/+subscriptions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/232172 Title: MASTER no wlan option for pppoe configuration Status in NetworkManager: Fix Released Status in Network Manager Applet: Fix Released Status in dillo package in Ubuntu: Invalid Status in network-manager package in Ubuntu: Triaged Status in network-manager-applet package in Ubuntu: Triaged Bug description: In Ubuntu 8.04, there is possibility to set up ppoe connection using gui in network settings. But there is only possibility to use ethernet devices for setting the connection. In my case, I am using pppoe over wlan device (quite common internet connection in Germany), it means, I have to connect to WLAN bridge and then use this wlan bridge for setting pppoe connection. To do this, I have to set up it using command line tool pppoeconf. So I think this is not feature request, this is a bug in present gui, that the wlan device can't be chosen. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/232172/+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 1895060] Re: [FFe] apparmor 3 upstream release
I knew from my former tests: 1. apparmor 3.0 = bad 2. downgrading to 2.13.3-7ubuntu6 and back up to 3.0 = good 3. aa-enforce + service restart = good I checked the logs on the affected systems how this got into the bad state: $ grep -E 'configure (lib)?(apparmor|libvirt)' /var/log/dpkg.log 2020-09-16 05:56:09 configure libapparmor1:amd64 3.0.0~beta1-0ubuntu1 2020-09-16 05:56:18 configure apparmor:amd64 3.0.0~beta1-0ubuntu1 2020-09-16 05:57:31 configure libvirt-daemon-system-systemd:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:31 configure libvirt0:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:33 configure libvirt-clients:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon-driver-qemu:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon-system:amd64 6.6.0-1ubuntu2 2020-09-16 05:58:05 configure apparmor-utils:amd64 3.0.0~beta1-0ubuntu1 2020-09-17 14:04:17 configure libvirt-daemon-system-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt0-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-daemon-driver-qemu-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-clients-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-daemon-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-22 06:56:34 configure apparmor:amd64 3.0.0~beta1-0ubuntu5 It seems I had: 1. groovy container 2. upgrade to proposed (including libapparmor1 / apparmor 3.0) 3. install libvirt I was trying to recreate the above with a new container as of today: 1. groovy container (2.13.3-7ubuntu6, all still confined) 2. upgrade to proposed (3.0.0~beta1-0ubuntu5, all still confined) 3. install libvirt (confinement working well) Hmm, something must have been different. I know I have used container snapshots when I ran into that - I need to sort out in what order that happened and if it would occur again. -- 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/1895060 Title: [FFe] apparmor 3 upstream release Status in apparmor package in Ubuntu: Fix Committed Bug description: As per the draft upstream release notes[1]: AppArmor 3.0 is a major new release of the AppArmor user space that makes an important change to policy development and support. Its focus is transitioning policy to the new features ABI and as such other new features have been limited. Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the newer AppArmor 3 style policy which requires the declaration of a features abi. As such AppArmor 3.0 will be a short lived release, and will not receive long term support. The following AppArmor 3.1 feature release is planned to be a regular release, please take this into account when including AppArmor 3.0 into a distro release. As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3 to Ubuntu and provide these new capabilities to users and system administrators. The short support lifespan of Ubuntu 20.10 ensures that there is alignment with the limited support lifetime of AppArmor 3.0 from upstream, whilst giving good exposure and opportunity to test and exercise the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight of new features provided by AppArmor 3.0 include: - Policy now must declare the feature abi it was developed for if it is to use any new features. This ensures that old policy will not become incompatible with new kernels that support additional AppArmor features. - The use of profile names that are based on pathnames are deprecated. - Support for new kernel features (requires appropriate features abi tagging in policy) - upstream v8 network socket rules - xattr attachment conditionals - capabilities PERFMON and BPF - Improved compiler warnings and semantic checks - aa-status rewritten in C (previously was python) with additional features - supports use in systems/images where python is not available - supports kill, unconfined and mixed profile modes - Rewritten aa-notify (previously was perl, now python3) - shared backend with other python tools - support use of aa.CONFDIR instead of hard coded /etc/apparmor - improved message layout - Improved support for kernels that support LSM stacking - New utility aa-features-abi to extract and work with kernel abi features - New utility aa-load to load binary policy without calling the apparmor_parser - Support for profile modes - enforce (default when no mode flag is supplied) - kill (experimental) - unconfined (experimental) The use of the new AppArmor profile feature ABI includes a default configuration (for the Ubuntu packaged version of AppArmor proposed in this FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures that all pro
[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release
Sorry, while being about evaluating the new apparmor this got posted to the wrong bug :-/ -- 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/1895060 Title: [FFe] apparmor 3 upstream release Status in apparmor package in Ubuntu: Fix Committed Bug description: As per the draft upstream release notes[1]: AppArmor 3.0 is a major new release of the AppArmor user space that makes an important change to policy development and support. Its focus is transitioning policy to the new features ABI and as such other new features have been limited. Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the newer AppArmor 3 style policy which requires the declaration of a features abi. As such AppArmor 3.0 will be a short lived release, and will not receive long term support. The following AppArmor 3.1 feature release is planned to be a regular release, please take this into account when including AppArmor 3.0 into a distro release. As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3 to Ubuntu and provide these new capabilities to users and system administrators. The short support lifespan of Ubuntu 20.10 ensures that there is alignment with the limited support lifetime of AppArmor 3.0 from upstream, whilst giving good exposure and opportunity to test and exercise the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight of new features provided by AppArmor 3.0 include: - Policy now must declare the feature abi it was developed for if it is to use any new features. This ensures that old policy will not become incompatible with new kernels that support additional AppArmor features. - The use of profile names that are based on pathnames are deprecated. - Support for new kernel features (requires appropriate features abi tagging in policy) - upstream v8 network socket rules - xattr attachment conditionals - capabilities PERFMON and BPF - Improved compiler warnings and semantic checks - aa-status rewritten in C (previously was python) with additional features - supports use in systems/images where python is not available - supports kill, unconfined and mixed profile modes - Rewritten aa-notify (previously was perl, now python3) - shared backend with other python tools - support use of aa.CONFDIR instead of hard coded /etc/apparmor - improved message layout - Improved support for kernels that support LSM stacking - New utility aa-features-abi to extract and work with kernel abi features - New utility aa-load to load binary policy without calling the apparmor_parser - Support for profile modes - enforce (default when no mode flag is supplied) - kill (experimental) - unconfined (experimental) The use of the new AppArmor profile feature ABI includes a default configuration (for the Ubuntu packaged version of AppArmor proposed in this FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures that all profiles provided in AppArmor3 for groovy will conform to this feature set and that upgrades to the kernel version (say to 5.8) that may include newer AppArmor confinement features will not result in additional policy denials as a result (since say the existing profile did not specify a rule for a new AppArmor feature which is now supported by the upgraded kernel). This ensures that there will be no regressions in application behaviour as a result of AppArmor kernel feature upgrades. TESTING This has been extensively tested by the security team - this includes following the documented Ubuntu merges test plan[2] for AppArmor and the extensive QA Regression Tests[3] for AppArmor as well. This ensures that the various applications that make heavy use of AppArmor (LXD, docker, lxc, dbus, libvirt, snapd etc) have all been exercised and no regressions have been observed. All tests have passed and demonstrated both apparmor and the various applications that use it to be working as expected. BUILD LOGS This is currently uploaded to groovy-proposed, build logs can be found on Launchpad at: https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1 INSTALL LOG See attached (https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files /groovy-proposed-apparmor-install.log) for a log showing install of the packages from groovy-proposed [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0 [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor [3] https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post t
[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
I knew from my former tests: 1. apparmor 3.0 = bad 2. downgrading to 2.13.3-7ubuntu6 and back up to 3.0 = good 3. aa-enforce + service restart = good I checked the logs on the affected systems how this got into the bad state: $ grep -E 'configure (lib)?(apparmor|libvirt)' /var/log/dpkg.log 2020-09-16 05:56:09 configure libapparmor1:amd64 3.0.0~beta1-0ubuntu1 2020-09-16 05:56:18 configure apparmor:amd64 3.0.0~beta1-0ubuntu1 2020-09-16 05:57:31 configure libvirt-daemon-system-systemd:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:31 configure libvirt0:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:33 configure libvirt-clients:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon-driver-qemu:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon-system:amd64 6.6.0-1ubuntu2 2020-09-16 05:58:05 configure apparmor-utils:amd64 3.0.0~beta1-0ubuntu1 2020-09-17 14:04:17 configure libvirt-daemon-system-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt0-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-daemon-driver-qemu-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-clients-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-daemon-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-22 06:56:34 configure apparmor:amd64 3.0.0~beta1-0ubuntu5 It seems I had: 1. groovy container 2. upgrade to proposed (including libapparmor1 / apparmor 3.0) 3. install libvirt I was trying to recreate the above with a new container as of today: 1. groovy container (2.13.3-7ubuntu6, all still confined) 2. upgrade to proposed (3.0.0~beta1-0ubuntu5, all still confined) 3. install libvirt (confinement working well) Hmm, something must have been different. I know I have used container snapshots when I ran into that - I need to sort out in what order that happened and if it would occur again. -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Hi Christian Bolz o/ I'd have such rules but this isn't the problem here as that would matter only much later. I libvirtd itself isn't confined it refuses to go on confining the guests and that is here the problem. The current question really comes down to "how did I manage to have everything but snaps loose enforce mode"? -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Ok, I have definitely a snapshot left that has "conserved" the bad state. $ lxc stop testkvm-groovy-from $ lxc restore testkvm-groovy-from orig $ lxc start testkvm-groovy-from $ lxc exec testkvm-groovy-from # aa-status apparmor module is loaded. 15 profiles are loaded. 15 profiles are in enforce mode. /snap/snapd/9279/usr/lib/snapd/snap-confine /snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper snap-update-ns.lxd snap.lxd.activate snap.lxd.benchmark snap.lxd.buginfo snap.lxd.check-kernel snap.lxd.daemon snap.lxd.hook.configure snap.lxd.hook.install snap.lxd.hook.remove snap.lxd.lxc snap.lxd.lxc-to-lxd snap.lxd.lxd snap.lxd.migrate 0 profiles are in complain mode. 0 profiles are in kill mode. 0 profiles are in unconfined mode. 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. 0 processes are in mixed mode. 0 processes are in kill mode. While silly this gets me back to normal from here # aa-enforce /etc/apparmor.d/* # aa-status apparmor module is loaded. 32 profiles are loaded. 32 profiles are in enforce mode. ... You see that we now have more than twice as much loaded -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1896577] Re: FFE: new upstream release 20.2 and migrate to llvm 11
** Description changed: Mesa 20.2.0 has been delayed by upstream, but we still want it in 20.10. - It's currrently at rc4, final was supposed to be out a month ago. + It's currrently at rc4, final was supposed to be out a month ago. It's + been in debian experimental since rc1. The packaging in debian also migrates to use llvm 11. + + packages for groovy are available on ppa:canonical-x/x-staging -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1896577 Title: FFE: new upstream release 20.2 and migrate to llvm 11 Status in mesa package in Ubuntu: New Bug description: Mesa 20.2.0 has been delayed by upstream, but we still want it in 20.10. It's currrently at rc4, final was supposed to be out a month ago. It's been in debian experimental since rc1. The packaging in debian also migrates to use llvm 11. packages for groovy are available on ppa:canonical-x/x-staging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1896577/+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 1895631] Re: systemd at 100% handling apport failures
*** This bug is a duplicate of bug 1891657 *** https://bugs.launchpad.net/bugs/1891657 ** This bug has been marked a duplicate of bug 1890913 init is using 100% of processor -- 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/1895631 Title: systemd at 100% handling apport failures Status in systemd package in Ubuntu: Confirmed Bug description: systemd is pegged at 100% after booting Groovy Desktop. Seems like an apport-report.service issue: Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. I removed apport to resolve the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895631/+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 1895293] Re: After last upgrade systemd uses 100% CPU
*** This bug is a duplicate of bug 1891657 *** https://bugs.launchpad.net/bugs/1891657 ** This bug has been marked a duplicate of bug 1890913 init is using 100% of processor -- 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/1895293 Title: After last upgrade systemd uses 100% CPU Status in systemd package in Ubuntu: New Bug description: I'm not sure, but none of the already reported bugs seems to fit. At shutdown I get for a moment many messages concerning "automatic report enabled but not possible" (roughly) and after showing these the shutdown lasts about one Minute. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.4-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: openafs nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Sep 11 14:30:32 2020 InstallationDate: Installed on 2020-09-01 (10 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200826) MachineType: Hewlett-Packard HP Z420 Workstation ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=de_DE.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-18-generic root=UUID=8d55d30d-adfe-4f99-9e71-193677d1ec1e ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/29/2019 dmi.bios.release: 3.96 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: J61 v03.96 dmi.board.asset.tag: CZC4123JXT dmi.board.name: 1589 dmi.board.vendor: Hewlett-Packard dmi.board.version: 0.00 dmi.chassis.asset.tag: CZC4123JXT dmi.chassis.type: 6 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvrJ61v03.96:bd10/29/2019:br3.96:svnHewlett-Packard:pnHPZ420Workstation:pvr:rvnHewlett-Packard:rn1589:rvr0.00:cvnHewlett-Packard:ct6:cvr: dmi.product.family: 103C_53335X G=D dmi.product.name: HP Z420 Workstation dmi.product.sku: LJ449AV dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895293/+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 1890913] Re: init is using 100% of processor
*** This bug is a duplicate of bug 1891657 *** https://bugs.launchpad.net/bugs/1891657 Will be fixed in next upload, in 246.6-1ubuntu1 https://github.com/systemd/systemd/issues/16669 ** Bug watch added: github.com/systemd/systemd/issues #16669 https://github.com/systemd/systemd/issues/16669 -- 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/1890913 Title: init is using 100% of processor Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: the `sbin/init splash` process is using more than 100% of processor after boot. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246-2ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-12.13-generic 5.8.0-rc7 Uname: Linux 5.8.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu44 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Sat Aug 8 22:14:37 2020 InstallationDate: Installed on 2019-11-01 (280 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: LENOVO 2349KEG ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-12-generic root=/dev/mapper/vgubuntu-root ro i915.fastboot=1 quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/07/2019 dmi.bios.release: 2.82 dmi.bios.vendor: LENOVO dmi.bios.version: G1ETC2WW (2.82 ) dmi.board.asset.tag: Not Available dmi.board.name: 2349KEG dmi.board.vendor: LENOVO dmi.board.version: Win8 Pro DPK TPG dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.ec.firmware.release: 1.14 dmi.modalias: dmi:bvnLENOVO:bvrG1ETC2WW(2.82):bd08/07/2019:br2.82:efr1.14:svnLENOVO:pn2349KEG:pvrThinkPadT430:rvnLENOVO:rn2349KEG:rvrWin8ProDPKTPG:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.family: ThinkPad T430 dmi.product.name: 2349KEG dmi.product.sku: LENOVO_MT_2349 dmi.product.version: ThinkPad T430 dmi.sys.vendor: LENOVO modified.conffile..etc.default.apport: # set this to 0 to disable apport, or to 1 to enable it # you can temporarily override this with # sudo service apport start force_start=1 enabled=0 mtime.conffile..etc.default.apport: 2020-08-08T22:11:41.151132 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890913/+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 1895631] Re: systemd at 100% handling apport failures
*** This bug is a duplicate of bug 1891657 *** https://bugs.launchpad.net/bugs/1891657 ** This bug is no longer a duplicate of bug 1890913 init is using 100% of processor ** This bug has been marked a duplicate of bug 1891657 systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit' -- 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/1895631 Title: systemd at 100% handling apport failures Status in systemd package in Ubuntu: Confirmed Bug description: systemd is pegged at 100% after booting Groovy Desktop. Seems like an apport-report.service issue: Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Sep 15 08:01:50 lenovo systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Sep 15 08:01:50 lenovo systemd[1]: apport-autoreport.service: Start request repeated too quickly. I removed apport to resolve the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895631/+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 1890913] Re: init is using 100% of processor
*** This bug is a duplicate of bug 1891657 *** https://bugs.launchpad.net/bugs/1891657 ** This bug has been marked a duplicate of bug 1891657 systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit' -- 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/1890913 Title: init is using 100% of processor Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: the `sbin/init splash` process is using more than 100% of processor after boot. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246-2ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-12.13-generic 5.8.0-rc7 Uname: Linux 5.8.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu44 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Sat Aug 8 22:14:37 2020 InstallationDate: Installed on 2019-11-01 (280 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: LENOVO 2349KEG ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-12-generic root=/dev/mapper/vgubuntu-root ro i915.fastboot=1 quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/07/2019 dmi.bios.release: 2.82 dmi.bios.vendor: LENOVO dmi.bios.version: G1ETC2WW (2.82 ) dmi.board.asset.tag: Not Available dmi.board.name: 2349KEG dmi.board.vendor: LENOVO dmi.board.version: Win8 Pro DPK TPG dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.ec.firmware.release: 1.14 dmi.modalias: dmi:bvnLENOVO:bvrG1ETC2WW(2.82):bd08/07/2019:br2.82:efr1.14:svnLENOVO:pn2349KEG:pvrThinkPadT430:rvnLENOVO:rn2349KEG:rvrWin8ProDPKTPG:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.family: ThinkPad T430 dmi.product.name: 2349KEG dmi.product.sku: LENOVO_MT_2349 dmi.product.version: ThinkPad T430 dmi.sys.vendor: LENOVO modified.conffile..etc.default.apport: # set this to 0 to disable apport, or to 1 to enable it # you can temporarily override this with # sudo service apport start force_start=1 enabled=0 mtime.conffile..etc.default.apport: 2020-08-08T22:11:41.151132 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890913/+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 1895293] Re: After last upgrade systemd uses 100% CPU
*** This bug is a duplicate of bug 1891657 *** https://bugs.launchpad.net/bugs/1891657 ** This bug is no longer a duplicate of bug 1890913 init is using 100% of processor ** This bug has been marked a duplicate of bug 1891657 systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit' -- 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/1895293 Title: After last upgrade systemd uses 100% CPU Status in systemd package in Ubuntu: New Bug description: I'm not sure, but none of the already reported bugs seems to fit. At shutdown I get for a moment many messages concerning "automatic report enabled but not possible" (roughly) and after showing these the shutdown lasts about one Minute. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.4-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: openafs nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Sep 11 14:30:32 2020 InstallationDate: Installed on 2020-09-01 (10 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200826) MachineType: Hewlett-Packard HP Z420 Workstation ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=de_DE.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-18-generic root=UUID=8d55d30d-adfe-4f99-9e71-193677d1ec1e ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/29/2019 dmi.bios.release: 3.96 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: J61 v03.96 dmi.board.asset.tag: CZC4123JXT dmi.board.name: 1589 dmi.board.vendor: Hewlett-Packard dmi.board.version: 0.00 dmi.chassis.asset.tag: CZC4123JXT dmi.chassis.type: 6 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvrJ61v03.96:bd10/29/2019:br3.96:svnHewlett-Packard:pnHPZ420Workstation:pvr:rvnHewlett-Packard:rn1589:rvr0.00:cvnHewlett-Packard:ct6:cvr: dmi.product.family: 103C_53335X G=D dmi.product.name: HP Z420 Workstation dmi.product.sku: LJ449AV dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895293/+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 1891657] Re: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit'
Will be fixed in next systemd upload, in 246.6-1ubuntu1, at least for the systemd part. https://github.com/systemd/systemd/issues/16669 ** Changed in: systemd (Ubuntu Groovy) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Groovy) Importance: Undecided => High ** Bug watch added: github.com/systemd/systemd/issues #16669 https://github.com/systemd/systemd/issues/16669 -- 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/1891657 Title: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit' Status in apport package in Ubuntu: Confirmed Status in systemd package in Ubuntu: In Progress Status in apport source package in Groovy: Confirmed Status in systemd source package in Groovy: In Progress Bug description: after upgrade from Ubuntu 20.04 to 20.10 seeing systemd use 100% cpu forever top top - 10:16:19 up 20 min, 1 user, load average: 3.91, 4.28, 3.39 Tasks: 332 total, 2 running, 330 sleeping, 0 stopped, 0 zombie %Cpu(s): 18.7 us, 6.4 sy, 11.9 ni, 62.2 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st MiB Mem : 15917.6 total, 8553.4 free, 2604.3 used, 4759.9 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 12633.7 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 177316 12252 8684 R 100.0 0.1 15:01.25 systemd 4636 kush 39 19 633796 176152 16360 S 98.3 1.1 17:51.56 tracker-miner-f 820 message+ 20 0 10740 6452 4212 S 39.8 0.0 6:19.06 dbus-daemon 316 root 19 -1 535916 322896 320824 S 15.3 2.0 3:16.41 systemd-journal 844 syslog20 0 221136 5840 3920 S 13.6 0.0 2:14.52 rsyslogd 858 root 20 0 83708 74124 7568 S 12.7 0.5 2:06.98 systemd-logind 5 root 20 0 0 0 0 I 3.4 0.0 0:05.01 kworker/0:0-events 35566 kush 20 0 3850088 588344 262192 S 2.5 3.6 0:30.48 MainThread 5626 kush 20 0 5004788 260876 93400 S 1.7 1.6 3:05.19 gnome-shell 7033 kush 20 0 869792 66440 44272 S 1.7 0.4 0:06.05 gnome-terminal- 36790 kush 20 0 2525432 156636 98568 S 1.7 1.0 0:04.99 Web Content 957 root 20 0 1556196 45044 24284 S 0.8 0.3 0:02.48 containerd 1038 root 20 0 10460 4412 3300 S 0.8 0.0 0:00.16 fancontrol sudo tail -n 100 /var/log/syslog Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process
[Touch-packages] [Bug 1892290] Re: PXE load Focal initrd.img-5.4.0-42-generic always timeout
Verified that focal grub2 with above commit works.
grub> linux vmlinuz-5.4.0-47-generic
grub> echo $?
0
grub> initrd initrd.img-5.4.0-47-generic
grub> echo $?
0
Rebuild grub2 deb with above commit and install
$ git clone -b applied/ubuntu/focal-updates
https://git.launchpad.net/ubuntu/+source/grub2
$ cd grub2; git cherry-pick a6838bbc6726ad624bd2b94991f690b8e9d23c69 (which
fetch from https://git.savannah.gnu.org/git/grub.git)
$ sudo apt-get build-dep grub2
$ dpkg-buildpackage -rfakeroot -b
$ cd ../; sudo apt install ./*.deb
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1892290
Title:
PXE load Focal initrd.img-5.4.0-42-generic always timeout
Status in grub2 package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Bug description:
PXE booting Focal initrd always gets a timeout, but PXE booting Bionic initrd
works
error: timeout reading `initrd.img-5.4.0-42-generic'.
grub.cfg
menuentry "boot_iscsi" {
linux vmlinuz-5.4.0-42-generic ...
initrd initrd.img-5.4.0-42-generic
}
grub, kernel and initrd get from Focal boot dir
$ cp /usr/lib/grub/arm64-efi-signed/grubnetaa64.efi.signed
~/tftproot/grubaa64.efi
$ cp /boot/vmlinuz-5.4.0-42-generic ~/tftproot/
$ cp /boot/initrd.img-5.4.0-42-generic ~/tftproot/
hardware
Real aarch64 server or qemu-system-aarch64 machine
software
$ apt search grub-efi-arm64
Sorting... Done
Full Text Search... Done
grub-efi-arm64/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64
[installed]
GRand Unified Bootloader, version 2 (ARM64 UEFI version)
grub-efi-arm64-bin/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64
[installed,automatic]
GRand Unified Bootloader, version 2 (ARM64 UEFI modules)
grub-efi-arm64-dbg/focal-updates,focal-security 2.04-1ubuntu26.2 arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI debug files)
grub-efi-arm64-signed/focal-updates,focal-security,now
1.142.4+2.04-1ubuntu26.2 arm64 [installed]
GRand Unified Bootloader, version 2 (EFI-ARM64 version, signed)
grub-efi-arm64-signed-template/focal-updates,focal-security 2.04-1ubuntu26.2
arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI signing template)
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04 LTS
Release:20.04
Codename: focal
$ uname -a
Linux j12-d05-07 5.4.0-42-generic #1 SMP Tue Jul 7 02:48:00 GMT 2020 aarch64
aarch64 aarch64 GNU/Linux
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1892290/+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 1892290] Re: PXE load Focal initrd.img-5.4.0-42-generic always timeout
To be noted that this issue also exists in Debian 10 and Ubuntu 18.04.
Because they all has commit 781b3e5efc3 (tftp: Do not use priority
queue).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1892290
Title:
PXE load Focal initrd.img-5.4.0-42-generic always timeout
Status in grub2 package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Bug description:
PXE booting Focal initrd always gets a timeout, but PXE booting Bionic initrd
works
error: timeout reading `initrd.img-5.4.0-42-generic'.
grub.cfg
menuentry "boot_iscsi" {
linux vmlinuz-5.4.0-42-generic ...
initrd initrd.img-5.4.0-42-generic
}
grub, kernel and initrd get from Focal boot dir
$ cp /usr/lib/grub/arm64-efi-signed/grubnetaa64.efi.signed
~/tftproot/grubaa64.efi
$ cp /boot/vmlinuz-5.4.0-42-generic ~/tftproot/
$ cp /boot/initrd.img-5.4.0-42-generic ~/tftproot/
hardware
Real aarch64 server or qemu-system-aarch64 machine
software
$ apt search grub-efi-arm64
Sorting... Done
Full Text Search... Done
grub-efi-arm64/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64
[installed]
GRand Unified Bootloader, version 2 (ARM64 UEFI version)
grub-efi-arm64-bin/focal-updates,focal-security,now 2.04-1ubuntu26.2 arm64
[installed,automatic]
GRand Unified Bootloader, version 2 (ARM64 UEFI modules)
grub-efi-arm64-dbg/focal-updates,focal-security 2.04-1ubuntu26.2 arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI debug files)
grub-efi-arm64-signed/focal-updates,focal-security,now
1.142.4+2.04-1ubuntu26.2 arm64 [installed]
GRand Unified Bootloader, version 2 (EFI-ARM64 version, signed)
grub-efi-arm64-signed-template/focal-updates,focal-security 2.04-1ubuntu26.2
arm64
GRand Unified Bootloader, version 2 (ARM64 UEFI signing template)
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04 LTS
Release:20.04
Codename: focal
$ uname -a
Linux j12-d05-07 5.4.0-42-generic #1 SMP Tue Jul 7 02:48:00 GMT 2020 aarch64
aarch64 aarch64 GNU/Linux
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1892290/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
I have backed up this container and its snapshot for later and re-run the whole automation which got me that bad state. That allowed me to run my automation again without removing this container (in case we need it for debugging later). So I ran everything again to check if it would happen again with the version now in groovy proposed. Ok it ran into the same issues again so it is reproducible with the current version in proposed. Since in the tests have plenty of systems involved I need to cut it down and simplify it to just one ... -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: New Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
FYI - other testing might miss this as "starting a guest on groovy" works with the new versions, but it will be without apparmor. Migrating from focal or a pre-upgrade groovy shows the issues broken by apparmor not being enabled. ** Changed in: apparmor (Ubuntu) Status: Incomplete => New ** Changed in: apparmor (Ubuntu) Importance: Low => High ** Tags added: block-proposed -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: New Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1890270] Re: SRU: update gdb 9.2 for 20.04 LTS
package works as expected. test suite check done with the binary upload. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1890270 Title: SRU: update gdb 9.2 for 20.04 LTS Status in gdb package in Ubuntu: New Status in gdb source package in Focal: Fix Committed Bug description: SRU: update gdb 9.2 for 20.04 LTS according to https://sourceware.org/gdb/ this is a bug fix release: """ This is a minor corrective release over GDB 9.1, fixing the following issues: PR tui/25586 (Resizing the source/disassembly or command window produces corrupted display) PR gdb/25650 (GDB can't 'printf' a convenience variable holding an inferior address) PR build/25981 (Use of short i386 register names breaks compilation on recent Solaris 11.4) PR symtab/26003 (infinite loop loading symbols from separate debug objfile) PR build/26029 (GDB build failure on SPARC) """ Regression potential: minimal, package also not used by normal users, but for development. Acceptence criteria: Package builds, no regressions in the testsuite. The package also was part of a focal test rebuild, see LP: #1879481. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1890270/+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 1888575] Re: Split motd-news config into a new package
please note that the stable UbuntuCore18 images regressed due to this: https://github.com/snapcore/core18/issues/170 ** Bug watch added: github.com/snapcore/core18/issues #170 https://github.com/snapcore/core18/issues/170 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-files in Ubuntu. https://bugs.launchpad.net/bugs/1888575 Title: Split motd-news config into a new package Status in base-files package in Ubuntu: Fix Released Status in livecd-rootfs package in Ubuntu: Invalid Status in ubuntu-meta package in Ubuntu: Fix Released Status in base-files source package in Xenial: Fix Released Status in livecd-rootfs source package in Xenial: Triaged Status in ubuntu-meta source package in Xenial: Fix Committed Status in base-files source package in Bionic: Fix Released Status in livecd-rootfs source package in Bionic: Invalid Status in ubuntu-meta source package in Bionic: Fix Released Status in base-files source package in Focal: Fix Released Status in livecd-rootfs source package in Focal: Invalid Status in ubuntu-meta source package in Focal: Fix Released Status in base-files source package in Groovy: Fix Released Status in livecd-rootfs source package in Groovy: Invalid Status in ubuntu-meta source package in Groovy: Fix Released Bug description: [Impact] The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users. We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan: - move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files) - have ubuntu-server depend on motd-news-config - have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config- news package, ENABLED=0 must remain set. [Test Case] a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news apt install base-files - upgrades ubuntu-server - installs motd-news-config - /e/d/motd-news remains, motd-news remains enabled b) base-files installed, ubuntu-server installed, modified /e/d/motd-news apt install base-files - upgrades ubuntu-server - installs motd-news-config - /e/d/motd-news remains with the original modification c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news apt install base-files - upgrades base-files - removes /e/d/motd-news - motd-news is disabled d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news apt install base-files - upgrades base-files - /e/d/motd-news gets renamed to backup - motd-news is disabled e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends) f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file h) base-files installed, ubuntu-server installed, removed /e/d/motd-news - apt install base-files - upgrades base-files, upgrades ubuntu-server, installs motd-news-config - /e/d/motd-news is installed with ENABLED=0 i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news - apt install base-files - base-files is upgraded - no /e/d/motd-news is installed, motd-news remains disabled j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install). At the end, motd-news should be disabled. Verify with: $ sudo /etc/update-motd.d/50-motd-news --force $ (no output) k) Test that supporting changes for xenial are in place: i) verify grub-legacy-ec2 is not in the xenial server seed ii) verify that the rootfs manifest built from the ubuntu-cpc project contains the ubuntu-server package iii) verify that images built from the ubuntu-cpc project which purge grub-legacy-ec2 have retained ubuntu-server [Regression Potential] This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here: a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the
[Touch-packages] [Bug 1896405] Re: Cannot install libglib2.0-dev on ubuntu 20.04.1
Great that it worked out. The downgrade was trying to remove things
because libglib binaries need to be on the same version so it was
necessary to downgrade libglib2.0-bin/focal in addition to the main
library
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1896405
Title:
Cannot install libglib2.0-dev on ubuntu 20.04.1
Status in glib2.0 package in Ubuntu:
Invalid
Bug description:
I already tried running `apt update/upgrade`, but it did not make any
difference.
Why these versions conflicts are happening?
1. libglib2.0-bin : Conflicts: libglib2.0-bin:i386 but 2.64.2-1~fakesync1 is
to be installed
1. libglib2.0-bin:i386 : Conflicts: libglib2.0-bin but 2.64.3-1~ubuntu20.04.1
is installed
1. libglib2.0-dev : Depends: libglib2.0-0 (= 2.64.2-1~fakesync1) but
2.64.3-1~ubuntu20.04.1 is installed
1. libglib2.0-0 : Breaks: libglib2.0-0:i386 (!= 2.64.3-1~ubuntu20.04.1) but
2.64.2-1~fakesync1 is to be installed
1. libglib2.0-0:i386 : Breaks: libglib2.0-0 (!= 2.64.2-1~fakesync1) but
2.64.3-1~ubuntu20.04.1 is installed
```
$ sudo aptitude install libglib2.0-dev
The following NEW packages will be installed:
gcc-10-base:i386{a} libblkid-dev{a} libblkid1:i386{a} libc6:i386{a}
libcrypt1:i386{a} libelf1:i386{a} libffi-dev{a} libffi7:i386{a}
libgcc-s1:i386{a} libglib2.0-0:i386{ab}
libglib2.0-bin:i386{ab} libglib2.0-dev{b} libglib2.0-dev-bin{a}
libidn2-0:i386{a} libmount-dev{a} libmount1:i386{a} libpcre2-8-0:i386{a}
libpcre2-dev{a} libpcre2-posix2{a}
libpcre3:i386{a} libselinux1:i386{a} libselinux1-dev{a} libsepol1-dev{a}
libunistring2:i386{a} zlib1g:i386{a}
0 packages upgraded, 25 newly installed, 0 to remove and 0 not upgraded.
Need to get 8.701 kB of archives. After unpacking 41,3 MB will be used.
The following packages have unmet dependencies:
libglib2.0-bin : Conflicts: libglib2.0-bin:i386 but 2.64.2-1~fakesync1 is to
be installed
libglib2.0-bin:i386 : Conflicts: libglib2.0-bin but 2.64.3-1~ubuntu20.04.1
is installed
libglib2.0-dev : Depends: libglib2.0-0 (= 2.64.2-1~fakesync1) but
2.64.3-1~ubuntu20.04.1 is installed
libglib2.0-0 : Breaks: libglib2.0-0:i386 (!= 2.64.3-1~ubuntu20.04.1) but
2.64.2-1~fakesync1 is to be installed
libglib2.0-0:i386 : Breaks: libglib2.0-0 (!= 2.64.2-1~fakesync1) but
2.64.3-1~ubuntu20.04.1 is installed
open: 2; closed: 4; defer: 0; conflict: 0
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) libglib2.0-0:i386 [Not Installed]
2) libglib2.0-bin:i386 [Not Installed]
3) libglib2.0-dev [Not Installed]
Accept this solution? [Y/n/q/?] y
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
```
```
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/";
SUPPORT_URL="https://help.ubuntu.com/";
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/";
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1896405/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
It seems it comes down to a change in /lib/apparmor/apparmor.systemd which now refuses to load profiles when running in a container. Example with 3.0: $ /lib/apparmor/apparmor.systemd reload Not starting AppArmor in container Example with 2.x /lib/apparmor/apparmor.systemd reload Restarting AppArmor Reloading AppArmor profiles This also explains why snap profiles work, the are loaded by snapd and not by apparmor.service. I'll attach a repro script and full logs of good and bad case. ** Attachment added: "repro script comparing current and proposed apparmor version" https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+attachment/5413150/+files/apparmor-repro.sh -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1890716] Re: xdg-mime query filetype index.html reports wrong type
The wrapper used depends of the environment, the previous one was under a command line clean instance, on a GNOME based desktop $ XDG_UTILS_DEBUG_LEVEL=1 xdg-mime query filetype index.html Running gio info "/tmp/index.html" text/html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shared-mime-info in Ubuntu. https://bugs.launchpad.net/bugs/1890716 Title: xdg-mime query filetype index.html reports wrong type Status in shared-mime-info package in Ubuntu: Incomplete Bug description: For .html files `xdg-mime` reports wrong type. The culprit is the `"use strict"` phrase which is used in JavaScript. It should not mistake .html files for anything else except of text/html ! STEPS TO REPRODUCE: Run the following step by step in any folder: 1. $ echo "\"use strict\"" > index.html 2. $ xdg-mime query filetype index.html # -> application/x-perl - this should be text/html! Platform: Ubuntu 20.04.1 LTS (Focal Fossa)" Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) xdg-utils: 1.1.3-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1891657] Re: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit'
here is output of running journalctl -b -u whoopsie journalctl -b -u apport-autoreport on Ubuntu 20.10 which has same 100% used by systemd ** Attachment added: "output of running journalctl -b -u whoopsie and journalctl -b -u apport-autoreport" https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1891657/+attachment/5413149/+files/sss.log -- 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/1891657 Title: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit' Status in apport package in Ubuntu: Confirmed Status in systemd package in Ubuntu: In Progress Status in apport source package in Groovy: Confirmed Status in systemd source package in Groovy: In Progress Bug description: after upgrade from Ubuntu 20.04 to 20.10 seeing systemd use 100% cpu forever top top - 10:16:19 up 20 min, 1 user, load average: 3.91, 4.28, 3.39 Tasks: 332 total, 2 running, 330 sleeping, 0 stopped, 0 zombie %Cpu(s): 18.7 us, 6.4 sy, 11.9 ni, 62.2 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st MiB Mem : 15917.6 total, 8553.4 free, 2604.3 used, 4759.9 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 12633.7 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 177316 12252 8684 R 100.0 0.1 15:01.25 systemd 4636 kush 39 19 633796 176152 16360 S 98.3 1.1 17:51.56 tracker-miner-f 820 message+ 20 0 10740 6452 4212 S 39.8 0.0 6:19.06 dbus-daemon 316 root 19 -1 535916 322896 320824 S 15.3 2.0 3:16.41 systemd-journal 844 syslog20 0 221136 5840 3920 S 13.6 0.0 2:14.52 rsyslogd 858 root 20 0 83708 74124 7568 S 12.7 0.5 2:06.98 systemd-logind 5 root 20 0 0 0 0 I 3.4 0.0 0:05.01 kworker/0:0-events 35566 kush 20 0 3850088 588344 262192 S 2.5 3.6 0:30.48 MainThread 5626 kush 20 0 5004788 260876 93400 S 1.7 1.6 3:05.19 gnome-shell 7033 kush 20 0 869792 66440 44272 S 1.7 0.4 0:06.05 gnome-terminal- 36790 kush 20 0 2525432 156636 98568 S 1.7 1.0 0:04.99 Web Content 957 root 20 0 1556196 45044 24284 S 0.8 0.3 0:02.48 containerd 1038 root 20 0 10460 4412 3300 S 0.8 0.0 0:00.16 fancontrol sudo tail -n 100 /var/log/syslog Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting
[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Bad case:
$ ./repro.sh bad
+ '[' bad == bad ']'
+ echo 'Bad case: Using apparmor from proposed'
Bad case: Using apparmor from proposed
+ BADCASE=1
+ lxc stop --force testguest-apparmor-bad
+ lxc delete --force testguest-apparmor-bad
+ lxc launch ubuntu-daily:groovy/amd64 testguest-apparmor-bad --profile default
--profile kvm
Creating testguest-apparmor-bad
Starting testguest-apparmor-bad
+ sleep 30s
+ lxc exec testguest-apparmor-bad runlevel
N 5
+ lxc exec testguest-apparmor-bad -- bash -c 'H=`cat /etc/hostname`; if [ -f
/var/lib/cloud/instance/boot-finished ]; then echo "LXD container $H ready";
else echo "LXD container $H not ready yet"; exit 2; fi'
LXD container testguest-apparmor-bad ready
+ lxc exec testguest-apparmor-bad --env DEBIAN_FRONTEND=noninteractive -- bash
-c 'apt-get --allow-unauthenticated --assume-yes -o
Dpkg::Options::='\''--force-confdef'\'' -o
Dpkg::Options::='\''--force-confold'\'' install apparmor-utils'
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
libfreetype6
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
python3-apparmor python3-libapparmor
Suggested packages:
vim-addon-manager
The following NEW packages will be installed:
apparmor-utils python3-apparmor python3-libapparmor
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 157 kB of archives.
After this operation, 966 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/main amd64 python3-libapparmor
amd64 2.13.3-7ubuntu6 [26.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu groovy/main amd64 python3-apparmor amd64
2.13.3-7ubuntu6 [78.6 kB]
Get:3 http://archive.ubuntu.com/ubuntu groovy/main amd64 apparmor-utils amd64
2.13.3-7ubuntu6 [51.4 kB]
Fetched 157 kB in 0s (385 kB/s)
Selecting previously unselected package python3-libapparmor.
(Reading database ... 31714 files and directories currently installed.)
Preparing to unpack .../python3-libapparmor_2.13.3-7ubuntu6_amd64.deb ...
Unpacking python3-libapparmor (2.13.3-7ubuntu6) ...
Selecting previously unselected package python3-apparmor.
Preparing to unpack .../python3-apparmor_2.13.3-7ubuntu6_amd64.deb ...
Unpacking python3-apparmor (2.13.3-7ubuntu6) ...
Selecting previously unselected package apparmor-utils.
Preparing to unpack .../apparmor-utils_2.13.3-7ubuntu6_amd64.deb ...
Unpacking apparmor-utils (2.13.3-7ubuntu6) ...
Setting up python3-libapparmor (2.13.3-7ubuntu6) ...
Setting up python3-apparmor (2.13.3-7ubuntu6) ...
Setting up apparmor-utils (2.13.3-7ubuntu6) ...
Processing triggers for man-db (2.9.3-2) ...
+ lxc exec testguest-apparmor-bad -- aa-status
apparmor module is loaded.
28 profiles are loaded.
28 profiles are in enforce mode.
/snap/snapd/9279/usr/lib/snapd/snap-confine
/snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/lib/snapd/snap-confine
/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/{,usr/}sbin/dhclient
lsb_release
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
snap-update-ns.lxd
snap.lxd.activate
snap.lxd.benchmark
snap.lxd.buginfo
snap.lxd.check-kernel
snap.lxd.daemon
snap.lxd.hook.configure
snap.lxd.hook.install
snap.lxd.hook.remove
snap.lxd.lxc
snap.lxd.lxc-to-lxd
snap.lxd.lxd
snap.lxd.migrate
tcpdump
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
+ '[' 1 -eq 1 ']'
+ lxc exec testguest-apparmor-bad -- bash -c 'echo '\''deb
http://archive.ubuntu.com/ubuntu/ groovy-proposed restricted main multiverse
universe'\'' >> /etc/apt/sources.list'
+ lxc exec testguest-apparmor-bad --env DEBIAN_FRONTEND=noninteractive -- bash
-c 'apt-get --allow-unauthenticated --assume-yes -o
Dpkg::Options::='\''--force-confdef'\'' -o
Dpkg::Options::='\''--force-confold'\'' update'
Hit:1 http://security.ubuntu.com/ubuntu groovy-security InRelease
Get:2 http://archive.ubuntu.com/ubuntu groovy InRelease [267 kB]
Get:3 http://security.ubuntu.com/ubuntu groovy-security/universe amd64 c-n-f
Metadata [116 B]
Get:4 http://security.ubuntu.com/ubuntu groovy-security/multiverse amd64 c-n-f
Metadata [116 B]
Hit:5 http://archive.ubuntu.com/ubuntu groovy-updates InRelease
Get:6 http://archive.ubuntu.com/ubuntu groovy-backports InRelease [89.2 kB]
Get:7 http://archive.ubuntu.com/ubuntu groovy-proposed InRelease [118 kB]
Get:8 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages [969 kB]
Get:9 http://archive.ubuntu.com/ubuntu groovy/main Translation-en [507 kB]
Get:10 http://archive.ubuntu.com/ubuntu groovy/main amd64 c-n-
Re: [Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package
See https://bugs.launchpad.net/bugs/1895302 On Tue, Sep 22, 2020, 07:41 Oliver Grawert <1888...@bugs.launchpad.net> wrote: > please note that the stable UbuntuCore18 images regressed due to this: > > https://github.com/snapcore/core18/issues/170 > > ** Bug watch added: github.com/snapcore/core18/issues #170 >https://github.com/snapcore/core18/issues/170 > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1888575 > > Title: > Split motd-news config into a new package > > Status in base-files package in Ubuntu: > Fix Released > Status in livecd-rootfs package in Ubuntu: > Invalid > Status in ubuntu-meta package in Ubuntu: > Fix Released > Status in base-files source package in Xenial: > Fix Released > Status in livecd-rootfs source package in Xenial: > Triaged > Status in ubuntu-meta source package in Xenial: > Fix Committed > Status in base-files source package in Bionic: > Fix Released > Status in livecd-rootfs source package in Bionic: > Invalid > Status in ubuntu-meta source package in Bionic: > Fix Released > Status in base-files source package in Focal: > Fix Released > Status in livecd-rootfs source package in Focal: > Invalid > Status in ubuntu-meta source package in Focal: > Fix Released > Status in base-files source package in Groovy: > Fix Released > Status in livecd-rootfs source package in Groovy: > Invalid > Status in ubuntu-meta source package in Groovy: > Fix Released > > Bug description: > [Impact] > The motd-news script is largely useless for desktop users, as they > rarely login via a text console. It makes more sense for server users. > > We can use package dependencies to have the motd-news script enabled on > servers, but disabled on desktops, and still handle upgrades. This is the > plan: > - move /etc/default/motd-news from base-files into a new binary package > (motd-news-config, produced by src:base-files) > - have ubuntu-server depend on motd-news-config > - have base-files break current ubuntu-server, so that if base-files if > upgraded and ubuntu-server is installed, ubuntu-server will also be > upgraded to the new version which has the depends on motd-news-config > > Care must be taken to preserve a changed /etc/default/motd-news when > the upgrade installs the new motd-news-config package. For example, on > a server that has set ENABLED=0 in /etc/default/motd-news and upgrades > to the new base-files and ubuntu-server, and gets the new motd-config- > news package, ENABLED=0 must remain set. > > [Test Case] > a) base-files installed, ubuntu-server installed, unmodified > /e/d/motd-news > apt install base-files > - upgrades ubuntu-server > - installs motd-news-config > - /e/d/motd-news remains, motd-news remains enabled > > b) base-files installed, ubuntu-server installed, modified /e/d/motd-news > apt install base-files > - upgrades ubuntu-server > - installs motd-news-config > - /e/d/motd-news remains with the original modification > > c) base-files installed, ubuntu-server not installed, unmodified > /e/d/motd-news > apt install base-files > - upgrades base-files > - removes /e/d/motd-news > - motd-news is disabled > > d) base-files installed, ubuntu-server not installed, modified > /e/d/motd-news > apt install base-files > - upgrades base-files > - /e/d/motd-news gets renamed to backup > - motd-news is disabled > > e) removing motd-news-config will also remove ubuntu-server (since > it's a depends, and not a recommends) > > f) upgrading just ubuntu-server should pull motd-news-config in, and > force-upgrade base-files > > g) Removing motd-news-server leaves /e/d/motd-news around; purging > motd-news-server removes the /e/d/motd-news config file > > h) base-files installed, ubuntu-server installed, removed /e/d/motd-news > - apt install base-files > - upgrades base-files, upgrades ubuntu-server, installs motd-news-config > - /e/d/motd-news is installed with ENABLED=0 > > i) base-files installed, ubuntu-server NOT installed, removed > e/d/motd-news > - apt install base-files > - base-files is upgraded > - no /e/d/motd-news is installed, motd-news remains disabled > > j) Perform a release upgrade from the previous ubuntu release to the > one being tested while having ubuntu-server NOT installed (or use a > desktop install). At the end, motd-news should be disabled. Verify > with: > > $ sudo /etc/update-motd.d/50-motd-news --force > $ (no output) > > k) Test that supporting changes for xenial are in place: > > i) verify grub-legacy-ec2 is not in the xenial server seed > ii) verify that the rootfs manifest built from the ubuntu-cpc project > contains the ubuntu-server package > iii) verify that images built from the ubuntu-cpc project which purge > grub-legacy-ec2 have retained ubuntu-server > > [Regression Potential] > This update is about config fil
[Touch-packages] [Bug 1890716] Re: xdg-mime query filetype index.html reports wrong type
in fact the script doesn't seem to used shared-mime-info $ XDG_UTILS_DEBUG_LEVEL=1 xdg-mime query filetype index.html Running mimetype --brief --dereference "/tmp/index.html" text/html could you try to use the command with the same environement variable and share the output? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shared-mime-info in Ubuntu. https://bugs.launchpad.net/bugs/1890716 Title: xdg-mime query filetype index.html reports wrong type Status in shared-mime-info package in Ubuntu: Incomplete Bug description: For .html files `xdg-mime` reports wrong type. The culprit is the `"use strict"` phrase which is used in JavaScript. It should not mistake .html files for anything else except of text/html ! STEPS TO REPRODUCE: Run the following step by step in any folder: 1. $ echo "\"use strict\"" > index.html 2. $ xdg-mime query filetype index.html # -> application/x-perl - this should be text/html! Platform: Ubuntu 20.04.1 LTS (Focal Fossa)" Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) xdg-utils: 1.1.3-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1896614] [NEW] Race condition when starting dbus services
Public bug reported: In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. The issue appears when systemd runs the "AddMatch" dbus method call to track the service's "NameOwnerChange" once it has already ran. A working instance would look like this: https://pastebin.ubuntu.com/p/868J6WBRQx/ A failing instance would be: https://pastebin.ubuntu.com/p/HhJZ4p8dT5/ I've been able to reproduce the issue on Bionic (237-3ubuntu10.42) running: sudo systemctl daemon-reload & sudo systemctl restart systemd-logind ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Tags: sts ** Tags added: sts ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1896614 Title: Race condition when starting dbus services Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. The issue appears when systemd runs the "AddMatch" dbus method call to track the service's "NameOwnerChange" once it has already ran. A working instance would look like this: https://pastebin.ubuntu.com/p/868J6WBRQx/ A failing instance would be: https://pastebin.ubuntu.com/p/HhJZ4p8dT5/ I've been able to reproduce the issue on Bionic (237-3ubuntu10.42) running: sudo systemctl daemon-reload & sudo systemctl restart systemd-logind To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896614/+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 1803203] Re: Support preferred_lft for IPv6 addresses
This bug was fixed in the package netplan.io - 0.100-0ubuntu4 --- netplan.io (0.100-0ubuntu4) groovy; urgency=medium * debian/tests/cloud-init - Improve reboot test to avoid failure on arm64 -- Lukas Märdian Mon, 21 Sep 2020 12:23:02 +0200 ** Changed in: netplan.io (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/1803203 Title: Support preferred_lft for IPv6 addresses Status in netplan: New Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Bug description: There doesn't currently seem to be any way to set the preferred_lft of an IPv6 address. With the "ip" command it might be, for example: # ip address add 2001:db8::2/32 dev eth0 preferred_lft 0 In a systemd unit file it might be: [Match] Name=eth0 [Network] Address=2001:db8::2/32 Gateway=2001:db8::1/32 PreferredLifetime=0 but I can't find any way to express this with netplan. This is commonly used for per-service IP addresses that should never be used as source addresses for outgoing traffic. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1803203/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
Still chasing this down The apparmor.systemd file is unchanged from focal. The change is in rc.apparmor.functions which is a dependency of apparmor.systemd. -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1896577] Re: FFE: new upstream release 20.2 and migrate to llvm 11
** Changed in: mesa (Ubuntu) Assignee: (unassigned) => Timo Aaltonen (tjaalton) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1896577 Title: FFE: new upstream release 20.2 and migrate to llvm 11 Status in mesa package in Ubuntu: New Bug description: Mesa 20.2.0 has been delayed by upstream, but we still want it in 20.10. It's currrently at rc4, final was supposed to be out a month ago. It's been in debian experimental since rc1. The packaging in debian also migrates to use llvm 11. packages for groovy are available on ppa:canonical-x/x-staging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1896577/+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 1896614] Re: Race condition when starting dbus services
restarting systemd-logind is not safe, as existing sessions can be logged out. also performing daemon-reload, mid-boot, also is not safe. Can you explain the usecase and why these actions are performed together, racing each other? -- 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/1896614 Title: Race condition when starting dbus services Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. The issue appears when systemd runs the "AddMatch" dbus method call to track the service's "NameOwnerChange" once it has already ran. A working instance would look like this: https://pastebin.ubuntu.com/p/868J6WBRQx/ A failing instance would be: https://pastebin.ubuntu.com/p/HhJZ4p8dT5/ I've been able to reproduce the issue on Bionic (237-3ubuntu10.42) running: sudo systemctl daemon-reload & sudo systemctl restart systemd-logind To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896614/+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 1882098] Re: Packagekit lets user install untrusted local packages in Bionic and Focal
** Patch added: "0001-aptcc-Do-not-trust-local-debs-allows-root-privileges.patch" https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+attachment/5413161/+files/0001-aptcc-Do-not-trust-local-debs-allows-root-privileges.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1882098 Title: Packagekit lets user install untrusted local packages in Bionic and Focal Status in packagekit package in Ubuntu: Triaged Bug description: We have packagekit configured to allow users to install trusted packages from preconfigured repositories, but disallowed them to install any untrusted packages. The policykit configuration we use is following: [tld.univ.packagekit] Identity=unix-group:adm; Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system; ResultAny=auth_self ResultActive=auth_self ResultInactive=auth_self [tld.univ.packagekit-deny] Identity=unix-user:*; Action=org.freedesktop.packagekit.package-install-untrusted; ResultAny=no We would expect this to prevent users from installing local packages downloaded from random repositories, however this does not seem to be the case. pkcon install-local random_package.deb will happily prompt for the user to authenticate and will install the package, while pkcon --allow-untrusted install-local random_package.deb will prompt for root password, which the user does not have. Our initial toughts was that the issue would be in packagekitd, but after further investigations it looks like the issue could be in aptcc backend. We are more than happy to provide you with further details, but the above should be enough to reproduce the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+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 1882098] Re: Packagekit lets user install untrusted local packages in Bionic and Focal
** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1882098 Title: Packagekit lets user install untrusted local packages in Bionic and Focal Status in packagekit package in Ubuntu: Triaged Bug description: We have packagekit configured to allow users to install trusted packages from preconfigured repositories, but disallowed them to install any untrusted packages. The policykit configuration we use is following: [tld.univ.packagekit] Identity=unix-group:adm; Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system; ResultAny=auth_self ResultActive=auth_self ResultInactive=auth_self [tld.univ.packagekit-deny] Identity=unix-user:*; Action=org.freedesktop.packagekit.package-install-untrusted; ResultAny=no We would expect this to prevent users from installing local packages downloaded from random repositories, however this does not seem to be the case. pkcon install-local random_package.deb will happily prompt for the user to authenticate and will install the package, while pkcon --allow-untrusted install-local random_package.deb will prompt for root password, which the user does not have. Our initial toughts was that the issue would be in packagekitd, but after further investigations it looks like the issue could be in aptcc backend. We are more than happy to provide you with further details, but the above should be enough to reproduce the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+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 1888575] Re: Split motd-news config into a new package
I meant, see *also* https://bugs.launchpad.net/bugs/1895302, no idea yet if it's related. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-files in Ubuntu. https://bugs.launchpad.net/bugs/1888575 Title: Split motd-news config into a new package Status in base-files package in Ubuntu: Fix Released Status in livecd-rootfs package in Ubuntu: Invalid Status in ubuntu-meta package in Ubuntu: Fix Released Status in base-files source package in Xenial: Fix Released Status in livecd-rootfs source package in Xenial: Triaged Status in ubuntu-meta source package in Xenial: Fix Committed Status in base-files source package in Bionic: Fix Released Status in livecd-rootfs source package in Bionic: Invalid Status in ubuntu-meta source package in Bionic: Fix Released Status in base-files source package in Focal: Fix Released Status in livecd-rootfs source package in Focal: Invalid Status in ubuntu-meta source package in Focal: Fix Released Status in base-files source package in Groovy: Fix Released Status in livecd-rootfs source package in Groovy: Invalid Status in ubuntu-meta source package in Groovy: Fix Released Bug description: [Impact] The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users. We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan: - move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files) - have ubuntu-server depend on motd-news-config - have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config- news package, ENABLED=0 must remain set. [Test Case] a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news apt install base-files - upgrades ubuntu-server - installs motd-news-config - /e/d/motd-news remains, motd-news remains enabled b) base-files installed, ubuntu-server installed, modified /e/d/motd-news apt install base-files - upgrades ubuntu-server - installs motd-news-config - /e/d/motd-news remains with the original modification c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news apt install base-files - upgrades base-files - removes /e/d/motd-news - motd-news is disabled d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news apt install base-files - upgrades base-files - /e/d/motd-news gets renamed to backup - motd-news is disabled e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends) f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file h) base-files installed, ubuntu-server installed, removed /e/d/motd-news - apt install base-files - upgrades base-files, upgrades ubuntu-server, installs motd-news-config - /e/d/motd-news is installed with ENABLED=0 i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news - apt install base-files - base-files is upgraded - no /e/d/motd-news is installed, motd-news remains disabled j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install). At the end, motd-news should be disabled. Verify with: $ sudo /etc/update-motd.d/50-motd-news --force $ (no output) k) Test that supporting changes for xenial are in place: i) verify grub-legacy-ec2 is not in the xenial server seed ii) verify that the rootfs manifest built from the ubuntu-cpc project contains the ubuntu-server package iii) verify that images built from the ubuntu-cpc project which purge grub-legacy-ec2 have retained ubuntu-server [Regression Potential] This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here: a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-confi
[Touch-packages] [Bug 1896614] Re: Race condition when starting dbus services
In the original report, the issue happened randomly on boot when a service[1] was triggering a reload while systemd-logind was starting, resulting in a list of queued jobs that were never executed. The issue can happen too under high load conditions, as reported upstream: https://github.com/systemd/systemd/issues/12956 To simplify the reproducer I went with systemd-logind+daemon-reload, but it can be done with any other dbus service. [1] [Unit] Description=Disable unattended upgrades After=network-online.target local-fs.target [Service] Type=oneshot ExecStart=/bin/bash -c "/bin/chmod 644 /etc/cron.daily/apt-compat ; /bin/systemctl disable apt-daily-upgrade.timer apt-daily.timer ; /bin/systemctl stop apt-daily-upgrade.timer apt-daily.timer" [Install] WantedBy=multi-user.target ** Bug watch added: github.com/systemd/systemd/issues #12956 https://github.com/systemd/systemd/issues/12956 -- 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/1896614 Title: Race condition when starting dbus services Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. The issue appears when systemd runs the "AddMatch" dbus method call to track the service's "NameOwnerChange" once it has already ran. A working instance would look like this: https://pastebin.ubuntu.com/p/868J6WBRQx/ A failing instance would be: https://pastebin.ubuntu.com/p/HhJZ4p8dT5/ I've been able to reproduce the issue on Bionic (237-3ubuntu10.42) running: sudo systemctl daemon-reload & sudo systemctl restart systemd-logind To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896614/+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 1838151] Re: Poor quality audio with modern Bluetooth headsets in HSP/HFP. Missing wide band speech support.
Linux Mint 19.3 user and I can also confirm this bug. -- 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/1838151 Title: Poor quality audio with modern Bluetooth headsets in HSP/HFP. Missing wide band speech support. Status in PulseAudio: New Status in bluez package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in pulseaudio package in Ubuntu: In Progress Status in Arch Linux: New Bug description: Bluetooth HSP/HFP audio quality is poor on Ubuntu comparative to all other major platforms (Windows, MacOS, ChromeOS, Android, iOS). Modern Bluetooth headsets (such as the Bose QC series headphones, many others) are capable of using HFP 1.6 with mSBC 16kHz audio encoding. As it currently stands, Ubuntu defaults to only supporting HSP headsets using 8kHz CVSD, and is incapable of supporting HFP 1.6 at this time. The ChromiumOS team recently tackled this issue - https://bugs.chromium.org/p/chromium/issues/detail?id=843048 Their efforts may assist in bringing this to Ubuntu, however it appears that there are quite a lot of differences considering they have developed their own audio server solution etc. The Bluetooth Telephony Working Group published the HFP 1.6 spec in May 2011 - https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=238193 Patches have been proposed in the past for this issue to the kernel and PulseAudio: PulseAudio: https://patchwork.freedesktop.org/patch/245272/ Kernel: https://www.spinics.net/lists/linux-bluetooth/msg76982.html It appears that the Chromium OS team applied the same kernel patch: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/77dd0cb94c1713a8a12f6e392955dfa64c430e54 ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: pulseaudio 1:12.2-2ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: jnappi 2777 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sat Jul 27 11:08:29 2019 EcryptfsInUse: Yes InstallationDate: Installed on 2017-11-04 (629 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: Upgraded to disco on 2019-07-18 (9 days ago) dmi.bios.date: 06/07/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R07ET67W (2.07 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FW000TUS dmi.board.vendor: LENOVO dmi.board.version: SDK0J40705 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR07ET67W(2.07):bd06/07/2016:svnLENOVO:pn20FW000TUS:pvrThinkPadT460p:rvnLENOVO:rn20FW000TUS:rvrSDK0J40705WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460p dmi.product.name: 20FW000TUS dmi.product.sku: LENOVO_MT_20FW_BU_Think_FM_ThinkPad T460p dmi.product.version: ThinkPad T460p dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/1838151/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
@gpiccoli, Can you break down everything this debdiff does per file being modified in the d/changelog along with the summary you have already provided ? It would ease for future reference and make the d/changelog more accurate about the changes. * d/cryptsetup-initramfs.install: - * d/functions cryptsetup-2.3.3/debian/functions: - * d/initramfs/scripts/local-block/cryptroot: - * d/initramfs/scripts/local-bottom/cryptroot: - * d/initramfs/scripts/local-top/cryptroot: - -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchp
[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
Isn't that "Not starting AppArmor in container" message just in:
/lib/apparmor/apparmor.systemd
-> /lib/apparmor/rc.apparmor.functions
-> function is_container_with_internal_policy()
That looks unchanged (except a comment) but it behaves differently:
root@testguest-apparmor-good:~# . /usr/lib/apparmor/rc.apparmor.functions
root@testguest-apparmor-good:~# is_container_with_internal_policy
root@testguest-apparmor-good:~# echo $?
0
root@testguest-apparmor-bad:~# . /usr/lib/apparmor/rc.apparmor.functions
root@testguest-apparmor-bad:~# is_container_with_internal_policy
root@testguest-apparmor-bad:~# echo $?
1
Looking into what happens in detail ...
good:
+ SFS_MOUNTPOINT=/sys/kernel/security/apparmor
+ local ns_stacked_path=/sys/kernel/security/apparmor/.ns_stacked
bad:
+ SFS_MOUNTPOINT=/sys/kernel/security/
+ local ns_stacked_path=/sys/kernel/security//.ns_stacked
Once we know that we can see that it is missing in the bad case
good:
root@testguest-apparmor-good:~# grep MODULE
/usr/lib/apparmor/rc.apparmor.functions
MODULE=apparmor
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
if [ -f "${SECURITYFS}/${MODULE}/profiles" ]; then
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
MODULE=apparmor
/sbin/modprobe -qr $MODULE
bad:
root@testguest-apparmor-bad:~# grep MODULE
/usr/lib/apparmor/rc.apparmor.functions
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
So whatever took away the modprobe from
/usr/lib/apparmor/rc.apparmor.functions also removed the variable, but
that has broken function is_container_with_internal_policy
--
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/1895967
Title:
Apparmor 3.0.0 does not load profiles in containers anymore
Status in apparmor package in Ubuntu:
Confirmed
Bug description:
Hi,
I stumbled over this due to automatic tests checking proposed.
I found that Focal no more could migrate to Groovy with:
$ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
error: unsupported configuration: Security driver model 'apparmor' is not
available
I looked after it and found that while all former releases detected
apparmor correctly:
$ virsh capabilities | grep -C 3 secmodel
apparmor
0
dac
0
+64055:+108
+64055:+108
Now on groovy that didn't work anymore:
none
0
dac
0
+64055:+108
+64055:+108
Since 3.0 is only in proposed:
# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
3.0.0~beta1-0ubuntu1 500
500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64
Packages
*** 2.13.3-7ubuntu6 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
100 /var/lib/dpkg/status
I installed the former version.
$ apt install apparmor=2.13.3-7ubuntu6
$ rm /var/cache/libvirt/qemu/capabilities/*
$ systemctl restart libvirtd
And it works again.
Interestingly going back to 3.0 then works and keeps working.
Therefore maybe it is a red-herring and I'll consider it incomplete & low
prio for now until I know more (allowing others that might see the same to find
this bug and chime in).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
Hi Eric, all the changes are part of the same functionality - the local-bottom script for example is a clean-up for the files created in the local-top phase. I think it'd be unnecessary verbosity to explain file by file, and this bug is waiting for a long time to be fixed (especially due to the FTBFS we needed to investigate and fix), so unless you think it's strictly necessary, I'd rather move this one forward without changing the description. Thanks, Guilherme -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/crypt
[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
https://gitlab.com/apparmor/apparmor/-/commit/61c27d8808f0589beb6a319cc04073e8bb32d860 -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
And we are back with Christian Bolz :-) commit 61c27d8808f0589beb6a319cc04073e8bb32d860 Author: Christian Boltz Date: Fri Jun 21 19:22:15 2019 +0200 Fix and simplify setting SFS_MOUNTPOINT The question is why isn't this in the apparmor 3.0 package in groovy- proposed ? -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
As refrence, it is a re-occurrence of https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812 , look who filed that bug :-) -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
Hi Guilherme, I can handle that while you're out. cheers, Mauricio -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
That patch by Christian Bolz is already applied (which seems reasonable after that much time), but when merging 3.0 the old patch for bug 1824812 should have been dropped. -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
** Merge proposal linked: https://code.launchpad.net/~paelzer/ubuntu/+source/apparmor/+git/apparmor/+merge/391134 -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
Tested the change - works as expected, prepping an MP -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1840784] Re: suspend.target: Job suspend.target/start failed with result 'dependency'.
Your ethernet driver or hw is preventing suspend: [231201.406221] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x50 [e1000e] returns -2 [231201.406226] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2 [231201.406230] PM: Device :00:19.0 failed to suspend async: error -2 [231201.406291] PM: Some devices failed to suspend, or early wake event detected This looks like maybe this kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=198519 Which maybe is bug 1865570. In any case, this is not a systemd bug, it's a kernel bug, so I'm changing the affected pacakge to the kernel. ** Bug watch added: Linux Kernel Bug Tracker #198519 https://bugzilla.kernel.org/show_bug.cgi?id=198519 ** Package changed: systemd (Ubuntu) => linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1840784 Title: suspend.target: Job suspend.target/start failed with result 'dependency'. Status in linux package in Ubuntu: New Bug description: System fails to suspend, screen goes dark then turns back on. The lid won't suspend the system either. Things I've tried: turning off baloo, disconnecting from network. From the logs: suspend.target: Job suspend.target/start failed with result 'dependency'. I've observed this behavior a often enough during the past month that suspend is unpredictable. Luckily my computer has a suspend state indicator - some laptops don't. A google search shows this to be a very old bug, earliest mentions are from 2014. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: systemd 240-6ubuntu5.3 ProcVersionSignature: Ubuntu 5.0.0-26.27-generic 5.0.21 Uname: Linux 5.0.0-26-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: KDE Date: Tue Aug 20 17:34:30 2019 InstallationDate: Installed on 2018-11-15 (278 days ago) InstallationMedia: Kubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) MachineType: LENOVO 20AQCTO1WW ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-26-generic root=/dev/mapper/kubuntu--vg-root ro psmouse.synaptics_intertouch=0 quiet splash vt.handoff=1 SourcePackage: systemd UpgradeStatus: Upgraded to disco on 2019-04-27 (114 days ago) dmi.bios.date: 03/20/2018 dmi.bios.vendor: LENOVO dmi.bios.version: GJET98WW (2.48 ) dmi.board.asset.tag: Not Available dmi.board.name: 20AQCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0E50510 PRO dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrGJET98WW(2.48):bd03/20/2018:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvrSDK0E50510PRO:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.family: ThinkPad T440s dmi.product.name: 20AQCTO1WW dmi.product.sku: LENOVO_MT_20AQ_BU_Think_FM_ThinkPad T440s dmi.product.version: ThinkPad T440s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840784/+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 1896395] Re: lid closure behavior unpredictable
You need to provide some kind of logs to review. ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- 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/1896395 Title: lid closure behavior unpredictable Status in systemd package in Ubuntu: Incomplete Bug description: in 20.04.01 LTS (release 20.04), suspend on lid closure works for a while, then one day stops working, with no error message in syslog. The event is not even registered. The problem seems to start when the system has been inactive for long enough so that the screen is blanked. systemd: Installed: 245.4-4ubuntu3.2 Candidate: 245.4-4ubuntu3.2 Version table: *** 245.4-4ubuntu3.2 500 500 http://ca.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3 500 500 http://ca.archive.ubuntu.com/ubuntu focal/main amd64 Packages seems similar to bug #1840784, even though no error message is generated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896395/+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 1896137] Re: syslog flooded with "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7"
> by unmasking those targets don't come masked by default, how did they get masked? ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- 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/1896137 Title: syslog flooded with "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7" Status in systemd package in Ubuntu: Incomplete Bug description: When I close the lid on my laptop, syslog goes crazy with the message systemd-logind: hibernation is restricted; see man kernel_lockdown.7 repeated ad infinitum, using up all the CPU and GBs of disk space. I am not even trying to hibernate; everything in /etc/systemd/login.conf is commented out. So nothing much should happen when I close the lid, but systemd is trying to kill me with these messages. I am running Ubuntu 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896137/+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 1896626] [NEW] apparmor service is dead
Public bug reported: // System Ubuntu 20.04 LTS 64-bit user@ubuntu:~/Desktop$ sudo apparmor_parser --version AppArmor parser version 2.13.3 Copyright (C) 1999-2008 Novell Inc. Copyright 2009-2018 Canonical Ltd. user@ubuntu:~/Desktop$ systemctl status apparmor.service ● apparmor.service - Load AppArmor profiles Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor pres> Active: inactive (dead) Condition: start condition failed at Tue 2020-09-22 21:12:13 +07; 6s ago └─ ConditionPathExists=!/rofs/etc/apparmor.d was not met Docs: man:apparmor(7) https://gitlab.com/apparmor/apparmor/wikis/home/ user@ubuntu:~/Desktop$ sudo aa-status apparmor module is loaded. 15 profiles are loaded. 12 profiles are in enforce mode. /snap/core/9993/usr/lib/snapd/snap-confine /snap/core/9993/usr/lib/snapd/snap-confine//mount-namespace-capture-helper /snap/snapd/7264/usr/lib/snapd/snap-confine /snap/snapd/7264/usr/lib/snapd/snap-confine//mount-namespace-capture-helper snap-update-ns.blender snap-update-ns.core snap-update-ns.gitkraken snap-update-ns.snap-store snap.core.hook.configure snap.snap-store.snap-store snap.snap-store.ubuntu-software snap.snap-store.ubuntu-software-local-file 3 profiles are in complain mode. snap.blender.blender snap.gitkraken.gitkraken snap.gitkraken.url-handler 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apparmor 2.13.3-7ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckMismatches: ./casper/initrd CasperMD5CheckResult: skip CasperVersion: 1.445 Date: Tue Sep 22 21:21:08 2020 LiveMediaBuild: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdline: BOOT_IMAGE=/casper/vmlinuz persistent file=/cdrom/preseed/hostname.seed quiet splash --- SourcePackage: apparmor UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- 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/1896626 Title: apparmor service is dead Status in apparmor package in Ubuntu: New Bug description: // System Ubuntu 20.04 LTS 64-bit user@ubuntu:~/Desktop$ sudo apparmor_parser --version AppArmor parser version 2.13.3 Copyright (C) 1999-2008 Novell Inc. Copyright 2009-2018 Canonical Ltd. user@ubuntu:~/Desktop$ systemctl status apparmor.service ● apparmor.service - Load AppArmor profiles Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor pres> Active: inactive (dead) Condition: start condition failed at Tue 2020-09-22 21:12:13 +07; 6s ago └─ ConditionPathExists=!/rofs/etc/apparmor.d was not met Docs: man:apparmor(7) https://gitlab.com/apparmor/apparmor/wikis/home/ user@ubuntu:~/Desktop$ sudo aa-status apparmor module is loaded. 15 profiles are loaded. 12 profiles are in enforce mode. /snap/core/9993/usr/lib/snapd/snap-confine /snap/core/9993/usr/lib/snapd/snap-confine//mount-namespace-capture-helper /snap/snapd/7264/usr/lib/snapd/snap-confine /snap/snapd/7264/usr/lib/snapd/snap-confine//mount-namespace-capture-helper snap-update-ns.blender snap-update-ns.core snap-update-ns.gitkraken snap-update-ns.snap-store snap.core.hook.configure snap.snap-store.snap-store snap.snap-store.ubuntu-software snap.snap-store.ubuntu-software-local-file 3 profiles are in complain mode. snap.blender.blender snap.gitkraken.gitkraken snap.gitkraken.url-handler 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apparmor 2.13.3-7ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckMismatches: ./casper/initrd CasperMD5CheckResult: skip CasperVersion: 1.445 Date: Tue Sep 22 21:21:08 2020 LiveMediaBuild: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdline: BOOT_IMAGE=/casper/vmlinuz persistent file=/cdrom/
[Touch-packages] [Bug 1896627] [NEW] Windows flicker when being reized with the mouse
Public bug reported: When resizing a window with the mouse by dragging the edge or corner, the window begins to flicker. It only flickers when actively being resized, and when I stop dragging, it looks normal. This behavior is does not occur on same pc in 20.04. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: Budgie:GNOME CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Tue Sep 22 10:21:51 2020 DistUpgraded: Fresh install DistroCodename: groovy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Skylake GT2 [HD Graphics 520] [17aa:2231] InstallationDate: Installed on 2020-09-22 (0 days ago) InstallationMedia: Ubuntu-Budgie 20.10 "Groovy Gorilla" - Alpha amd64 (20200921) MachineType: LENOVO 20FJS0AJ00 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-18-generic root=UUID=72bd1806-98fb-4fa6-be5b-638dec36ebc9 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/07/2016 dmi.bios.release: 1.13 dmi.bios.vendor: LENOVO dmi.bios.version: N1KET26W (1.13 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FJS0AJ00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.5 dmi.modalias: dmi:bvnLENOVO:bvrN1KET26W(1.13):bd10/07/2016:br1.13:efr1.5:svnLENOVO:pn20FJS0AJ00:pvrThinkPadT560:rvnLENOVO:rn20FJS0AJ00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T560 dmi.product.name: 20FJS0AJ00 dmi.product.sku: LENOVO_MT_20FJ_BU_Think_FM_ThinkPad T560 dmi.product.version: ThinkPad T560 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.102-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.1.7-1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu6 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug groovy reproducible 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/1896627 Title: Windows flicker when being reized with the mouse Status in xorg package in Ubuntu: New Bug description: When resizing a window with the mouse by dragging the edge or corner, the window begins to flicker. It only flickers when actively being resized, and when I stop dragging, it looks normal. This behavior is does not occur on same pc in 20.04. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: Budgie:GNOME CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Tue Sep 22 10:21:51 2020 DistUpgraded: Fresh install DistroCodename: groovy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Skylake GT2 [HD Graphics 520] [17aa:2231] InstallationDate: Installed on 2020-09-22 (0 days ago) InstallationMedia: Ubuntu-Budgie 20.10 "Groovy Gorilla" - Alpha amd64 (20200921) MachineType: LENOVO 20FJS0AJ00 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-18-generic root=UUID=72bd1806-98fb-4fa6-be5b-638dec36ebc9 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/07/2016 dmi.bios.release: 1.13 dmi.bios.vendor: LENOVO dmi.bios.version: N1KET26W (1.13 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FJS0AJ00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information
[Touch-packages] [Bug 1894622] Re: Missing manpage for systemd-resolve
systemd-resolve has been deprecated in favor of the new name 'resolvectl', but the resolvectl binary does provide backwards compatibility with systemd-resolve (which is symlinked to resolvectl), so there should be *some* kind of manpage for it, as long as that backwards compatibility symlink is provided. It looks like upstream, the systemd-resolve manpage was completely replaced by the resolvectl manpage in commit b69f810c8a2ece4e44c1b1898e237bb671b36a21. This should probably be discussed upstream to restore some kind of manpage for systemd-resolve compatibility mode, instead of just in Ubuntu. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1894622 Title: Missing manpage for systemd-resolve Status in systemd package in Ubuntu: New Bug description: On my Focal machine there is no file /usr/share/man/man1/systemd-resolve.1.gz This means that man systemd-resolve fails. http://manpages.ubuntu.com/manpages/bionic/en/man1/systemd- resolve.1.html exists and has a link on top to 20.04LTS: it points to http://manpages.ubuntu.com/manpages/focal/en/man1/systemd- resolve.1.html , that however 404's, and one ends up being redirected to Bionic's. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1894622/+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 1896395] Re: lid closure behavior unpredictable
sorry, you can withdraw this bug as I discovered it is a kernel bug, not systemd. (I wanted to withdraw it earlier but did not know how to get back to this report.) thanks -- 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/1896395 Title: lid closure behavior unpredictable Status in systemd package in Ubuntu: Incomplete Bug description: in 20.04.01 LTS (release 20.04), suspend on lid closure works for a while, then one day stops working, with no error message in syslog. The event is not even registered. The problem seems to start when the system has been inactive for long enough so that the screen is blanked. systemd: Installed: 245.4-4ubuntu3.2 Candidate: 245.4-4ubuntu3.2 Version table: *** 245.4-4ubuntu3.2 500 500 http://ca.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3 500 500 http://ca.archive.ubuntu.com/ubuntu focal/main amd64 Packages seems similar to bug #1840784, even though no error message is generated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896395/+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 1896137] Re: syslog flooded with "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7"
That's right, I masked them by hand following some advice on the internet for how to make systemd stop suspending, since it was not responding to settings in login.conf even after restating logind service. Regardless of my motivation, it seems buggy that changing these settings should lead to such undesirable behavior. -- 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/1896137 Title: syslog flooded with "Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7" Status in systemd package in Ubuntu: Incomplete Bug description: When I close the lid on my laptop, syslog goes crazy with the message systemd-logind: hibernation is restricted; see man kernel_lockdown.7 repeated ad infinitum, using up all the CPU and GBs of disk space. I am not even trying to hibernate; everything in /etc/systemd/login.conf is commented out. So nothing much should happen when I close the lid, but systemd is trying to kill me with these messages. I am running Ubuntu 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896137/+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 1896626] Re: apparmor service is dead
I just follow this thread and fix the issue. https://forums.whonix.org/t/live-mode-breaks-apparmor/7559/7 ** Changed in: apparmor (Ubuntu) Status: New => Invalid -- 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/1896626 Title: apparmor service is dead Status in apparmor package in Ubuntu: Invalid Bug description: // System Ubuntu 20.04 LTS 64-bit user@ubuntu:~/Desktop$ sudo apparmor_parser --version AppArmor parser version 2.13.3 Copyright (C) 1999-2008 Novell Inc. Copyright 2009-2018 Canonical Ltd. user@ubuntu:~/Desktop$ systemctl status apparmor.service ● apparmor.service - Load AppArmor profiles Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor pres> Active: inactive (dead) Condition: start condition failed at Tue 2020-09-22 21:12:13 +07; 6s ago └─ ConditionPathExists=!/rofs/etc/apparmor.d was not met Docs: man:apparmor(7) https://gitlab.com/apparmor/apparmor/wikis/home/ user@ubuntu:~/Desktop$ sudo aa-status apparmor module is loaded. 15 profiles are loaded. 12 profiles are in enforce mode. /snap/core/9993/usr/lib/snapd/snap-confine /snap/core/9993/usr/lib/snapd/snap-confine//mount-namespace-capture-helper /snap/snapd/7264/usr/lib/snapd/snap-confine /snap/snapd/7264/usr/lib/snapd/snap-confine//mount-namespace-capture-helper snap-update-ns.blender snap-update-ns.core snap-update-ns.gitkraken snap-update-ns.snap-store snap.core.hook.configure snap.snap-store.snap-store snap.snap-store.ubuntu-software snap.snap-store.ubuntu-software-local-file 3 profiles are in complain mode. snap.blender.blender snap.gitkraken.gitkraken snap.gitkraken.url-handler 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apparmor 2.13.3-7ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckMismatches: ./casper/initrd CasperMD5CheckResult: skip CasperVersion: 1.445 Date: Tue Sep 22 21:21:08 2020 LiveMediaBuild: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdline: BOOT_IMAGE=/casper/vmlinuz persistent file=/cdrom/preseed/hostname.seed quiet splash --- SourcePackage: apparmor UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1896626/+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 1896632] [NEW] package lvm2 2.03.07-1ubuntu1 failed to install/upgrade: »installiertes lvm2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück
Public bug reported: I ve no idea what happend or why. The system reports me a bug, I thought I would send the information. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: lvm2 2.03.07-1ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60 Uname: Linux 5.4.0-48-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.8 AptOrdering: NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Mon Sep 21 22:17:26 2020 DpkgHistoryLog: Start-Date: 2020-09-21 22:17:25 Commandline: apt-get autoremove Requested-By: pietsch (1000) ErrorMessage: »installiertes lvm2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SourcePackage: lvm2 Title: package lvm2 2.03.07-1ubuntu1 failed to install/upgrade: »installiertes lvm2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: lvm2 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package focal -- 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/1896632 Title: package lvm2 2.03.07-1ubuntu1 failed to install/upgrade: »installiertes lvm2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück Status in lvm2 package in Ubuntu: New Bug description: I ve no idea what happend or why. The system reports me a bug, I thought I would send the information. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: lvm2 2.03.07-1ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60 Uname: Linux 5.4.0-48-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.8 AptOrdering: NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Mon Sep 21 22:17:26 2020 DpkgHistoryLog: Start-Date: 2020-09-21 22:17:25 Commandline: apt-get autoremove Requested-By: pietsch (1000) ErrorMessage: »installiertes lvm2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18rc1, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SourcePackage: lvm2 Title: package lvm2 2.03.07-1ubuntu1 failed to install/upgrade: »installiertes lvm2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1896632/+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 1895060] Re: [FFe] apparmor 3 upstream release
FYI, there was a components mismatch where apparmor-notify pulled python3-notify2 (and its Depends) into main. For now, I've demoted apparmor-notify to universe and adjusted the seed (in practical terms, the security team will fix bugs in apparmor-notify regardless of where it lives). We might revisit promoting apparmor-notify at a future date. -- 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/1895060 Title: [FFe] apparmor 3 upstream release Status in apparmor package in Ubuntu: Fix Committed Bug description: As per the draft upstream release notes[1]: AppArmor 3.0 is a major new release of the AppArmor user space that makes an important change to policy development and support. Its focus is transitioning policy to the new features ABI and as such other new features have been limited. Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the newer AppArmor 3 style policy which requires the declaration of a features abi. As such AppArmor 3.0 will be a short lived release, and will not receive long term support. The following AppArmor 3.1 feature release is planned to be a regular release, please take this into account when including AppArmor 3.0 into a distro release. As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3 to Ubuntu and provide these new capabilities to users and system administrators. The short support lifespan of Ubuntu 20.10 ensures that there is alignment with the limited support lifetime of AppArmor 3.0 from upstream, whilst giving good exposure and opportunity to test and exercise the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight of new features provided by AppArmor 3.0 include: - Policy now must declare the feature abi it was developed for if it is to use any new features. This ensures that old policy will not become incompatible with new kernels that support additional AppArmor features. - The use of profile names that are based on pathnames are deprecated. - Support for new kernel features (requires appropriate features abi tagging in policy) - upstream v8 network socket rules - xattr attachment conditionals - capabilities PERFMON and BPF - Improved compiler warnings and semantic checks - aa-status rewritten in C (previously was python) with additional features - supports use in systems/images where python is not available - supports kill, unconfined and mixed profile modes - Rewritten aa-notify (previously was perl, now python3) - shared backend with other python tools - support use of aa.CONFDIR instead of hard coded /etc/apparmor - improved message layout - Improved support for kernels that support LSM stacking - New utility aa-features-abi to extract and work with kernel abi features - New utility aa-load to load binary policy without calling the apparmor_parser - Support for profile modes - enforce (default when no mode flag is supplied) - kill (experimental) - unconfined (experimental) The use of the new AppArmor profile feature ABI includes a default configuration (for the Ubuntu packaged version of AppArmor proposed in this FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures that all profiles provided in AppArmor3 for groovy will conform to this feature set and that upgrades to the kernel version (say to 5.8) that may include newer AppArmor confinement features will not result in additional policy denials as a result (since say the existing profile did not specify a rule for a new AppArmor feature which is now supported by the upgraded kernel). This ensures that there will be no regressions in application behaviour as a result of AppArmor kernel feature upgrades. TESTING This has been extensively tested by the security team - this includes following the documented Ubuntu merges test plan[2] for AppArmor and the extensive QA Regression Tests[3] for AppArmor as well. This ensures that the various applications that make heavy use of AppArmor (LXD, docker, lxc, dbus, libvirt, snapd etc) have all been exercised and no regressions have been observed. All tests have passed and demonstrated both apparmor and the various applications that use it to be working as expected. BUILD LOGS This is currently uploaded to groovy-proposed, build logs can be found on Launchpad at: https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1 INSTALL LOG See attached (https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files /groovy-proposed-apparmor-install.log) for a log showing install of the packages from groovy-proposed [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0 [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor [3] https://gi
[Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
This bug was fixed in the package squid3 - 3.5.12-1ubuntu7.14 --- squid3 (3.5.12-1ubuntu7.14) xenial; urgency=medium * d/squid.resolvconf: Invoke "systemctl reload --no-block" if we are using systemd. This prevents squid from blocking if the reload action is being issued indirectly because of another service (e.g., because dnsmasq has been restarted), which may cause a deadlock and prevent the whole transaction to complete. (LP: #1761096) -- Sergio Durigan Junior Fri, 04 Sep 2020 08:31:36 -0400 ** Changed in: squid3 (Ubuntu Xenial) Status: Fix Committed => Fix Released -- 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/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in squid3 package in Ubuntu: Invalid Status in dnsmasq source package in Xenial: Invalid Status in squid source package in Xenial: Invalid Status in squid3 source package in Xenial: Fix Released Status in dnsmasq source package in Bionic: Invalid Status in squid source package in Bionic: Invalid Status in squid3 source package in Bionic: Incomplete Bug description: [Impact] When using dnsmasq along with squid on Ubuntu Xenial, the user will experience a deadlock while performing on every second execution of the "systemctl start dnsmasq.service" command. The deadlock will be caused by an attempt to invoke, by nss-lookup.target, a "systemctl reload squid.service", which will itself try to start the nss- lookup.target, which will be waiting on squid, therefore eventually leading to a timeout. The underlying cause of this deadlock is related to how systemd used to handle dependencies between multiple jobs being started in the same transaction. [Test Case] One can reproduce the issue on a Xenial container: $ lxc launch ubuntu-daily:xenial squid-bug1761096 $ lxc shell squid-bug1761096 # apt update # apt install squid dnsmasq -y It is quite possible that during "apt install" the bug will manifest, and dnsmasq will fail to start due to a timeout. The user might see a message like: Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. If the bug doesn't manifest itself during installation, the following commands in sequence should trigger it: # systemctl restart dnsmasq.service # systemctl restart dnsmasq.service [Regression Potential] This change only touches the mechanism by which squid has its configuration reloaded in case of a DNS resolver change. Because "systemctl reload --no-block" returns practically immediately, if squid's configuration file is invalid the user won't see any notifications. However, this behaviour is already present currently, because "systemctl reload squid" invokes "/etc/init.d/squid reload"; the user has to check "journalctl -u squid.service" if she wants to verify whether there were any failures during the reload. Other than that, and because systemctl will offload the service to the SysV script as usual (in the case of squid), I don't foresee any potential regressions. [Original Description] Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.servi
[Touch-packages] [Bug 1761096] Update Released
The verification of the Stable Release Update for squid3 has completed successfully and the package is now being 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 dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in squid3 package in Ubuntu: Invalid Status in dnsmasq source package in Xenial: Invalid Status in squid source package in Xenial: Invalid Status in squid3 source package in Xenial: Fix Released Status in dnsmasq source package in Bionic: Invalid Status in squid source package in Bionic: Invalid Status in squid3 source package in Bionic: Incomplete Bug description: [Impact] When using dnsmasq along with squid on Ubuntu Xenial, the user will experience a deadlock while performing on every second execution of the "systemctl start dnsmasq.service" command. The deadlock will be caused by an attempt to invoke, by nss-lookup.target, a "systemctl reload squid.service", which will itself try to start the nss- lookup.target, which will be waiting on squid, therefore eventually leading to a timeout. The underlying cause of this deadlock is related to how systemd used to handle dependencies between multiple jobs being started in the same transaction. [Test Case] One can reproduce the issue on a Xenial container: $ lxc launch ubuntu-daily:xenial squid-bug1761096 $ lxc shell squid-bug1761096 # apt update # apt install squid dnsmasq -y It is quite possible that during "apt install" the bug will manifest, and dnsmasq will fail to start due to a timeout. The user might see a message like: Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. If the bug doesn't manifest itself during installation, the following commands in sequence should trigger it: # systemctl restart dnsmasq.service # systemctl restart dnsmasq.service [Regression Potential] This change only touches the mechanism by which squid has its configuration reloaded in case of a DNS resolver change. Because "systemctl reload --no-block" returns practically immediately, if squid's configuration file is invalid the user won't see any notifications. However, this behaviour is already present currently, because "systemctl reload squid" invokes "/etc/init.d/squid reload"; the user has to check "journalctl -u squid.service" if she wants to verify whether there were any failures during the reload. Other than that, and because systemctl will offload the service to the SysV script as usual (in the case of squid), I don't foresee any potential regressions. [Original Description] Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Comple
[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
** Changed in: apparmor (Ubuntu) Status: Confirmed => In Progress ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: In Progress Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
Hi Eric, I just updated the changelog with a more detailed description per file. If it looks good to you for Groovy I'll update the stable releases too. Thanks! Mauricio -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
** Patch added: "groovy_cryptsetup_lp1879980_V3.debdiff" https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+attachment/5413208/+files/groovy_cryptsetup_lp1879980_V3.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1888352] Update Released
The verification of the Stable Release Update for apport has completed successfully and the package is now being 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 apport in Ubuntu. https://bugs.launchpad.net/bugs/1888352 Title: use builtin dump_acpi_tables.py in hookutils Status in Apport: New Status in OEM Priority Project: Fix Committed Status in apport package in Ubuntu: Fix Released Status in apport source package in Focal: Fix Released Status in apport source package in Groovy: Fix Released Bug description: 1. add apcidump to hookutils.py:attach_hardware and use the builtin dump_acpi_tables.py. 2. remove explicit acpidump from oem-getlogs to use the builtin one. 3. refine usage string in oem-getlogs. To SRU to focal: [Impact] * for OEM project, lts is been used. And collect log is important. With built-in tool to get acpidump, we don't need to install extra tool in the end-customer's machine. That make it much easier for the oem process. * By call built-in utility, we no lounger need to install extra tools to collect data that's both complete and convenient for HWE people to work on. [Test Case] * before this applied, run oem-getlog without install acpidump. we can't get the dump data. After this applied, we can just dump the data HWE need. * test step: install the new package, run sudo -E oem-getlogs [-c case_id] to get the use apport-unpack to unpack the apport file. check the acpidump file. HWE people know much better on check the acpidump file. Give the dump_acpi_tables.py just updated and SRUed by HWE/ACPI/UEFI expert, it's pretty safe to do so. [Regression Potential] * Given the modification change the way to collect log, even it failed, it won't break apport itself. Just the collected log might contain data not so valid. * Given acpidump mostly used by HWE/ACIP/UEFI expert, and they just reviewed and updated the dump_acpi_tables.py script, I believe it will have good quality. To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1888352/+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 1888352] Re: use builtin dump_acpi_tables.py in hookutils
This bug was fixed in the package apport - 2.20.11-0ubuntu27.9 --- apport (2.20.11-0ubuntu27.9) focal; urgency=medium [ YC Cheng ] * apport/apport/hookutils.py: add acpidump using built-in dump_acpi_tables.py. (LP: #1888352) * bin/oem-getlogs: add "-E" in the usage, since we'd like to talk to pulseaudio session and that need environment infomation. Also remove acpidump since we will use the one from hook. -- Brian Murray Wed, 02 Sep 2020 09:48:39 -0700 ** Changed in: apport (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1888352 Title: use builtin dump_acpi_tables.py in hookutils Status in Apport: New Status in OEM Priority Project: Fix Committed Status in apport package in Ubuntu: Fix Released Status in apport source package in Focal: Fix Released Status in apport source package in Groovy: Fix Released Bug description: 1. add apcidump to hookutils.py:attach_hardware and use the builtin dump_acpi_tables.py. 2. remove explicit acpidump from oem-getlogs to use the builtin one. 3. refine usage string in oem-getlogs. To SRU to focal: [Impact] * for OEM project, lts is been used. And collect log is important. With built-in tool to get acpidump, we don't need to install extra tool in the end-customer's machine. That make it much easier for the oem process. * By call built-in utility, we no lounger need to install extra tools to collect data that's both complete and convenient for HWE people to work on. [Test Case] * before this applied, run oem-getlog without install acpidump. we can't get the dump data. After this applied, we can just dump the data HWE need. * test step: install the new package, run sudo -E oem-getlogs [-c case_id] to get the use apport-unpack to unpack the apport file. check the acpidump file. HWE people know much better on check the acpidump file. Give the dump_acpi_tables.py just updated and SRUed by HWE/ACPI/UEFI expert, it's pretty safe to do so. [Regression Potential] * Given the modification change the way to collect log, even it failed, it won't break apport itself. Just the collected log might contain data not so valid. * Given acpidump mostly used by HWE/ACIP/UEFI expert, and they just reviewed and updated the dump_acpi_tables.py script, I believe it will have good quality. To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1888352/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
[sts-sponsors] Sponsored and uploaded into groovy. Let's now wait until the package lands in groovy-releases before proceeding with the SRU. Thanks mfo and gpiccoli for your contributions. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1886300] Re: rename.ul refuses to rename links that don't resolve (regression)
** Tags removed: sts-sponsor-mfo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1886300 Title: rename.ul refuses to rename links that don't resolve (regression) Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Focal: Fix Released Status in util-linux source package in Groovy: Fix Released Status in util-linux package in Debian: Fix Released Bug description: [Impact] rename.ul refuses to rename links that don't resolve. bionic rename.ul renames links whether or not they resolve (util-linux 2.31.1-0.4ubuntu3.6). focal rename.ul refuses to rename links that don't resolve (regression) (util-linux 2.34-0.1ubuntu9). Eoan is EOL, so removed. [Test case] Commit has good test case. I paste it here Before: $ touch file-found $ ln -s file-found symlink-1 $ ./rename sym symbolic- symlink-1 # XPASS. $ echo $? 0 $ ln -s file-not-found symlink-2 $ ./rename sym symbolic- symlink-2 # FAIL! REGRESSION. rename: symlink-2: not accessible: No such file or directory $ echo $? 1 $ ./rename sym symbolic- symlink-3 # XFAIL. rename: symlink-3: not accessible: No such file or directory $ echo $? 1 $ touch file-found $ ./rename found existing file-found# XPASS. $ echo $? 0 $ ./rename found existing file-not-found # XFAIL. rename: file-not-found: not accessible: No such file or directory $ echo $? 1 After: $ touch file-found $ ln -s file-found symlink-1 $ ./rename sym symbolic- symlink-1 # XPASS. $ echo $? 0 $ ln -s file-not-found symlink-2 $ ./rename sym symbolic- symlink-2 # PASS! REGRESSION FIXED. $ echo $? 0 $ ./rename sym symbolic- symlink-3 # XFAIL. rename: symlink-3: not accessible: No such file or directory $ echo $? 1 $ touch file-found $ ./rename found existing file-found# XPASS. $ echo $? 0 $ ./rename found existing file-not-found # XFAIL. rename: file-not-found: not accessible: No such file or directory $ echo $? 1 [Regression Potential] This commit changes code that checking accessibility to file or sym link. If this fails, rename command will not work properly.it could be crashed or causes failure of rename. [Original Description] rename.ul refuses to rename links that don't resolve. bionic rename.ul renames links whether or not they resolve (util-linux 2.31.1-0.4ubuntu3.6). focal rename.ul refuses to rename links that don't resolve (regression) (util-linux 2.34-0.1ubuntu9). ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: util-linux 2.34-0.1ubuntu9 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.3 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat Jul 4 20:38:06 2020 InstallationDate: Installed on 2020-04-05 (90 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200331) ProcEnviron: LC_TIME=en_DK.utf8 TERM=screen PATH=(custom, no user) LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1886300/+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 1870316] Re: 'sudo hwclock -s' fails with 'settimeofday() failed: Invalid argument'
** Tags removed: sts-sponsor-mfo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1870316 Title: 'sudo hwclock -s' fails with 'settimeofday() failed: Invalid argument' Status in util-linux package in Ubuntu: Fix Released Status in util-linux package in Debian: Fix Released Bug description: In Focal VM. util-linux: 2.34-0.1ubuntu8 $ sudo hwclock -s [sudo] password for focal: hwclock: settimeofday() failed: Invalid argument Result should be syncing the time to the RTC, which until recently (possibly before glibc update) worked. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: util-linux 2.34-0.1ubuntu8 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 Uname: Linux 5.4.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu22 Architecture: amd64 CurrentDesktop: KDE Date: Thu Apr 2 11:20:45 2020 InstallationDate: Installed on 2019-12-24 (99 days ago) InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20191224) SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1870316/+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 1858802] Re: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device
** Tags removed: sts-sponsor-mfo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1858802 Title: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Fix Released Status in util-linux source package in Bionic: Fix Released Status in util-linux source package in Disco: Won't Fix Status in util-linux source package in Eoan: Fix Released Status in util-linux source package in Focal: Fix Released Status in util-linux package in Debian: Fix Released Bug description: [Impact] * Users with an XFS filesystem on top of bcache (this is seen on some ceph, cloud deployments) might fail to reference the bcache device by UUID or other udev properties. * The journal of the regular XFS filesystem in the bcache device is incorrectly detected as an XFS external log; so two superblocks are detected (bcache and xfs_external_log). * Thus blkid fails with ambivalent superblocks detected then doesn't provide the usual udev properties (UUID, etc.) * The fix improves the probe function for XFS external log so it detects it's regular XFS and bails out. [Test Case] * See test steps detailed in comment #7 and later. - Create an XFS filesystem with the journal/log in the beginning of the bcache device (< 256K). - Stop the bcache device. - Run '$ blkid -o udev -p $BCACHE_BACKING_DEVICE'. $ sudo make-bcache -B $BACKING_DEV $ sudo mkfs.xfs -d agsize=16m -l agnum=0 -f $BCACHE_DEV $ echo 1 | sudo tee /sys/block/$(basename $BCACHE_DEV)/bcache/stop $ sudo blkid -o udev -p $BACKING_DEV [Regression Potential] * The patch only changes the detection function for XFS external log to be more general about the sector where the magic of regular XFS may be found (which is shifted inside the bcache.) * It still checks at sector zero (the only one checked previously), so this behavior didn't change. * Possible regressions are actual XFS external log devices that are not anymore detected as such. (Although that would probably indicate a different bug in libblkid.) [Other Info] * upstream commit: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858802/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
** Tags added: sts-sponsor-mfo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1862846] Re: Crash and failure installing focal
** Tags removed: sts-sponsor-mfo
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1862846
Title:
Crash and failure installing focal
Status in subiquity:
Fix Released
Status in curtin package in Ubuntu:
Fix Released
Status in util-linux package in Ubuntu:
Fix Released
Status in curtin source package in Eoan:
Invalid
Status in util-linux source package in Eoan:
Fix Released
Status in curtin source package in Focal:
Fix Released
Status in util-linux source package in Focal:
Fix Released
Status in util-linux package in Debian:
Fix Released
Bug description:
[Impact]
* lsblk no longer prints a partition's parent
kernel device name (the wholedisk).
(i.e., 'lsblk -no PKNAME /dev/partition')
* Another impact is the 'removable media' check
always return zero for partitions.
(i.e., 'lsblk -no RM /dev/partition')
* The regression was introduced on v2.34, only
Eoan (v2.34) and later are affected.
Disco (v2.33) and earlier are not affected.
* The regression is fixed in v2.35, in commit
e3bb9bfb76c1 ("lsblk: force to print PKNAME
for partition"); fixes RM for partition too.
[Test Case]
* $ lsblk -no PKNAME /dev/vda1 # partition
* Expected output: vda # wholedisk
* Current output: (nothing)
* $ lsblk -no RM /dev/sdb1 # partition in removable disk
* Expected output: 1 # removable media
* Current output: 0 # not removable media
[Regression Potential]
* Columns that depend on a partition device's
parent device (i.e., seen as 'wholedisk')
could in theory show incorrect values if
another bug is present in v2.34 for that.
* Other usages of 'parent' pointer in the
function have been examined and reported
(e.g. issue w/ removable media column),
and others found to not have issues
(e.g. --merge option, to group multiple
parents of a device, as in RAID.)
[Other Info]
* The impacts to the curtin source package
have been addressed in other way, it no
longer requires util-linux, comment #14.
* util-linux github issue:
https://github.com/karelzak/util-linux/issues/813
[Original Bug Description]
During an install of the daily live image for 20.04 Ubuntu Server, the
installer first crashed and restarted itself, then failed to install
the system.
Attached are the logs left on the install USB key.
To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1862846/+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 1865504] Re: hwclock reports incorrect status in audit message
** Tags removed: sts-sponsor-mfo
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1865504
Title:
hwclock reports incorrect status in audit message
Status in util-linux package in Ubuntu:
Fix Released
Status in util-linux source package in Bionic:
Fix Released
Status in util-linux source package in Eoan:
Fix Released
Status in util-linux package in Debian:
Confirmed
Bug description:
[Impact]
hwclock reports incorrect status in audit message:
- hwclock calls audit_log_user_message(3) to create an audit entry.
- audit_log_user_message(3) result 1 is "success" and 0 is "failed".
- hwclock use standard EXIT_{SUCCESS,FAILURE} macros with reverse status.
- Thus reports its status incorrectly in audit message.
It is a requirement for Common Criteria Certification that hwclock
reports correct status in audit message.
This has been fixed upstream in https://github.com/karelzak/util-
linux/commit/189edf1fe501ea39b35911337eab1740888fae7a
[Test Steps]
Steps to test:
1. Install auditd
2. Run following testcase,
# hwclock
2020-03-02 15:03:03.280351+
# hwclock --set --date "1/1/2000 00:00:00"
# echo $?
0
# hwclock
2000-01-01 00:00:05.413924+
# hwclock --utc --systohc
# echo $?
0
# hwclock
2020-03-02 15:07:00.264331+
Following audit messages from /var/log/audit/audit.log,
Note that last field in each audit record produced when hardware clock
was modified has, "res=failed". Although, testcase shows no* failure
occurred.
type=USYS_CONFIG msg=audit(1583161562.884:105): pid=2084 uid=0
auid=1000 ses=1 msg='op=change-system-time exe="/sbin/hwclock"
hostname=bionic-fips addr=? terminal=pts/0 res=failed'
type=USYS_CONFIG msg=audit(1583161614.497:106): pid=2103 uid=0
auid=1000 ses=1 msg='op=change-system-time exe="/sbin/hwclock"
hostname=bionic-fips addr=? terminal=pts/0 res=failed'
[Regression Potential]
Changes limited to the result value passed to audit_log_user_message(3),
so the audit messages will change the 'res=' field (to correct result.)
There should not be any regression to fix the status given to auditd.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1865504/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
Thanks a bunch mfo!! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+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 1891657] Re: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit'
This is growing my syslog file like crazy. Often running out of space in /var partition (yes, I have a different partition for this). Deleting the files /var/crash/ stops this. Restarts again after a reboot. -- 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/1891657 Title: systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit' Status in apport package in Ubuntu: Confirmed Status in systemd package in Ubuntu: In Progress Status in apport source package in Groovy: Confirmed Status in systemd source package in Groovy: In Progress Bug description: after upgrade from Ubuntu 20.04 to 20.10 seeing systemd use 100% cpu forever top top - 10:16:19 up 20 min, 1 user, load average: 3.91, 4.28, 3.39 Tasks: 332 total, 2 running, 330 sleeping, 0 stopped, 0 zombie %Cpu(s): 18.7 us, 6.4 sy, 11.9 ni, 62.2 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st MiB Mem : 15917.6 total, 8553.4 free, 2604.3 used, 4759.9 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 12633.7 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 177316 12252 8684 R 100.0 0.1 15:01.25 systemd 4636 kush 39 19 633796 176152 16360 S 98.3 1.1 17:51.56 tracker-miner-f 820 message+ 20 0 10740 6452 4212 S 39.8 0.0 6:19.06 dbus-daemon 316 root 19 -1 535916 322896 320824 S 15.3 2.0 3:16.41 systemd-journal 844 syslog20 0 221136 5840 3920 S 13.6 0.0 2:14.52 rsyslogd 858 root 20 0 83708 74124 7568 S 12.7 0.5 2:06.98 systemd-logind 5 root 20 0 0 0 0 I 3.4 0.0 0:05.01 kworker/0:0-events 35566 kush 20 0 3850088 588344 262192 S 2.5 3.6 0:30.48 MainThread 5626 kush 20 0 5004788 260876 93400 S 1.7 1.6 3:05.19 gnome-shell 7033 kush 20 0 869792 66440 44272 S 1.7 0.4 0:06.05 gnome-terminal- 36790 kush 20 0 2525432 156636 98568 S 1.7 1.0 0:04.99 Web Content 957 root 20 0 1556196 45044 24284 S 0.8 0.3 0:02.48 containerd 1038 root 20 0 10460 4412 3300 S 0.8 0.0 0:00.16 fancontrol sudo tail -n 100 /var/log/syslog Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'. Aug 14 10:14:17 lhotse systemd[1]: Failed to start Process error reports when automatic reporting is enabled. Aug 14 10:14:17 lhotse systemd[1]: apport-autoreport.service: Start request repeated too quickly. Aug 14 10:14:17 lhotse syst
[Touch-packages] [Bug 1882098] Re: Packagekit lets user install untrusted local packages in Bionic and Focal
Please use CVE-2020-16122 for this issue. Thanks. ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-16122 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1882098 Title: Packagekit lets user install untrusted local packages in Bionic and Focal Status in packagekit package in Ubuntu: Triaged Bug description: We have packagekit configured to allow users to install trusted packages from preconfigured repositories, but disallowed them to install any untrusted packages. The policykit configuration we use is following: [tld.univ.packagekit] Identity=unix-group:adm; Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system; ResultAny=auth_self ResultActive=auth_self ResultInactive=auth_self [tld.univ.packagekit-deny] Identity=unix-user:*; Action=org.freedesktop.packagekit.package-install-untrusted; ResultAny=no We would expect this to prevent users from installing local packages downloaded from random repositories, however this does not seem to be the case. pkcon install-local random_package.deb will happily prompt for the user to authenticate and will install the package, while pkcon --allow-untrusted install-local random_package.deb will prompt for root password, which the user does not have. Our initial toughts was that the issue would be in packagekitd, but after further investigations it looks like the issue could be in aptcc backend. We are more than happy to provide you with further details, but the above should be enough to reproduce the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1882098/+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 1896644] [NEW] Dual screen window size problem
Public bug reported: Certain programs don't seem to co-operate well with a dual monitor setup. If it is of any importance, my setup is a laptop with a TV plugged in via HDMI. So far I've found that VLC media player and Oracle Virtualbox won't play nicely with two monitors. When both monitors are in use, virtualbox crashes before it can open, and vlc tends to freeze the entire system, requiring a hard reboot. If I run these programs while only one monitor is being used and plug in the second one, they'll start misbehaving if moved to the other monitor. virtualbox and vlc will both become way too huge to be usable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-generic 5.4.55 Uname: Linux 5.4.0-47-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Sep 22 12:02:21 2020 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company HD Graphics 620 [103c:8364] InstallationDate: Installed on 2020-02-21 (214 days ago) InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1) MachineType: HP HP Pavilion Laptop 15-cc0xx ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= PATH=(custom, no user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-47-generic root=UUID=da68f1b9-ec5f-4962-8098-08f28713396e ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/03/2017 dmi.bios.vendor: Insyde dmi.bios.version: F.13 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 8364 dmi.board.vendor: HP dmi.board.version: 46.23 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnInsyde:bvrF.13:bd11/03/2017:svnHP:pnHPPavilionLaptop15-cc0xx:pvrType1ProductConfigId:rvnHP:rn8364:rvr46.23:cvnHP:ct10:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Pavilion dmi.product.name: HP Pavilion Laptop 15-cc0xx dmi.product.sku: 1KU17UA#ABA dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ubuntu ** Attachment added: "Screen recordings of some of the issues" https://bugs.launchpad.net/bugs/1896644/+attachment/5413216/+files/multiple-screen-problem.tar.xz -- 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/1896644 Title: Dual screen window size problem Status in xorg package in Ubuntu: New Bug description: Certain programs don't seem to co-operate well with a dual monitor setup. If it is of any importance, my setup is a laptop with a TV plugged in via HDMI. So far I've found that VLC media player and Oracle Virtualbox won't play nicely with two monitors. When both monitors are in use, virtualbox crashes before it can open, and vlc tends to freeze the entire system, requiring a hard reboot. If I run these programs while only one monitor is being used and plug in the second one, they'll start misbehaving if moved to the other monitor. virtualbox and vlc will both become way too huge to be usable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-generic 5.4.55 Uname: Linux 5.4.0-47-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Sep 22 12:02:21 2020 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company HD Graphics 620 [103c:8364] InstallationDate: Installed on 2020-02-21 (214 days ago) InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1) MachineType: HP HP Pavilion Laptop 15-cc0xx ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash TERM=xterm-256color XDG_RUN
[Touch-packages] [Bug 1896645] [NEW] Dual screen window size problem
Public bug reported: Certain programs don't seem to co-operate well with a dual monitor setup. If it is of any importance, my setup is a laptop with a TV plugged in via HDMI. So far I've found that VLC media player and Oracle Virtualbox won't play nicely with two monitors. When both monitors are in use, virtualbox crashes before it can open, and vlc tends to freeze the entire system, requiring a hard reboot. If I run these programs while only one monitor is being used and plug in the second one, they'll start misbehaving if moved to the other monitor. virtualbox and vlc will both become way too huge to be usable. Description:Ubuntu 18.04.5 LTS Release:18.04 xorg: Installed: 1:7.7+19ubuntu7.1 Candidate: 1:7.7+19ubuntu7.1 Version table: *** 1:7.7+19ubuntu7.1 500 500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:7.7+19ubuntu7 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-generic 5.4.55 Uname: Linux 5.4.0-47-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Sep 22 12:02:21 2020 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company HD Graphics 620 [103c:8364] InstallationDate: Installed on 2020-02-21 (214 days ago) InstallationMedia: Ubuntu 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1) MachineType: HP HP Pavilion Laptop 15-cc0xx ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= PATH=(custom, no user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-47-generic root=UUID=da68f1b9-ec5f-4962-8098-08f28713396e ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/03/2017 dmi.bios.vendor: Insyde dmi.bios.version: F.13 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 8364 dmi.board.vendor: HP dmi.board.version: 46.23 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnInsyde:bvrF.13:bd11/03/2017:svnHP:pnHPPavilionLaptop15-cc0xx:pvrType1ProductConfigId:rvnHP:rn8364:rvr46.23:cvnHP:ct10:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Pavilion dmi.product.name: HP Pavilion Laptop 15-cc0xx dmi.product.sku: 1KU17UA#ABA dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ubuntu ** Attachment added: "Screen recordings of some of the issues" https://bugs.launchpad.net/bugs/1896645/+attachment/5413232/+files/multiple-screen-problem.tar.xz -- 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/1896645 Title: Dual screen window size problem Status in xorg package in Ubuntu: New Bug description: Certain programs don't seem to co-operate well with a dual monitor setup. If it is of any importance, my setup is a laptop with a TV plugged in via HDMI. So far I've found that VLC media player and Oracle Virtualbox won't play nicely with two monitors. When both monitors are in use, virtualbox crashes before it can open, and vlc tends to freeze the entire system, requiring a hard reboot. If I run these programs while only one monitor is being used and plug in the second one, they'll start misbehaving if moved to the other monitor. virtualbox and vlc will both become way too huge to be usable. Description: Ubuntu 18.04.5 LTS Release: 18.04 xorg: Installed: 1:7.7+19ubuntu7.1 Candidate: 1:7.7+19ubuntu7.1 Version table: *** 1:7.7+19ubuntu7.1 500 500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:7.7+19ubuntu7 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.4.0-47.51~18.04.1-generi
[Touch-packages] [Bug 1894606] Re: [SRU] Add profile-set for HP Thunderbolt Dock
This bug was fixed in the package pulseaudio - 1:13.99.1-1ubuntu11 --- pulseaudio (1:13.99.1-1ubuntu11) groovy; urgency=medium [ Kai-Heng Feng ] * d/p/0001-alsa-mixer-Add-support-for-HP-Thunderbolt-Dock.patch * d/p/0002-alsa-mixer-Expand-comments-in-the-HP-Thunderbolt-Doc.patch Add profile-sets for HP Thunderbolt Dock (LP: #1894606) -- Alberto Milone Tue, 22 Sep 2020 10:09:09 +0200 ** Changed in: pulseaudio (Ubuntu Groovy) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1894606 Title: [SRU] Add profile-set for HP Thunderbolt Dock Status in HWE Next: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: In Progress Status in pulseaudio source package in Groovy: Fix Released Bug description: [Impact] HP Thunderbolt Dock has a USB audio device provides headset connector functionality. The Dock can also attach an optional USB audio module. Since they are both USB audio device, the input/output names are the same and it confuses user. [Fix] Add PulseAudio profile-sets for each USB device with different monikers. The merge request is already approved by maintainer, will be merged after 14.0 release: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/353 [Test] With profile-set applied, two different USB audio device on HP TBT Dock have distinctive names. [Regression Potential] Currently I can't think of any regression risk, as this SRU only adds new profile-sets and description translation. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1894606/+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 1871148] Re: services start before apparmor profiles are loaded
This was fixed in snapd in 2.44 via https://github.com/snapcore/snapd/pull/8467 ** Changed in: snapd (Ubuntu) Status: In Progress => Fix Released ** Changed in: snapd (Ubuntu Focal) Status: In Progress => 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/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in snapd: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in snapd package in Ubuntu: Fix Released Status in zsys package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Released Status in snapd source package in Focal: Fix Released Status in zsys source package in Focal: Invalid Bug description: Per discussion with Zyga in #snapd on Freenode, I have hit a race condition where services are being started by the system before apparmor has been started. I have a complete log of my system showing the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/. Restarting apparmor using `sudo systemctl restart apparmor` is enough to bring installed snaps back to full functionality. Previously, when running any snap I would receive the following in the terminal: --- cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1: File exists --- Updated to add for Jamie: $ snap version snap2.44.2+20.04 snapd 2.44.2+20.04 series 16 ubuntu 20.04 kernel 5.4.0-21-generic To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
I uploaded 3.0.0~beta1-0ubuntu6 just now that should address this issue. Thanks Christian for your debugging! ** Changed in: apparmor (Ubuntu) Status: In Progress => Fix Committed -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Fix Committed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1896646] [NEW] bluetooth no longer installed
You have been subscribed to a public bug: 22 september 2020 update removed bluetooth capability. No Bluetooth hardware detected by system, cannot turn on or add devices. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 5.4.0-49.53-generic 5.4.65 Uname: Linux 5.4.0-49-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.9 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Sep 22 12:53:31 2020 InstallationDate: Installed on 2019-12-07 (290 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) InterestingModules: bluetooth Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0bda:57de Realtek Semiconductor Corp. USB2.0 VGA UVC WebCam Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M |__ Port 5: Dev 2, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M |__ Port 6: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 6: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M MachineType: ASUSTeK COMPUTER INC. X556UAM ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-49-generic root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/06/2016 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X556UAM.305 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X556UAM dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: ATN12345678901234567 dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX556UAM.305:bd07/06/2016:svnASUSTeKCOMPUTERINC.:pnX556UAM:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX556UAM:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.family: X dmi.product.name: X556UAM dmi.product.sku: ASUS-NotebookSKU dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. hciconfig: rfkill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no ** Affects: bluez (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- bluetooth no longer installed https://bugs.launchpad.net/bugs/1896646 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1896646] Re: bluetooth no longer installed
** Package changed: ubuntu => bluez (Ubuntu) -- 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/1896646 Title: bluetooth no longer installed Status in bluez package in Ubuntu: New Bug description: 22 september 2020 update removed bluetooth capability. No Bluetooth hardware detected by system, cannot turn on or add devices. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: bluetooth (not installed) ProcVersionSignature: Ubuntu 5.4.0-49.53-generic 5.4.65 Uname: Linux 5.4.0-49-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.9 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Sep 22 12:53:31 2020 InstallationDate: Installed on 2019-12-07 (290 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) InterestingModules: bluetooth Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0bda:57de Realtek Semiconductor Corp. USB2.0 VGA UVC WebCam Bus 001 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M |__ Port 5: Dev 2, If 0, Class=Vendor Specific Class, Driver=rtsx_usb, 480M |__ Port 6: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 6: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M MachineType: ASUSTeK COMPUTER INC. X556UAM ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-49-generic root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/06/2016 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X556UAM.305 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X556UAM dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: ATN12345678901234567 dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX556UAM.305:bd07/06/2016:svnASUSTeKCOMPUTERINC.:pnX556UAM:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX556UAM:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.family: X dmi.product.name: X556UAM dmi.product.sku: ASUS-NotebookSKU dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. hciconfig: rfkill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1896646/+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 1890716] Re: xdg-mime query filetype index.html reports wrong type
After running that commands I got the following output: $ ... Running kmimetypefinder5 "/home/alex/Desktop/index.html" application/x-perl It seems like that kmimetypefinder5 is major culprit here. I've found another unrelated bugreport here which was reported about a year ago: https://bugs.launchpad.net/ubuntu/+source/kde-cli-tools/+bug/1857824 In that case the program reports wrong type for *.py files with correct content. Weird! I think it's wortht to rename this bugreport. ** Summary changed: - xdg-mime query filetype index.html reports wrong type + kmimetypefinder5 *.html reports wrong type -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shared-mime-info in Ubuntu. https://bugs.launchpad.net/bugs/1890716 Title: kmimetypefinder5 *.html reports wrong type Status in shared-mime-info package in Ubuntu: Incomplete Bug description: For .html files `xdg-mime` reports wrong type. The culprit is the `"use strict"` phrase which is used in JavaScript. It should not mistake .html files for anything else except of text/html ! STEPS TO REPRODUCE: Run the following step by step in any folder: 1. $ echo "\"use strict\"" > index.html 2. $ xdg-mime query filetype index.html # -> application/x-perl - this should be text/html! Platform: Ubuntu 20.04.1 LTS (Focal Fossa)" Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) xdg-utils: 1.1.3-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1894881] Re: [XPS 13 9300, Realtek ALC289, Speaker, Internal] Pulseaudio fails to detect card
problem seems gone since 5.4.0-48-generic #52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1894881 Title: [XPS 13 9300, Realtek ALC289, Speaker, Internal] Pulseaudio fails to detect card Status in linux package in Ubuntu: Incomplete Status in pulseaudio package in Ubuntu: Confirmed Bug description: kernel 5.4.0-47-generic #51 upgraded today to this new kernel sound is now totally broken kern.org and syslog are filling with those messages every second, in loop, with no end to it : Sep 8 19:42:34 orion kernel: [ 147.398030] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20970500 Sep 8 19:42:35 orion kernel: [ 148.410043] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20a70500 Sep 8 19:42:36 orion kernel: [ 149.413955] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20b70500 Sep 8 19:42:37 orion kernel: [ 150.421890] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 Sep 8 19:42:38 orion kernel: [ 151.453799] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x204f0015 Sep 8 19:42:39 orion kernel: [ 152.461793] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x204f0015 Sep 8 19:42:41 orion kernel: [ 153.473734] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x2043b000 Sep 8 19:42:42 orion kernel: [ 154.477653] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20470740 Sep 8 19:42:43 orion kernel: [ 155.481576] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x204f0015 Sep 8 19:42:44 orion kernel: [ 156.489620] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x204f0015 Sep 8 19:42:45 orion kernel: [ 157.497553] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x2043b000 Sep 8 19:42:46 orion kernel: [ 158.509530] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20470740 Sep 8 19:42:47 orion kernel: [ 159.513471] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x204f0015 Because of this, machine has become very slow and response time is awful Login into the machine, even trying to launch a simple program can take up to 30 seconds of wait before anything happens. Sound was working fine with previous kernel. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: pulseaudio 1:13.99.1-1ubuntu3.6 ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55 Uname: Linux 5.4.0-47-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: gf 1758 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Tue Sep 8 19:42:19 2020 InstallationDate: Installed on 2020-08-29 (9 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: pulseaudio Symptom: audio Symptom_Card: HDA-Intel - HDA Intel PCH Symptom_Jack: Speaker, Internal Title: [XPS 13 9300, Realtek ALC289, Speaker, Internal] Pulseaudio fails to detect card UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/07/2020 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.1.0 dmi.board.name: 077Y9N dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.1.0:bd07/07/2020:svnDellInc.:pnXPS139300:pvr:rvnDellInc.:rn077Y9N:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: XPS dmi.product.name: XPS 13 9300 dmi.product.sku: 096D dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894881/+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 1756238] Re: gdebi-gtk broken in 18.04 error: unable to read filedescriptor flags
In groovy the code for vte-keep-FD patch has been refactored to support new upstream code. However, I think it's the time we plan to remove this next cycle, given that gdebi is the only project using it so far [1], and that upstream already suggested a better way to do it [2]. So, if someone is still interested in fixing gdebi to address this, please act as otherwise it's very likely that next versions of vte will break it. [1] https://codesearch.debian.net/search?q=VTE_PTY_KEEP_FD&literal=1 [2] https://bugzilla.gnome.org/show_bug.cgi?id=320128#c23 ** Bug watch added: bugzilla.gnome.org/ #320128 https://bugzilla.gnome.org/show_bug.cgi?id=320128 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdebi in Ubuntu. https://bugs.launchpad.net/bugs/1756238 Title: gdebi-gtk broken in 18.04 error: unable to read filedescriptor flags Status in gdebi package in Ubuntu: Triaged Status in vte2.91 package in Ubuntu: Fix Released Status in vte2.91 source package in Bionic: Fix Released Bug description: When using gdebi-gtk to install a .deb the install fails with the message:- dpkg: error: unable to read filedescriptor flags for : Bad file descriptor This only occurs via the gdebi-gtk GUI front end, packages install perfectly if done via the CLI with: sudo gdebi /path/to/packagename.deb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/1756238/+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 1890716] Re: kmimetypefinder5 *.html reports wrong type
I've reported a new bug providing a complete and correct description: https://bugs.launchpad.net/ubuntu/+source/kde-cli-tools/+bug/1896682 This one can be safely closed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shared-mime-info in Ubuntu. https://bugs.launchpad.net/bugs/1890716 Title: kmimetypefinder5 *.html reports wrong type Status in shared-mime-info package in Ubuntu: Invalid Bug description: For .html files `xdg-mime` reports wrong type. The culprit is the `"use strict"` phrase which is used in JavaScript. It should not mistake .html files for anything else except of text/html ! STEPS TO REPRODUCE: Run the following step by step in any folder: 1. $ echo "\"use strict\"" > index.html 2. $ xdg-mime query filetype index.html # -> application/x-perl - this should be text/html! Platform: Ubuntu 20.04.1 LTS (Focal Fossa)" Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) xdg-utils: 1.1.3-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1890716] Re: kmimetypefinder5 *.html reports wrong type
New bug reopened with complete and correct explanation: https://bugs.launchpad.net/ubuntu/+source/kde-cli-tools/+bug/1896682 ** Changed in: shared-mime-info (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shared-mime-info in Ubuntu. https://bugs.launchpad.net/bugs/1890716 Title: kmimetypefinder5 *.html reports wrong type Status in shared-mime-info package in Ubuntu: Invalid Bug description: For .html files `xdg-mime` reports wrong type. The culprit is the `"use strict"` phrase which is used in JavaScript. It should not mistake .html files for anything else except of text/html ! STEPS TO REPRODUCE: Run the following step by step in any folder: 1. $ echo "\"use strict\"" > index.html 2. $ xdg-mime query filetype index.html # -> application/x-perl - this should be text/html! Platform: Ubuntu 20.04.1 LTS (Focal Fossa)" Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) xdg-utils: 1.1.3-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1890716/+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 1732962] Re: apport uses sys.argv instead of named arguments
** Patch removed: "diff for xenial to support named param. (backport from
cosmic)"
https://bugs.launchpad.net/apport/+bug/1732962/+attachment/5405275/+files/apport_2.20.1-0ubuntu2.25.debdiff
** Patch removed: "diff for bionic to support named param. (backport from
cosmic)"
https://bugs.launchpad.net/apport/+bug/1732962/+attachment/5405276/+files/apport_2.20.9-0ubuntu7.18.debdiff
** Patch added: "diff for xenial to support named param. (backport from cosmic)"
https://bugs.launchpad.net/apport/+bug/1732962/+attachment/5413348/+files/apport_2.20.1-0ubuntu2.25.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732962
Title:
apport uses sys.argv instead of named arguments
Status in Apport:
Fix Committed
Status in apport package in Ubuntu:
Fix Released
Status in apport source package in Trusty:
Won't Fix
Status in apport source package in Xenial:
In Progress
Status in apport source package in Bionic:
In Progress
Status in apport source package in Cosmic:
Won't Fix
Status in apport source package in Disco:
Fix Released
Bug description:
SRU Description
[Impact]
data/apport which processes core files expects a certain quantity of
arguments in a specific order. This ended up causing an issue with some
security updates where we were trying to support a new version of apport on a
host system and one inside a container.
This SRU for xenial and bionic based on the work made in cosmic enabled
proper handling of named argument.
Note that this is disabled for now on ALL series
[Test Case]
No real test here since apport general behavior should be unchanged Just to
check that the feature is disable, /proc/sys/kernel/core_pattern
content should remain unchanged :
$> cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c %d %P %E
[Regression Potential]
The new feature is not enabled so the regression risk is fairly low. this
will take place in a future coordinated SRU across all LTS but in the meanwhile
we can make sure that there's no regression by running apport with various
End SRU Description
data/apport which processes core files expects a certain quantity of
arguments in a specific order. This ended up causing an issue with
some security updates where we were trying to support a new version of
apport on a host system and one inside a container. Here's something
of an example:
347 # Normal startup
348 if len(sys.argv) not in (5, 6):
349 try:
350 print('Usage: %s [global pid]' % sys.argv[0])
351 print('The core dump is read from stdin.')
We could not maintain backwards compatibility because "global pid" is
an optional argument and "dump mode" was a new argument. So if there
were five arguments its possible the last one was "dump mode" (no
global pid) or "global pid" (no support for dump mode).
Its possible to use strings in /proc/sys/kernel/core_pattern so we
could use those and have apport accept named arguments e.g:
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport --pid=%p --signal=%s --core-size=%c --dump-mode=%d
--global-pid=%P
['/home/bdmurray/source-trees/apport/artful/data/apport', '--
pid=5870', '--signal=11', '--core-size=0', '--dump-mode=1', '--global-
pid=5870']
Tyler said "that's probably a nice cleanup to make no matter what
because the magic arg ordering is dangerous".
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1732962/+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 1732962] Re: apport uses sys.argv instead of named arguments
Updated debdiff and made sure autopkgtest were successful on both xenial
and bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732962
Title:
apport uses sys.argv instead of named arguments
Status in Apport:
Fix Committed
Status in apport package in Ubuntu:
Fix Released
Status in apport source package in Trusty:
Won't Fix
Status in apport source package in Xenial:
In Progress
Status in apport source package in Bionic:
In Progress
Status in apport source package in Cosmic:
Won't Fix
Status in apport source package in Disco:
Fix Released
Bug description:
SRU Description
[Impact]
data/apport which processes core files expects a certain quantity of
arguments in a specific order. This ended up causing an issue with some
security updates where we were trying to support a new version of apport on a
host system and one inside a container.
This SRU for xenial and bionic based on the work made in cosmic enabled
proper handling of named argument.
Note that this is disabled for now on ALL series
[Test Case]
No real test here since apport general behavior should be unchanged Just to
check that the feature is disable, /proc/sys/kernel/core_pattern
content should remain unchanged :
$> cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c %d %P %E
[Regression Potential]
The new feature is not enabled so the regression risk is fairly low. this
will take place in a future coordinated SRU across all LTS but in the meanwhile
we can make sure that there's no regression by running apport with various
End SRU Description
data/apport which processes core files expects a certain quantity of
arguments in a specific order. This ended up causing an issue with
some security updates where we were trying to support a new version of
apport on a host system and one inside a container. Here's something
of an example:
347 # Normal startup
348 if len(sys.argv) not in (5, 6):
349 try:
350 print('Usage: %s [global pid]' % sys.argv[0])
351 print('The core dump is read from stdin.')
We could not maintain backwards compatibility because "global pid" is
an optional argument and "dump mode" was a new argument. So if there
were five arguments its possible the last one was "dump mode" (no
global pid) or "global pid" (no support for dump mode).
Its possible to use strings in /proc/sys/kernel/core_pattern so we
could use those and have apport accept named arguments e.g:
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport --pid=%p --signal=%s --core-size=%c --dump-mode=%d
--global-pid=%P
['/home/bdmurray/source-trees/apport/artful/data/apport', '--
pid=5870', '--signal=11', '--core-size=0', '--dump-mode=1', '--global-
pid=5870']
Tyler said "that's probably a nice cleanup to make no matter what
because the magic arg ordering is dangerous".
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1732962/+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 1732962] Re: apport uses sys.argv instead of named arguments
** Patch added: "diff for bionic to support named param. (backport from cosmic)"
https://bugs.launchpad.net/apport/+bug/1732962/+attachment/5413349/+files/apport_2.20.9-0ubuntu7.18.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732962
Title:
apport uses sys.argv instead of named arguments
Status in Apport:
Fix Committed
Status in apport package in Ubuntu:
Fix Released
Status in apport source package in Trusty:
Won't Fix
Status in apport source package in Xenial:
In Progress
Status in apport source package in Bionic:
In Progress
Status in apport source package in Cosmic:
Won't Fix
Status in apport source package in Disco:
Fix Released
Bug description:
SRU Description
[Impact]
data/apport which processes core files expects a certain quantity of
arguments in a specific order. This ended up causing an issue with some
security updates where we were trying to support a new version of apport on a
host system and one inside a container.
This SRU for xenial and bionic based on the work made in cosmic enabled
proper handling of named argument.
Note that this is disabled for now on ALL series
[Test Case]
No real test here since apport general behavior should be unchanged Just to
check that the feature is disable, /proc/sys/kernel/core_pattern
content should remain unchanged :
$> cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c %d %P %E
[Regression Potential]
The new feature is not enabled so the regression risk is fairly low. this
will take place in a future coordinated SRU across all LTS but in the meanwhile
we can make sure that there's no regression by running apport with various
End SRU Description
data/apport which processes core files expects a certain quantity of
arguments in a specific order. This ended up causing an issue with
some security updates where we were trying to support a new version of
apport on a host system and one inside a container. Here's something
of an example:
347 # Normal startup
348 if len(sys.argv) not in (5, 6):
349 try:
350 print('Usage: %s [global pid]' % sys.argv[0])
351 print('The core dump is read from stdin.')
We could not maintain backwards compatibility because "global pid" is
an optional argument and "dump mode" was a new argument. So if there
were five arguments its possible the last one was "dump mode" (no
global pid) or "global pid" (no support for dump mode).
Its possible to use strings in /proc/sys/kernel/core_pattern so we
could use those and have apport accept named arguments e.g:
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport --pid=%p --signal=%s --core-size=%c --dump-mode=%d
--global-pid=%P
['/home/bdmurray/source-trees/apport/artful/data/apport', '--
pid=5870', '--signal=11', '--core-size=0', '--dump-mode=1', '--global-
pid=5870']
Tyler said "that's probably a nice cleanup to make no matter what
because the magic arg ordering is dangerous".
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1732962/+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 1890716] Re: kmimetypefinder5 *.html reports wrong type
** Changed in: shared-mime-info (Ubuntu) Status: Invalid => New ** Bug watch added: Debian Bug tracker #887709 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887709 ** Also affects: shared-mime-info (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887709 Importance: Unknown Status: Unknown ** Summary changed: - kmimetypefinder5 *.html reports wrong type + misidentifies .html file as Perl script when it contains JavaScript "use strict" ** Bug watch added: gitlab.freedesktop.org/xdg/shared-mime-info/-/issues #80 https://gitlab.freedesktop.org/xdg/shared-mime-info/-/issues/80 ** Also affects: shared-mime-info via https://gitlab.freedesktop.org/xdg/shared-mime-info/-/issues/80 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shared-mime-info in Ubuntu. https://bugs.launchpad.net/bugs/1890716 Title: misidentifies .html file as Perl script when it contains JavaScript "use strict" Status in shared-mime-info: Unknown Status in shared-mime-info package in Ubuntu: New Status in shared-mime-info package in Debian: Unknown Bug description: For .html files `xdg-mime` reports wrong type. The culprit is the `"use strict"` phrase which is used in JavaScript. It should not mistake .html files for anything else except of text/html ! STEPS TO REPRODUCE: Run the following step by step in any folder: 1. $ echo "\"use strict\"" > index.html 2. $ xdg-mime query filetype index.html # -> application/x-perl - this should be text/html! Platform: Ubuntu 20.04.1 LTS (Focal Fossa)" Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) xdg-utils: 1.1.3-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/shared-mime-info/+bug/1890716/+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 1857824] [NEW] kmimetypefinder5 misidentifies mimetype of python files containing certain strings
You have been subscribed to a public bug:
Expected behavior:
$ kmimetypefinder5 example.py
text/x-python3
or
$ kmimetypefinder5 example.py
text/x-python
or
$ kmimetypefinder5 example.py
text/plain
Actual behavior:
$ kmimetypefinder5 example.py
application/xhtml+xml
Summary: Python scripts with a string containing HTML can be
misidentified as HTML files by kmimetypefinder5.
For example, this python script is identified as
"application/xhtml+xml":
#! /usr/bin/env python3
example_string = \
"""\
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>
Example title
Example body
"""
print('Hello, world!')
This difficulty is not shared by other mimetype identification tools.
$ kmimetypefinder5 example.py
application/xhtml+xml
$ cat example2.py #! /usr/bin/env python3
print('Hello, world!')
$ kmimetypefinder5 example2.py
text/x-python3
$ mimetype 'example.py'
example.py: text/x-python
$ mimetype 'example2.py'
example2.py: text/x-python
$ file --mime-type 'example.py'
example.py: text/plain
$ file --mime-type 'example2.py'
example2.py: text/plain
$ lsb_release -rd
Description:Ubuntu 18.04.3 LTS
Release:18.04
$ apt-cache policy kde-cli-tools
kde-cli-tools:
Installed: 4:5.12.8-0ubuntu0.1
Candidate: 4:5.12.8-0ubuntu0.1
Version table:
*** 4:5.12.8-0ubuntu0.1 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/universe amd64
Packages
100 /var/lib/dpkg/status
4:5.12.4-0ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: kde-cli-tools 4:5.12.8-0ubuntu0.1
ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
Uname: Linux 4.15.0-72-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
CurrentDesktop: KDE
Date: Sun Dec 29 13:28:37 2019
InstallationDate: Installed on 2018-12-12 (381 days ago)
InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64
(20180725)
SourcePackage: kde-cli-tools
UpgradeStatus: No upgrade log present (probably fresh install)
** Affects: shared-mime-info (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug bionic third-party-packages
--
kmimetypefinder5 misidentifies mimetype of python files containing certain
strings
https://bugs.launchpad.net/bugs/1857824
You received this bug notification because you are a member of Ubuntu Touch
seeded packages, which is subscribed to shared-mime-info in Ubuntu.
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1857824] Re: kmimetypefinder5 misidentifies mimetype of python files containing certain strings
** Package changed: kde-cli-tools (Ubuntu) => shared-mime-info (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shared-mime-info in
Ubuntu.
https://bugs.launchpad.net/bugs/1857824
Title:
kmimetypefinder5 misidentifies mimetype of python files containing
certain strings
Status in shared-mime-info package in Ubuntu:
New
Bug description:
Expected behavior:
$ kmimetypefinder5 example.py
text/x-python3
or
$ kmimetypefinder5 example.py
text/x-python
or
$ kmimetypefinder5 example.py
text/plain
Actual behavior:
$ kmimetypefinder5 example.py
application/xhtml+xml
Summary: Python scripts with a string containing HTML can be
misidentified as HTML files by kmimetypefinder5.
For example, this python script is identified as
"application/xhtml+xml":
#! /usr/bin/env python3
example_string = \
"""\
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>
Example title
Example body
"""
print('Hello, world!')
This difficulty is not shared by other mimetype identification tools.
$ kmimetypefinder5 example.py
application/xhtml+xml
$ cat example2.py #! /usr/bin/env python3
print('Hello, world!')
$ kmimetypefinder5 example2.py
text/x-python3
$ mimetype 'example.py'
example.py: text/x-python
$ mimetype 'example2.py'
example2.py: text/x-python
$ file --mime-type 'example.py'
example.py: text/plain
$ file --mime-type 'example2.py'
example2.py: text/plain
$ lsb_release -rd
Description: Ubuntu 18.04.3 LTS
Release: 18.04
$ apt-cache policy kde-cli-tools
kde-cli-tools:
Installed: 4:5.12.8-0ubuntu0.1
Candidate: 4:5.12.8-0ubuntu0.1
Version table:
*** 4:5.12.8-0ubuntu0.1 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/universe amd64
Packages
100 /var/lib/dpkg/status
4:5.12.4-0ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: kde-cli-tools 4:5.12.8-0ubuntu0.1
ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
Uname: Linux 4.15.0-72-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
CurrentDesktop: KDE
Date: Sun Dec 29 13:28:37 2019
InstallationDate: Installed on 2018-12-12 (381 days ago)
InstallationMedia: Kubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64
(20180725)
SourcePackage: kde-cli-tools
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1857824/+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 1890716] Re: misidentifies .html file as Perl script when it contains JavaScript "use strict"
** Also affects: kde-cli-tools (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shared-mime-info in Ubuntu. https://bugs.launchpad.net/bugs/1890716 Title: misidentifies .html file as Perl script when it contains JavaScript "use strict" Status in shared-mime-info: Unknown Status in kde-cli-tools package in Ubuntu: New Status in shared-mime-info package in Ubuntu: New Status in shared-mime-info package in Debian: Unknown Bug description: For .html files `xdg-mime` reports wrong type. The culprit is the `"use strict"` phrase which is used in JavaScript. It should not mistake .html files for anything else except of text/html ! STEPS TO REPRODUCE: Run the following step by step in any folder: 1. $ echo "\"use strict\"" > index.html 2. $ xdg-mime query filetype index.html # -> application/x-perl - this should be text/html! Platform: Ubuntu 20.04.1 LTS (Focal Fossa)" Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) xdg-utils: 1.1.3-2ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/shared-mime-info/+bug/1890716/+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 1895839] Re: CVE-2020-24977
** Description changed: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977 Upstream patch: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8e7c20a1af8776677d7890f30b7a180567701a49 + + GNOME project libxml2 v2.9.10 and earlier have a global buffer over-read + vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libxml2 in Ubuntu. https://bugs.launchpad.net/bugs/1895839 Title: CVE-2020-24977 Status in libxml2 package in Ubuntu: New Status in libxml2 package in Debian: Unknown Bug description: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977 Upstream patch: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8e7c20a1af8776677d7890f30b7a180567701a49 GNOME project libxml2 v2.9.10 and earlier have a global buffer over- read vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1895839/+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
