[Touch-packages] [Bug 1852837] Re: Ubuntu 19.10 boots into blinking underscore when manually restart, not even grub shows up!
** Package changed: xorg (Ubuntu) => linux (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/1852837 Title: Ubuntu 19.10 boots into blinking underscore when manually restart, not even grub shows up! Status in linux package in Ubuntu: New Bug description: Hello, I didn't exactly know which category to slected during bug report submission, but after I updated my Ubuntu 19.10 installation yesterday, whenever I press restart either through gui or terminal the system boot into blinking underscore immediately after bios post screen. Not even grub menu shows up. I have to shutdown the system, then turn it on again to fix the problem. The system boot normally from a shutdown. I have already tried clean installing Ubuntu 19.10 but the problem returned after installing the updates by executing sudo apt upgrade command! I guess this issue happens after upgrading the linux-firmware package to the latest 1.183.2 version. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7 Uname: Linux 5.3.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia .proc.driver.nvidia.gpus..65.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:65:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 435.21 Sun Aug 25 08:17:57 CDT 2019 GCC version: gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2) ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Nov 15 22:56:48 2019 DistUpgraded: Fresh install DistroCodename: eoan DistroVariant: ubuntu DkmsStatus: nvidia, 435.21, 5.3.0-18-generic, x86_64: installed nvidia, 435.21, 5.3.0-23-generic, x86_64: installed GraphicsCard: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GP107 [GeForce GTX 1050 Ti] [1043:85d1] InstallationDate: Installed on 2019-11-16 (0 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: System manufacturer System Product Name ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-23-generic root=UUID=c39caed8-873a-4a54-a075-6917258f368e ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/25/2019 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2002 dmi.board.asset.tag: Default string dmi.board.name: PRIME X299-DELUXE dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2002:bd09/25/2019:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX299-DELUXE:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: ASUS_MB_KBLX dmi.product.version: System Version dmi.sys.vendor: System manufacturer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1852837/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843381] Re: Dell system takes a long time to connect network with external dock
** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Invalid Bug description: [impact] On Dell system with BIOS-based "MAC passthrough", there can be multiple USB nics with identical MAC addresses. Since the udev rules in Debian and Ubuntu assign interface names for USB nics by mac address (because that is the only consistent identifier for USB nics; their path can change based on which USB port they are connected to), it's impossible to name two interfaces with the same name. As Ubuntu also carries a patch to retry renaming of any interface when the first renaming fails, this causes a 90 second delay before being able to the "MAC passthrough" nic after connecting it. [test case] On a system with this "MAC passthrough" enabled and required devices, boot the system and then connect to the dock or connect the second USB nic with identical MAC. It will not be usable for 90 seconds as its renames takes that long to timeout. [regression potential] the change here is very limited to only Dell systems with the specific USB vendor/product ID affected by this, and additionally the change only sets a ENV flag in the udev rule, which is later used by udevd to skip the rename-retries for 90 seconds. So, the regression potential for anyone else without a system affected by this "MAC passthrough" should be very low, and any regression potential for those with this "MAC passthrough" should still be low, as this only skips the rename- retry that we know will never succeed. However, the regression potential is likely limited to failure to properly name a USB nic, or other bugs during the udev processing of new USB nics. [other info] original description: --- This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed
[Touch-packages] [Bug 854762] Re: pocketsphinx_batch throws ERROR
[Expired for pocketsphinx (Ubuntu) because there has been no activity for 60 days.] ** Changed in: pocketsphinx (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pocketsphinx in Ubuntu. https://bugs.launchpad.net/bugs/854762 Title: pocketsphinx_batch throws ERROR Status in pocketsphinx package in Ubuntu: Expired Bug description: ERROR: "cmd_ln.c", line 644: cmd_ln_parse_r failed there are no man pages tarvid@tarvid-Dimension-8300:~$ lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 tarvid@tarvid-Dimension-8300:~$ apt-cache policy pocketsphinx-utils pocketsphinx-utils: Installed: 0.5.1+dfsg1-0ubuntu2 Candidate: 0.5.1+dfsg1-0ubuntu2 Version table: *** 0.5.1+dfsg1-0ubuntu2 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/universe i386 Packages 100 /var/lib/dpkg/status I expected it to run without errors -and - I expected man pages. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: pocketsphinx-utils 0.5.1+dfsg1-0ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-11.48-generic 2.6.38.8 Uname: Linux 2.6.38-11-generic i686 NonfreeKernelModules: nvidia Architecture: i386 Date: Tue Sep 20 10:43:36 2011 InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110427.1) ProcEnviron: LANGUAGE=en_US:en LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: pocketsphinx UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pocketsphinx/+bug/854762/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 863533] Re: PocketSphinx Segmentation Fault
[Expired for pocketsphinx (Ubuntu) because there has been no activity for 60 days.] ** Changed in: pocketsphinx (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pocketsphinx in Ubuntu. https://bugs.launchpad.net/bugs/863533 Title: PocketSphinx Segmentation Fault Status in pocketsphinx package in Ubuntu: Expired Bug description: The ps_test.py file included in the python-pocketsphinx doesn't work out of the box since it refers to paths ../model/hmm/wsj1, ../test/data/wsj/wlist5o.nvp.lm.DMP, and ../model/lm/cmudict.0.6d, which don't seem to exist anywhere in the other pocketsphinx packages. The most similar paths I could find, provided by the pocketsphinx-hmm- wsj1 and pocketsphinx-lm-wsj packages, are /usr/share/pocketsphinx/model/hmm/wsj1, /usr/share/pocketsphinx/model/lm/wsj/wlist5o.3e-7.vp.tg.lm.DMP, /usr/share/pocketsphinx/model/lm/wsj/wlist5o.dic. However, replacing the paths in ps_test.py with those results in the error: INFO: cmd_ln.c(506): Parsing command line: \ -hmm /usr/share/pocketsphinx/model/hmm/wsj1 \ -fwdtree yes \ -dict /usr/share/pocketsphinx/model/lm/wsj/wlist5o.dic \ -lm /usr/share/pocketsphinx/model/lm/wsj/wlist5o.3e-7.vp.tg.lm.DMP \ -fwdflat yes \ -bestpath no Current configuration: [NAME][DEFLT] [VALUE] -agc nonenone -agcthresh2.0 2.00e+00 -alpha0.979.70e-01 -ascale 20.02.00e+01 -backtraceno no -beam 1e-48 1.00e-48 -bestpath yes no -bestpathlw 9.5 9.50e+00 -cep2spec no no -ceplen 13 13 -cmn current current -cmninit 8.0 8.0 -compallsen no no -dict /usr/share/pocketsphinx/model/lm/wsj/wlist5o.dic -dictcase no no -dither no no -doublebw no no -ds 1 1 -fdict -feat 1s_c_d_dd 1s_c_d_dd -featparams -fillprob 1e-81.00e-08 -frate100 100 -fsg -fsgusealtpronyes yes -fsgusefiller yes yes -fwdflat yes yes -fwdflatbeam 1e-64 1.00e-64 -fwdflatefwid 4 4 -fwdflatlw8.5 8.50e+00 -fwdflatsfwin 25 25 -fwdflatwbeam 7e-29 7.00e-29 -fwdtree yes yes -hmm /usr/share/pocketsphinx/model/hmm/wsj1 -input_endian little little -jsgf -kdmaxbbi -1 -1 -kdmaxdepth 0 0 -kdtree -latsize 50005000 -lda -ldadim 0 0 -lifter 0 0 -lm /usr/share/pocketsphinx/model/lm/wsj/wlist5o.3e-7.vp.tg.lm.DMP -lmctl -lmname default default -logbase 1.0001 1.000100e+00 -logfn -logspec no no -lowerf 133.4 1.33e+02 -lpbeam 1e-40 1.00e-40 -lponlybeam 7e-29 7.00e-29 -lw 6.5 6.50e+00 -maxhistpf100 100 -maxhmmpf -1 -1 -maxnewoov20 20 -maxwpf -1 -1 -mdef -mean -mfclogdir -mixw -mixwfloor0.001 1.00e-07 -mmap yes yes -ncep 13 13 -nfft 512 512 -nfilt40 40 -nwpen1.0 1.00e+00 -pbeam1e-48 1.00e-48 -pip 1.0 1.00e+00 -rawlogdir -remove_dcno no -round_filtersyes yes -samprate 16000 1.60e+04 -sdmap -seed -1 -1 -sendump -silprob 0.005 5.00e-03 -smoothspec no no -spec2cep no no -svspec -tmat -tmatfloor0.0001 1.00e-04 -topn 4 4 -toprule -transformlegacy legacy -unit_area
[Touch-packages] [Bug 1318103] Re: Error importing Python module pocketsphinx
[Expired for pocketsphinx (Ubuntu) because there has been no activity for 60 days.] ** Changed in: pocketsphinx (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pocketsphinx in Ubuntu. https://bugs.launchpad.net/bugs/1318103 Title: Error importing Python module pocketsphinx Status in pocketsphinx package in Ubuntu: Expired Bug description: Pretty much stock standard Ubuntu 14.04 AMD64 with no manually compiled software and no manually installed python modules. $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pocketsphinx Traceback (most recent call last): File "", line 1, in File "sphinxbase.pxd", line 150, in init pocketsphinx (pocketsphinx.c:7935) ValueError: PyCapsule_GetPointer called with invalid PyCapsule object >>> To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pocketsphinx/+bug/1318103/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852837] [NEW] Ubuntu 19.10 boots into blinking underscore when manually restart, not even grub shows up!
Public bug reported: Hello, I didn't exactly know which category to slected during bug report submission, but after I updated my Ubuntu 19.10 installation yesterday, whenever I press restart either through gui or terminal the system boot into blinking underscore immediately after bios post screen. Not even grub menu shows up. I have to shutdown the system, then turn it on again to fix the problem. The system boot normally from a shutdown. I have already tried clean installing Ubuntu 19.10 but the problem returned after installing the updates by executing sudo apt upgrade command! I guess this issue happens after upgrading the linux-firmware package to the latest 1.183.2 version. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7 Uname: Linux 5.3.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia .proc.driver.nvidia.gpus..65.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:65:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 435.21 Sun Aug 25 08:17:57 CDT 2019 GCC version: gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2) ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Nov 15 22:56:48 2019 DistUpgraded: Fresh install DistroCodename: eoan DistroVariant: ubuntu DkmsStatus: nvidia, 435.21, 5.3.0-18-generic, x86_64: installed nvidia, 435.21, 5.3.0-23-generic, x86_64: installed GraphicsCard: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GP107 [GeForce GTX 1050 Ti] [1043:85d1] InstallationDate: Installed on 2019-11-16 (0 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: System manufacturer System Product Name ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-23-generic root=UUID=c39caed8-873a-4a54-a075-6917258f368e ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/25/2019 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2002 dmi.board.asset.tag: Default string dmi.board.name: PRIME X299-DELUXE dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2002:bd09/25/2019:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEX299-DELUXE:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: ASUS_MB_KBLX dmi.product.version: System Version dmi.sys.vendor: System manufacturer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug eoan 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/1852837 Title: Ubuntu 19.10 boots into blinking underscore when manually restart, not even grub shows up! Status in xorg package in Ubuntu: New Bug description: Hello, I didn't exactly know which category to slected during bug report submission, but after I updated my Ubuntu 19.10 installation yesterday, whenever I press restart either through gui or terminal the system boot into blinking underscore immediately after bios post screen. Not even grub menu shows up. I have to shutdown the system, then turn it on again to fix the problem. The system boot normally from a shutdown. I have already tried clean installing Ubuntu 19.10 but the problem returned after installing the updates by executing sudo apt upgrade command! I guess this issue happens after upgrading the linux-firmware package to the latest 1.183.2 version.
[Touch-packages] [Bug 1843381] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Invalid Bug description: [impact] On Dell system with BIOS-based "MAC passthrough", there can be multiple USB nics with identical MAC addresses. Since the udev rules in Debian and Ubuntu assign interface names for USB nics by mac address (because that is the only consistent identifier for USB nics; their path can change based on which USB port they are connected to), it's impossible to name two interfaces with the same name. As Ubuntu also carries a patch to retry renaming of any interface when the first renaming fails, this causes a 90 second delay before being able to the "MAC passthrough" nic after connecting it. [test case] On a system with this "MAC passthrough" enabled and required devices, boot the system and then connect to the dock or connect the second USB nic with identical MAC. It will not be usable for 90 seconds as its renames takes that long to timeout. [regression potential] the change here is very limited to only Dell systems with the specific USB vendor/product ID affected by this, and additionally the change only sets a ENV flag in the udev rule, which is later used by udevd to skip the rename-retries for 90 seconds. So, the regression potential for anyone else without a system affected by this "MAC passthrough" should be very low, and any regression potential for those with this "MAC passthrough" should still be low, as this only skips the rename- retry that we know will never succeed. However, the regression potential is likely limited to failure to properly name a USB nic, or other bugs during the udev processing of new USB nics. [other info] original description: --- This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules
[Touch-packages] [Bug 1783994] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1783994 Title: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] on systems with mmc device installed, systemd-gpt-auto-generator fails. [test case] on a system with mmc device installed, run systemd-gpt-auto-generator and check log for: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error [regression potential] as this is related to boot, regressions might occur at boot, or while modifying or configuring a boot loader. [other info] original description: --- If a device has an mmc installed, systemd-gpt-auto-generator will fail because of "special partition" (rpmb, boot) and record a log message: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error This issue was discussed here: https://github.com/systemd/systemd/issues/5806 and a fix is proposed for new systemd versions. Please include in bionic. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1783994/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1796501] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Bug description: [impact] an NXDOMAIN response from a dns server when systemd-resolved is configured as DNSSEC=yes breaks dns resolution as it downgrades from DNSSEC. [test case] see comment 9 [regression potential] as with the original patch that introduced this problem, this has the potential to break dns resolution. [other info] original description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840640] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic
have finished running.
The following regressions have been reported in tests triggered by the package:
gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64)
dovecot/1:2.2.33.2-1ubuntu4.5 (armhf)
umockdev/0.11.1-1 (ppc64el)
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#systemd
[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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1840640
Title:
sync_file_range fails in nspawn containers on arm, ppc
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Disco:
Fix Committed
Bug description:
[impact]
calling the glibc function sync_file_range() on a armhf nspawn
container fails.
[test case]
see sample C program from original description below. compile and run
that inside a nspawn container on armhf and it will fail.
nspawn instructions:
sudo apt install debootstrap systemd-container
sudo -i
debootstrap --arch=armhf bionic ~/bionic-tree/
systemd-nspawn -D ~/bionic-tree/
[regression potential]
this only adjusts nspawn to allow the sync_file_range2 syscall which
is used on armhf, so the regression potential is very low. any
possible regressions would likely be when calling sync_file_range().
[other info]
original description:
---
ARM has two sync_file_range syscalls, sync_file_range and
sync_file_range2. The former is apparently not used, and glibc calls
the latter whenever a userspace program calls sync_file_range. I'm
guessing systemd-nspawn doesn't know this, because the follow code
consistently fails in an nspawn container on ARM:
#define _GNU_SOURCE
#include
#include
#include
#include
void main()
{
int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
int r=sync_file_range(f, 0, 0, 0);
if (r)
perror("sync_file_range");
close(f);
}
This seems to be causing problems specifically for borg(backup) and
postgres:
https://github.com/borgbackup/borg/issues/4710
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
The solution should be to cherrypick
https://github.com/systemd/systemd/pull/13352, I am currently waiting
for systemd to rebuild on a slow ARM box. Any chance of an SRU?
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd-container 237-3ubuntu10.24
Uname: Linux 4.14.66+ armv7l
NonfreeKernelModules: extcon_usb_gpio
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: armhf
Date: Mon Aug 19 11:10:48 2019
ProcEnviron:
TERM=screen
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1840640/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849733] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849733 Title: resolved incorrectly limits TCP reply to edns0 payload Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: [impact] glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its payload limit to 1200. When the response is larger than 1200, resolved will limit the response and set the truncate flag. This causes getaddrinfo() to switch to TCP and request again, but glibc incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit. Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC it applies only to UDP, but resolved does not and again marks the response as truncated. This prevents getaddrinfo() from being able to resolve any records with a response over 1200 bytes. [test case] use ping or telnet, which use getaddrinfo(), to lookup an A record with a lot of results, like toomany100.ddstreet.org $ telnet toomany100.ddstreet.org telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure in name resolution [regression potential] any regression would likely result in failure to correctly lookup a hostname or to provide the correct response to a local client. [other info] note that on Bionic, this also requires backporting TCP pipelining support in the stub resolver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1850704] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1850704 Title: networkd doesn't set MTUBytes if interface is already up Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] if a networkd .network file specifies a [Link] section with MTUBytes=XXX set, networkd will only apply that mtu if the interface is down when networkd starts; if the interface is already up, the mtu won't be applied. [test case] on a bionic system, create a .network file like: [Match] Name=ens8 [Link] MTUBytes= then, reboot. The interface should be set correctly with that mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff now, manually change the interface back to 1500 mtu, and restart networkd, then recheck the mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo ip l set mtu 1500 dev ens8 $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo systemctl restart systemd-networkd $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff [regression potential] low, but any regression would likely involve failure to correctly set the configured mtu. this is needed only in bionic, it's fixed in disco and later already. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1850704/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852754] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1852754 Title: networkd does not complete interface configuration if Link MTUBytes is set Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] interfaces configured with .network file [Link] section specifying MTUBytes will not be successfully brought up. [test case] configure interface e.g. Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [Link] MTUBytes=1550 start/restart networkd, the interface will never reach 'routable' stage and will not get an IPv4 address. [regression potential] any regressions would likely occur during networkd configuration/startup/restart, and would likely cause failure to successfully setup the interface. [other info] this is a regression-proposed caused by incomplete backport for bug 1850704 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1852754/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849658] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1849658 Title: resolved fallback to TCP fails for truncated UDP replies Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] for DNS UDP replies larger than 512 bytes, fallback to TCP is used. For example 'host toomany.ddstreet.org'. Due to a bug in resolved in refcounting DNS stream types, the refcount underflows for type 0 streams (which resolved uses to talk to upstream nameservers), resulting in resolved being unable to fallback to TCP to handle truncated UDP replies. [test case] ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 24 11:40:29 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; connection timed out; no servers could be reached [regression potential] very low, as this only properly sets the stream type in the DnsStream object; any regression would be a failure to be able to use TCP for DNS requests or replies. [other info] https://github.com/systemd/systemd/pull/13838 The commit adding stream types is not present in x/b, so this is needed only for disco and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832672] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1832672 Title: systemd-resolve not ignoring comments in /etc/hosts Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] resolved does not ignore comments properly in /etc/hosts [test case] see original description below [regression potential] as this modifies resolved parsing of /etc/hosts, regressions would likely be in hostname lookups from hosts in /etc/hosts, or failure(s) to parse /etc/hosts correctly. [other info] original description: --- $ lsb_release -rd Description: Ubuntu 18.04.2 LTS Release: 18.04 $ LANG=C apt-cache policy systemd systemd: Installed: 237-3ubuntu10.22 Candidate: 237-3ubuntu10.22 Version table: *** 237-3ubuntu10.22 500 500 http://ch.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://ch.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 500 http://mirrors.kernel.org/ubuntu bionic/main amd64 Packages $ head -1 /etc/hosts 127.0.2.1 foo # bar $ /usr/bin/systemd-resolve -4 bar expected -- bar: resolve call failed: 'bar' not found What happened instead - bar: 127.0.2.1 HOSTS(5) > Text from a "#" character until the end of the line is a comment, and is ignored. This is fixed in upstream: https://github.com/systemd/systemd/issues/10779 https://github.com/systemd/systemd/commit/bd0052777981044cf54a1e9d6e3acb1c3d813656 Please backport to current LTS version. I accidentally connected to wrong systems because of this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1832672/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1805183] Autopkgtest regression report (systemd/237-3ubuntu10.33)
All autopkgtests for the newly accepted systemd (237-3ubuntu10.33) for bionic have finished running. The following regressions have been reported in tests triggered by the package: gvfs/1.36.1-0ubuntu1.3.3 (ppc64el, amd64) dovecot/1:2.2.33.2-1ubuntu4.5 (armhf) umockdev/0.11.1-1 (ppc64el) 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#systemd [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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu Date: Mon Nov 26 16:17:52 2018 PackageArchitecture: all SourcePackage: ubuntu-release-upgrader UpgradeStatus: No upgrade
[Touch-packages] [Bug 1827757] Re: PMF
A better workaround solution to this problem is the systemd wpa_supplicant.service override. This is better than messing with broken packages and versions. Here is my systemd override.conf (you can apply it with `systemctl edit wpa_supplicant`): [Service] Environment="LD_PRELOAD=/path_to_wpa_bundle_dir/libm.so.6" ExecStart= ExecStart=/path_to_wpa_bundle_dir/wpa_supplicant -u -s -O /run/wpa_supplicant is just a custom folder that consists of wpa_supplicant binary from package wpasupplicant_2.9-1ubuntu2_amd64.deb + libm-2.30.so from package libc6_2.30-0ubuntu2_amd64.deb and libm.so.6 which is a symlink to the libm-2.30.so in the same folder. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1827757 Title: PMF Status in wpa package in Ubuntu: Confirmed Bug description: WPA Supplicant packaged with Ubuntu doesn't support PMF. PMF support has been available in wpa supplicant for about 3 years now and in couple of major releases. PMF is a security feature and should be supported (at least at the level when it needs to be manually enabled). Thanks! ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: wpasupplicant 2:2.6-21ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6 Uname: Linux 5.0.0-13-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 CurrentDesktop: MATE Date: Sat May 4 23:55:42 2019 InstallationDate: Installed on 2016-02-20 (1169 days ago) InstallationMedia: Ubuntu-MATE 15.10 "Wily Werewolf" - Release amd64 (20151021) SourcePackage: wpa UpgradeStatus: Upgraded to disco on 2019-05-02 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1827757/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1851340] Re: Ubuntu 19.10 upgrade results in invisible mouse cursor
Seeing same problem on my xubuntu machine after upgrade to 19.10. I tried different GDM's (xubuntu, gnome, xfce) and tried different themes (default, Adwaita, Breeze, DMZ). I have basic Intel graphics card with minimal capabilities, and machine is used in production so I'm unable to experiment much further. Logitech trackball mouse. I don't see anything obvious in logs. Everything was working properly prior to upgrade. I'm able to use the mouse to select and click, just no cursor is being display so it's hard to see where the pointer is located. I'm assuming this problem is related to this bug. -- 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/1851340 Title: Ubuntu 19.10 upgrade results in invisible mouse cursor Status in xorg package in Ubuntu: Confirmed Bug description: Following in place upgrade of Ubuntu 19.04 -> 19.10 I no longer have visible cursor with my Gnone desktop. I have found the same problem when upgrading 2 machines from Ubuntu 19.04 -> 19.10. Reproducing problem is easy: 1. Open Ubuntu Update Window 2. Select "Upgrade" 3. On completion of update (after reboot) cursor is no longer visible. 4. This applies to display connected to VGA port on host with USB Keyboard + Mouse While the connected display has no visible cursor and so is usable, I have always used X11VNC Server to provide network GUI access. On the remote X11VNC display I see and can use the cursor. This bug report is being sent via Remote X11VNC window, as I cannot use the main VGA display window (due to lack of visible cursor) I have done search online and thought that maybe issue was with my USB Mighty Mouse, so I also tried with Logitech M100R USB Mouse. Same result, no visible mouse cursor. I have done: "grep usb /var/log/syslog" and can see many USB events, including both Apple and Logitech mouse detection events. NOTE: Due to compatibility issue with X11VNC, I have disable Wayland on both machines by adding the following option to: /etc/gdm3/custom.conf WaylandEnable=false Regards, John Hartley. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1 Uname: Linux 5.3.0-19-generic x86_64 ApportVersion: 2.20.11-0ubuntu8.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Nov 5 18:25:23 2019 DistUpgraded: 2019-11-05 15:20:04,402 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: eoan DistroVariant: ubuntu GraphicsCard: Matrox Electronics Systems Ltd. G200eR2 [102b:0534] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Lenovo G200eR2 [1d49:0a01] InstallationDate: Installed on 2018-12-17 (322 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) MachineType: LENOVO System x3650 M5: -[8871AC1]- ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-19-generic root=UUID=3b8f415b-7e78-461c-83df-64f1f1a7826a ro ipv6.disable=1 quiet splash iommu=1 intel_iommu=on ipv6.disable=1 vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to eoan on 2019-11-05 (0 days ago) dmi.bios.date: 06/03/2019 dmi.bios.vendor: LENOVO dmi.bios.version: -[TCE140H-2.91]- dmi.board.asset.tag: (none) dmi.board.name: 01KN179 dmi.board.vendor: LENOVO dmi.board.version: NULL dmi.chassis.asset.tag: none dmi.chassis.type: 23 dmi.chassis.vendor: LENOVO dmi.chassis.version: none dmi.modalias: dmi:bvnLENOVO:bvr-[TCE140H-2.91]-:bd06/03/2019:svnLENOVO:pnSystemx3650M5-[8871AC1]-:pvr13:rvnLENOVO:rn01KN179:rvrNULL:cvnLENOVO:ct23:cvrnone: dmi.product.family: System X dmi.product.name: System x3650 M5: -[8871AC1]- dmi.product.sku: (none) dmi.product.version: 13 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1851340/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1847896] Re: Unable to shutdown or restart from log-in screen
After a few tests, I confirm that the bug looks fixed to me. -- 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/1847896 Title: Unable to shutdown or restart from log-in screen Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] * Shutdown and restart options don't work from the login screen, when the user is not logged in. [Test Case] * Start the system and don't log in, or log out in case the system is set up with autologin. * Restart, then shut down the system using the option in the upper right corner of the login screen. * Observe both operations working. [Regression Potential] * The fix is treating treating the greeter as user display sessions by cherry-picking upstream's change released in v243. The fix itself is very small, but there may be non-obvious security implications. [Original Bug Text] When selecting the shutdown icon from the log-in screen you are prompted with a dialog that allows you to either cancel, restart or shutdown. It has been noted that the restart and shutdown options no longer work. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 13 09:08:23 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-05-17 (148 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517) RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1847896] Re: Unable to shutdown or restart from log-in screen
After a few tests, I confirm that the bug looked fixed to me. -- 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/1847896 Title: Unable to shutdown or restart from log-in screen Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] * Shutdown and restart options don't work from the login screen, when the user is not logged in. [Test Case] * Start the system and don't log in, or log out in case the system is set up with autologin. * Restart, then shut down the system using the option in the upper right corner of the login screen. * Observe both operations working. [Regression Potential] * The fix is treating treating the greeter as user display sessions by cherry-picking upstream's change released in v243. The fix itself is very small, but there may be non-obvious security implications. [Original Bug Text] When selecting the shutdown icon from the log-in screen you are prompted with a dialog that allows you to either cancel, restart or shutdown. It has been noted that the restart and shutdown options no longer work. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 13 09:08:23 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-05-17 (148 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517) RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1765775] Re: Window decoration becomes very large if the image has much more height than width
Upstream stated that it's fixed in gtk 3.24 which is newer Ubuntu series, closing. The bug can still make to target bionic if we believe a SRU for it should be workedon ** Changed in: gtk+3.0 (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1765775 Title: Window decoration becomes very large if the image has much more height than width Status in gtk+3.0 package in Ubuntu: Fix Released Bug description: When a image with much higher height than width is opened, the window decoration becomes very big, as it tries to keep the image proportional: https://i.imgur.com/SZu0lOk.png ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: eog 3.28.1-1 Uname: Linux 4.16.3-041603-generic x86_64 ApportVersion: 2.20.9-0ubuntu5 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Apr 20 13:08:37 2018 InstallationDate: Installed on 2017-06-13 (310 days ago) InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) SourcePackage: eog UpgradeStatus: Upgraded to bionic on 2017-10-20 (182 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1765775/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1765775] Re: Window decoration becomes very large if the image has much more height than width
The bug is in GTK3. https://gitlab.gnome.org/GNOME/eog/issues/4 https://gitlab.gnome.org/GNOME/gtk/issues/657 ** Bug watch added: gitlab.gnome.org/GNOME/eog/issues #4 https://gitlab.gnome.org/GNOME/eog/issues/4 ** Bug watch added: gitlab.gnome.org/GNOME/gtk/issues #657 https://gitlab.gnome.org/GNOME/gtk/issues/657 ** Package changed: xfce (Ubuntu) => gtk+3.0 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1765775 Title: Window decoration becomes very large if the image has much more height than width Status in gtk+3.0 package in Ubuntu: Fix Released Bug description: When a image with much higher height than width is opened, the window decoration becomes very big, as it tries to keep the image proportional: https://i.imgur.com/SZu0lOk.png ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: eog 3.28.1-1 Uname: Linux 4.16.3-041603-generic x86_64 ApportVersion: 2.20.9-0ubuntu5 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Apr 20 13:08:37 2018 InstallationDate: Installed on 2017-06-13 (310 days ago) InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) SourcePackage: eog UpgradeStatus: Upgraded to bionic on 2017-10-20 (182 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1765775/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1765775] [NEW] Window decoration becomes very large if the image has much more height than width
You have been subscribed to a public bug: When a image with much higher height than width is opened, the window decoration becomes very big, as it tries to keep the image proportional: https://i.imgur.com/SZu0lOk.png ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: eog 3.28.1-1 Uname: Linux 4.16.3-041603-generic x86_64 ApportVersion: 2.20.9-0ubuntu5 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Apr 20 13:08:37 2018 InstallationDate: Installed on 2017-06-13 (310 days ago) InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) SourcePackage: eog UpgradeStatus: Upgraded to bionic on 2017-10-20 (182 days ago) ** Affects: gtk+3.0 (Ubuntu) Importance: Low Status: New ** Tags: amd64 apport-bug bionic -- Window decoration becomes very large if the image has much more height than width https://bugs.launchpad.net/bugs/1765775 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1847896] Re: Unable to shutdown or restart from log-in screen
@paulw2u My apologies. After double-checking, I found out that (for whatever reason) eoan-proposed were disabled for me. I'll retest and report here if an update doesn't help. -- 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/1847896 Title: Unable to shutdown or restart from log-in screen Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] * Shutdown and restart options don't work from the login screen, when the user is not logged in. [Test Case] * Start the system and don't log in, or log out in case the system is set up with autologin. * Restart, then shut down the system using the option in the upper right corner of the login screen. * Observe both operations working. [Regression Potential] * The fix is treating treating the greeter as user display sessions by cherry-picking upstream's change released in v243. The fix itself is very small, but there may be non-obvious security implications. [Original Bug Text] When selecting the shutdown icon from the log-in screen you are prompted with a dialog that allows you to either cancel, restart or shutdown. It has been noted that the restart and shutdown options no longer work. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 13 09:08:23 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-05-17 (148 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517) RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to
** Changed in: systemd Status: Unknown => 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/1846232 Title: networkd pads interface MTU by 4 bytes for vlan even when told not to Status in curtin: Invalid Status in systemd: Fix Released Status in systemd package in Ubuntu: New Bug description: From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel- amd64/916/console: == FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan) -- Traceback (most recent call last): File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 311, in test_ip_output routes) File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 337, in check_interface int(ipcfg[key])) AssertionError: 1500 != 1504 >> begin captured stdout << - parsed ip_a dict: interface0: broadcast: 10.245.175.255 group: default inet4: - address: 10.245.168.16 prefixlen: '21' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4913 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4913 prefixlen: '64' scope: link valid_lft: forever interface: interface0 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:13 mtu: '1500' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1: broadcast: 10.245.188.255 group: default inet4: - address: 10.245.188.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4915 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1504' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1.2667: broadcast: 10.245.184.255 group: default inet4: - address: 10.245.184.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2667 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2668: broadcast: 10.245.185.255 group: default inet4: - address: 10.245.185.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2668 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2669: broadcast: 10.245.186.255 group: default inet4: - address: 10.245.186.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2669 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2670: broadcast: 10.245.187.255 group: default inet4: - address: 10.245.187.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2670 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000'
[Touch-packages] [Bug 1847896] Re: Unable to shutdown or restart from log-in screen
The fix has not yet been released but is in a period of testing. Did you follow the instructions in comment #15? The updated package is in -proposed and will be for a *minimum* of seven days from the date of comment #15. If you want to test whether the update works for you then please follow the instructions in comment #15. If that update doesn't work for you then please confirm that you have enabled -proposed and downloaded the updated package. ** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1847896 Title: Unable to shutdown or restart from log-in screen Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] * Shutdown and restart options don't work from the login screen, when the user is not logged in. [Test Case] * Start the system and don't log in, or log out in case the system is set up with autologin. * Restart, then shut down the system using the option in the upper right corner of the login screen. * Observe both operations working. [Regression Potential] * The fix is treating treating the greeter as user display sessions by cherry-picking upstream's change released in v243. The fix itself is very small, but there may be non-obvious security implications. [Original Bug Text] When selecting the shutdown icon from the log-in screen you are prompted with a dialog that allows you to either cancel, restart or shutdown. It has been noted that the restart and shutdown options no longer work. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 13 09:08:23 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-05-17 (148 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517) RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1847896] Re: Unable to shutdown or restart from log-in screen
Same for me as of this today: logging off, then navigating through the menu in the right upper screen corner till the turn-off button and then clicking it produces no effect in eoan. ** Changed in: systemd (Ubuntu Eoan) Status: Fix Committed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1847896 Title: Unable to shutdown or restart from log-in screen Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: In Progress Status in systemd source package in Focal: Fix Released Bug description: [Impact] * Shutdown and restart options don't work from the login screen, when the user is not logged in. [Test Case] * Start the system and don't log in, or log out in case the system is set up with autologin. * Restart, then shut down the system using the option in the upper right corner of the login screen. * Observe both operations working. [Regression Potential] * The fix is treating treating the greeter as user display sessions by cherry-picking upstream's change released in v243. The fix itself is very small, but there may be non-obvious security implications. [Original Bug Text] When selecting the shutdown icon from the log-in screen you are prompted with a dialog that allows you to either cancel, restart or shutdown. It has been noted that the restart and shutdown options no longer work. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 13 09:08:23 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-05-17 (148 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517) RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852813] [NEW] [HP hostname All-in-One 24-xa0xxx, Realtek ALC225, Speaker, Internal] No sound at all
Public bug reported: I have described my problems here: https://askubuntu.com/questions/1186588/no-sound-except-popping-noises-on-my-hp-aio-realtek-alc225-for-all-linux-distr I still have no sound (ubuntu 19.10). Thanks in advance ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7 Uname: Linux 5.3.0-23-generic x86_64 ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chris131377 F pulseaudio /dev/snd/pcmC0D0p: chris131377 F...m pulseaudio CurrentDesktop: ubuntu:GNOME Date: Fri Nov 15 23:08:45 2019 InstallationDate: Installed on 2019-11-05 (10 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) PackageArchitecture: all ProcEnviron: LANGUAGE=fr_CH:fr PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_CH.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Audio interne - HDA Intel PCH Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chris131377 F pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [HP hostname All-in-One 24-xa0xxx, Realtek ALC225, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/01/2018 dmi.bios.vendor: AMI dmi.bios.version: F.10 dmi.board.asset.tag: 8CC9043T9C dmi.board.name: 84EE dmi.board.vendor: HP dmi.board.version: 1100 dmi.chassis.asset.tag: 8CC9043T9C dmi.chassis.type: 13 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnAMI:bvrF.10:bd11/01/2018:svnHP:pnHPPavilionAll-in-One24-xa0xxx:pvr:rvnHP:rn84EE:rvr1100:cvnHP:ct13:cvr: dmi.product.family: 103C_53311M HP Pavilion dmi.product.name: HP Pavilion All-in-One 24-xa0xxx dmi.product.sku: 4ZG56EA#UUZ dmi.sys.vendor: HP mtime.conffile..etc.modprobe.d.alsa-base.conf: 2019-11-06T00:01:22.112143 ** Affects: alsa-driver (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug eoan -- 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/1852813 Title: [HP hostname All-in-One 24-xa0xxx, Realtek ALC225, Speaker, Internal] No sound at all Status in alsa-driver package in Ubuntu: New Bug description: I have described my problems here: https://askubuntu.com/questions/1186588/no-sound-except-popping-noises-on-my-hp-aio-realtek-alc225-for-all-linux-distr I still have no sound (ubuntu 19.10). Thanks in advance ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7 Uname: Linux 5.3.0-23-generic x86_64 ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chris131377 F pulseaudio /dev/snd/pcmC0D0p: chris131377 F...m pulseaudio CurrentDesktop: ubuntu:GNOME Date: Fri Nov 15 23:08:45 2019 InstallationDate: Installed on 2019-11-05 (10 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) PackageArchitecture: all ProcEnviron: LANGUAGE=fr_CH:fr PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_CH.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Audio interne - HDA Intel PCH Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chris131377 F pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [HP hostname All-in-One 24-xa0xxx, Realtek ALC225, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/01/2018 dmi.bios.vendor: AMI dmi.bios.version: F.10 dmi.board.asset.tag: 8CC9043T9C dmi.board.name: 84EE dmi.board.vendor: HP dmi.board.version: 1100 dmi.chassis.asset.tag: 8CC9043T9C dmi.chassis.type: 13 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnAMI:bvrF.10:bd11/01/2018:svnHP:pnHPPavilionAll-in-One24-xa0xxx:pvr:rvnHP:rn84EE:rvr1100:cvnHP:ct13:cvr: dmi.product.family: 103C_53311M HP Pavilion dmi.product.name: HP Pavilion All-in-One 24-xa0xxx dmi.product.sku: 4ZG56EA#UUZ dmi.sys.vendor: HP mtime.conffile..etc.modprobe.d.alsa-base.conf: 2019-11-06T00:01:22.112143 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1852813/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1847896] Re: Unable to shutdown or restart from log-in screen
still there with ubuntu 19.10 everything & freshly upgraded -- 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/1847896 Title: Unable to shutdown or restart from log-in screen Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] * Shutdown and restart options don't work from the login screen, when the user is not logged in. [Test Case] * Start the system and don't log in, or log out in case the system is set up with autologin. * Restart, then shut down the system using the option in the upper right corner of the login screen. * Observe both operations working. [Regression Potential] * The fix is treating treating the greeter as user display sessions by cherry-picking upstream's change released in v243. The fix itself is very small, but there may be non-obvious security implications. [Original Bug Text] When selecting the shutdown icon from the log-in screen you are prompted with a dialog that allows you to either cancel, restart or shutdown. It has been noted that the restart and shutdown options no longer work. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 13 09:08:23 2019 DisplayManager: gdm3 InstallationDate: Installed on 2019-05-17 (148 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517) RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1847896/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to
I believe this is due to https://github.com/systemd/systemd/commit/4b151b71320bbee1549afcbad5554a40d90d63b4 and probably is https://github.com/systemd/systemd/issues/12552 fixed by https://github.com/systemd/systemd/pull/12574/commits which prevents the automatic mtu bump when MTUBytes is specified but i'm still uncertain about upstream's link_get_requested_mtu_by_stacked_netdevs() function, that bumps MTU automatically; I might be misunderstanding it, but I don't think it is needed or even correct - but I need to look more closely at it and haven't had time. ** Bug watch added: github.com/systemd/systemd/issues #12552 https://github.com/systemd/systemd/issues/12552 ** Also affects: systemd via https://github.com/systemd/systemd/issues/12552 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1846232 Title: networkd pads interface MTU by 4 bytes for vlan even when told not to Status in curtin: Invalid Status in systemd: Unknown Status in systemd package in Ubuntu: New Bug description: From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel- amd64/916/console: == FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan) -- Traceback (most recent call last): File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 311, in test_ip_output routes) File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 337, in check_interface int(ipcfg[key])) AssertionError: 1500 != 1504 >> begin captured stdout << - parsed ip_a dict: interface0: broadcast: 10.245.175.255 group: default inet4: - address: 10.245.168.16 prefixlen: '21' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4913 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4913 prefixlen: '64' scope: link valid_lft: forever interface: interface0 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:13 mtu: '1500' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1: broadcast: 10.245.188.255 group: default inet4: - address: 10.245.188.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4915 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1504' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1.2667: broadcast: 10.245.184.255 group: default inet4: - address: 10.245.184.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2667 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2668: broadcast: 10.245.185.255 group: default inet4: - address: 10.245.185.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2668 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2669: broadcast: 10.245.186.255 group: default inet4: - address: 10.245.186.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2669 loopback: false
[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to
> This looks to be related to networkd: sorry, I didn't read comments before posting, you found it already :) -- 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/1846232 Title: networkd pads interface MTU by 4 bytes for vlan even when told not to Status in curtin: Invalid Status in systemd: Unknown Status in systemd package in Ubuntu: New Bug description: From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel- amd64/916/console: == FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan) -- Traceback (most recent call last): File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 311, in test_ip_output routes) File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 337, in check_interface int(ipcfg[key])) AssertionError: 1500 != 1504 >> begin captured stdout << - parsed ip_a dict: interface0: broadcast: 10.245.175.255 group: default inet4: - address: 10.245.168.16 prefixlen: '21' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4913 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4913 prefixlen: '64' scope: link valid_lft: forever interface: interface0 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:13 mtu: '1500' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1: broadcast: 10.245.188.255 group: default inet4: - address: 10.245.188.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4915 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1504' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1.2667: broadcast: 10.245.184.255 group: default inet4: - address: 10.245.184.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2667 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2668: broadcast: 10.245.185.255 group: default inet4: - address: 10.245.185.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2668 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2669: broadcast: 10.245.186.255 group: default inet4: - address: 10.245.186.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2669 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2670: broadcast: 10.245.187.255 group: default inet4: - address: 10.245.187.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2670 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false
[Touch-packages] [Bug 1827757] Re: PMF
Tests were performed with Intel Dual Band Wireless-AC 7265 card. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1827757 Title: PMF Status in wpa package in Ubuntu: Confirmed Bug description: WPA Supplicant packaged with Ubuntu doesn't support PMF. PMF support has been available in wpa supplicant for about 3 years now and in couple of major releases. PMF is a security feature and should be supported (at least at the level when it needs to be manually enabled). Thanks! ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: wpasupplicant 2:2.6-21ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6 Uname: Linux 5.0.0-13-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 CurrentDesktop: MATE Date: Sat May 4 23:55:42 2019 InstallationDate: Installed on 2016-02-20 (1169 days ago) InstallationMedia: Ubuntu-MATE 15.10 "Wily Werewolf" - Release amd64 (20151021) SourcePackage: wpa UpgradeStatus: Upgraded to disco on 2019-05-02 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1827757/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to
** Summary changed: - vmtests: test_ip_output failing in vlan tests on eoan + networkd pads interface MTU by 4 bytes for vlan even when told not to -- 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/1846232 Title: networkd pads interface MTU by 4 bytes for vlan even when told not to Status in curtin: Invalid Status in systemd package in Ubuntu: New Bug description: From https://jenkins.ubuntu.com/server/job/curtin-vmtest-devel- amd64/916/console: == FAIL: test_ip_output (vmtests.test_network_vlan.EoanTestNetworkVlan) -- Traceback (most recent call last): File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 311, in test_ip_output routes) File "/var/lib/jenkins/servers/server/workspace/curtin-vmtest-devel-amd64/curtin-916/tests/vmtests/test_network.py", line 337, in check_interface int(ipcfg[key])) AssertionError: 1500 != 1504 >> begin captured stdout << - parsed ip_a dict: interface0: broadcast: 10.245.175.255 group: default inet4: - address: 10.245.168.16 prefixlen: '21' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4913 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4913 prefixlen: '64' scope: link valid_lft: forever interface: interface0 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:13 mtu: '1500' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1: broadcast: 10.245.188.255 group: default inet4: - address: 10.245.188.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fec0::d6be:d9ff:fea8:4915 prefixlen: '64' scope: site valid_lft: 86256sec - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1504' multicast: false qdisc: fq_codel qlen: '1000' running: false state: UP up: false interface1.2667: broadcast: 10.245.184.255 group: default inet4: - address: 10.245.184.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2667 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2668: broadcast: 10.245.185.255 group: default inet4: - address: 10.245.185.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2668 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2669: broadcast: 10.245.186.255 group: default inet4: - address: 10.245.186.1 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2669 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false qdisc: noqueue qlen: '1000' running: false state: UP up: false vlan_link: interface1 interface1.2670: broadcast: 10.245.187.255 group: default inet4: - address: 10.245.187.2 prefixlen: '24' scope: global valid_lft: forever inet6: - address: fe80::d6be:d9ff:fea8:4915 prefixlen: '64' scope: link valid_lft: forever interface: interface1.2670 loopback: false lower_up: false mac_address: d4:be:d9:a8:49:15 mtu: '1500' multicast: false
[Touch-packages] [Bug 1827757] Re: PMF
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: wpa (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1827757 Title: PMF Status in wpa package in Ubuntu: Confirmed Bug description: WPA Supplicant packaged with Ubuntu doesn't support PMF. PMF support has been available in wpa supplicant for about 3 years now and in couple of major releases. PMF is a security feature and should be supported (at least at the level when it needs to be manually enabled). Thanks! ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: wpasupplicant 2:2.6-21ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6 Uname: Linux 5.0.0-13-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 CurrentDesktop: MATE Date: Sat May 4 23:55:42 2019 InstallationDate: Installed on 2016-02-20 (1169 days ago) InstallationMedia: Ubuntu-MATE 15.10 "Wily Werewolf" - Release amd64 (20151021) SourcePackage: wpa UpgradeStatus: Upgraded to disco on 2019-05-02 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1827757/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1827757] Re: PMF
Can confirm that this problem still exist on the latest LTS release. I tested connecting to enterprise network with enabled and required PMF ( Protected Management Frames / Management Protected Frames or 802.11w ) on Ubuntu 18.04.3 LTS (with all updates) - all attempts failed, when the PMF was set to `Required` on the AP side. I also tested with my home setup: TP-Link AP ( OpenWrt 18.06.5 ) and 802.11w set to `Required` in the `Wireless Security` section. The current wpasupplicant version for 18.04 is 2:2.6-15ubuntu2.5 When the Network Manager tries to connect to the AP, it fails because the activation takes too long. I tested the Ubuntu 19.10 Eoan release and it seems that the wpasupplicant is able to connect to APs with Required PMF option. I found a workaround for Ubuntu 18.04 Bionic, but it is a bit "hacky/risky" - basically force upgraded the wpasupplicant and all deps with the packages from Ubuntu 19.10 Eoan. The dependency packages can be downloaded from https://packages.ubuntu.com Package versions: libnl-3-200_3.4.0-1_amd64.deb libnl-route-3-200_3.4.0-1_amd64.deb locales_2.30-0ubuntu2_all.deb libc-bin_2.30-0ubuntu2_amd64.deb libc6_2.30-0ubuntu2_amd64.deb libc6_2.30-0ubuntu2_i386.deb libtinfo6_6.1+20190803-1ubuntu1_amd64.deb libreadline8_8.0-3_amd64.deb wpasupplicant_2.9-1ubuntu2_amd64.deb NOTE: force upgrade this packages only if you are sure that they will not break your existing apps. If you are stuck with the LTS version, but you want the be able to connect to APs with mandatory PMF until this issue is resolved, you can try the workaround on your own risk (future LTS updates could break this setup). ** Tags added: 802.11w bionic pmf wpasupplicant -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1827757 Title: PMF Status in wpa package in Ubuntu: Confirmed Bug description: WPA Supplicant packaged with Ubuntu doesn't support PMF. PMF support has been available in wpa supplicant for about 3 years now and in couple of major releases. PMF is a security feature and should be supported (at least at the level when it needs to be manually enabled). Thanks! ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: wpasupplicant 2:2.6-21ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6 Uname: Linux 5.0.0-13-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 CurrentDesktop: MATE Date: Sat May 4 23:55:42 2019 InstallationDate: Installed on 2016-02-20 (1169 days ago) InstallationMedia: Ubuntu-MATE 15.10 "Wily Werewolf" - Release amd64 (20151021) SourcePackage: wpa UpgradeStatus: Upgraded to disco on 2019-05-02 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1827757/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1777010] Re: ip token set, results in: Invalid argument
I found this bug report because I have the same issue, but I think it's because the interface is "UP". When I try the same "set" command on a "DOWN" interface, it's successful. My issue is figuring out how to run the set command during the boot process on the eth0 interface, before it comes up. Netplan is making this difficult. ubuntu@ubuntu:/etc/networkd-dispatcher/degraded.d$ sudo ip token list token :: dev eth0 token :: dev wlan0 ubuntu@ubuntu:/etc/networkd-dispatcher/degraded.d$ sudo ip token set ::18/64 dev eth0 RTNETLINK answers: Invalid argument ubuntu@ubuntu:/etc/networkd-dispatcher/degraded.d$ sudo ip token set ::18/64 dev wlan0 ubuntu@ubuntu:/etc/networkd-dispatcher/degraded.d$ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether dc:a6:32:37:a0:3a brd ff:ff:ff:ff:ff:ff inet xxx.xxx.xxx.125/24 brd 192.168.88.255 scope global dynamic eth0 valid_lft 604343sec preferred_lft 604343sec inet6 /64 scope global dynamic mngtmpaddr noprefixroute valid_lft 345288sec preferred_lft 345288sec inet6 fe80::dea6:32ff:fe37:a03a/64 scope link valid_lft forever preferred_lft forever 3: wlan0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether dc:a6:32:37:a0:3b brd ff:ff:ff:ff:ff:ff ubuntu@ubuntu:/etc/networkd-dispatcher/degraded.d$ ip token list token :: dev eth0 token ::18 dev wlan0 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1777010 Title: ip token set, results in: Invalid argument Status in iproute2 package in Ubuntu: Confirmed Bug description: Hi, I can't set any ipv6 token with ip command. It seems that it has a bug. Also it is not possible to set it with netplan (see bug #1737976) ~# ip token list token :: dev enp1s0 token :: dev enp2s0 token :: dev ovpn0 token :: dev br0 ~# ip token set ::2a:2a:2a:2a/64 dev br0 RTNETLINK answers: Invalid argument ~# ip token set ::2a/64 dev br0 RTNETLINK answers: Invalid argument ~# ip token set ::beef dev br0 RTNETLINK answers: Invalid argument It seems, that this Bug is really old?! https://bbs.archlinux.org/viewtopic.php?id=202757 This is really fatal, because I cant set a static ip. My prefix get mixed from my provider every x days. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: iproute2 4.15.0-2ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 Date: Fri Jun 15 01:26:04 2018 InstallationDate: Installed on 2018-06-12 (2 days ago) InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=de_DE.UTF-8 SHELL=/bin/bash SourcePackage: iproute2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1777010/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843381] Re: Dell system takes a long time to connect network with external dock
I can confirm that systemd 237-3ubuntu10.33 fixes this issue for me on bionic. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Invalid Bug description: [impact] On Dell system with BIOS-based "MAC passthrough", there can be multiple USB nics with identical MAC addresses. Since the udev rules in Debian and Ubuntu assign interface names for USB nics by mac address (because that is the only consistent identifier for USB nics; their path can change based on which USB port they are connected to), it's impossible to name two interfaces with the same name. As Ubuntu also carries a patch to retry renaming of any interface when the first renaming fails, this causes a 90 second delay before being able to the "MAC passthrough" nic after connecting it. [test case] On a system with this "MAC passthrough" enabled and required devices, boot the system and then connect to the dock or connect the second USB nic with identical MAC. It will not be usable for 90 seconds as its renames takes that long to timeout. [regression potential] the change here is very limited to only Dell systems with the specific USB vendor/product ID affected by this, and additionally the change only sets a ENV flag in the udev rule, which is later used by udevd to skip the rename-retries for 90 seconds. So, the regression potential for anyone else without a system affected by this "MAC passthrough" should be very low, and any regression potential for those with this "MAC passthrough" should still be low, as this only skips the rename- retry that we know will never succeed. However, the regression potential is likely limited to failure to properly name a USB nic, or other bugs during the udev processing of new USB nics. [other info] original description: --- This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged
[Touch-packages] [Bug 1852489] Re: [SRU] Enable support for Ussuri Cloud Archive
This is also going to need the following to be fixed for focal: LP: #1852772 LP: #1852773 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1852489 Title: [SRU] Enable support for Ussuri Cloud Archive Status in software-properties package in Ubuntu: Triaged Status in software-properties source package in Bionic: Triaged Status in software-properties source package in Focal: Triaged Bug description: Please add support for: cloud-archive:ussuri cloud-archive:ussuri-proposed This will also need to be SRU'd back to bionic. [Impact] End users have to manually enable the ussuri cloud archive pockets. [Test case] sudo add-apt-repository cloud-archive:ussuri sudo add-apt-repository cloud-archive:ussuri-proposed [Regression potential] Limited - just a data item addition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1852489/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852018] Re: Audio Stops Playing Briefly When Emptying Trash
Thanks ** Changed in: pulseaudio (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1852018 Title: Audio Stops Playing Briefly When Emptying Trash Status in pulseaudio package in Ubuntu: New Bug description: I am running Ubuntu 19.10 and encountered this issue. I had a podcast playing in the background on Firefox v. 70.0.1 and I was deleting some files. I then proceeded to empty the trash and saw that the audio stops briefly till the "Empty all items from Trash?" prompt shows up. I was able to duplicate this many times and it even occurred with audio on Chrome. The expected way for things to work would be the audio keeps on playing, if I just empty the trash. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1852018/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852763] Re: Systematically tries to connect to wifi at startup even though ethernet cable connected
Thank you for your bug report, could you report it upstream on https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues ? ** Changed in: network-manager (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1852763 Title: Systematically tries to connect to wifi at startup even though ethernet cable connected Status in network-manager package in Ubuntu: New Bug description: There's a WiFi network to which I sometime connected and saved it and set it to automatically connect when available; however the password was changed, so whenever my laptop automatically tries to connect to that network, I get the prompt to enter the password. So far all expected. What is unexpected is the following: What I do is: - plug my laptop to the office LAN via an ethernet cable - turn on the laptop Expected: after boot, the computer should connect to the wired network, and hence not attempt to connect to the WiFi network Observed: every single time I boot, 100% systematically, I get the prompt that says that it couldn't connect to the WiFi network and asks me to enter the password manually. The popup shows up even before I log in (usually even before the login screen shows up, when part of the screen is still a mess with random garbage presumably from the uninitialized GPU memory). This most likely means one of two things: either the network manager attempts to connect to the WiFi network before it checks the wired network (by the time I dismiss the prompt the wired network is already connected), or it attempts to connect to WiFi even though it is already connected to the wired network. Either way the behavior is wrong. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: network-manager 1.2.6-0ubuntu0.16.04.3 ProcVersionSignature: Ubuntu 4.4.0-166.195-generic 4.4.194 Uname: Linux 4.4.0-166-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia ApportVersion: 2.20.1-0ubuntu2.20 Architecture: amd64 CurrentDesktop: Unity Date: Fri Nov 15 16:20:10 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2013-10-11 (2225 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) IpRoute: default via 192.168.1.1 dev eth0 proto static metric 100 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.37 metric 100 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.NetworkManager.NetworkManager.conf: [modified] mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2015-02-20T16:52:59.722501 nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH eth0ethernet connected /org/freedesktop/NetworkManager/Devices/1 Wired connection 1 662a0c09-71a8-4101-9236-ebcc1696d69a /org/freedesktop/NetworkManager/ActiveConnection/1 wlan0 wifi disconnected /org/freedesktop/NetworkManager/Devices/0 -- ---- lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/2 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.6connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1852763/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852773] Re: test failures on focal due to missing build-depend for gpg
Adding gpg to build-depends helps but then we get the following due to
missing gpg-agent:
==
FAIL: test_add_gpg_key (tests.test_dbus.TestDBus)
--
Traceback (most recent call last):
File "/build/software-properties-0.98.6/tests/test_dbus.py", line 372, in
test_add_gpg_key
self.assertTrue(res)
AssertionError: dbus.Boolean(False) is not true
** Summary changed:
- test failures on focal due to missing build-depend for gpg
+ test failures on focal due to missing build-depends on gpg and gpg-agent
** Changed in: software-properties (Ubuntu)
Status: New => Triaged
** Changed in: software-properties (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1852773
Title:
test failures on focal due to missing build-depends on gpg and gpg-
agent
Status in software-properties package in Ubuntu:
Triaged
Bug description:
==
ERROR: test_add_ppa_signing_key_multiple_fingerprints
(tests.test_lp.AddPPASigningKeyTestCase)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1330, in patched
return func(*args, **keywargs)
File "/build/software-properties-0.98.6/tests/test_lp.py", line 148, in
test_add_ppa_signing_key_multiple_fingerprints
res = self.t.add_ppa_signing_key("~mvo/ubuntu/ppa")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
317, in add_ppa_signing_key
minimal_key = self._minimize_key(armored_key)
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
259, in _minimize_key
p = self.gpg_cmd("import-minimal,import-export")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
242, in gpg_cmd
return subprocess.Popen(cmd.split(), stdin=subprocess.PIPE,
stdout=subprocess.PIPE)
File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'gpg'
==
ERROR: test_add_ppa_signing_key_ok (tests.test_lp.AddPPASigningKeyTestCase)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1330, in patched
return func(*args, **keywargs)
File "/build/software-properties-0.98.6/tests/test_lp.py", line 158, in
test_add_ppa_signing_key_ok
res = self.t.add_ppa_signing_key("~mvo/ubuntu/ppa")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
317, in add_ppa_signing_key
minimal_key = self._minimize_key(armored_key)
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
259, in _minimize_key
p = self.gpg_cmd("import-minimal,import-export")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
242, in gpg_cmd
return subprocess.Popen(cmd.split(), stdin=subprocess.PIPE,
stdout=subprocess.PIPE)
File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'gpg'
==
ERROR: test_add_ppa_signing_key_wrong_fingerprint
(tests.test_lp.AddPPASigningKeyTestCase)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1330, in patched
return func(*args, **keywargs)
File "/build/software-properties-0.98.6/tests/test_lp.py", line 140, in
test_add_ppa_signing_key_wrong_fingerprint
res = self.t.add_ppa_signing_key("~mvo/ubuntu/ppa")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
317, in add_ppa_signing_key
minimal_key = self._minimize_key(armored_key)
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
259, in _minimize_key
p = self.gpg_cmd("import-minimal,import-export")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line
242, in gpg_cmd
return subprocess.Popen(cmd.split(), stdin=subprocess.PIPE,
[Touch-packages] [Bug 1852773] [NEW] test failures on focal due to missing build-depends on gpg and gpg-agent
Public bug reported:
==
ERROR: test_add_ppa_signing_key_multiple_fingerprints
(tests.test_lp.AddPPASigningKeyTestCase)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1330, in patched
return func(*args, **keywargs)
File "/build/software-properties-0.98.6/tests/test_lp.py", line 148, in
test_add_ppa_signing_key_multiple_fingerprints
res = self.t.add_ppa_signing_key("~mvo/ubuntu/ppa")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 317,
in add_ppa_signing_key
minimal_key = self._minimize_key(armored_key)
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 259,
in _minimize_key
p = self.gpg_cmd("import-minimal,import-export")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 242,
in gpg_cmd
return subprocess.Popen(cmd.split(), stdin=subprocess.PIPE,
stdout=subprocess.PIPE)
File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'gpg'
==
ERROR: test_add_ppa_signing_key_ok (tests.test_lp.AddPPASigningKeyTestCase)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1330, in patched
return func(*args, **keywargs)
File "/build/software-properties-0.98.6/tests/test_lp.py", line 158, in
test_add_ppa_signing_key_ok
res = self.t.add_ppa_signing_key("~mvo/ubuntu/ppa")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 317,
in add_ppa_signing_key
minimal_key = self._minimize_key(armored_key)
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 259,
in _minimize_key
p = self.gpg_cmd("import-minimal,import-export")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 242,
in gpg_cmd
return subprocess.Popen(cmd.split(), stdin=subprocess.PIPE,
stdout=subprocess.PIPE)
File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'gpg'
==
ERROR: test_add_ppa_signing_key_wrong_fingerprint
(tests.test_lp.AddPPASigningKeyTestCase)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1330, in patched
return func(*args, **keywargs)
File "/build/software-properties-0.98.6/tests/test_lp.py", line 140, in
test_add_ppa_signing_key_wrong_fingerprint
res = self.t.add_ppa_signing_key("~mvo/ubuntu/ppa")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 317,
in add_ppa_signing_key
minimal_key = self._minimize_key(armored_key)
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 259,
in _minimize_key
p = self.gpg_cmd("import-minimal,import-export")
File "/build/software-properties-0.98.6/softwareproperties/ppa.py", line 242,
in gpg_cmd
return subprocess.Popen(cmd.split(), stdin=subprocess.PIPE,
stdout=subprocess.PIPE)
File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'gpg'
==
FAIL: test_add_gpg_key (tests.test_dbus.TestDBus)
--
Traceback (most recent call last):
File "/build/software-properties-0.98.6/tests/test_dbus.py", line 372, in
test_add_gpg_key
self.assertTrue(res)
AssertionError: dbus.Boolean(False) is not true
--
Ran 30 tests in 1.972s
** Affects: software-properties (Ubuntu)
Importance: High
Status: Triaged
** Summary changed:
- test failures on focal due to missing gpg BD
+ test failures on focal due to missing build-depend for gpg
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
[Touch-packages] [Bug 1852772] Re: test_updates_interval fails on focal
** Changed in: software-properties (Ubuntu)
Status: New => Triaged
** Changed in: software-properties (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1852772
Title:
test_updates_interval fails on focal
Status in software-properties package in Ubuntu:
Triaged
Bug description:
==
FAIL: test_updates_interval (tests.test_dbus.TestDBus)
--
Traceback (most recent call last):
File "/build/software-properties-0.98.6/tests/test_dbus.py", line 332, in
test_updates_interval
self.assertTrue('APT::Periodic::Update-Package-Lists "1";' in config)
AssertionError: False is not true
Looking closer, while in the SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py, days is of
dbus.Int32 type. A simple print output shows:
days=dbus.Int32(1)
D-Bus is statically typed, unlike python. More details at:
https://dbus.freedesktop.org/doc/dbus-python/tutorial.html#data-types
I think once we're in the dbus method (SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py) we can convert the
dbus.Int32 to an int.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1852772/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852772] [NEW] test_updates_interval fails on focal
Public bug reported:
==
FAIL: test_updates_interval (tests.test_dbus.TestDBus)
--
Traceback (most recent call last):
File "/build/software-properties-0.98.6/tests/test_dbus.py", line 332, in
test_updates_interval
self.assertTrue('APT::Periodic::Update-Package-Lists "1";' in config)
AssertionError: False is not true
Looking closer, while in the SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py, days is of dbus.Int32
type. A simple print output shows:
days=dbus.Int32(1)
D-Bus is statically typed, unlike python. More details at:
https://dbus.freedesktop.org/doc/dbus-python/tutorial.html#data-types
I think once we're in the dbus method (SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py) we can convert the
dbus.Int32 to an int.
** Affects: software-properties (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1852772
Title:
test_updates_interval fails on focal
Status in software-properties package in Ubuntu:
New
Bug description:
==
FAIL: test_updates_interval (tests.test_dbus.TestDBus)
--
Traceback (most recent call last):
File "/build/software-properties-0.98.6/tests/test_dbus.py", line 332, in
test_updates_interval
self.assertTrue('APT::Periodic::Update-Package-Lists "1";' in config)
AssertionError: False is not true
Looking closer, while in the SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py, days is of
dbus.Int32 type. A simple print output shows:
days=dbus.Int32(1)
D-Bus is statically typed, unlike python. More details at:
https://dbus.freedesktop.org/doc/dbus-python/tutorial.html#data-types
I think once we're in the dbus method (SetUpdateInterval() method in
softwareproperties/dbus/SoftwarePropertiesDBus.py) we can convert the
dbus.Int32 to an int.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1852772/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849658] Re: resolved fallback to TCP fails for truncated UDP replies
Hello Dan, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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. ** Tags removed: verification-done verification-done-bionic ** Tags added: verification-needed verification-needed-bionic -- 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/1849658 Title: resolved fallback to TCP fails for truncated UDP replies Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] for DNS UDP replies larger than 512 bytes, fallback to TCP is used. For example 'host toomany.ddstreet.org'. Due to a bug in resolved in refcounting DNS stream types, the refcount underflows for type 0 streams (which resolved uses to talk to upstream nameservers), resulting in resolved being unable to fallback to TCP to handle truncated UDP replies. [test case] ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 24 11:40:29 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; connection timed out; no servers could be reached [regression potential] very low, as this only properly sets the stream type in the DnsStream object; any regression would be a failure to be able to use TCP for DNS requests or replies. [other info] https://github.com/systemd/systemd/pull/13838 The commit adding stream types is not present in x/b, so this is needed only for disco and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843381] Re: Dell system takes a long time to connect network with external dock
Hello Che, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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. ** Tags removed: verification-done-bionic ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Invalid Bug description: [impact] On Dell system with BIOS-based "MAC passthrough", there can be multiple USB nics with identical MAC addresses. Since the udev rules in Debian and Ubuntu assign interface names for USB nics by mac address (because that is the only consistent identifier for USB nics; their path can change based on which USB port they are connected to), it's impossible to name two interfaces with the same name. As Ubuntu also carries a patch to retry renaming of any interface when the first renaming fails, this causes a 90 second delay before being able to the "MAC passthrough" nic after connecting it. [test case] On a system with this "MAC passthrough" enabled and required devices, boot the system and then connect to the dock or connect the second USB nic with identical MAC. It will not be usable for 90 seconds as its renames takes that long to timeout. [regression potential] the change here is very limited to only Dell systems with the specific USB vendor/product ID affected by this, and additionally the change only sets a ENV flag in the udev rule, which is later used by udevd to skip the rename-retries for 90 seconds. So, the regression potential for anyone else without a system affected by this "MAC passthrough" should be very low, and any regression potential for those with this "MAC passthrough" should still be low, as this only skips the rename- retry that we know will never succeed. However, the regression potential is likely limited to failure to properly name a USB nic, or other bugs during the udev processing of new USB nics. [other info] original description: --- This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90
[Touch-packages] [Bug 1840640] Please test proposed package
Hello Steve, or anyone else affected,
Accepted systemd into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1840640
Title:
sync_file_range fails in nspawn containers on arm, ppc
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Disco:
Fix Committed
Bug description:
[impact]
calling the glibc function sync_file_range() on a armhf nspawn
container fails.
[test case]
see sample C program from original description below. compile and run
that inside a nspawn container on armhf and it will fail.
nspawn instructions:
sudo apt install debootstrap systemd-container
sudo -i
debootstrap --arch=armhf bionic ~/bionic-tree/
systemd-nspawn -D ~/bionic-tree/
[regression potential]
this only adjusts nspawn to allow the sync_file_range2 syscall which
is used on armhf, so the regression potential is very low. any
possible regressions would likely be when calling sync_file_range().
[other info]
original description:
---
ARM has two sync_file_range syscalls, sync_file_range and
sync_file_range2. The former is apparently not used, and glibc calls
the latter whenever a userspace program calls sync_file_range. I'm
guessing systemd-nspawn doesn't know this, because the follow code
consistently fails in an nspawn container on ARM:
#define _GNU_SOURCE
#include
#include
#include
#include
void main()
{
int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);
int r=sync_file_range(f, 0, 0, 0);
if (r)
perror("sync_file_range");
close(f);
}
This seems to be causing problems specifically for borg(backup) and
postgres:
https://github.com/borgbackup/borg/issues/4710
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93
The solution should be to cherrypick
https://github.com/systemd/systemd/pull/13352, I am currently waiting
for systemd to rebuild on a slow ARM box. Any chance of an SRU?
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd-container 237-3ubuntu10.24
Uname: Linux 4.14.66+ armv7l
NonfreeKernelModules: extcon_usb_gpio
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: armhf
Date: Mon Aug 19 11:10:48 2019
ProcEnviron:
TERM=screen
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1840640/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
Hello Neil, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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. ** Tags removed: verification-done verification-done-bionic ** Tags added: verification-needed verification-needed-bionic -- 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/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name
[Touch-packages] [Bug 1783994] Please test proposed package
Hello Marc, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1783994 Title: systemd spams log with "Failed to dissect: Input/output error" on systems with mmc Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] on systems with mmc device installed, systemd-gpt-auto-generator fails. [test case] on a system with mmc device installed, run systemd-gpt-auto-generator and check log for: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error [regression potential] as this is related to boot, regressions might occur at boot, or while modifying or configuring a boot loader. [other info] original description: --- If a device has an mmc installed, systemd-gpt-auto-generator will fail because of "special partition" (rpmb, boot) and record a log message: systemd-gpt-auto-generator[207]: Failed to dissect: Input/output error This issue was discussed here: https://github.com/systemd/systemd/issues/5806 and a fix is proposed for new systemd versions. Please include in bionic. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1783994/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849733] Re: resolved incorrectly limits TCP reply to edns0 payload
Hello Dan, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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. ** Tags removed: verification-done verification-done-bionic ** Tags added: verification-needed verification-needed-bionic -- 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/1849733 Title: resolved incorrectly limits TCP reply to edns0 payload Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: [impact] glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its payload limit to 1200. When the response is larger than 1200, resolved will limit the response and set the truncate flag. This causes getaddrinfo() to switch to TCP and request again, but glibc incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit. Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC it applies only to UDP, but resolved does not and again marks the response as truncated. This prevents getaddrinfo() from being able to resolve any records with a response over 1200 bytes. [test case] use ping or telnet, which use getaddrinfo(), to lookup an A record with a lot of results, like toomany100.ddstreet.org $ telnet toomany100.ddstreet.org telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure in name resolution [regression potential] any regression would likely result in failure to correctly lookup a hostname or to provide the correct response to a local client. [other info] note that on Bionic, this also requires backporting TCP pipelining support in the stub resolver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832672] Re: systemd-resolve not ignoring comments in /etc/hosts
Hello Bruno, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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. ** Tags removed: verification-done verification-done-bionic ** Tags added: verification-needed verification-needed-bionic -- 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/1832672 Title: systemd-resolve not ignoring comments in /etc/hosts Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] resolved does not ignore comments properly in /etc/hosts [test case] see original description below [regression potential] as this modifies resolved parsing of /etc/hosts, regressions would likely be in hostname lookups from hosts in /etc/hosts, or failure(s) to parse /etc/hosts correctly. [other info] original description: --- $ lsb_release -rd Description: Ubuntu 18.04.2 LTS Release: 18.04 $ LANG=C apt-cache policy systemd systemd: Installed: 237-3ubuntu10.22 Candidate: 237-3ubuntu10.22 Version table: *** 237-3ubuntu10.22 500 500 http://ch.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://ch.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 500 http://mirrors.kernel.org/ubuntu bionic/main amd64 Packages $ head -1 /etc/hosts 127.0.2.1 foo # bar $ /usr/bin/systemd-resolve -4 bar expected -- bar: resolve call failed: 'bar' not found What happened instead - bar: 127.0.2.1 HOSTS(5) > Text from a "#" character until the end of the line is a comment, and is ignored. This is fixed in upstream: https://github.com/systemd/systemd/issues/10779 https://github.com/systemd/systemd/commit/bd0052777981044cf54a1e9d6e3acb1c3d813656 Please backport to current LTS version. I accidentally connected to wrong systems because of this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1832672/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes
Hello jrb0001, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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. ** Tags removed: verification-done verification-done-bionic ** Tags added: verification-needed verification-needed-bionic -- 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/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Bug description: [impact] an NXDOMAIN response from a dns server when systemd-resolved is configured as DNSSEC=yes breaks dns resolution as it downgrades from DNSSEC. [test case] see comment 9 [regression potential] as with the original patch that introduced this problem, this has the potential to break dns resolution. [other info] original description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1850704] Re: networkd doesn't set MTUBytes if interface is already up
Hello Dan, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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. ** Tags removed: verification-failed verification-failed-bionic ** Tags added: verification-needed verification-needed-bionic -- 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/1850704 Title: networkd doesn't set MTUBytes if interface is already up Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] if a networkd .network file specifies a [Link] section with MTUBytes=XXX set, networkd will only apply that mtu if the interface is down when networkd starts; if the interface is already up, the mtu won't be applied. [test case] on a bionic system, create a .network file like: [Match] Name=ens8 [Link] MTUBytes= then, reboot. The interface should be set correctly with that mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff now, manually change the interface back to 1500 mtu, and restart networkd, then recheck the mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo ip l set mtu 1500 dev ens8 $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo systemctl restart systemd-networkd $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff [regression potential] low, but any regression would likely involve failure to correctly set the configured mtu. this is needed only in bionic, it's fixed in disco and later already. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1850704/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852754] Re: networkd does not complete interface configuration if Link MTUBytes is set
Hello Dan, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.33 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 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. ** Description changed: [impact] interfaces configured with .network file [Link] section specifying MTUBytes will not be successfully brought up. [test case] configure interface e.g. Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [Link] MTUBytes=1550 start/restart networkd, the interface will never reach 'routable' stage and will not get an IPv4 address. [regression potential] - regressions will likely occur during networkd + any regressions would likely occur during networkd configuration/startup/restart, and would likely cause failure to successfully setup the interface. [other info] this is a regression-proposed caused by incomplete backport for bug 1850704 ** Changed in: systemd (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-bionic -- 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/1852754 Title: networkd does not complete interface configuration if Link MTUBytes is set Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] interfaces configured with .network file [Link] section specifying MTUBytes will not be successfully brought up. [test case] configure interface e.g. Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [Link] MTUBytes=1550 start/restart networkd, the interface will never reach 'routable' stage and will not get an IPv4 address. [regression potential] any regressions would likely occur during networkd configuration/startup/restart, and would likely cause failure to successfully setup the interface. [other info] this is a regression-proposed caused by incomplete backport for bug 1850704 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1852754/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849835] Re: add-apt-repository does not work in focal
Thanks for reporting. I'm closing this after your comment. I strongly suspect the problem was that focal wasn't found in the list of possible Ubuntu releases. Whenever a new developmen cycle starts, the new code name needs to be added in a couple of places and this can sometimes take a few days. ** Changed in: software-properties (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1849835 Title: add-apt-repository does not work in focal Status in software-properties package in Ubuntu: Fix Released Bug description: I tested to use a ppa because I wanted to test if mkusb will work in focal. But add-apt-repository does not work. --- lubuntu@lubuntu:~$ sudo add-apt-repository ppa:mkusb/ppa # existing ppa Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 107, in sp = SoftwareProperties(options=options) File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 118, in __init__ self.reload_sourceslist() File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 613, in reload_sourceslist self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 93, in get_sources (self.id, self.codename)) aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/focal lubuntu@lubuntu:~$ sudo add-apt-repository ppa:qwerty/asdf # not existing ppa: same output Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 107, in sp = SoftwareProperties(options=options) File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 118, in __init__ self.reload_sourceslist() File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 613, in reload_sourceslist self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 93, in get_sources (self.id, self.codename)) aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/focal lubuntu@lubuntu:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu Focal Fossa (development branch) Release:20.04 Codename: focal lubuntu@lubuntu:~$ --- ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: software-properties-common 0.98.5 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CasperVersion: 1.427 CurrentDesktop: LXQt Date: Fri Oct 25 13:10:33 2019 LiveMediaBuild: Lubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20191024) PackageArchitecture: all SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1849835/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849658] Re: resolved fallback to TCP fails for truncated UDP replies
oops, copied too much in the last comment; the first part of that is verification for bug 1849733 (which i pasted in there as well). After the ^C is verification for this bug. ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- 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/1849658 Title: resolved fallback to TCP fails for truncated UDP replies Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] for DNS UDP replies larger than 512 bytes, fallback to TCP is used. For example 'host toomany.ddstreet.org'. Due to a bug in resolved in refcounting DNS stream types, the refcount underflows for type 0 streams (which resolved uses to talk to upstream nameservers), resulting in resolved being unable to fallback to TCP to handle truncated UDP replies. [test case] ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 24 11:40:29 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; connection timed out; no servers could be reached [regression potential] very low, as this only properly sets the stream type in the DnsStream object; any regression would be a failure to be able to use TCP for DNS requests or replies. [other info] https://github.com/systemd/systemd/pull/13838 The commit adding stream types is not present in x/b, so this is needed only for disco and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849658] Re: resolved fallback to TCP fails for truncated UDP replies
bionic verification note: as mentioned in description, the commit introducing this wasn't present in bionic so this bug isn't reproducable with version 237-3ubuntu10.31; however that commit was added to version 237-3ubuntu10.32 in bug 1849733, so the verification here doesn't need to check version ..ubuntu10.31, it only needs to verify this bug wasn't introduced in version ..ubuntu10.32 ubuntu@lp1849733-b:~$ dpkg -l systemd|grep ii ii systemd237-3ubuntu10.32 amd64system and service manager ubuntu@lp1849733-b:~$ telnet toomany100.ddstreet.org Trying 10.254.201.100... ^C ubuntu@lp1849733-b:~$ dpkg -l systemd|grep ii ii systemd237-3ubuntu10.32 amd64system and service manager ubuntu@lp1849733-b:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.10-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6871 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Fri Nov 15 15:53:48 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@lp1849733-b:~$ sudo systemd-resolve --flush-caches ubuntu@lp1849733-b:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.10-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46778 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Fri Nov 15 15:53:56 UTC 2019 ;; MSG SIZE rcvd: 678 -- 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/1849658 Title: resolved fallback to TCP fails for truncated UDP replies Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] for DNS UDP replies larger than 512 bytes, fallback to TCP is used. For example 'host toomany.ddstreet.org'. Due to a bug in resolved in refcounting DNS stream types, the refcount underflows for type 0 streams (which resolved uses to talk to upstream nameservers), resulting in resolved being unable to fallback to TCP to handle truncated UDP replies. [test case] ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2683 ;; flags: qr rd ra; QUERY: 1, ANSWER: 40, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;toomany.ddstreet.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 24 11:40:29 UTC 2019 ;; MSG SIZE rcvd: 678 ubuntu@sf247344-upstream:~$ sudo resolvectl flush-caches ubuntu@sf247344-upstream:~$ dig +noanswer +noedns toomany.ddstreet.org ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> +noanswer +noedns toomany.ddstreet.org ;; global options: +cmd ;; connection timed out; no servers could be reached [regression potential] very low, as this only properly sets the stream type in the DnsStream object; any regression would be a failure to be able to use TCP for DNS requests or replies. [other info] https://github.com/systemd/systemd/pull/13838 The commit adding stream types is not present in x/b, so this is needed only for disco and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1849733] Re: resolved incorrectly limits TCP reply to edns0 payload
ubuntu@lp1849733-b:~$ dpkg -l systemd|grep ii ii systemd237-3ubuntu10.31 amd64system and service manager ubuntu@lp1849733-b:~$ telnet toomany100.ddstreet.org telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure in name resolution ubuntu@lp1849733-b:~$ dpkg -l systemd|grep ii ii systemd237-3ubuntu10.32 amd64system and service manager ubuntu@lp1849733-b:~$ telnet toomany100.ddstreet.org Trying 10.254.201.100... ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- 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/1849733 Title: resolved incorrectly limits TCP reply to edns0 payload Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: [impact] glibc's getaddrinfo() uses EDNS0 to talk to resolved, and it sets its payload limit to 1200. When the response is larger than 1200, resolved will limit the response and set the truncate flag. This causes getaddrinfo() to switch to TCP and request again, but glibc incorrectly keeps the EDNS0 RR opt, with the same 1200 payload limit. Most dns nameservers ignore EDNS0 payload limit for TCP, since per RFC it applies only to UDP, but resolved does not and again marks the response as truncated. This prevents getaddrinfo() from being able to resolve any records with a response over 1200 bytes. [test case] use ping or telnet, which use getaddrinfo(), to lookup an A record with a lot of results, like toomany100.ddstreet.org $ telnet toomany100.ddstreet.org telnet: could not resolve toomany100.ddstreet.org/telnet: Temporary failure in name resolution [regression potential] any regression would likely result in failure to correctly lookup a hostname or to provide the correct response to a local client. [other info] note that on Bionic, this also requires backporting TCP pipelining support in the stub resolver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849733/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852754] Re: networkd does not complete interface configuration if Link MTUBytes is set
** Changed in: systemd Status: Unknown => 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/1852754 Title: networkd does not complete interface configuration if Link MTUBytes is set Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [impact] interfaces configured with .network file [Link] section specifying MTUBytes will not be successfully brought up. [test case] configure interface e.g. Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [Link] MTUBytes=1550 start/restart networkd, the interface will never reach 'routable' stage and will not get an IPv4 address. [regression potential] regressions will likely occur during networkd configuration/startup/restart, and would likely cause failure to successfully setup the interface. [other info] this is a regression-proposed caused by incomplete backport for bug 1850704 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1852754/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1832672] Re: systemd-resolve not ignoring comments in /etc/hosts
ubuntu@lp1832672-b:~$ dpkg -l systemd|grep ii ii systemd237-3ubuntu10.31 amd64system and service manager ubuntu@lp1832672-b:~$ grep bar /etc/hosts 127.0.2.1 foo # bar ubuntu@lp1832672-b:~$ systemd-resolve -4 bar bar: 127.0.2.1 -- Information acquired via protocol DNS in 1.5ms. -- Data is authenticated: yes ubuntu@lp1832672-b:~$ dpkg -l systemd|grep ii ii systemd237-3ubuntu10.32 amd64system and service manager ubuntu@lp1832672-b:~$ grep bar /etc/hosts 127.0.2.1 foo # bar ubuntu@lp1832672-b:~$ systemd-resolve -4 bar bar: resolve call failed: 'bar' not found ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- 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/1832672 Title: systemd-resolve not ignoring comments in /etc/hosts Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] resolved does not ignore comments properly in /etc/hosts [test case] see original description below [regression potential] as this modifies resolved parsing of /etc/hosts, regressions would likely be in hostname lookups from hosts in /etc/hosts, or failure(s) to parse /etc/hosts correctly. [other info] original description: --- $ lsb_release -rd Description: Ubuntu 18.04.2 LTS Release: 18.04 $ LANG=C apt-cache policy systemd systemd: Installed: 237-3ubuntu10.22 Candidate: 237-3ubuntu10.22 Version table: *** 237-3ubuntu10.22 500 500 http://ch.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://ch.archive.ubuntu.com/ubuntu bionic/main amd64 Packages 500 http://mirrors.kernel.org/ubuntu bionic/main amd64 Packages $ head -1 /etc/hosts 127.0.2.1 foo # bar $ /usr/bin/systemd-resolve -4 bar expected -- bar: resolve call failed: 'bar' not found What happened instead - bar: 127.0.2.1 HOSTS(5) > Text from a "#" character until the end of the line is a comment, and is ignored. This is fixed in upstream: https://github.com/systemd/systemd/issues/10779 https://github.com/systemd/systemd/commit/bd0052777981044cf54a1e9d6e3acb1c3d813656 Please backport to current LTS version. I accidentally connected to wrong systems because of this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1832672/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852763] [NEW] Systematically tries to connect to wifi at startup even though ethernet cable connected
Public bug reported: There's a WiFi network to which I sometime connected and saved it and set it to automatically connect when available; however the password was changed, so whenever my laptop automatically tries to connect to that network, I get the prompt to enter the password. So far all expected. What is unexpected is the following: What I do is: - plug my laptop to the office LAN via an ethernet cable - turn on the laptop Expected: after boot, the computer should connect to the wired network, and hence not attempt to connect to the WiFi network Observed: every single time I boot, 100% systematically, I get the prompt that says that it couldn't connect to the WiFi network and asks me to enter the password manually. The popup shows up even before I log in (usually even before the login screen shows up, when part of the screen is still a mess with random garbage presumably from the uninitialized GPU memory). This most likely means one of two things: either the network manager attempts to connect to the WiFi network before it checks the wired network (by the time I dismiss the prompt the wired network is already connected), or it attempts to connect to WiFi even though it is already connected to the wired network. Either way the behavior is wrong. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: network-manager 1.2.6-0ubuntu0.16.04.3 ProcVersionSignature: Ubuntu 4.4.0-166.195-generic 4.4.194 Uname: Linux 4.4.0-166-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia ApportVersion: 2.20.1-0ubuntu2.20 Architecture: amd64 CurrentDesktop: Unity Date: Fri Nov 15 16:20:10 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2013-10-11 (2225 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) IpRoute: default via 192.168.1.1 dev eth0 proto static metric 100 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.37 metric 100 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.NetworkManager.NetworkManager.conf: [modified] mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2015-02-20T16:52:59.722501 nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH eth0ethernet connected /org/freedesktop/NetworkManager/Devices/1 Wired connection 1 662a0c09-71a8-4101-9236-ebcc1696d69a /org/freedesktop/NetworkManager/ActiveConnection/1 wlan0 wifi disconnected /org/freedesktop/NetworkManager/Devices/0 -- ---- lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/2 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.6connected started full enabled enabled enabled enabled enabled ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug third-party-packages xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1852763 Title: Systematically tries to connect to wifi at startup even though ethernet cable connected Status in network-manager package in Ubuntu: New Bug description: There's a WiFi network to which I sometime connected and saved it and set it to automatically connect when available; however the password was changed, so whenever my laptop automatically tries to connect to that network, I get the prompt to enter the password. So far all expected. What is unexpected is the following: What I do is: - plug my laptop to the office LAN via an ethernet cable - turn on the laptop Expected: after boot, the computer should connect to the wired network, and hence not attempt to connect to the WiFi network Observed: every single time I boot, 100% systematically, I get the prompt that says that it couldn't connect to the WiFi network and asks me to enter the password manually. The popup shows up even before I log in (usually even before the login screen shows up, when part of the screen is still a mess with random garbage presumably from the uninitialized GPU memory). This most likely means one of two things: either the network manager attempts to connect to the WiFi network before it checks the wired network (by the time I dismiss the prompt the wired network is
[Touch-packages] [Bug 1850704] Re: networkd doesn't set MTUBytes if interface is already up
the backport for this bug has caused regression-proposed bug 1852754 ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-failed verification-failed-bionic -- 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/1850704 Title: networkd doesn't set MTUBytes if interface is already up Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] if a networkd .network file specifies a [Link] section with MTUBytes=XXX set, networkd will only apply that mtu if the interface is down when networkd starts; if the interface is already up, the mtu won't be applied. [test case] on a bionic system, create a .network file like: [Match] Name=ens8 [Link] MTUBytes= then, reboot. The interface should be set correctly with that mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff now, manually change the interface back to 1500 mtu, and restart networkd, then recheck the mtu: $ ip l show ens8 3: ens8: mtu qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo ip l set mtu 1500 dev ens8 $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff $ sudo systemctl restart systemd-networkd $ ip l show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:30:4c:1e brd ff:ff:ff:ff:ff:ff [regression potential] low, but any regression would likely involve failure to correctly set the configured mtu. this is needed only in bionic, it's fixed in disco and later already. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1850704/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852754] [NEW] networkd does not complete interface configuration if Link MTUBytes is set
Public bug reported: [impact] interfaces configured with .network file [Link] section specifying MTUBytes will not be successfully brought up. [test case] configure interface e.g. Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [Link] MTUBytes=1550 start/restart networkd, the interface will never reach 'routable' stage and will not get an IPv4 address. [regression potential] regressions will likely occur during networkd configuration/startup/restart, and would likely cause failure to successfully setup the interface. [other info] this is a regression-proposed caused by incomplete backport for bug 1850704 ** Affects: systemd Importance: Unknown Status: Unknown ** Affects: systemd (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: systemd (Ubuntu Bionic) Importance: Critical Assignee: Dan Streetman (ddstreet) Status: In Progress ** Tags: bionic ddstreet regression-proposed systemd ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released ** Bug watch added: github.com/systemd/systemd/issues #9831 https://github.com/systemd/systemd/issues/9831 ** Also affects: systemd via https://github.com/systemd/systemd/issues/9831 Importance: Unknown Status: Unknown ** Changed in: systemd (Ubuntu Bionic) Status: New => In Progress ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Critical ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Tags added: bionic ddstreet regression-proposed systemd -- 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/1852754 Title: networkd does not complete interface configuration if Link MTUBytes is set Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Bug description: [impact] interfaces configured with .network file [Link] section specifying MTUBytes will not be successfully brought up. [test case] configure interface e.g. Name=ens3 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [Link] MTUBytes=1550 start/restart networkd, the interface will never reach 'routable' stage and will not get an IPv4 address. [regression potential] regressions will likely occur during networkd configuration/startup/restart, and would likely cause failure to successfully setup the interface. [other info] this is a regression-proposed caused by incomplete backport for bug 1850704 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1852754/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
"I think you're trying to start dhclient on an interface that's already setup." It just triggers a lease refresh on the existing interface, which has the same issue. Nov 15 14:17:10 srv-ywz63 systemd-logind[981]: New session 27 of user ubuntu. Nov 15 14:17:10 srv-ywz63 systemd[1]: Started Session 27 of user ubuntu. Nov 15 14:17:30 srv-ywz63 sudo[12484]: ubuntu : TTY=pts/2 ; PWD=/home/ubuntu ; USER=root ; COMMAND=/sbin/dhclient eth0 Nov 15 14:17:30 srv-ywz63 sudo[12484]: pam_unix(sudo:session): session opened for user root by ubuntu(uid=0) Nov 15 14:17:30 srv-ywz63 dhclient[12485]: DHCPREQUEST of 10.241.196.178 on eth0 to 255.255.255.255 port 67 (xid=0x511efd40) Nov 15 14:17:30 srv-ywz63 dhclient[12485]: DHCPACK of 10.241.196.178 from 10.241.196.177 Nov 15 14:17:30 srv-ywz63 dhclient[12485]: bound to 10.241.196.178 -- renewal in 1421 seconds. Nov 15 14:17:30 srv-ywz63 sudo[12484]: pam_unix(sudo:session): session closed for user root -- 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/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25
[Touch-packages] [Bug 1852752] [NEW] DPMS does not switch off the monitor back light
Public bug reported: 'xset dpms force off' blanks the screen but does not switch off the HDMI (LCD) monitor backlight. 'xset -q' shows DPMS is enabled. 'tvservice -o' does switch off the monitor. No warnings/errors related to dpms in /var/log/XOrg.0.log Not sure if this is a xorg, kernel, libxcb-dpms0 or other issue. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: User Name 5.3.0-1012.14-raspi2 5.3.7 Uname: Linux 5.3.0-1012-raspi2 aarch64 ApportVersion: 2.20.11-0ubuntu8.2 Architecture: arm64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: XFCE Date: Fri Nov 15 18:33:52 2019 DistUpgraded: Fresh install DistroCodename: eoan DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 cma=64M cma=256M video=HDMI-A-1:1920x1080@60 smsc95xx.macaddr=DC:A6:32:17:19:0B vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 net.ifnames=0 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait quiet splash SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug arm64 eoan ubuntu uec-images -- 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/1852752 Title: DPMS does not switch off the monitor back light Status in xorg package in Ubuntu: New Bug description: 'xset dpms force off' blanks the screen but does not switch off the HDMI (LCD) monitor backlight. 'xset -q' shows DPMS is enabled. 'tvservice -o' does switch off the monitor. No warnings/errors related to dpms in /var/log/XOrg.0.log Not sure if this is a xorg, kernel, libxcb-dpms0 or other issue. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: xorg 1:7.7+19ubuntu12 ProcVersionSignature: User Name 5.3.0-1012.14-raspi2 5.3.7 Uname: Linux 5.3.0-1012-raspi2 aarch64 ApportVersion: 2.20.11-0ubuntu8.2 Architecture: arm64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: XFCE Date: Fri Nov 15 18:33:52 2019 DistUpgraded: Fresh install DistroCodename: eoan DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 cma=64M cma=256M video=HDMI-A-1:1920x1080@60 smsc95xx.macaddr=DC:A6:32:17:19:0B vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 net.ifnames=0 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait quiet splash SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1852752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
> ubuntu@srv-ywz63:~$ sudo dhclient eth0 > RTNETLINK answers: File exists I think you're trying to start dhclient on an interface that's already setup. root@lp1805183-b:~# dpkg -l systemd|grep ii ii systemd237-3ubuntu10.31 amd64system and service manager root@lp1805183-b:~# journalctl -b -u systemd-resolved | grep Started Nov 15 12:38:54 lp1805183-b systemd[1]: Started Network Name Resolution. root@lp1805183-b:~# dhclient ens8 root@lp1805183-b:~# journalctl -b -u systemd-resolved | grep Started Nov 15 12:38:54 lp1805183-b systemd[1]: Started Network Name Resolution. Nov 15 12:45:42 lp1805183-b systemd[1]: Started Network Name Resolution. root@lp1805183-b:~# sleep 300 ; journalctl -b -u systemd-resolved | grep Started Nov 15 12:38:54 lp1805183-b systemd[1]: Started Network Name Resolution. Nov 15 12:45:42 lp1805183-b systemd[1]: Started Network Name Resolution. Nov 15 12:46:29 lp1805183-b systemd[1]: Started Network Name Resolution. Nov 15 12:47:22 lp1805183-b systemd[1]: Started Network Name Resolution. Nov 15 12:48:10 lp1805183-b systemd[1]: Started Network Name Resolution. Nov 15 12:49:00 lp1805183-b systemd[1]: Started Network Name Resolution. Nov 15 12:49:51 lp1805183-b systemd[1]: Started Network Name Resolution. root@lp1805183-b:~# dpkg -l systemd|grep ii ii systemd237-3ubuntu10.32 amd64system and service manager root@lp1805183-b:~# journalctl -b -u systemd-resolved | grep Started Nov 15 13:19:35 lp1805183-b systemd[1]: Started Network Name Resolution. root@lp1805183-b:~# dhclient ens8 cmp: EOF on /tmp/tmp.64FqHLxW32 which is empty root@lp1805183-b:~# sleep 300 ; journalctl -b -u systemd-resolved | grep Started Nov 15 13:19:35 lp1805183-b systemd[1]: Started Network Name Resolution. Nov 15 13:20:25 lp1805183-b systemd[1]: Started Network Name Resolution. ** Tags removed: verification-needed ** Tags added: verification-done -- 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/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26
[Touch-packages] [Bug 1852018] Re: Audio Stops Playing Briefly When Emptying Trash
No did not experience it with paplay -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1852018 Title: Audio Stops Playing Briefly When Emptying Trash Status in pulseaudio package in Ubuntu: Incomplete Bug description: I am running Ubuntu 19.10 and encountered this issue. I had a podcast playing in the background on Firefox v. 70.0.1 and I was deleting some files. I then proceeded to empty the trash and saw that the audio stops briefly till the "Empty all items from Trash?" prompt shows up. I was able to duplicate this many times and it even occurred with audio on Chrome. The expected way for things to work would be the audio keeps on playing, if I just empty the trash. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1852018/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1852735] Re: Intel r HD Graphics not install
Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, I wonder if you would be better seeking Support instead of filing a bug report. This bug report can be converted to a question (which is aimed at support). You can also find help with your problem in the support forum of your local Ubuntu community http://loco.ubuntu.com/ or asking at https://askubuntu.com or https://ubuntuforums.org, or for more support options please look at https://discourse.ubuntu.com/t/community- support/709 We cannot work on this bug because your description didn't include enough information, as such I've marked it incomplete. If you believe I'm in error, or can provide additional detail of steps done, please change status back to "New" and leave comment. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem. We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected. 3. The behavior you actually encountered (in as much detail as possible). Thanks again for helping make Ubuntu better. ** Changed in: xorg (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1852735 Title: Intel r HD Graphics not install Status in xorg package in Ubuntu: Incomplete Bug description: How to install Intel r HD Graphics install in Lenovo Desktop Model No.mtm 3156-RY6 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.0.0-36.39~18.04.1-generic 5.0.21 Uname: Linux 5.0.0-36-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.9 Architecture: amd64 CompositorRunning: None Date: Fri Nov 15 17:14:37 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: openafs, 1.8.0pre5, 5.0.0-35-generic, x86_64: installed openafs, 1.8.0pre5, 5.0.0-36-generic, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics Controller [17aa:307c] InstallationDate: Installed on 2019-11-13 (1 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 17ef:608d Lenovo Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 3156RY6 ProcEnviron: LANGUAGE=en_IN:en TERM=xterm-256color PATH=(custom, no user) LANG=en_IN SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-36-generic root=UUID=ecada68e-a7eb-4e27-89af-66755d1dedc6 ro quiet splash vt.handoff=1 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/19/2011 dmi.bios.vendor: LENOVO dmi.bios.version: 9QKT29AUS dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: To be filled by O.E.M. dmi.board.vendor: LENOVO dmi.board.version: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnLENOVO:bvr9QKT29AUS:bd08/19/2011:svnLENOVO:pn3156RY6:pvrThinkCentreM71e:rvnLENOVO:rnTobefilledbyO.E.M.:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: 3156RY6 dmi.product.sku: To be filled by O.E.M. dmi.product.version: ThinkCentre M71e dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.3 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.3 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1852735/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1852735] [NEW] Intel r HD Graphics not install
Public bug reported: How to install Intel r HD Graphics install in Lenovo Desktop Model No.mtm 3156-RY6 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.0.0-36.39~18.04.1-generic 5.0.21 Uname: Linux 5.0.0-36-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.9 Architecture: amd64 CompositorRunning: None Date: Fri Nov 15 17:14:37 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: openafs, 1.8.0pre5, 5.0.0-35-generic, x86_64: installed openafs, 1.8.0pre5, 5.0.0-36-generic, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics Controller [17aa:307c] InstallationDate: Installed on 2019-11-13 (1 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 17ef:608d Lenovo Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 3156RY6 ProcEnviron: LANGUAGE=en_IN:en TERM=xterm-256color PATH=(custom, no user) LANG=en_IN SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-36-generic root=UUID=ecada68e-a7eb-4e27-89af-66755d1dedc6 ro quiet splash vt.handoff=1 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/19/2011 dmi.bios.vendor: LENOVO dmi.bios.version: 9QKT29AUS dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: To be filled by O.E.M. dmi.board.vendor: LENOVO dmi.board.version: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnLENOVO:bvr9QKT29AUS:bd08/19/2011:svnLENOVO:pn3156RY6:pvrThinkCentreM71e:rvnLENOVO:rnTobefilledbyO.E.M.:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: 3156RY6 dmi.product.sku: To be filled by O.E.M. dmi.product.version: ThinkCentre M71e dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.3 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.3 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ubuntu -- 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/1852735 Title: Intel r HD Graphics not install Status in xorg package in Ubuntu: New Bug description: How to install Intel r HD Graphics install in Lenovo Desktop Model No.mtm 3156-RY6 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.0.0-36.39~18.04.1-generic 5.0.21 Uname: Linux 5.0.0-36-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.9 Architecture: amd64 CompositorRunning: None Date: Fri Nov 15 17:14:37 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: openafs, 1.8.0pre5, 5.0.0-35-generic, x86_64: installed openafs, 1.8.0pre5, 5.0.0-36-generic, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics Controller [17aa:307c] InstallationDate: Installed on 2019-11-13 (1 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 17ef:608d Lenovo Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 3156RY6 ProcEnviron: LANGUAGE=en_IN:en TERM=xterm-256color PATH=(custom, no user) LANG=en_IN SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-36-generic root=UUID=ecada68e-a7eb-4e27-89af-66755d1dedc6 ro quiet splash
[Touch-packages] [Bug 1843381] Re: Dell system takes a long time to connect network with external dock
I can confirm that systemd 237-3ubuntu10.32 fixes this issue for me on disco. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1843381 Title: Dell system takes a long time to connect network with external dock Status in OEM Priority Project: New Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Invalid Bug description: [impact] On Dell system with BIOS-based "MAC passthrough", there can be multiple USB nics with identical MAC addresses. Since the udev rules in Debian and Ubuntu assign interface names for USB nics by mac address (because that is the only consistent identifier for USB nics; their path can change based on which USB port they are connected to), it's impossible to name two interfaces with the same name. As Ubuntu also carries a patch to retry renaming of any interface when the first renaming fails, this causes a 90 second delay before being able to the "MAC passthrough" nic after connecting it. [test case] On a system with this "MAC passthrough" enabled and required devices, boot the system and then connect to the dock or connect the second USB nic with identical MAC. It will not be usable for 90 seconds as its renames takes that long to timeout. [regression potential] the change here is very limited to only Dell systems with the specific USB vendor/product ID affected by this, and additionally the change only sets a ENV flag in the udev rule, which is later used by udevd to skip the rename-retries for 90 seconds. So, the regression potential for anyone else without a system affected by this "MAC passthrough" should be very low, and any regression potential for those with this "MAC passthrough" should still be low, as this only skips the rename- retry that we know will never succeed. However, the regression potential is likely limited to failure to properly name a USB nic, or other bugs during the udev processing of new USB nics. [other info] original description: --- This is a bug reopen from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700 The original one caused systemd regressed. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651 This issue needs an alternative solution. Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme
