[Touch-packages] [Bug 1906627] Autopkgtest regression report (cyrus-sasl2/2.1.27~101-g0780600+dfsg-3ubuntu2.3)
All autopkgtests for the newly accepted cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3ubuntu2.3) for bionic have finished running. The following regressions have been reported in tests triggered by the package: postfix/3.3.0-1ubuntu0.3 (amd64) kimap/17.12.3-0ubuntu1 (armhf, ppc64el, arm64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#cyrus-sasl2 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the
[Touch-packages] [Bug 1871268] Re: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected
Installer Crashed Error -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1871268 Title: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected Status in Ubuntu CD Images: Fix Released Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Confirmed Status in apt source package in Focal: Triaged Status in apt source package in Groovy: Triaged Status in apt package in Debian: Unknown Bug description: [Impact] Installations that really succeeded would then fail because APT could not immediately configure a package. Which is a pointless way to fail at that point, because everything did work out anyway. So what we do is change that to a warning. [Test case] Not available right now. Issues can flare up and then disappear again. [Regression potential] It's imaginable that we missed something somewhere and some path that checked for a set error doesn't check it anymore, and we report success when we hit an error, but it seems unlikely. Behavior of --simulate changes. This used to fail before as well, and will now only produce a warning. We don't believe that is a reason of concern. [Groovy SRU] The groovy SRU is a sync of the 2.1.11 micro release from Debian unstable which also incorporates changes to the documentation: A typo fix, replacing focal with groovy in examples, and minor Dutch manual pages translation updates. We do not have test cases for the documentation changes, and we do not consider there to be a huge regression potential. As long as they build, they should be readable - maybe some words are wrong in the translation, who knows. [Original bug report] Test Case 1. Install Ubuntu Desktop on hardware with an nVidia card and select to install 3rd party drivers 2. Proceed with installation The following error message is displayed in /var/log/syslog /plugininstall.py: Verifying downloads ... /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/gcc_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxcrypt/libcrypt-dev_4.4.10-10ubuntu4_amd64.deb: "Version: '4.4.10-10ubuntu4' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/g++_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/z/zlib/zlib1g_1.2.11.dfsg-2ubuntu1_i386.deb: "Version: '1.2.11.dfsg-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxau/libxau6_1.0.9-0ubuntu1_i386.deb: "Version: '1.0.9-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdmcp/libxdmcp6_1.1.3-0ubuntu1_i386.deb: "Version: '1.1.3-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-6_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxext/libxext6_1.3.4-0ubuntu1_i386.deb: "Version: '1.3.4-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/l/lm-sensors/libsensors5_3.6.0-2ubuntu1_i386.deb: "Version: '3.6.0-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-xcb1_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdamage/libxdamage1_1.1.5-1_i386.deb: "Version: '1.1.5-1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxfixes/libxfixes3_5.0.3-1_i386.deb: "Version: '5.0.3-1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxxf86vm/libxxf86vm1_1.1.4-1build1_i386.deb: "Version: '1.1.4-1build1' not found." /plugininstall.py: Downloads verified successfully ubiquity: Error in function: install /plugininstall.py: Exception during installation: /plugininstall.py: apt_pkg.Error: E:Could not configure 'libc6:i386'. , E:Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) /plugininstall.py: ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: ubiquity 20.04.9 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu22 Architecture: amd64 CasperVersion: 1.442 Date: Mon Apr 6 20:17:07 2020 InstallCmdLine: file=/cdrom/preseed/xubuntu.seed only-ubiquity
[Touch-packages] [Bug 1874020] Re: Jack clients cannot use real-time scheduling with kernel 5.4.0-25-generic
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: lightdm (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1874020 Title: Jack clients cannot use real-time scheduling with kernel 5.4.0-25-generic Status in lightdm package in Ubuntu: Confirmed Bug description: With kernels 5.4.0-24-generic and 5.4.0-25-generic Jack client applications can no longer use real-time scheduling. Kernel 5.4.0-23-generic works. For example starting guitarix or ardour produces the following logs on stderr: Cannot use real-time scheduling (RR/5)(1: Operation not permitted) JackClient::AcquireSelfRealTime error The following is a strace from an older (working) kernel: sched_get_priority_min(SCHED_FIFO) = 1 sched_get_priority_max(SCHED_FIFO) = 99 sched_get_priority_min(SCHED_FIFO) = 1 sched_get_priority_max(SCHED_FIFO) = 99 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fd5c307c000 mprotect(0x7fd5c307d000, 8388608, PROT_READ|PROT_WRITE) = 0 clone(child_stack=0x7fd5c387b9f0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CL ONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[47564], tls=0x7fd5c3 87c700, child_tidptr=0x7fd5c387c9d0) = 47564 sched_setscheduler(47564, SCHED_FIFO, [1]) = 0 Compare against an strace with an affected kernel: sched_get_priority_min(SCHED_FIFO) = 1 sched_get_priority_max(SCHED_FIFO) = 99 sched_get_priority_min(SCHED_FIFO) = 1 sched_get_priority_max(SCHED_FIFO) = 99 mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f8d827ee000 mprotect(0x7f8d827ef000, 8388608, PROT_READ|PROT_WRITE) = 0 clone(child_stack=0x7f8d82fed9f0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CL ONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[21592], tls=0x7f8d82 fee700, child_tidptr=0x7f8d82fee9d0) = 21592 sched_setscheduler(21592, SCHED_FIFO, [1]) = -1 EPERM (Operation not permitted) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1874020/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1553685] Re: Lenovo Y700-17ISK subwoofer doesn't work
I have followed this guide https://davidwpearson.wordpress.com/2020/01/10/lenovo-laptop-subwoofers-and-linux/#fix i don't think it did a thing for the subwoofer, but it manages to sound a bit nicer -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1553685 Title: Lenovo Y700-17ISK subwoofer doesn't work Status in alsa-driver package in Ubuntu: Confirmed Bug description: Lenovo Y700-17ISK (Intel Core i7-6700HQ/RAM 16GB/SSD 512GB/Nvidia GTX960M 4GB) Operating system: Ubuntu 16.04 (xenial-desktop-amd64.iso 04-Mar-2016, kernel 4.4.0-10-generic, nvidia 361.28) Problem: Notebook subwoofer doesn't work. Judging from alsa-info.sh output, there is no pin declared for the bass output by BIOS. Please find a zip file attached: 'alsa-info_hdajackretask-unconnected-pins' ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-10-generic 4.4.0-10.25 ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3 Uname: Linux 4.4.0-10-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: aljosa 1776 F pulseaudio CurrentDesktop: Unity Date: Sun Mar 6 11:02:21 2016 HibernationDevice: RESUME=UUID=ac022671-63df-40ae-bffe-66fff3b35125 InstallationDate: Installed on 2016-03-05 (0 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160304) MachineType: LENOVO 80Q0 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-10-generic.efi.signed root=UUID=aa4325c4-4b4c-4372-b8ca-a66c3e5b2aa6 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-10-generic N/A linux-backports-modules-4.4.0-10-generic N/A linux-firmware1.156 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/31/2016 dmi.bios.vendor: LENOVO dmi.bios.version: CDCN30WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: Allsparks 7A dmi.board.vendor: LENOVO dmi.board.version: NO DPK dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad Y700-17ISK dmi.modalias: dmi:bvnLENOVO:bvrCDCN30WW:bd01/31/2016:svnLENOVO:pn80Q0:pvrLenovoideapadY700-17ISK:rvnLENOVO:rnAllsparks7A:rvrNODPK:cvnLENOVO:ct10:cvrLenovoideapadY700-17ISK: dmi.product.name: 80Q0 dmi.product.version: Lenovo ideapad Y700-17ISK dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1553685/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906627] Autopkgtest regression report (cyrus-sasl2/2.1.27~101-g0780600+dfsg-3ubuntu2.2)
All autopkgtests for the newly accepted cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3ubuntu2.2) for bionic have finished running. The following regressions have been reported in tests triggered by the package: kimap/17.12.3-0ubuntu1 (s390x) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#cyrus-sasl2 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the
[Touch-packages] [Bug 1907870] [NEW] Secondary screen detected but black screen with Intel UHD graphics on kernel 5.9
Public bug reported: Hi! I have an HP ProBook 440 G7 with i7-10510U and INTEL UHD GRAPHICS. The problem: When i connect to my external monitor (a Samsung BX2250) via HDMI, the screen is detected (i can see it in display settings) but the external monitor remains black. Seams like a bad frequency or resolution. I tried adding a new mode to xrandr with no luck. Also i tried different versions of kernels from 5.4 to 5.9. I am using Ubuntu 20.10 This is my lspci 0:00.0 Host bridge: Intel Corporation Device 9b61 (rev 0c) 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics (rev 02) 00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 0c) 00:12.0 Signal processing controller: Intel Corporation Comet Lake Thermal Subsytem 00:14.0 USB controller: Intel Corporation Device 02ed 00:14.2 RAM memory: Intel Corporation Device 02ef 00:14.3 Network controller: Intel Corporation Wireless-AC 9462 00:14.5 SD Host controller: Intel Corporation Device 02f5 00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO I2C Host Controller 00:16.0 Communication controller: Intel Corporation Comet Lake Management Engine Interface 00:17.0 SATA controller: Intel Corporation Comet Lake SATA AHCI Controller 00:1d.0 PCI bridge: Intel Corporation Device 02b0 (rev f0) 00:1d.4 PCI bridge: Intel Corporation Device 02b4 (rev f0) 00:1f.0 ISA bridge: Intel Corporation Device 0284 00:1f.3 Multimedia audio controller: Intel Corporation Device 02c8 00:1f.4 SMBus: Intel Corporation Device 02a3 00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake SPI (flash) Controller 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 02:00.0 Non-Volatile memory controller: Sandisk Corp Device 5009 (rev 01) inxi -Gx output: Graphics: Device-1: Intel UHD Graphics vendor: Hewlett-Packard driver: i915 v: kernel bus ID: 00:02.0 Device-2: Lite-On HP HD Camera type: USB driver: uvcvideo bus ID: 1-2:2 Display: x11 server: X.Org 1.20.9 driver: modesetting unloaded: fbdev,vesa resolution: 1366x768~60Hz OpenGL: renderer: Mesa Intel UHD Graphics (CML GT2) v: 4.6 Mesa 20.2.1 direct render: Yes xrandr output (with hdmi cable connected to external monitor): Screen 0: minimum 320 x 200, current 1366 x 768, maximum 16384 x 16384 eDP-1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 309mm x 173mm 1366x768 60.06*+ 40.04 1360x768 59.8059.96 1280x720 60.0059.9959.8659.74 1024x768 60.0460.00 960x720 60.00 928x696 60.05 896x672 60.01 1024x576 59.9559.9659.9059.82 960x600 59.9360.00 960x540 59.9659.9959.6359.82 800x600 60.0060.3256.25 840x525 60.0159.88 864x486 59.9259.57 800x512 60.17 700x525 59.98 800x450 59.9559.82 640x512 60.02 720x450 59.89 700x450 59.9659.88 640x480 60.0059.94 720x405 59.5158.99 684x384 59.8859.85 680x384 59.8059.96 640x400 59.8859.98 576x432 60.06 640x360 59.8659.8359.8459.32 512x384 60.00 512x288 60.0059.92 480x270 59.6359.82 400x300 60.3256.34 432x243 59.9259.57 320x240 60.05 360x202 59.5159.13 320x180 59.8459.32 HDMI-1 connected (normal left inverted right x axis y axis) 1920x1080 60.00 + 50.0059.94 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.88 1280x1024 75.0260.02 1440x900 74.9859.90 1280x960 60.00 1280x800 59.91 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0370.0760.00 832x624 74.55 800x600 72.1975.0060.3256.25 720x576 50.00 720x480 60.0059.94 640x480 75.0072.8166.6760.0059.94 720x400 70.08 DP-1 disconnected (normal left inverted right x axis y axis) HDMI-2 disconnected (normal left inverted right x axis y axis) ** Affects: xorg (Ubuntu) Importance: Undecided Status: New -- 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/1907870 Title: Secondary screen detected but black screen with Intel UHD graphics on kernel 5.9 Status in xorg package in Ubuntu: New Bug description: Hi! I have an HP ProBook 440 G7 with i7-10510U and INTEL UHD GRAPHICS. The problem: When i connect to my external monitor (a Samsung
[Touch-packages] [Bug 1906627] Autopkgtest regression report (cyrus-sasl2/2.1.27~101-g0780600+dfsg-3ubuntu2.2)
All autopkgtests for the newly accepted cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3ubuntu2.2) for bionic have finished running. The following regressions have been reported in tests triggered by the package: kimap/17.12.3-0ubuntu1 (s390x) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#cyrus-sasl2 [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the
[Touch-packages] [Bug 1906627] Please test proposed package
Hello Rolf, or anyone else affected, Accepted cyrus-sasl2 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cyrus- sasl2/2.1.27~101-g0780600+dfsg-3ubuntu2.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal
[Touch-packages] [Bug 1907865] [NEW] Xorg crash
Public bug reported: I can't reliably reproduce this crash, and I don't know, even approximately, what's causing it, or what I might be doing to possibly cause it. It just randomly crashes, and dumps me back to the login screen. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-56.62-generic 5.4.73 Uname: Linux 5.4.0-56-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.11-0ubuntu27.13 Architecture: amd64 BootLog: CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Dec 11 15:35:06 2020 DistUpgraded: 2020-10-07 09:25:09,468 ERROR got error from PostInstallScript ./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process “./xorg_fix_proprietary.py” (No such file or directory) (8)) DistroCodename: focal 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: Dell Skylake GT2 [HD Graphics 520] [1028:06de] InstallationDate: Installed on 2016-12-06 (1466 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) MachineType: Dell Inc. Latitude E5470 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-56-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display Title: Xorg crash UpgradeStatus: Upgraded to focal on 2020-10-07 (65 days ago) dmi.bios.date: 06/15/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.7.3 dmi.board.name: 0VHKV0 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.7.3:bd06/15/2016:svnDellInc.:pnLatitudeE5470:pvr:rvnDellInc.:rn0VHKV0:rvrA00:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E5470 dmi.product.sku: 06DE dmi.sys.vendor: Dell Inc. modified.conffile..etc.apport.crashdb.conf: [modified] mtime.conffile..etc.apport.crashdb.conf: 2020-12-09T15:53:03.120486 version.compiz: compiz 1:0.9.14.1+20.04.20200211-0ubuntu1 version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~20.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.6 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 xserver.bootTime: Fri Aug 17 21:02:51 2018 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id1523 vendor BOE xserver.version: 2:1.18.4-0ubuntu0.7 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug crash focal 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/1907865 Title: Xorg crash Status in xorg package in Ubuntu: New Bug description: I can't reliably reproduce this crash, and I don't know, even approximately, what's causing it, or what I might be doing to possibly cause it. It just randomly crashes, and dumps me back to the login screen. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-56.62-generic 5.4.73 Uname: Linux 5.4.0-56-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.11-0ubuntu27.13 Architecture: amd64 BootLog: CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Dec 11 15:35:06 2020 DistUpgraded: 2020-10-07 09:25:09,468 ERROR got error from PostInstallScript ./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process “./xorg_fix_proprietary.py” (No such file or directory) (8)) DistroCodename: focal 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: Dell Skylake GT2 [HD Graphics 520] [1028:06de] InstallationDate: Installed on 2016-12-06 (1466 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) MachineType: Dell Inc. Latitude E5470 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-56-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display Title: Xorg crash UpgradeStatus: Upgraded to focal on 2020-10-07 (65 days ago) dmi.bios.date: 06/15/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.7.3 dmi.board.name: 0VHKV0 dmi.board.vendor: Dell Inc.
[Touch-packages] [Bug 1664818] Re: Not possible to render pre-up, pre-down, post-up, or post-down snippets
To my knowledge, networkd-dispatcher has no way to do 'pre' hooks on systemd-networkd events, so this is still a valid feature request. ** Changed in: systemd (Ubuntu) Status: Invalid => Triaged ** Changed in: systemd (Ubuntu) Milestone: ubuntu-17.05 => None ** Changed in: systemd (Ubuntu) Assignee: Mathieu Trudel-Lapierre (cyphermox) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1664818 Title: Not possible to render pre-up, pre-down, post-up, or post-down snippets Status in netplan: New Status in systemd package in Ubuntu: Triaged Bug description: Many configurations require scripts to run before or after an interface comes up or down. Example: I had a situation where I needed to render a post-up script to monitor an interface with ifupdown (and with the interface set to manual mode, because if the link was down I didn't want to require DHCP to run before the system continued booting). This is similar to what NetworkManager does in order to launch (or kill) a DHCP client. Other use cases involve setting up custom routes (such as when complex logic involving metrics or source routing is required) or anything else the designers of the netplan rendering engine didn't think of, such as invoking workarounds or special settings required for a particular NIC or environment, iptables rules that should be added or removed, etc. A follow-on issue is, it should be possible to ask that custom scripts run if the *link* is detected to come up or down. But I'll be happy if netplan first can simply replicate the custom-script-invoking behavior of ifupdown. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1664818/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1900008] Re: Sessions of screen does not keep running in background
Well, is a really close (or same) behaviur like exposed in https://bugs.debian.org/825394 (shared by Axel). Screen version 4.8.0-1. The system (or either systemd) has modifications at all, so is really weird. -- 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/198 Title: Sessions of screen does not keep running in background Status in screen package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: In a new fresh installed 20.04, when I use screen command and close the terminal (not closing screen sesion), then I can't recover it with screen -x, since does not exist. I can only recover screen sesion if the original terminal running screen is not being closed. For some reason, this is closing screen session of that user: Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded. Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario. This does not happen in an upgraded system from 18.04 to 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/screen/+bug/198/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1900008] Re: Sessions of screen does not keep running in background
That's interesting, I just performed your suggested test, and I couldn't reproduce - it's a fresh Ubuntu 20.04 install, running MATE (not KDE!) and GNU screen 4.8.0-1. After closing the terminal, I've opened another one and "screen -x" worked fine, as expected. Could you try to use MATE / Gnome to perform your test? So we can isolate it to KDE (or not). Also, which version of screen is installed in your system? 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/198 Title: Sessions of screen does not keep running in background Status in screen package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: In a new fresh installed 20.04, when I use screen command and close the terminal (not closing screen sesion), then I can't recover it with screen -x, since does not exist. I can only recover screen sesion if the original terminal running screen is not being closed. For some reason, this is closing screen session of that user: Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded. Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario. This does not happen in an upgraded system from 18.04 to 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/screen/+bug/198/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1900008] Re: Sessions of screen does not keep running in background
Hi, first of all I don' t know why I did' t receive any notification of this bug report. Second, and to clarify, I being using screen command since 2000 (which Is my beginning as Linux admin). This being said, I know how it works. All my other Ubuntu upgrades from 18.04 to 20.04, this does not happen (I do not have time yet to test it in a new Ubuntu 20.04, maybe later in a VM). Simple test: open screen. Just close you terminal (not exit...). When I want to recover screen session with screen -x, is gone, none, nothing... Btw, I only tested this KDE Neon, which is Ubuntu 20.04 based and I think has nothing to do that is KDE based, since screen has nothing to do with it. -- 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/198 Title: Sessions of screen does not keep running in background Status in screen package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: In a new fresh installed 20.04, when I use screen command and close the terminal (not closing screen sesion), then I can't recover it with screen -x, since does not exist. I can only recover screen sesion if the original terminal running screen is not being closed. For some reason, this is closing screen session of that user: Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded. Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario. This does not happen in an upgraded system from 18.04 to 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/screen/+bug/198/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1889668] Re: set-cpufreq error when cpu is offline
try disabling the 'ondemand' service and install cpufrequtils package. -- 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/1889668 Title: set-cpufreq error when cpu is offline Status in systemd package in Ubuntu: New Bug description: I have hyperthreading disabled on my Ubuntu 19.10 machine, which makes some processors in /sys/devices/system/cpu/cpu* have their "online" set to 0. However, when the for-loop in /lib/systemd/set-cpufreq iterates over the processors, it doesn't check if the processor is online before trying to write the governor name into scaling_governor. The script appears to have the same bug in Ubuntu 20.04. I modified the script to print the cpu it is trying to set before doing so, and I get the following: Setting powersave scheduler for all CPUs /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor /sys/devices/system/cpu/cpu10/cpufreq/scaling_governor /lib/systemd/set-cpufreq: 43: echo: echo: I/O error Since the script doesn't continue to try other processors in the loop, it means that only cpu0 and cpu1 on my machine get set to powersave and the others remain with the performance governor. The cpufreq-info command confirms this. Checking if the processor has online==1 before writing, or putting the echo within a "set +e" "set -e" pair would fix the problem (although the latter approach would still print error messages). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1889668/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907850] [NEW] Cache not generated for all translations
Public bug reported: [Impact] In bug 1161743 we discovered that if a system is configured with multiple locales, only the locales of the user who generated the apt-cache will be available for translated descriptions. [Test case] # apt install locales-all # get the locale # export LANG=sv_SE.UTF-8 # locale LANG=sv_SE.UTF-8 LANGUAGE= LC_CTYPE="sv_SE.UTF-8" LC_NUMERIC="sv_SE.UTF-8" LC_TIME="sv_SE.UTF-8" LC_COLLATE="sv_SE.UTF-8" LC_MONETARY="sv_SE.UTF-8" LC_MESSAGES="sv_SE.UTF-8" LC_PAPER="sv_SE.UTF-8" LC_NAME="sv_SE.UTF-8" LC_ADDRESS="sv_SE.UTF-8" LC_TELEPHONE="sv_SE.UTF-8" LC_MEASUREMENT="sv_SE.UTF-8" LC_IDENTIFICATION="sv_SE.UTF-8" LC_ALL= # apt update # apt-cache show tasksel | grep Desc Description-sv: tool for selecting tasks for installation on Debian systems Description-md5: cbbb747708986d11ea77c80b9b038fec # apt-cache showpkg tasksel Package: tasksel Versions: 3.34ubuntu16 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_binary-amd64_Packages) Description Language: File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_binary-amd64_Packages MD5: cbbb747708986d11ea77c80b9b038fec Description Language: sv File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_i18n_Translation-sv MD5: cbbb747708986d11ea77c80b9b038fec Description Language: en File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_i18n_Translation-en MD5: cbbb747708986d11ea77c80b9b038fec [...] So far so good, but now assume the root user actually has C configured as locale, and e.g. runs apt-cache show (or apt-daily.service does an update): root@g:~# rm /var/cache/apt/*.bin root@g:~# LANG=C apt-cache show tasksel [...] Description-en: tool for selecting tasks for installation on Debian systems This package provides 'tasksel', a simple interface for users who want to configure their system to perform a specific task. root@g:~# apt-cache showpkg tasksel Package: tasksel Versions: 3.34ubuntu16 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_binary-amd64_Packages) Description Language: File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_binary-amd64_Packages MD5: cbbb747708986d11ea77c80b9b038fec Description Language: en File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_i18n_Translation-en MD5: cbbb747708986d11ea77c80b9b038fec This should show the sv locale as well given that it's still around (also we are still running with LANG=sv_SE.UTF-8), but it only generated the cache with the english language description in here. [Where problems could occur] Unknown so far, we've not investigated the cause or solution yet. [Other Info] N/A ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Tags: rls-hh-incoming ** Description changed: [Impact] In bug 1161743 we discovered that if a system is configured with multiple locales, only the locales of the user who generated the apt-cache will be available for translated descriptions. [Test case] # apt install locales-all # get the locale # export LANG=sv_SE.UTF-8 # locale LANG=sv_SE.UTF-8 LANGUAGE= LC_CTYPE="sv_SE.UTF-8" LC_NUMERIC="sv_SE.UTF-8" LC_TIME="sv_SE.UTF-8" LC_COLLATE="sv_SE.UTF-8" LC_MONETARY="sv_SE.UTF-8" LC_MESSAGES="sv_SE.UTF-8" LC_PAPER="sv_SE.UTF-8" LC_NAME="sv_SE.UTF-8" LC_ADDRESS="sv_SE.UTF-8" LC_TELEPHONE="sv_SE.UTF-8" LC_MEASUREMENT="sv_SE.UTF-8" LC_IDENTIFICATION="sv_SE.UTF-8" LC_ALL= # apt update # apt-cache show tasksel | grep Desc Description-sv: tool for selecting tasks for installation on Debian systems Description-md5: cbbb747708986d11ea77c80b9b038fec # apt-cache showpkg tasksel Package: tasksel Versions: 3.34ubuntu16 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_binary-amd64_Packages) - Description Language: - File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_binary-amd64_Packages - MD5: cbbb747708986d11ea77c80b9b038fec - Description Language: sv - File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_i18n_Translation-sv - MD5: cbbb747708986d11ea77c80b9b038fec - Description Language: en - File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_i18n_Translation-en - MD5: cbbb747708986d11ea77c80b9b038fec + Description Language: + File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_binary-amd64_Packages + MD5: cbbb747708986d11ea77c80b9b038fec + Description Language: sv + File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_groovy_main_i18n_Translation-sv + MD5: cbbb747708986d11ea77c80b9b038fec + Description Language:
[Touch-packages] [Bug 1890186] Re: Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument
@kaihengfeng can you review this bug to see if you can tell what the correct change to the hwdb should be? -- 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/1890186 Title: Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument Status in systemd package in Ubuntu: New Bug description: I run an up-to-date Ubuntu 20.04.1 LTS "focal" with kernel 5.4.0-42-generic on Dell Latitude E6440. Upon examining the output of journalctl -b, I see this: Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in Show Plymouth Boot Screen being skipped. Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in Forward Password Requests to Plymouth Directory Watch being skipped. Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in File System Check on Root Device being skipped. Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. Aug 03 19:22:15 pseudonymizedHostname systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. Aug 03 19:22:15 pseudonymizedHostname kernel: [drm] radeon: dpm initialized Aug 03 19:22:15 pseudonymizedHostname kernel: [drm] GART: num cpu pages 524288, num gpu pages 524288 Aug 03 19:22:15 pseudonymizedHostname kernel: dell_laptop: Using dell-rbtn acpi driver for receiving events Aug 03 19:22:15 pseudonymizedHostname systemd-udevd[385]: event8: Failed to call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument Aug 03 19:22:15 pseudonymizedHostname systemd-udevd[385]: event8: Failed to call EVIOCSKEYCODE with scan code 0xc022e, and key code 108: Invalid argument "Invalid argument" means that something goes wrong there, and I don't know what it is. On my laptop, event8 seems to be keyboard-related: $ sudo cat /proc/bus/input/devices | grep -C 5 event8 I: Bus=0003 Vendor=045e Product=00db Version=0111 N: Name="Microsoft Natural® Ergonomic Keyboard 4000" P: Phys=usb-:00:14.0-13.1/input0 S: Sysfs=/devices/pci:00/:00:14.0/usb3/3-13/3-13.1/3-13.1:1.0/0003:045E:00DB.0002/input/input9 U: Uniq= H: Handlers=sysrq kbd event8 leds B: PROP=0 B: EV=120013 B: KEY=10007 ff8007ff febeffdff3cf fffe B: MSC=10 B: LED=107 The issue report https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1754921 is probably related but marked as a duplicate of a no longer existing issue report (#1750855). The report https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597415 describes a similar issue for older kernels; the differences pertain to error message, error code, input..., and, opposed to #19 there, I have no Windows partitions (except /boot/efi vfat) in /etc/fstab; mine is not a dual-boot machine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890186/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890448] Re: hwdb: Add EliteBook to use micmute hotkey
@kaihengfeng, can we skip Xenial since that goes ESM soon?
** Description changed:
[Impact]
Micmute hotkey on many HP EliteBooks don't work.
[Fix]
Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT
keyboard's scancode to micmute hotkey.
[Test]
With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.
[Regression Potential]
The hwdb originally only matches a few EliteBook, and fix changes that to
match all EliteBook models. So if there's an EliteBook that uses the scancode
for other purpose, there will be a regression.
However, the risk is rather slim because HP is confident that all EliteBooks
use the same scancode for mic mute hotkey.
+
+ [scope]
+
+ this is needed for f and earlier.
+
+ this is fixed upstream by commit b6eb208b29ae which is included starting
+ in v246, so g and later are already fixed.
** Also affects: systemd (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu)
Status: New => Fix Released
** Changed in: systemd (Ubuntu Bionic)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: systemd (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: systemd (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: systemd (Ubuntu Focal)
Status: New => In Progress
** Changed in: systemd (Ubuntu Bionic)
Status: New => In Progress
** Changed in: systemd (Ubuntu Focal)
Assignee: (unassigned) => Dan Streetman (ddstreet)
--
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/1890448
Title:
hwdb: Add EliteBook to use micmute hotkey
Status in HWE Next:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Focal:
In Progress
Bug description:
[Impact]
Micmute hotkey on many HP EliteBooks don't work.
[Fix]
Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT
keyboard's scancode to micmute hotkey.
[Test]
With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.
[Regression Potential]
The hwdb originally only matches a few EliteBook, and fix changes that to
match all EliteBook models. So if there's an EliteBook that uses the scancode
for other purpose, there will be a regression.
However, the risk is rather slim because HP is confident that all EliteBooks
use the same scancode for mic mute hotkey.
[scope]
this is needed for f and earlier.
this is fixed upstream by commit b6eb208b29ae which is included
starting in v246, so g and later are already fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1890448/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902236] Re: Duplicated root and nobody returned by getent on Focal
per comment in bug description, marking as affecting only focal ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1902236 Title: Duplicated root and nobody returned by getent on Focal Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Bug description: * Summary systemd's NSS integration causes getent passwd/group to return duplicated entries for root/root and nobody/nogroup. The root account also gets a different shell (/bin/sh instead of /bin/bash). * Steps to reproduce: 1) create a container $ lxc launch images:ubuntu/focal test-nobody 2) check the root and nobody accounts $ lxc exec test-nobody -- getent passwd | grep -E '^(root|nobody):' 3) check the root and nogroup groups $ lxc exec test-nobody -- getent group | grep -E '^(root|nogroup):' 2 and 3 should report a single entry for each account/group but they return dups like this: root:x:0:0:root:/root:/bin/bash nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin root:x:0:0:root:/root:/bin/sh nobody:x:65534:65534:nobody:/:/usr/sbin/nologin * Description The problem seems to come from the NSS integration: $ lxc exec test-nobody -- grep -wF systemd /etc/nsswitch.conf passwd: files systemd group: files systemd as the /etc/passwd and /etc/group file contain no dups: $ lxc exec test-nobody -- grep ^nobody: /etc/passwd nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin $ lxc exec test-nobody -- grep ^nogroup: /etc/group nogroup:x:65534: Removing systemd from /etc/nsswitch.conf indeed removes the dup. An alternative way of seeing what systemd adds on top of the flat files: $ lxc exec test-nobody -- bash -c 'diff -u /etc/passwd <(getent passwd)' --- /etc/passwd 2020-10-30 13:07:52.219261001 + +++ /dev/fd/632020-10-30 13:29:38.396928732 + @@ -24,3 +24,5 @@ _apt:x:105:65534::/nonexistent:/usr/sbin/nologin ubuntu:x:1000:1000::/home/ubuntu:/bin/bash systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin +root:x:0:0:root:/root:/bin/sh +nobody:x:65534:65534:nobody:/:/usr/sbin/nologin $ lxc exec test-nobody -- bash -c 'diff -u /etc/group <(getent group)' --- /etc/group2020-10-30 13:07:52.211261089 + +++ /dev/fd/632020-10-30 13:29:45.892846747 + @@ -50,3 +50,5 @@ ubuntu:x:1000: ssh:x:111: systemd-coredump:x:999: +root:x:0: +nogroup:x:65534: * Additional information This bug seems to occur on Focal alone as Bionic and Groovy are not affected. $ lsb_release -rd Description: Ubuntu 20.04.1 LTS Release: 20.04 $ apt-cache policy base-passwd systemd base-passwd: Installed: 3.5.47 Candidate: 3.5.47 Version table: *** 3.5.47 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status systemd: Installed: 245.4-4ubuntu3.2 Candidate: 245.4-4ubuntu3.2 Version table: *** 245.4-4ubuntu3.2 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1902236/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1899232] Re: ansible fails with systemd 245.4
*** This bug is a duplicate of bug 1905245 ***
https://bugs.launchpad.net/bugs/1905245
you didn't say specifically what's causing ansible to fail, but the fix
you referenced suggests this is a dup of 1905245, so i'll mark it as
such.
** This bug has been marked a duplicate of bug 1905245
"Failed to parse bus message: Invalid argument" with Linux 5.8
--
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/1899232
Title:
ansible fails with systemd 245.4
Status in ansible:
Fix Released
Status in systemd package in Ubuntu:
Confirmed
Bug description:
Ansible 2.10.2 fails when determining state of a service on systemd
245.4 in Ubuntu 20.04. It's related to this bug
[https://github.com/systemd/systemd/pull/16424]. This bug has been
fixed in systemd 245.7. Is there plans to release a fix with this?
Without this fix, ansible fails when attempting to manage services on
Ubuntu 20.04.
Ubuntu release: Ubuntu 20.04
Package: 245.4-4ubuntu3.2 amd64
What I expected to happen
Service marked as started when it is stopped.
What happened instead
Got 'failed: [127.0.0.1] (item=ssh) => {"ansible_loop_var": "item",
"changed": false, "item": "ssh", "msg": "Service is in unknown state",
"status": {}}'
Thank you.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ansible/+bug/1899232/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902891] Re: "Too many levels of symbolic links” error when using systemd to mount sshfs
@sampie you have a reference to the upstream issue? -- 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/1902891 Title: "Too many levels of symbolic links” error when using systemd to mount sshfs Status in systemd package in Ubuntu: Confirmed Bug description: I have asked question at askubuntu about "Too many levels of symbolic links” error when trying to use systemd to mount sshfs (https://askubuntu.com/questions/1286375/too-many-levels-of-symbolic- links-error-when-using-systemd) I have not got any responses, so I am submitting a bug report. If this is not a bug, please advice how to mount sshfs share with systemd. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.2 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27.10 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Nov 4 16:17:04 2020 InstallationDate: Installed on 2019-11-03 (367 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: LENOVO 81H1 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-52-generic root=UUID=7f92666a-65f8-485e-b998-046c2c596aa5 ro rootflags=subvol=@ quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: Upgraded to focal on 2020-03-28 (220 days ago) dmi.bios.date: 08/17/2018 dmi.bios.vendor: LENOVO dmi.bios.version: 8PCN45WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40700 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 530S-14ARR dmi.modalias: dmi:bvnLENOVO:bvr8PCN45WW:bd08/17/2018:svnLENOVO:pn81H1:pvrLenovoideapad530S-14ARR:rvnLENOVO:rnLNVNB161216:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrLenovoideapad530S-14ARR: dmi.product.family: ideapad 530S-14ARR dmi.product.name: 81H1 dmi.product.sku: LENOVO_MT_81H1_BU_idea_FM_ideapad 530S-14ARR dmi.product.version: Lenovo ideapad 530S-14ARR dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1902891/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907814] Re: This is not an official Ubuntu package. (but it was, yesterday!)
** Description changed: This is a special case of Bug 559345 somewhere between a question and a request for better/more discoverable error message/documentation. In apport, because thats what people encountering bugs are going to use. In USN, because the one thing worse than no security notices is incorrect advice. In the package changelog, because reverts are confusing enough already. Proposed fix, among others: Add two URLs to the apport error messages. One to the relevant "https://changelogs.ubuntu.com/; site which apt should still know, package in Relaase or not, which hopefully by then includes a note about a package rebuild to clarify the revert. And another one to any relevant "https://ubuntu.com/security/notices/?details=package; site, if you are able to keep the search URL stable long enough for that to reliably present a list of related USNs. - Background: `ubuntu-bug linux` will not let me report the kernel regression I ran into.. because the package went AWOL (linux-image-5.8.0-31-generic, linux-image-5.4.0-56-generic, .. as announced from https://ubuntu.com/security/notices/USN-4658-1) + Background: `ubuntu-bug linux` will not let me report the kernel regression I ran into.. because the package went AWOL (linux-image-5.8.0-31-generic, linux-image-5.4.0-56-generic, .. see Bug 1907761) Since I might now have two tentatively non-reproducible versions, one reproducible in between and presumably one upcoming that re-introduces the potentially responsible security backports, bisecting will be much easier with some knowledge of the order of backports applied. -- 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/1907814 Title: This is not an official Ubuntu package. (but it was, yesterday!) Status in apport package in Ubuntu: New Bug description: This is a special case of Bug 559345 somewhere between a question and a request for better/more discoverable error message/documentation. In apport, because thats what people encountering bugs are going to use. In USN, because the one thing worse than no security notices is incorrect advice. In the package changelog, because reverts are confusing enough already. Proposed fix, among others: Add two URLs to the apport error messages. One to the relevant "https://changelogs.ubuntu.com/; site which apt should still know, package in Relaase or not, which hopefully by then includes a note about a package rebuild to clarify the revert. And another one to any relevant "https://ubuntu.com/security/notices/?details=package; site, if you are able to keep the search URL stable long enough for that to reliably present a list of related USNs. Background: `ubuntu-bug linux` will not let me report the kernel regression I ran into.. because the package went AWOL (linux-image-5.8.0-31-generic, linux-image-5.4.0-56-generic, .. see Bug 1907761) Since I might now have two tentatively non-reproducible versions, one reproducible in between and presumably one upcoming that re-introduces the potentially responsible security backports, bisecting will be much easier with some knowledge of the order of backports applied. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1907814/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906653] Re: Backport systemd to make uevents "sticky"
I'm hesitant to backport, because the change causes significant issues on upgrade, e.g.: https://github.com/systemd/systemd/issues/17605 if we do backport the 'sticky' udev tags, we'll need to make sure to also pull back the proper commits to handle the new udev format across daemon-reexec, e.g.: https://github.com/systemd/systemd/pull/17622 ** Bug watch added: github.com/systemd/systemd/issues #17605 https://github.com/systemd/systemd/issues/17605 -- 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/1906653 Title: Backport systemd to make uevents "sticky" Status in systemd package in Ubuntu: Confirmed Bug description: Base on lwn 837033 [0], Linux 4.12 introduced two new uevents "bind" and "unbind" to the Linux device model which resulted in a number of software issues. So in this PR [1] which minimize issues resulting from this kernel change (but not avoid them entirely) by make uevent "sticky", meaning that once a tag is assigned to a device it will not be removed from the device again until the device itself is removed (i.e. unplugged). An example causing by this issue, I had a usb printer (non-ippusbxd) which connected to my laptop, but after unplugging it from my laptop, the .device unit were still present, if a different printer gets plugged to the same USB port then, it won't be configured correctly. [0] https://lwn.net/Articles/837033/ [1] https://github.com/systemd/systemd/pull/16853/files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1906653/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1846334] Re: cupsd assert failure: free(): invalid pointer
This has been happening for ages now. 18.04 to 20.10 are all affected -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1846334 Title: cupsd assert failure: free(): invalid pointer Status in cups package in Ubuntu: Confirmed Bug description: Just running in the background, no user action (printing) ProblemType: Crash DistroRelease: Ubuntu 19.10 Package: cups-daemon 2.2.12-2ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-16.17-generic 5.3.1 Uname: Linux 5.3.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 AssertionMessage: free(): invalid pointer Date: Tue Oct 1 19:41:35 2019 ExecutablePath: /usr/sbin/cupsd InstallationDate: Installed on 2019-02-09 (234 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190203) Lpstat: device for HP_LaserJet_CM1415fn_44A808_: implicitclass://HP_LaserJet_CM1415fn_44A808_/ device for Samsung_C48x_Series_SEC84251900EE44_: implicitclass://Samsung_C48x_Series_SEC84251900EE44_/ MachineType: Dell Inc. Latitude E6530 Papersize: letter PpdFiles: HP_LaserJet_CM1415fn_44A808_: LaserJet CM1415fn - IPP Everywhere Samsung_C48x_Series_SEC84251900EE44_: C48x Series - IPP Everywhere ProcAttrCurrent: /usr/sbin/cupsd (enforce) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.0-16-generic root=UUID=4cc2c833-0db9-4a3d-84d1-9f00f5785fca ro quiet splash vt.handoff=7 ProcEnviron: LANG=de_DE.UTF-8 PATH=(custom, no user) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-16-generic root=UUID=4cc2c833-0db9-4a3d-84d1-9f00f5785fca ro quiet splash vt.handoff=7 Signal: 6 SourcePackage: cups StacktraceTop: __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f923ecb83a5 "%s\n") at ../sysdeps/posix/libc_fatal.c:181 malloc_printerr (str=str@entry=0x7f923ecb652a "free(): invalid pointer") at malloc.c:5332 _int_free (av=, p=, have_lock=0) at malloc.c:4173 ?? () from /lib/x86_64-linux-gnu/libcups.so.2 ippDelete () from /lib/x86_64-linux-gnu/libcups.so.2 Title: cupsd assert failure: free(): invalid pointer UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: dmi.bios.date: 11/30/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: A22 dmi.board.name: 07Y85M dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA22:bd11/30/2018:svnDellInc.:pnLatitudeE6530:pvr01:rvnDellInc.:rn07Y85M:rvrA00:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6530 dmi.product.sku: Latitude E6530 dmi.product.version: 01 dmi.sys.vendor: Dell Inc. separator: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1846334/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1664818] Re: Not possible to render pre-up, pre-down, post-up, or post-down snippets
marking this as invalid for systemd as arbitrary code can be run using networkd-dispatcher and/or suggestions from comment 4. ** Changed in: systemd (Ubuntu) Status: Triaged => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1664818 Title: Not possible to render pre-up, pre-down, post-up, or post-down snippets Status in netplan: New Status in systemd package in Ubuntu: Invalid Bug description: Many configurations require scripts to run before or after an interface comes up or down. Example: I had a situation where I needed to render a post-up script to monitor an interface with ifupdown (and with the interface set to manual mode, because if the link was down I didn't want to require DHCP to run before the system continued booting). This is similar to what NetworkManager does in order to launch (or kill) a DHCP client. Other use cases involve setting up custom routes (such as when complex logic involving metrics or source routing is required) or anything else the designers of the netplan rendering engine didn't think of, such as invoking workarounds or special settings required for a particular NIC or environment, iptables rules that should be added or removed, etc. A follow-on issue is, it should be possible to ask that custom scripts run if the *link* is detected to come up or down. But I'll be happy if netplan first can simply replicate the custom-script-invoking behavior of ifupdown. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1664818/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1665143] Re: Commission scripts select the wrong nvme device link, then fails to report any storage
marking as invalid for systemd as i believe the bug was in maas, per previous comments. ** Changed in: systemd (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1665143 Title: Commission scripts select the wrong nvme device link, then fails to report any storage Status in MAAS: Fix Released Status in MAAS 2.1 series: Fix Released Status in systemd package in Ubuntu: Invalid Bug description: The udev package provides /lib/udev/rules.d/60-persistent- storage.rules which creates two symlinks for nvme devices, under /dev/disk/by-id/. The first link name includes the device wwid and the second includes the device model/serial. The commission script selects the first link discovered and subsequently attempts to store it in a FilePath field, which allows for 100 characters. Since the wwid link is greater than 100 characters an exception is thrown, causing not only the nvme device not to be registered but all other storage devices as well. Although commissioning completes there is no storage assigned, which makes deployment of the node impossible. This issue has blocked all test runs performed by the CDO-QA test infrastructure, since every run installs MAAS on a fresh machine and commissions new nodes. The failure is seen when installing from either ppa:maas/next (2.2.0~beta2) or ppa:maas/stable (2.1.3+bzr5573). ubuntu@meowth:~$ dpkg -l '*maas*'|cat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---= ii maas2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM ii maas-cli2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all MAAS client and command-line interface un maas-cluster-controller (no description available) ii maas-common 2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all MAAS server common files ii maas-dhcp 2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all MAAS DHCP server ii maas-dns2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all MAAS DNS server ii maas-proxy 2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all MAAS Caching Proxy ii maas-rack-controller2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all Rack Controller for MAAS ii maas-region-api 2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all Region controller API service for MAAS ii maas-region-controller 2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all Region Controller for MAAS un maas-region-controller-min (no description available) un python-django-maas (no description available) un python-maas-client (no description available) un python-maas-provisioningserver (no description available) ii python3-django-maas 2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3) ii python3-maas-client 2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all MAAS python API client (Python 3) ii python3-maas-provisioningserver 2.2.0~beta2+bzr5717-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3) After re-commissioning one of the servers with ssh enabled the attached log files were collected. Please note that from the shell it can be seen that block devices are discovered and even the commissioning output found in /tmp/user_data.sh.IK9yVp/out/00-maas-07 -block-devices lists devices (see attached), where-as this file is shown as a 0 byte file from the GUI (see screen shot). There are 'HTTP Error 500: INTERNAL SERVER ERROR' errors in cloud- init-output.log ubuntu@azurill:~$ uname -a Linux azurill 4.8.0-34-generic #36~16.04.1-Ubuntu SMP Wed Dec 21 18:55:08 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux ubuntu@azurill:~$ sudo lsblk --exclude 1,2,7 -d -P -o NAME,RO,RM,MODEL,ROTA NAME="sdb" RO="0" RM="0" MODEL="LOGICAL VOLUME " ROTA="1" NAME="sdc" RO="1" RM="0" MODEL="VIRTUAL-DISK" ROTA="1" NAME="sda" RO="0" RM="0" MODEL="LOGICAL VOLUME " ROTA="1" NAME="nvme0n1" RO="0" RM="0" MODEL="INTEL SSDPEDME400G4 To manage notifications about this bug go to:
[Touch-packages] [Bug 1830955] Re: Systemd removes OpenVPN IP addresses
please boot with kernel boot parameter 'systemd.log_level=debug' and
reproduce this, then provide the journal logs (before rebooting) with:
$ journalctl -k -b > /tmp/lp1830955.log
** 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/1830955
Title:
Systemd removes OpenVPN IP addresses
Status in systemd package in Ubuntu:
Incomplete
Bug description:
This is probably related to, but not a duplicate of, bug 1815101.
Running
root@third:/home/leroy# lsb_release -rd
Description:Ubuntu 18.04.2 LTS
Release:18.04
Systemd version:
root@third:/home/leroy# apt-cache policy systemd
systemd:
Installed: 237-3ubuntu10.21
Candidate: 237-3ubuntu10.21
Version table:
*** 237-3ubuntu10.21 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64
Packages
100 /var/lib/dpkg/status
237-3ubuntu10.19 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
Packages
237-3ubuntu10 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
I expected the OpenVPN IP addresses to remain, instead they were
removed, the physical NIC address remained, process:
Start OpenVPN with systemctl start openvpn@ (in this
situation, two instances). Result:
root@third:/etc/openvpn# ip addr sh tun0
7: tun0: mtu 1500 qdisc fq_codel
state UNKNOWN group default qlen 100
link/none
inet 10.57.3.1 peer 10.57.3.2/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::f0ea:151b:cb91:5d1b/64 scope link stable-privacy
valid_lft forever preferred_lft forever
root@third:/etc/openvpn# ip addr sh tun1
8: tun1: mtu 1500 qdisc fq_codel
state UNKNOWN group default qlen 100
link/none
inet 10.222.108.234 peer 10.222.108.233/32 scope global tun1
valid_lft forever preferred_lft forever
inet6 fe80::3103:7936:cf19:6237/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Test a configuration (which, incidentally, isn't valid for this
system) with 'netplan try ..' and allow it to revert (which should
have restored the previous configuration), see below:
root@third:/etc/openvpn# cd ~leroy/Downloads
root@third:/home/leroy/Downloads# ll *.yaml
-rw-rw-r-- 1 leroy leroy 555 May 29 10:46 startup.yaml
root@third:/home/leroy/Downloads# netplan --debug try --config-file
~leroy/Downloads/startup.yaml --timeout 15
DEBUG:eno1 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
eno1:
addresses:
- 10.15.0.37/24
dhcp4: false
gateway4: 10.15.0.1
nameservers:
addresses:
- 10.15.0.8
- 10.3.77.11
- 10.45.77.11
- 8.8.8.8
vlans: {}
wifis: {}
DEBUG:New interfaces: {'eno1'}
** (generate:8216): DEBUG: 11:19:39.770: Processing input file
/etc/netplan/01-network-manager-all.yaml..
** (generate:8216): DEBUG: 11:19:39.771: starting new processing pass
** (generate:8216): DEBUG: 11:19:39.771: Processing input file
/etc/netplan/startup.1559146779.768221.yaml..
** (generate:8216): DEBUG: 11:19:39.771: starting new processing pass
** (generate:8216): DEBUG: 11:19:39.771: eno1: setting default backend to 2
** (generate:8216): DEBUG: 11:19:39.771: Generating output files..
** (generate:8216): DEBUG: 11:19:39.771: networkd: definition eno1 is not for
us (backend 2)
DEBUG:no netplan generated networkd configuration exists
DEBUG:netplan generated NM configuration exists, restarting NM
DEBUG:eno1 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
eno1:
addresses:
- 10.15.0.37/24
dhcp4: false
gateway4: 10.15.0.1
nameservers:
addresses:
- 10.15.0.8
- 10.3.77.11
- 10.45.77.11
- 8.8.8.8
vlans: {}
wifis: {}
DEBUG:Skipping non-physical interface: lo
DEBUG:Skipping non-physical interface: enp2s0
DEBUG:Skipping non-physical interface: virbr0
DEBUG:Skipping non-physical interface: virbr0-nic
DEBUG:Skipping non-physical interface: tun0
DEBUG:Skipping non-physical interface: tun1
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for enp2s0
DEBUG:netplan triggering .link rules for virbr0
DEBUG:netplan triggering .link rules for virbr0-nic
DEBUG:netplan triggering .link rules for tun0
DEBUG:netplan triggering .link rules for tun1
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 1 seconds
Reverting.
DEBUG:no netplan generated networkd configuration exists
DEBUG:netplan
[Touch-packages] [Bug 1837227] Re: Random mount units sometimes fail, while file system is correctly mounted
Just to follow up, a quick read of the upstream bug seems to indicate there are kernel patch(es) involved in fixing this as well as systemd patch(es). The upstream bug isn't yet marked fixed, so hopefully we can check back in the new year to start backporting. -- 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/1837227 Title: Random mount units sometimes fail, while file system is correctly mounted Status in systemd: New Status in systemd package in Ubuntu: New Bug description: In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1837227/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1871641] Re: Ubuntu never finishes booting: A start job is running for Hold until boot process finishes up (3min 7s / no limit) -- removing 'splash' kernel parm fixes it
it sounds like this bug is a dup of bug 1872159? I'm assuming so, and marking this invalid for systemd. ** Changed in: systemd (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1871641 Title: Ubuntu never finishes booting: A start job is running for Hold until boot process finishes up (3min 7s / no limit) -- removing 'splash' kernel parm fixes it Status in plymouth package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Bug description: Boot process freezes at the splash screen and nothing happens after that. The computer can be suspended and it is able to return from suspend. Boot is possible by pressing escape early in the process to bypass plymouth. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: plymouth 0.9.4git20200323-0ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu24 Architecture: amd64 Date: Wed Apr 8 14:30:13 2020 DefaultPlymouth: /usr/share/plymouth/themes/bgrt/bgrt.plymouth InstallationDate: Installed on 2020-04-08 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200402) MachineType: LENOVO 7469A23 ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-21-generic root=UUID=e12af5fd-b700-4292-8727-70345cb61c8e ro quiet splash vt.handoff=7 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-21-generic root=UUID=e12af5fd-b700-4292-8727-70345cb61c8e ro quiet splash vt.handoff=7 SourcePackage: plymouth TextPlymouth: /usr/share/plymouth/themes/ubuntu-text/ubuntu-text.plymouth UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/25/2012 dmi.bios.vendor: LENOVO dmi.bios.version: 6DET72WW (3.22 ) dmi.board.name: 7469A23 dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr6DET72WW(3.22):bd10/25/2012:svnLENOVO:pn7469A23:pvrThinkPadX200s:rvnLENOVO:rn7469A23:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.family: ThinkPad X200s dmi.product.name: 7469A23 dmi.product.version: ThinkPad X200s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1871641/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1874337] Re: resolvconf should never touch /etc/resolv.conf in Ubuntu; all DNS configuration from resolvconf, ifupdown, and dhclient should always be fed directly to systemd-reso
** Tags added: resolved-resolvconf -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1874337 Title: resolvconf should never touch /etc/resolv.conf in Ubuntu; all DNS configuration from resolvconf, ifupdown, and dhclient should always be fed directly to systemd-resolved. Status in ifupdown package in Ubuntu: New Status in resolvconf package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: systemd-resolved is a standard component of Ubuntu in 20.04. We should not have packages in the archive - some of which may be installed on users' systems as a result of upgrading from previous releases - that cause the handling of DNS resolution to diverge from the default. This means that: - the dhclient hook that picks up DNS settings should only feed settings directly to resolved, and not via resolvconf. - resolvconf must not change the target of /etc/resolv.conf and on upgrade must correct it. - resolvconf must feed its settings reliably into resolved rather than pulling resolved settings into resolvconf. - systemd should not ship a dhclient hook at all because dhclient is not used by any systems that use netplan for network management, it is only needed for compatibility on upgrade with ifupdown; so move the hook to the ifupdown package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1874337/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1891358] Re: systemd not respecting EXTEND_TIMEOUT_USEC when stopping service
can you boot with the kernel param 'systemd.log_level=debug' and recreate the problem, and then provide the full journal logs, e.g.: $ journalctl -b > /tmp/lp1891358.log ** 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/1891358 Title: systemd not respecting EXTEND_TIMEOUT_USEC when stopping service Status in systemd package in Ubuntu: Incomplete Bug description: It seems like systemd is not consistently respecting EXTEND_TIMEOUT_USEC. When I stop a service, it is being killed prematurely even after EXTEND_TIMEOUT_USEC was recently sent to systemd (however it is not killed immediately after the default TimeoutStopSec either). The service `ihm-eco-sputnik-agent.service` includes the following configuration: [Service] Restart=always RestartSec=5 Type=notify TimeoutStartSec=10 WatchdogSec=60 TimeoutStopSec=60 KillMode=mixed ... When I `systemctl restart ihm-eco-sputnik-agent.service`, I see the following logs in `journalctl`: ``` Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Trying to enqueue job ihm-eco-sputnik-agent.service/restart/replace Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Installed new job ihm-eco-sputnik-agent.service/restart as 1149303 Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Enqueued job ihm-eco-sputnik-agent.service/restart as 1149303 Aug 12 15:43:59 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Changed running -> stop-sigterm Aug 12 15:43:59 00044bcbe9bc systemd[1]: Stopping ihm-eco sputnik-agent... -- Subject: Unit ihm-eco-sputnik-agent.service has begun shutting down -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit ihm-eco-sputnik-agent.service has begun shutting down. Aug 12 15:44:49 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Got notification message from PID 19520 (WATCHDOG=1) Aug 12 15:44:49 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Got notification message from PID 19520 (EXTEND_TIMEOUT_USEC=6000) Aug 12 15:45:09 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Got notification message from PID 19520 (WATCHDOG=1) Aug 12 15:45:09 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Got notification message from PID 19520 (EXTEND_TIMEOUT_USEC=6000) Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: State 'stop-sigterm' timed out. Killing. Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Killing process 19520 (ihm-eco-sputnik) with signal SIGKILL. Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Killing process 21114 (systemctl) with signal SIGKILL. Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Killing process 2 (200_IhmEcoDeplo) with signal SIGKILL. Aug 12 15:45:10 00044bcbe9bc systemd[1]: ihm-eco-sputnik-agent.service: Main process exited, code=killed, status=9/KILL ``` I'm not sure if this is related but I'm also seeing the application successfully writing notification messages which systemd apparently doesn't receive (they aren't logged). lsb_release -rd: ``` Description: Ubuntu 18.04.5 LTS Release: 18.04 ``` apt-cache policy systemd: ``` systemd: Installed: 237-3ubuntu10.42 Candidate: 237-3ubuntu10.42 Version table: *** 237-3ubuntu10.42 500 500 s3://ihm-eco-apt-repository-us-west-2.s3-accelerate.amazonaws.com/ihm-eco-apt-repository-us-west-2 bionic-20200810/ubuntu arm64 Packages 100 /var/lib/dpkg/status ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1891358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1905166] Re: systemd-shutdown cannot detach DM
please reboot with this kernel boot parameter added: systemd.log_level=debug Then let the system boot up, and then perform a shutdown, to reproduce the problem. Then start the system back up (you can remove the kernel boot parameter) and capture the previous boot's journal, which should include the problem reproduction while debug is enabled; you can use the command: $ journalctl -k -b -1 > /tmp/lp1905166.log which will capture the log output from the previous boot. ** Changed in: systemd (Ubuntu) Status: Confirmed => 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/1905166 Title: systemd-shutdown cannot detach DM Status in systemd package in Ubuntu: Incomplete Bug description: when powering down the system systemd cannot unmount / systemd-shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy systemd-shutdown[1]: Failed to finalize DM devices, ignoring reboot: Power down as a result at each startup the filesystem is checked: Press Ctrl+C to cancel all filesystem checks in progress If systemd cannot unmount / that might not be a problem but it should be less noisy and not result in a filesystem check after each reboot. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.3 ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65 Uname: Linux 5.4.0-54-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.12 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sun Nov 22 11:40:05 2020 MachineType: Dell Inc. Latitude 7410 ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-54-generic root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/11/2020 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.4.1 dmi.board.name: 0M5G57 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 31 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.4.1:bd10/11/2020:svnDellInc.:pnLatitude7410:pvr:rvnDellInc.:rn0M5G57:rvrA00:cvnDellInc.:ct31:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7410 dmi.product.sku: 09CD dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905166/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907814] [NEW] This is not an official Ubuntu package. (but it was, yesterday!)
Public bug reported: This is a special case of Bug 559345 somewhere between a question and a request for better/more discoverable error message/documentation. In apport, because thats what people encountering bugs are going to use. In USN, because the one thing worse than no security notices is incorrect advice. In the package changelog, because reverts are confusing enough already. Proposed fix, among others: Add two URLs to the apport error messages. One to the relevant "https://changelogs.ubuntu.com/; site which apt should still know, package in Relaase or not, which hopefully by then includes a note about a package rebuild to clarify the revert. And another one to any relevant "https://ubuntu.com/security/notices/?details=package; site, if you are able to keep the search URL stable long enough for that to reliably present a list of related USNs. Background: `ubuntu-bug linux` will not let me report the kernel regression I ran into.. because the package went AWOL (linux-image-5.8.0-31-generic, linux-image-5.4.0-56-generic, .. as announced from https://ubuntu.com/security/notices/USN-4658-1) Since I might now have two tentatively non-reproducible versions, one reproducible in between and presumably one upcoming that re-introduces the potentially responsible security backports, bisecting will be much easier with some knowledge of the order of backports applied. ** Affects: apport (Ubuntu) Importance: Undecided Status: New -- 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/1907814 Title: This is not an official Ubuntu package. (but it was, yesterday!) Status in apport package in Ubuntu: New Bug description: This is a special case of Bug 559345 somewhere between a question and a request for better/more discoverable error message/documentation. In apport, because thats what people encountering bugs are going to use. In USN, because the one thing worse than no security notices is incorrect advice. In the package changelog, because reverts are confusing enough already. Proposed fix, among others: Add two URLs to the apport error messages. One to the relevant "https://changelogs.ubuntu.com/; site which apt should still know, package in Relaase or not, which hopefully by then includes a note about a package rebuild to clarify the revert. And another one to any relevant "https://ubuntu.com/security/notices/?details=package; site, if you are able to keep the search URL stable long enough for that to reliably present a list of related USNs. Background: `ubuntu-bug linux` will not let me report the kernel regression I ran into.. because the package went AWOL (linux-image-5.8.0-31-generic, linux-image-5.4.0-56-generic, .. as announced from https://ubuntu.com/security/notices/USN-4658-1) Since I might now have two tentatively non-reproducible versions, one reproducible in between and presumably one upcoming that re-introduces the potentially responsible security backports, bisecting will be much easier with some knowledge of the order of backports applied. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1907814/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1887968] Re: Pairing with Bluetooth LE mice fails on a Huawei Matebook 13 AMD laptop with Realtek RTL8822CE Wifi/Bluetooth combo adapter
I checked on kernel 5.9.12 Ubuntu 20.04 Huawei amd D13 , problem not
solved
--
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/1887968
Title:
Pairing with Bluetooth LE mice fails on a Huawei Matebook 13 AMD
laptop with Realtek RTL8822CE Wifi/Bluetooth combo adapter
Status in Linux:
Confirmed
Status in bluez package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
I'm using Ubuntu 20.04 on a Huawei Matebook 13 AMD laptop which seems
to use a Realtek RTL8822CE Wifi/Bluetooth combo adapter.
I've been unsuccessful to pair with 2 different bluetooth mice.
However bluetooth seems to work with other devices. I'm under the
impression that this problem only happens with Bluetooth LE devices.
Trying to pair using bluetoothctl fails with the
org.bluez.Error.AuthenticationCanceled error:
[bluetooth]# pair E5:5B:67:2A:09:76
Attempting to pair with E5:5B:67:2A:09:76
[CHG] Device E5:5B:67:2A:09:76 Connected: yes
[CHG] Device E5:5B:67:2A:09:76 Connected: no
Failed to pair: org.bluez.Error.AuthenticationCanceled
A quick google search for org.bluez.Error.AuthenticationCanceled
reported nothing relevant.
Running btmon while trying to pair with the device gives me the
following:
Bluetooth monitor ver 5.53
= Note: Linux version 5.4.0-40-generic (x86_64)
0.998188
= Note: Bluetooth subsystem version 2.22
0.998193
= New Index: E8:6F:38:9C:2B:3C (Primary,USB,hci0)
[hci0] 0.998194
= Open Index: E8:6F:38:9C:2B:3C
[hci0] 0.998195
= Index Info: E8:6F:38:9C:2B:3C (Realtek Semiconductor Corporation)
[hci0] 0.998197
@ MGMT Open: bluetoothd (privileged) version 1.14
{0x0001} 0.998198
@ MGMT Open: btmon (privileged) version 1.14
{0x0002} 0.998310
@ MGMT Command: Pair Device (0x0019) plen 8
{0x0001} [hci0] 8.162442
LE Address: E5:5B:67:2A:09:76 (Static)
Capability: KeyboardDisplay (0x04)
< HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8
#1 [hci0] 8.162527
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
PHYs: 0x01
Entry 0: LE 1M
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
> HCI Event: Command Complete (0x0e) plen 4
#2 [hci0] 8.284618
LE Set Extended Scan Parameters (0x08|0x0041) ncmd 2
Status: Success (0x00)
< HCI Command: LE Set Extended Scan Enable (0x08|0x0042) plen 6
#3 [hci0] 8.284654
Extended scan: Enabled (0x01)
Filter duplicates: Enabled (0x01)
Duration: 0 msec (0x)
Period: 0.00 sec (0x)
> HCI Event: Command Complete (0x0e) plen 4
#4 [hci0] 8.289616
LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 52
#5 [hci0] 8.343614
LE Extended Advertising Report (0x0d)
Num reports: 1
Entry 0
Event type: 0x0013
Props: 0x0013
Connectable
Scannable
Use legacy advertising PDUs
Data status: Complete
Legacy PDU Type: ADV_IND (0x0013)
Address type: Random (0x01)
Address: E5:5B:67:2A:09:76 (Static)
Primary PHY: LE 1M
Secondary PHY: No packets
SID: no ADI field (0xff)
TX power: 127 dBm
RSSI: -20 dBm (0xec)
Periodic advertising invteral: 0.00 msec (0x)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Data length: 0x1a
[Touch-packages] [Bug 1907789] Re: 2.35.50 breaks ld -no-pie
** Changed in: binutils (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils package in Ubuntu: Fix Committed Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907789] [NEW] 2.35.50 breaks ld -no-pie
Public bug reported: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD ** Affects: binutils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils package in Ubuntu: New Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907789] Re: 2.35.50 breaks ld -no-pie
** Attachment added: "linuxboot.o - build artifact to re-create the issue" https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+attachment/5442724/+files/linuxboot.o -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils package in Ubuntu: New Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907789] Re: 2.35.50 breaks ld -no-pie
** Attachment added: "flat.lds - build artifact to re-create the issue" https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+attachment/5442723/+files/flat.lds -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils package in Ubuntu: New Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
