[Touch-packages] [Bug 2078866] [NEW] Laptop will not charge, will charge when powered down or on Windows
Public bug reported: I have tried Ubuntu 20.04, 22.04, 24.04.01. Also tried Debian and Mint. Will not charge on any variant of Debian. Charge indicator stays at whatever value was present before booting Linux. Shows 0 charge rate. Tried multiple acpi settings and changing kernels. Will only not charge in Ubuntu. Purchased a new battery and have the same results as previous battery. native-path: BAT0 vendor: 13-42 model:HS04041 serial: 5938 power supply: yes updated: Mon 02 Sep 2024 12:27:07 PM PDT (48 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable:yes state: charging warning-level: none energy: 24.7392 Wh energy-empty:0 Wh energy-full: 37.9872 Wh energy-full-design: 37.9872 Wh energy-rate: 0 W voltage: 15.251 V charge-cycles: N/A percentage: 65% capacity:100% technology: lithium-ion icon-name: 'battery-full-charging-symbolic' ** Affects: upower (Ubuntu) Importance: Undecided Status: New ** Description changed: - I have tried Ubuntu 20.04, 22.04, 24.04.01. Also tried Debian and Mint. - Will not charge on any variant of Debian. Charge indicator stays at - whatever value was present before booting Linux. Shows 0 charge rate. - Tried multiple acpi settings and changing kernels. Will only not charge - in Ubuntu. + I have tried Ubuntu 20.04, 22.04, 24.04.01. Also tried Debian and Mint. Will not charge on any variant of Debian. Charge indicator stays at whatever value was present before booting Linux. Shows 0 charge rate. Tried multiple acpi settings and changing kernels. Will only not charge in Ubuntu. + Purchased a new battery and have the same results as previous battery. native-path: BAT0 - vendor: 13-42 - model:HS04041 - serial: 5938 - power supply: yes - updated: Mon 02 Sep 2024 12:27:07 PM PDT (48 seconds ago) - has history: yes - has statistics: yes - battery - present: yes - rechargeable:yes - state: charging - warning-level: none - energy: 24.7392 Wh - energy-empty:0 Wh - energy-full: 37.9872 Wh - energy-full-design: 37.9872 Wh - energy-rate: 0 W - voltage: 15.251 V - charge-cycles: N/A - percentage: 65% - capacity:100% - technology: lithium-ion - icon-name: 'battery-full-charging-symbolic' + vendor: 13-42 + model:HS04041 + serial: 5938 + power supply: yes + updated: Mon 02 Sep 2024 12:27:07 PM PDT (48 seconds ago) + has history: yes + has statistics: yes + battery + present: yes + rechargeable:yes + state: charging + warning-level: none + energy: 24.7392 Wh + energy-empty:0 Wh + energy-full: 37.9872 Wh + energy-full-design: 37.9872 Wh + energy-rate: 0 W + voltage: 15.251 V + charge-cycles: N/A + percentage: 65% + capacity:100% + technology: lithium-ion + icon-name: 'battery-full-charging-symbolic' -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upower in Ubuntu. https://bugs.launchpad.net/bugs/2078866 Title: Laptop will not charge, will charge when powered down or on Windows Status in upower package in Ubuntu: New Bug description: I have tried Ubuntu 20.04, 22.04, 24.04.01. Also tried Debian and Mint. Will not charge on any variant of Debian. Charge indicator stays at whatever value was present before booting Linux. Shows 0 charge rate. Tried multiple acpi settings and changing kernels. Will only not charge in Ubuntu. Purchased a new battery and have the same results as previous battery. native-path: BAT0 vendor: 13-42 model:HS04041 serial: 5938 power supply: yes updated: Mon 02 Sep 2024 12:27:07 PM PDT (48 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable:yes state: charging warning-level: none energy: 24.7392 Wh energy-empty:0 Wh energy-full: 37.9872 Wh energy-full-design: 37.9872 Wh energy-rate: 0 W voltage: 15.251 V charge-cycles: N/A perce
[Touch-packages] [Bug 2077761] Re: Enhancement Request - General Personalization of Date/Time specification
I believe the option to make such customization should be happening up-
front, during the installation, so that presumably the OS could have the
preferred format "hard-coded" so that there isn't overhead at every
usage to generate the customized date/time reporting.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2077761
Title:
Enhancement Request - General Personalization of Date/Time
specification
Status in coreutils package in Ubuntu:
New
Bug description:
The following was sent as an email to coreut...@gnu.org as directed
by them.
=
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
Version:coreutils 8.32-4.1ubuntu1.2
What I expect to happen: Please see below.
Question: Why does ubuntu-bug transmit 300kbs for close to 4 minutes !!!
That is a log of data, and I have to question the justification for so much
data.
=
Hello,
Please refer to my postings,
=
here
(https://github.com/mate-desktop/caja/issues/1712#issuecomment-2305818307),
where I stated:
The issue here is that the FORMAT for time and date should be set
set from the UbuntuMATE Preferences window for Time and Date**, for it
to be globally applied to the system.
The choices offered should be
either as a regional/country/ISO default, or
a personalized version of a regional/country/ISO default.
This would involve a click-toggle to offer customization of any date/time
field.
This could include user-defined change of TimeZone, to a specified
region/country, even if that TimeZone is different than the default, I suggest
selectable by drop-down).
Once that specification is chosen/edited, that format
specification should be applied universally for all user-oriented
interactions, with the exception of those that are core system (i.e.
syslog and the like, which would use the regional/county/ISO default
underlying the user's personalizations.
Something like that was previously offered in one of the older
Ubuntu distros (somewhere between 10 and 16) but I can't remember
which one.
=
and here
(https://github.com/mate-desktop/caja/issues/616#issuecomment-2305779056),
where I stated:
I have this bash logic which I would like to see merged into Caja
as an option for global time formatting. Would that be possible? (I
would like it for the ls command, but I don't think that you handle
that. :-) )
Create customized version of ‘ls l’ to report on files during the
progress of the script.
Key aspect is that, if the modification is older than 24 hours,
it reports only the date;
otherwise
it reports only the time of the last change using the 24-hour
clock.
myLs()
{
#eval stat --format=\"\|\%A\|\%h\|\%s\|\%y\|\%n\|\" \"${1}\"
eval stat --format=\"\|\%A\|\%h\|\%s\|\%Y\|\%n\|\" \"${1}\" |
awk -v now=${time_now} '{
n=split( $0, vals, "|" ) ;
#mult24=( (1.0*now) - vals[5] )/86400 ;
#print mult24 ;
# 86400 seconds in a 24 hour period
if( ( (1.0*now) - vals[5] )/86400 > 1 ){
printf("%s %2s %15s %10s %s\n", vals[2], vals[3],
vals[4], strftime("%F", vals[5]), vals[6] ) ;
}else{
printf("%s %2s %15s %9s %s\n", vals[2], vals[3],
vals[4], strftime("%R:%S", vals[5]), vals[6] ) ;
} ;
}'
}
=
Thank you in advance for your consideration and, hopefully your
acceptance of this feature request.
Regards,
Eric Marceau
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: coreutils 8.32-4.1ubuntu1.2
ProcVersionSignature: Ubuntu 5.15.0-116.126-generic 5.15.158
Uname: Linux 5.15.0-116-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Fri Aug 23 15:25:27 2024
InstallationDate: Installed on 2020-10-29 (1394 days ago)
InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64
(20200423)
ProcEnviron:
LANGUAGE=en_CA:en
TERM=xterm-256color
PATH=(custom, no user)
LANG=en_CA.UTF-8
SHELL=/bin/bash
SourcePackage: coreutils
UpgradeStatus: Upgraded to jammy on 2024-07-14 (40 days ago)
To manag
[Touch-packages] [Bug 2077761] [NEW] Enhancement Request - General Personalization of Date/Time specification
Public bug reported:
The following was sent as an email to coreut...@gnu.org as directed by
them.
=
Distributor ID: Ubuntu
Description:Ubuntu 22.04.4 LTS
Release:22.04
Codename: jammy
Version:coreutils 8.32-4.1ubuntu1.2
What I expect to happen: Please see below.
Question: Why does ubuntu-bug transmit 300kbs for close to 4 minutes !!! That
is a log of data, and I have to question the justification for so much data.
=
Hello,
Please refer to my postings,
=
here (https://github.com/mate-desktop/caja/issues/1712#issuecomment-2305818307),
where I stated:
The issue here is that the FORMAT for time and date should be set
set from the UbuntuMATE Preferences window for Time and Date**, for it
to be globally applied to the system.
The choices offered should be
either as a regional/country/ISO default, or
a personalized version of a regional/country/ISO default.
This would involve a click-toggle to offer customization of any date/time
field.
This could include user-defined change of TimeZone, to a specified
region/country, even if that TimeZone is different than the default, I suggest
selectable by drop-down).
Once that specification is chosen/edited, that format specification
should be applied universally for all user-oriented interactions, with
the exception of those that are core system (i.e. syslog and the like,
which would use the regional/county/ISO default underlying the user's
personalizations.
Something like that was previously offered in one of the older
Ubuntu distros (somewhere between 10 and 16) but I can't remember which
one.
=
and here
(https://github.com/mate-desktop/caja/issues/616#issuecomment-2305779056),
where I stated:
I have this bash logic which I would like to see merged into Caja as
an option for global time formatting. Would that be possible? (I would
like it for the ls command, but I don't think that you handle that. :-)
)
Create customized version of ‘ls l’ to report on files during the
progress of the script.
Key aspect is that, if the modification is older than 24 hours,
it reports only the date;
otherwise
it reports only the time of the last change using the 24-hour clock.
myLs()
{
#eval stat --format=\"\|\%A\|\%h\|\%s\|\%y\|\%n\|\" \"${1}\"
eval stat --format=\"\|\%A\|\%h\|\%s\|\%Y\|\%n\|\" \"${1}\" |
awk -v now=${time_now} '{
n=split( $0, vals, "|" ) ;
#mult24=( (1.0*now) - vals[5] )/86400 ;
#print mult24 ;
# 86400 seconds in a 24 hour period
if( ( (1.0*now) - vals[5] )/86400 > 1 ){
printf("%s %2s %15s %10s %s\n", vals[2], vals[3],
vals[4], strftime("%F", vals[5]), vals[6] ) ;
}else{
printf("%s %2s %15s %9s %s\n", vals[2], vals[3],
vals[4], strftime("%R:%S", vals[5]), vals[6] ) ;
} ;
}'
}
=
Thank you in advance for your consideration and, hopefully your
acceptance of this feature request.
Regards,
Eric Marceau
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: coreutils 8.32-4.1ubuntu1.2
ProcVersionSignature: Ubuntu 5.15.0-116.126-generic 5.15.158
Uname: Linux 5.15.0-116-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Fri Aug 23 15:25:27 2024
InstallationDate: Installed on 2020-10-29 (1394 days ago)
InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64
(20200423)
ProcEnviron:
LANGUAGE=en_CA:en
TERM=xterm-256color
PATH=(custom, no user)
LANG=en_CA.UTF-8
SHELL=/bin/bash
SourcePackage: coreutils
UpgradeStatus: Upgraded to jammy on 2024-07-14 (40 days ago)
** Affects: coreutils (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug jammy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2077761
Title:
Enhancement Request - General Personalization of Date/Time
specification
Status in coreutils package in Ubuntu:
New
Bug description:
The following was sent as an email to coreut...@gnu.org as directed
by them.
=
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
Version:coreutils 8.32-4.1u
[Touch-packages] [Bug 1285444] Re: Login Successful, Desktop Never Loads
Same issue with Secure boot enable and file system encrypted. The only workaround i find was at the login screen toggle to shell Crtl Alt F3, then login and manually launch the gnome (startx) to see what was wrong.The error was xf86enableio failed to enable io ports -03ff operation. Something wrong in the configuration file perhaps linked with the use of a dual screen configuration. So sudo apt install ubuntu- desktop will allow to run gnome ( without tweaks from canonical). The only problem is that in the x.conf there is a leak of definition for the second screen but i think it's a know bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to at-spi2-core in Ubuntu. https://bugs.launchpad.net/bugs/1285444 Title: Login Successful, Desktop Never Loads Status in at-spi2-core package in Ubuntu: Triaged Bug description: Here is what I encounter 1. Boot computer, boot proceeds normally 2. Reach standard Ubuntu login screen, nothing seems to be amiss 3. Enter user name and password 4. Login disappears, just see the pink "Ubuntu 14.04" background The desktop never loads, not even after ~30 minutes. The launcher never appears, and the Desktop background never changes to the user- configured background. Other features: * Cursor works fine, it can be moved around the screen * No error messages pop up * ALT+F1 etc. can be used to switch to different TTYs; all files on the system appear to be intact * Print screen button works (I will upload a screen shot when I get a chance to copy it onto a USB drive) * Hitting power button pops up a window prompting the user to decide whether to shut down * CTRL+ALT+DELETE prompts the user to log out * Desktop does not load on any user accounts, including the guest account To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/at-spi2-core/+bug/1285444/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2038490] Re: Apt and apt-get reporting different lists of packages to be held back/upgraded
Thank you. I'd wondered how something seeingly so significant had gone unnoticed. I apologize for the invalid bug report. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/2038490 Title: Apt and apt-get reporting different lists of packages to be held back/upgraded Status in apt package in Ubuntu: Invalid Bug description: When running apt-get from a script (or command line), I see a different list of packages to be held back / upgraded vs when I run apt. I am running Kubuntu 23.04. The version of apt and apt-get I first noticed the problem in is 2.6.0ubuntu0.1 I also see the problem on my servers running Ubuntu 22.04.3 with apt and apt-get version 2.4.10. I upgraded my copy on Kubuntu 23.04 to 2.7.6 through the launchpad.net ppa deity/sid (actually version 2.7.6+0~202309200852~ubuntu23.04.1) and the problem remains. I've spent a few hours looking for the correct place to search for this being already reported and have reviewed recent commits at https://salsa.debian.org/apt-team/apt. I'm hesitant but I do not see any other mention of this issue. I have tried deleting my /var/cache/apt and running apt update. To duplicate the issue one needs to have an Ubuntu version that has not yet received the update to linux-headers-6.2.0-34, et al. I attempted to duplicate the issue on a fresh install of Ubuntu Desktop 23.04, but discovered that the system is upgraded to linux 6.2.0-34 during the install process. Please see the output of the apt-get and apt commands below. $ apt-get update Hit:1 http://ftp.usf.edu/pub/ubuntu lunar InRelease Hit:2 http://ftp.usf.edu/pub/ubuntu lunar-updates InRelease Hit:3 http://ftp.usf.edu/pub/ubuntu lunar-backports InRelease Hit:4 https://dl.winehq.org/wine-builds/ubuntu lunar InRelease Hit:5 http://ftp.usf.edu/pub/ubuntu lunar-security InRelease Hit:6 http://packages.microsoft.com/repos/code stable InRelease Hit:7 https://repo.steampowered.com/steam stable InRelease Hit:8 https://pkg.cloudflareclient.com jammy InRelease Hit:9 https://download.sublimetext.com apt/stable/ InRelease Get:10 https://pkgs.tailscale.com/stable/ubuntu jammy InRelease Ign:11 https://repo.vivaldi.com/stable/deb stable InRelease Hit:12 https://repo.vivaldi.com/stable/deb stable Release Hit:13 https://download.virtualbox.org/virtualbox/debian jammy InRelease Ign:16 https://download.webmin.com/download/repository sarge InRelease Hit:17 https://ppa.launchpadcontent.net/cappelikan/ppa/ubuntu lunar InRelease Hit:18 https://download.webmin.com/download/repository sarge Release Hit:21 https://ppa.launchpadcontent.net/teejee2008/foss/ubuntu lunar InRelease Hit:14 https://packagecloud.io/github/git-lfs/ubuntu lunar InRelease Hit:15 https://packagecloud.io/eugeny/tabby/ubuntu jammy InRelease Hit:22 https://ppa.launchpadcontent.net/cubic-wizard/release/ubuntu lunar InRelease Hit:23 https://repo.waydro.id bullseye InRelease Hit:24 https://ppa.launchpadcontent.net/deity/sid/ubuntu lunar InRelease Hit:25 https://ppa.launchpadcontent.net/papirus/papirus/ubuntu lunar InRelease Fetched 6,557 B in 3s (2,503 B/s) Reading package lists... Done $ apt-get upgrade --assume-no Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages have been kept back: grub-efi-amd64-bin grub-efi-amd64-signed linux-generic linux-headers-generic linux-image-generic The following packages will be upgraded: code freerdp2-x11 libfreerdp-client2-
[Touch-packages] [Bug 2038490] [NEW] Apt and apt-get reporting different lists of packages to be held back/upgraded
Public bug reported: When running apt-get from a script (or command line), I see a different list of packages to be held back / upgraded vs when I run apt. I am running Kubuntu 23.04. The version of apt and apt-get I first noticed the problem in is 2.6.0ubuntu0.1 I also see the problem on my servers running Ubuntu 22.04.3 with apt and apt-get version 2.4.10. I upgraded my copy on Kubuntu 23.04 to 2.7.6 through the launchpad.net ppa deity/sid (actually version 2.7.6+0~202309200852~ubuntu23.04.1) and the problem remains. I've spent a few hours looking for the correct place to search for this being already reported and have reviewed recent commits at https://salsa.debian.org/apt-team/apt. I'm hesitant but I do not see any other mention of this issue. I have tried deleting my /var/cache/apt and running apt update. To duplicate the issue one needs to have an Ubuntu version that has not yet received the update to linux-headers-6.2.0-34, et al. I attempted to duplicate the issue on a fresh install of Ubuntu Desktop 23.04, but discovered that the system is upgraded to linux 6.2.0-34 during the install process. Please see the output of the apt- get and apt commands below. $ apt-get update Hit:1 http://ftp.usf.edu/pub/ubuntu lunar InRelease Hit:2 http://ftp.usf.edu/pub/ubuntu lunar-updates InRelease Hit:3 http://ftp.usf.edu/pub/ubuntu lunar-backports InRelease Hit:4 https://dl.winehq.org/wine-builds/ubuntu lunar InRelease Hit:5 http://ftp.usf.edu/pub/ubuntu lunar-security InRelease Hit:6 http://packages.microsoft.com/repos/code stable InRelease Hit:7 https://repo.steampowered.com/steam stable InRelease Hit:8 https://pkg.cloudflareclient.com jammy InRelease Hit:9 https://download.sublimetext.com apt/stable/ InRelease Get:10 https://pkgs.tailscale.com/stable/ubuntu jammy InRelease Ign:11 https://repo.vivaldi.com/stable/deb stable InRelease Hit:12 https://repo.vivaldi.com/stable/deb stable Release Hit:13 https://download.virtualbox.org/virtualbox/debian jammy InRelease Ign:16 https://download.webmin.com/download/repository sarge InRelease Hit:17 https://ppa.launchpadcontent.net/cappelikan/ppa/ubuntu lunar InRelease Hit:18 https://download.webmin.com/download/repository sarge Release Hit:21 https://ppa.launchpadcontent.net/teejee2008/foss/ubuntu lunar InRelease Hit:14 https://packagecloud.io/github/git-lfs/ubuntu lunar InRelease Hit:15 https://packagecloud.io/eugeny/tabby/ubuntu jammy InRelease Hit:22 https://ppa.launchpadcontent.net/cubic-wizard/release/ubuntu lunar InRelease Hit:23 https://repo.waydro.id bullseye InRelease Hit:24 https://ppa.launchpadcontent.net/deity/sid/ubuntu lunar InRelease Hit:25 https://ppa.launchpadcontent.net/papirus/papirus/ubuntu lunar InRelease Fetched 6,557 B in 3s (2,503 B/s) Reading package lists... Done $ apt-get upgrade --assume-no Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages have been kept back: grub-efi-amd64-bin grub-efi-amd64-signed linux-generic linux-headers-generic linux-image-generic The following packages will be upgraded: code freerdp2-x11 libfreerdp-client2-2 libfreerdp-server2-2 libfreerdp2-2 libwinpr2-2 6 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. Need to get 97.1 MB of archives. After this operation, 1,480 kB of additional disk space will be used. Do you want to continue? [Y/n] N Abort. $ apt upgrade --assume-no Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: linux-headers-6.2.0-34 linux-headers-6.2.0-34-generic linux-image-6.2.0-3
[Touch-packages] [Bug 2026814] [NEW] package apparmor 3.0.8-1ubuntu2.1 failed to install/upgrade: installed apparmor package post-installation script subprocess returned error exit status 1
Public bug reported: ubuntu unity is being used. ProblemType: Package DistroRelease: Ubuntu 23.04 Package: apparmor 3.0.8-1ubuntu2.1 ProcVersionSignature: Ubuntu 6.2.0-24.24-generic 6.2.12 Uname: Linux 6.2.0-24-generic x86_64 ApportVersion: 2.26.1-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass Date: Tue Jul 11 18:34:08 2023 ErrorMessage: installed apparmor package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2023-07-11 (0 days ago) InstallationMedia: Ubuntu-Unity 23.04 "Lunar Lobster" - Release amd64 (20230419) ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-6.2.0-24-generic root=UUID=fb045af7-2921-4e16-932c-8a1bd04f1db7 ro quiet splash vt.handoff=7 Python3Details: /usr/bin/python3.11, Python 3.11.2, python3-minimal, 3.11.2-1 PythonDetails: N/A RelatedPackageVersions: dpkg 1.21.21ubuntu1 apt 2.6.0 SourcePackage: apparmor Title: package apparmor 3.0.8-1ubuntu2.1 failed to install/upgrade: installed apparmor package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package lunar -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2026814 Title: package apparmor 3.0.8-1ubuntu2.1 failed to install/upgrade: installed apparmor package post-installation script subprocess returned error exit status 1 Status in apparmor package in Ubuntu: New Bug description: ubuntu unity is being used. ProblemType: Package DistroRelease: Ubuntu 23.04 Package: apparmor 3.0.8-1ubuntu2.1 ProcVersionSignature: Ubuntu 6.2.0-24.24-generic 6.2.12 Uname: Linux 6.2.0-24-generic x86_64 ApportVersion: 2.26.1-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass Date: Tue Jul 11 18:34:08 2023 ErrorMessage: installed apparmor package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2023-07-11 (0 days ago) InstallationMedia: Ubuntu-Unity 23.04 "Lunar Lobster" - Release amd64 (20230419) ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-6.2.0-24-generic root=UUID=fb045af7-2921-4e16-932c-8a1bd04f1db7 ro quiet splash vt.handoff=7 Python3Details: /usr/bin/python3.11, Python 3.11.2, python3-minimal, 3.11.2-1 PythonDetails: N/A RelatedPackageVersions: dpkg 1.21.21ubuntu1 apt 2.6.0 SourcePackage: apparmor Title: package apparmor 3.0.8-1ubuntu2.1 failed to install/upgrade: installed apparmor package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2026814/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1964763] Re: QtChooser doesn't support qt6
Adding further configuration for Chooser may support invocation of tools for Qt 6, but desktop icons, for example, for Designer, are also unavailable except for Qt 5. Perhaps the report would be more appropriate for a different package. Unfortunately, I am not adequately familiar with the system. The organization of the various packages for Qt 6 is quite chaotic. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtchooser in Ubuntu. https://bugs.launchpad.net/bugs/1964763 Title: QtChooser doesn't support qt6 Status in qtchooser package in Ubuntu: Confirmed Bug description: qtchooser doesn't run qt6 applications because it doesn't have a qt6.conf/6.conf file yet. In order to work, it must have two files `/usr/lib/x86_64-linux- gnu/qtchooser/qt6.conf` and a `/usr/lib/x86_64-linux- gnu/qtchooser/6.conf` with this content: ``` /usr/lib/qt6/bin /usr/lib/x86_64-linux-gnu ``` Without it, lupdate, lrelease, and any other qt6 tools show this error: `could not find a Qt installation of ''` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qtchooser/+bug/1964763/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1992497] Re: 22.04 LTS: alsa-library + PulseAudio won't detect my USB sound card
Alsa-lib + Pulseaudio. Library version 1.2.6.1 ** Package changed: ubuntu => alsa-lib (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-lib in Ubuntu. https://bugs.launchpad.net/bugs/1992497 Title: 22.04 LTS: alsa-library + PulseAudio won't detect my USB sound card Status in alsa-lib package in Ubuntu: New Bug description: ALSA+Pulseaudio have always been difficult with USB Sound. In order to make it work under the best of circumstances, one would have to edit /etc/modprobe.d/alsa-base.conf And comment out any line that said options snd-usb-audio index=-2 Without commenting that out, PulseAudio cannot detect the card. Now, Ubuntu 22.04 LTS worked for a while with that change. Until Roughly the last week of September, 2022. A normal update got pushed which disabled my sound card. Alsa-lib version: 1.2.6.1 In /var/log/syslog: Oct 02 14:33:56 patchwork alsactl[1000]: alsa-lib main.c:1412:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -2 After two weeks of effort, and attempts to roll back to an earlier version of 22.04 LTS, I scrubbed the root partition and reverted to 20.04 LTS which works right. Samples of output from my exercise can be found here: https://ubuntuforums.org/showthread.php?t=2479484 Again, Xubuntu 22.04 LTS worked (after the alsa-base.conf edit) fine, Until the end of September update. The above thread on ubuntuforums.org has samples of lsusb, syslog, output from various ALSA utilities and PulseAudio utilities, brands and models of USB sound DACs tried, alsa-version output, and so on. If you need me to, I can build a throwaway system to get you any further information you want, but I'd rather not scrub a fully configured root partition *again* to go through this effort. linuxquestions.org showed that a search on "failed to open hw:1 use case configuration" or subsets of that phrase will show this bug. The tip of the ALSA development chain release notes for a while back shows no effort put forward to fixing this problem. What works is Alsa-lib version 1.2.2. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/1992497/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982086] Re: package linux-image-5.4.0-1080-aws 5.4.0-1080.87 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
I'm seeing the same thing just trying to update via apt update && apt upgrade -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1982086 Title: package linux-image-5.4.0-1080-aws 5.4.0-1080.87 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Status in initramfs-tools package in Ubuntu: Confirmed Bug description: Ubuntu 18 to 20 version update failed ProblemType: Package DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-1080-aws 5.4.0-1080.87 ProcVersionSignature: Ubuntu 5.4.0-1081.88~18.04.1-aws 5.4.192 Uname: Linux 5.4.0-1081-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip Date: Tue Jul 19 07:33:31 2022 Ec2AMI: ami-04a019398ef05fc20 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: ap-southeast-2b Ec2InstanceType: t2.micro Ec2Kernel: unavailable Ec2Ramdisk: unavailable ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.9 SourcePackage: initramfs-tools Title: package linux-image-5.4.0-1080-aws 5.4.0-1080.87 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: Upgraded to focal on 2022-07-19 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1982086/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1969976] Re: DynamicUser=1 doesn't get along with services that need dbus-daemon
Can someone explain why this fix is still not rolled out on Focal and Jammy? What am I missing? -- 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/1969976 Title: DynamicUser=1 doesn't get along with services that need dbus-daemon Status in Fwupd: Fix Released Status in systemd: New Status in fwupd package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Won't Fix Status in fwupd source package in Focal: Confirmed Status in systemd source package in Focal: Won't Fix Status in fwupd source package in Impish: Won't Fix Status in systemd source package in Impish: Won't Fix Status in fwupd source package in Jammy: Confirmed Status in systemd source package in Jammy: Won't Fix Bug description: Updating to systemd 245.4-4ubuntu3.16 has caused a regression in Ubuntu 20.04, that fwupd-refresh.service always fails to run. This has been root caused down to the changes in https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538 Unfortunately this is an upstream issue introduced by stable systemd. https://github.com/systemd/systemd/issues/22737 The problem also occurs in Ubuntu 22.04 with a newer systemd release. As discussed in https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538/comments/61 it's a tradeoff of issues. So within Ubuntu something probably needs to be done about fwupd-refresh.service. One proposal is to remove DynamicUser=yes from the systemd unit, but this will mean fwupdgmr refresh runs as root. It's relatively sandboxed by other security mechanisms, but still not ideal. Could we repurpose any other service account? Or alternatively we can make a new fwupd service account that this systemd unit uses. To manage notifications about this bug go to: https://bugs.launchpad.net/fwupd/+bug/1969976/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1971409] Re: value_copy: Assertion `arg->contents != nullptr' failed.
It would be much appreciated if a LTS version of ubuntu would not ship completely broken random master branch checkouts for months. See also https://github.com/microsoft/vscode-cpptools/issues/9135 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1971409 Title: value_copy: Assertion `arg->contents != nullptr' failed. Status in gdb package in Ubuntu: Confirmed Bug description: When debugging RP2040 with vscode this assert makes gdb crash. This is a new assert, that wasn't present in gdb 11. The fix is easy, replace `if (!value_lazy (val))` to `if (!value_lazy (val) && arg->contents != nullptr) `. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1971409/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974230] [NEW] Negative cache results from dnsmasq do not include SOA as required in RFC2308
Public bug reported: RFC2308 states: 6 - Negative answers from the cache When a server, in answering a query, encounters a cached negative response it MUST add the cached SOA record to the authority section of the response with the TTL decremented by the amount of time it was stored in the cache. This allows the NXDOMAIN / NODATA response to time out correctly. The effect is that the negative cache results returned by dnsmasq cannot be cached by other resolvers such as systemd-resolved. A good example of why this is a problem: Two clients with systemd-resolved send DNS queries to dnsmasq for the same record The first one makes a query and gets NXDOMAIN with SOA. This results in systemd-resolved caching the negative result. The second client makes a query and gets NODATA without the SOA. This results in systemd-resolved not caching the negative result. Consider a domain name that only has an A record published. When connecting to that domain a lookup happens for the and A record. One can end up in a situation where systemd-resolved has the A record cached locally, but it still goes out to the network to perform the lookup only to get the same negative cache result that is missing the SOA I see this behavior in 18.04 and 22.04 First query to dnsmasq can be cached: dig @10.0.1.21 a.google.com ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3107 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;a.google.com. IN A ;; AUTHORITY SECTION: google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. 449437361 900 900 1800 60 ;; Query time: 15 msec ;; SERVER: 10.0.1.21#53(10.0.1.21) ;; WHEN: Thu May 19 15:00:12 EDT 2022 ;; MSG SIZE rcvd: 91 Cached response from dnsmasq cannot be cached: dig @10.0.1.21 a.google.com ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61408 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;a.google.com. IN A ;; Query time: 0 msec ;; SERVER: 10.0.1.21#53(10.0.1.21) ;; WHEN: Thu May 19 15:00:13 EDT 2022 ;; MSG SIZE rcvd: 41 ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1974230 Title: Negative cache results from dnsmasq do not include SOA as required in RFC2308 Status in dnsmasq package in Ubuntu: New Bug description: RFC2308 states: 6 - Negative answers from the cache When a server, in answering a query, encounters a cached negative response it MUST add the cached SOA record to the authority section of the response with the TTL decremented by the amount of time it was stored in the cache. This allows the NXDOMAIN / NODATA response to time out correctly. The effect is that the negative cache results returned by dnsmasq cannot be cached by other resolvers such as systemd-resolved. A good example of why this is a problem: Two clients with systemd-resolved send DNS queries to dnsmasq for the same record The first one makes a query and gets NXDOMAIN with SOA. This results in systemd-resolved caching the negative result. The second client makes a query and gets NODATA without the SOA. This results in systemd-resolved not caching the negative result. Consider a domain name that only has an A record published. When connecting to that domain a lookup happens for the and A record. One can end up in a situation where systemd-resolved has the A record cached locally, but it still goes out to the network to perform the lookup only to get the same negative cache result that is missing the SOA I see this behavior in 18.04 and 22.04 First query to dnsmasq can be cached: dig @10.0.1.21 a.google.com ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3107 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;a.google.com. IN A ;; AUTHORITY SECTION: google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. 449437361 900 900 1800 60 ;; Query time: 15 msec ;; SERVER: 10.0.1.21#53(10.0.1.21) ;; WHEN: Thu May 19 15:00:12 EDT 2022 ;; MSG SIZE rcvd: 91 Cached response from dnsmasq ca
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
> I will attempt to upstream this fix to klibc, but I believe the change
to Bionic should happen in parallel/independently since the upstream
patch will not make its way back to Bionic (which is stuck at 2.0.4, as
mentioned above).
Yes that is the plan to SRU the fix on top of what is currently found in
Bionic's klibc.
And I'll gladly sponsor your patch in Bionic.
The idea with upstream is to make our contribution available to other
who may suffer from the same issue, make sure it won't re-occur in a
future release of Ubuntu as we will sync from debian which sync from
upstream, ... and also have some kind of upstream
adoption/approval/review of your proposal fix.
Let's give a few days after the submission for the upstream to have some
time to review your patch. If it takes too long for them to get back to
us, I'll sponsor the patch as-is, knowing that it was submitted to
upstream with a reasonable amount of time given to them to review.
- Eric
** Changed in: klibc (Ubuntu Bionic)
Assignee: (unassigned) => Khaled El Mously (kmously)
** Changed in: klibc (Ubuntu Bionic)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
In Progress
Bug description:
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the
timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too
(see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
And let them judge if it's worth an upstream adoption or not as a first
exercise. Then we can take a decision for Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
I still believe, it would be a good practice to submit the patch to
upstream.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
And let them judge if it's worth the adoption or not as a first
exercise. Then we can take a decision for Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Khaled El Mously (kmously),
Thanks for the update. I'll review this and talk with sil2100, an SRU
verification member.
Could you please help to fill the SRU template in the description above.
Extra documentations can be found here:
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
What make Bionic more susceptible to this particular problem ? Bionic
kernel version in use ? else ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1949495] [NEW] Error shown when using chsh to change shells
Public bug reported: I wanted to change my shell to zsh so I installed the zsh package and then used the chsh command as so: chsh -s $(which zsh) After running the command I am shown the errors: (2021-11-02 12:54:47:928739): [sss_cache] [confdb_get_enabled_domain_list] (0x0040): Failed to get [domains] from [sssd], error [2] (No such file or directory) (2021-11-02 12:54:47:928885): [sss_cache] [init_domains] (0x0020): Could not initialize domains (2021-11-02 12:54:47:949846): [sss_cache] [confdb_get_enabled_domain_list] (0x0040): Failed to get [domains] from [sssd], error [2] (No such file or directory) (2021-11-02 12:54:47:949987): [sss_cache] [init_domains] (0x0020): Could not initialize domains I also receive this error when just running chsh without any parameters. The change is successful, even though the error might lead you to believe otherwise. After logging out and back in, zsh was my default shell. >From what I can tell from a quick search, the error has to do with SSSD and Active Directory support so I assume there is something happening around that but honestly don't know enough about it to know if that's correct. Please let me know if there's any additional information needed and thanks for all you do to create and support Ubuntu. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: passwd 1:4.8.1-1ubuntu9 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Tue Nov 2 13:09:46 2021 InstallationDate: Installed on 2020-12-24 (312 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200907) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: shadow UpgradeStatus: Upgraded to impish on 2021-10-17 (15 days ago) ** Affects: shadow (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug impish -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1949495 Title: Error shown when using chsh to change shells Status in shadow package in Ubuntu: New Bug description: I wanted to change my shell to zsh so I installed the zsh package and then used the chsh command as so: chsh -s $(which zsh) After running the command I am shown the errors: (2021-11-02 12:54:47:928739): [sss_cache] [confdb_get_enabled_domain_list] (0x0040): Failed to get [domains] from [sssd], error [2] (No such file or directory) (2021-11-02 12:54:47:928885): [sss_cache] [init_domains] (0x0020): Could not initialize domains (2021-11-02 12:54:47:949846): [sss_cache] [confdb_get_enabled_domain_list] (0x0040): Failed to get [domains] from [sssd], error [2] (No such file or directory) (2021-11-02 12:54:47:949987): [sss_cache] [init_domains] (0x0020): Could not initialize domains I also receive this error when just running chsh without any parameters. The change is successful, even though the error might lead you to believe otherwise. After logging out and back in, zsh was my default shell. From what I can tell from a quick search, the error has to do with SSSD and Active Directory support so I assume there is something happening around that but honestly don't know enough about it to know if that's correct. Please let me know if there's any additional information needed and thanks for all you do to create and support Ubuntu. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: passwd 1:4.8.1-1ubuntu9 ProcVersionSignature: Ubuntu 5.13.0-20.20-generic 5.13.14 Uname: Linux 5.13.0-20-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Tue Nov 2 13:09:46 2021 InstallationDate: Installed on 2020-12-24 (312 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200907) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: shadow UpgradeStatus: Upgraded to impish on 2021-10-17 (15 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1949495/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
** Description changed:
+ ** SRU TEMPLATE DRAFT **
+
+ [Impact]
+
+
+ [Test Plan]
+
+
+ [Where problems could occur]
+
+
+ [Other Info]
+
+
+ [Original Description]
+
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again later"
at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up
extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
+ I believe the current behaviour is buggy. This is confirmed when the
+ following line is executed:
- I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
+ if (loop_timeout >= 0 &&
+ now.tv_sec - start >= loop_timeout) {
+ printf("IP-Config: no response after %d "
+ "secs - giving up\n", loop_timeout);
+ rc = -1;
+ goto bail;
+ }
-
- if (loop_timeout >= 0 &&
- now.tv_sec - start >= loop_timeout) {
- printf("IP-Config: no response after %d "
-"secs - giving up\n", loop_timeout);
- rc = -1;
- goto bail;
- }
-
-
- 'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
+ 'loop_timeout' is the user-specified time-out. With a value of 2, in
+ case of error, this line prints:
IP-Config: no response after 2 secs - giving up
-
- So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
+ So it thinks that it waited 2 seconds - however, in reality it had
+ actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used
never exceeds the user-specified timeout.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is ex
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
@Khaled El Mously (kmously)
I don't see this piece of code in the klibc upstream project[0]
Is this something you only reproduce in Bionic/18.04LTS ?
Since your fix is not found anywhere else, I would be tempted to assume that it
could be affecting other releases of Ubuntu and possibly more.
Could you please erport a bug and submit your patch by making sure the
upstream klibc project adopts it ? It would help get some traction in
order to SRU this patch into Ubuntu.
If it needs to be a UBUNTU_SAUCE only, please provide rationale.
- Eric
[0] - https://git.kernel.org/pub/scm/libs/klibc/klibc.git/about/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(&now, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
[Verification Focal] This has been brought to my attention by an impacted user: " I was able to apply the fixed procps package from the focal-proposed repo on servers in a test cluster. The fix resolved the issue with free -V and the related DataStax OpsCenter error. Thanks " - Eric ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: Fix Committed Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
[autopkg regression] All tests are now fine. They needed a second retry. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: Fix Committed Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
I totally get your concern. In the same time, other procps pkkg in Ubuntu groovy, ... uses the same approach. But I leave you to decide what is best for this particular bug. Let us know. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
** Tags removed: sts-sponsors-slashd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
[sts-sponsors] Sponsored in Focal upload queue, now waiting for SRU verification team approval. Thanks for your contribution, Kellen. Test case validation (before upload): root@procpsf:/tmp# pgrep --version pgrep from procps-ng 3.3.16 root@procpsf:/tmp# ps --version ps from procps-ng 3.3.16 root@procpsf:/tmp# free --version free from procps-ng 3.3.16 - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
** Description changed: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. - * The addition of the autopkgtests could cause testing failures. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
[sts-sponsors] Debian uses autopkgtest for 'version' w/ restriction superficial as follows: Tests: version Restrictions: superficial https://people.debian.org/~eriberto/README.package-tests.html superficial The test does not provide significant test coverage, so if it passes, that does not necessarily mean that the package under test is actually functional. If a superficial test fails, it will be treated like any other failing test, but if it succeeds, this is only a weak indication of success. Continuous integration systems should treat a package where all non-superficial tests are skipped as equivalent to a package where all tests are skipped. Additionally, since that ".tarball-version" only focus on upstream version "3.3.16". The version won't change unless ones bump the version (which won't happen in stable release) unless under serious exception. So this value is unlikely to be removed or changes any time soon in Focal. Usually, adding autopkgtest inside an SRU is not a desired change. For the above reasons, I think it is safe to skip the autopkgtest and only focus on the version fix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. * The addition of the autopkgtests could cause testing failures. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
** Tags added: sts-sponsors-slashd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: Confirmed Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] [Test Plan] [Where problems could occur] [Other Info] [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
** Tags added: seg sts ** Also affects: procps (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: procps (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: procps (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: procps (Ubuntu Impish) Importance: Undecided Assignee: Kellen Renshaw (krenshaw) Status: Confirmed ** Changed in: procps (Ubuntu Bionic) Status: New => Fix Released ** Changed in: procps (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: procps (Ubuntu Impish) Status: Confirmed => Fix Released ** Changed in: procps (Ubuntu Focal) Assignee: (unassigned) => Kellen Renshaw (krenshaw) ** Changed in: procps (Ubuntu Impish) Assignee: Kellen Renshaw (krenshaw) => (unassigned) ** Changed in: procps (Ubuntu Focal) Importance: Undecided => Low ** Description changed: + [Impact] + + + [Test Plan] + + + [Where problems could occur] + + + [Other Info] + + + [Original Description] + From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. ** Changed in: procps (Ubuntu Focal) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: Confirmed Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] [Test Plan] [Where problems could occur] [Other Info] [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
I'll be reviewing the change with my colleague Kellen. In the meanwhile ... What is the concern/impact behind not having the version available in ps ? (Outside it should output/report it) ? The version can be found in the package version (dpkg -l procps) Is it for integrity purposes in order to make sure the ps binary in place really comes from that given procps package ? If it is the case, making --version works won't help much as an integrity check. There are other approaches that can be used to achieve this goal such as 'dpkg '-- verify' and '--audit' To summarize, I'm trying to find the rationale behind it to clearly document the bug when we'll reach the SRU approval/justification. Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Confirmed Bug description: From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
systemd reaches day 7 wo/ autopkgtest failure nor negative
outcome/feedbacks.
I have asked 'sil2100' to promote the package into bionic-updates.
Stay tuned ...
- Eric
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # option
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Thanks Maanus for all the testing. Much appreciated.
I'll take care of the rest in a couple of days with Lukasz.
Package needs to stay in proposed for a couple more days (minimum 7 days)
- Eric
** 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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Hi Maanus,
Would you mind perform the 'test cases' now against the systemd's
bionic-proposed package ? And report any outcome.
This is one of the last steps for Lukasz to approve the proposed package
after the baking minimum aging period (7 days) in verification phase.
- Eric
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Uploaded into bionic upload queue, now waiting for SRU approval.
- Eric
** Changed in: systemd (Ubuntu Bionic)
Status: Incomplete => In Progress
** Changed in: systemd (Ubuntu Bionic)
Assignee: (unassigned) => Eric Desrochers (slashd)
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 22
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Good catch Dan.
Maanus could you repeat the testing with what Dan brought up ?
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Thanks @Maanus.
So the outcome is positive here then.
- Eric
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
@maanus, That is a first iteration.
sudo add-apt-repository ppa:slashd/keepconfiguration
sudo apt-get update
Let me know the outcome.
- Eric
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Any volunteer to test a package in Bionic in the attempt to support
keepconfiguration ?
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
I think 'backports' would have been a great place to have this behavior change in Bionic while keep the current one in -updates. I just came across an email about 'backports' about to die (from rbasak). Let's see what is the outcome and rely on the flock() alternative for now. I'll monitor the "-backports" discussion and let's see from there. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
I'm on the same page. Maybe we should leave the package in -update as is and go with the flock() alternative. OR evaluate if, let's say, the Focal's iptables could be backported (if feasible) in bionic-backports. That way, one who wants the 'wait' and 'wait-interval' to be available could rely on -backport, while the rest of our Bionic users could remain on the same old iptables behavior provided in -updates. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
New testpackage: iptables - 1.6.1-2ubuntu2+testpkg20210706b8 Note: If that works as expected for Andreas. The only things that needed would be to update the manpage, which I didn't do on this current test pkg. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Both 'iptables' and 'ip*tables-restores' sleep and wait until the lock is released if no 'wait' option. If 'wait' option is set, it wait for the amount of time instructed and stop waiting. I think the printed message make more sense now : # time cat /etc/rules.v4 | iptables-restore -c Another app is currently holding the xtables lock; still -9s 0us time ahead to have a chance to grab the lock... # time cat /etc/rules.v4 | iptables-restore -c -w 2 Another app is currently holding the xtables lock. Stopped waiting after 2s. # time cat /etc/rules.v4 | ip6tables-restore -c Another app is currently holding the xtables lock; still -9s 0us time ahead to have a chance to grab the lock... # time cat /etc/rules.v4 | ip6tables-restore -c -w 2 Another app is currently holding the xtables lock. Stopped waiting after 2s. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
I'll work to re-arrange the fprintf if 'wait' option is used or not and see the outcome of it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
I have a new test pkg: This pkg keeps the same behavior for 'iptables' # Hold the lock: flock /run/xtables.lock sleep 36000 # It holds and wait until flock() finishes or get killed, and then get executed. iptables -L # With 'wait' option, it waits until the wait time is ended: time iptables -L -w 3 Another app is currently holding the xtables lock. Stopped waiting after 3s. real0m3.006s user0m0.002s sys 0m0.001s --- # Hold the lock: flock /run/xtables.lock sleep 36000 # cat /etc/rules.v4 | iptables-restore -c -w 5 Another app is currently holding the xtables lock. Perhaps you want to use the -w option? real0m5.009s user0m0.006s sys 0m0.001s The 'wait' option instruction is respected. The message may be confusing as it is suggesting to use '-w' even if it was used. This is the progress I have made so far. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Version in comment #12 is "iptables - 1.6.1-2ubuntu2+testpkg20210706b4" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
What about "iptables - 1.6.1-2ubuntu2+testpkg20210629b3" ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Thanks Andreas. I'll be working on a minimalistic patch set (if feasible) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Thanks Andreas. I'll be working on a minimalistic patch set -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Look like a potential patchset to backport without having to bump
version in stable release:
6e2e169eb iptables: remove duplicated argument parsing code
24f81746 xshared: do not lock again and again if "-w" option is not specified
72bb3dbf0 xshared: using the blocking file lock request when we wait
indefinitely
999eaa24 iptables-restore: support acquiring the lock.
65801d02 iptables-restore.8: document -w/-W options
21ba5b38 ip{,6}tables-restore: Don't accept wait-interval without wait
I'll test it, and then will talk w/ the SRU verification team to see if
eligible for SRU.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1791958
Title:
iptables-restore is missing -w option
Status in iptables package in Ubuntu:
Confirmed
Bug description:
For CRIU we need to have iptables version 1.6.2 which includes the
'-w' option in iptables-restore.
This is a request to update iptables to 1.6.2 in 18.10 and if possible
backport the necessary changes to 18.04.
The CRIU project gets right now many bug reports (mostly in the
combination LXD + CRIU) due to the missing '-w' option in iptables-
restore. Especially as 18.04 will be around for some time it would be
good to have iptables-restore available with '-w'.
This is one example bug report: https://github.com/checkpoint-
restore/criu/issues/551
But not only CRIU would benefit from this change. It seems also
problematic with Kubernetes:
https://github.com/kubernetes/kubernetes/pull/60978
So if possible, please update iptables to 1.6.2 (or backport changes)
to support -w in iptables-restore.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Look like a potential patchset to backport without having to bump
version in stable release:
I'll test it, and then will alk w/ the SRU verification team to see if
eligible for SRU.
commit 6e2e169eb66b63d2991e1c7ada931e3cdb0ced32
Author: Lorenzo Colitti
Date: Thu Mar 16 16:55:01 2017 +0900
iptables: remove duplicated argument parsing code
1. Factor out repeated code to a new xs_has_arg function.
2. Add a new parse_wait_time option to parse the value of -w.
3. Make parse_wait_interval take argc and argv so its callers
can be simpler.
+
21ba5b38 ip{,6}tables-restore: Don't accept wait-interval without wait
d89dc47a iptables-restore/save: exit when given an unknown option
65801d02 iptables-restore.8: document -w/-W options
999eaa24 iptables-restore: support acquiring the lock.
** Tags added: seg sts
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1791958
Title:
iptables-restore is missing -w option
Status in iptables package in Ubuntu:
Confirmed
Bug description:
For CRIU we need to have iptables version 1.6.2 which includes the
'-w' option in iptables-restore.
This is a request to update iptables to 1.6.2 in 18.10 and if possible
backport the necessary changes to 18.04.
The CRIU project gets right now many bug reports (mostly in the
combination LXD + CRIU) due to the missing '-w' option in iptables-
restore. Especially as 18.04 will be around for some time it would be
good to have iptables-restore available with '-w'.
This is one example bug report: https://github.com/checkpoint-
restore/criu/issues/551
But not only CRIU would benefit from this change. It seems also
problematic with Kubernetes:
https://github.com/kubernetes/kubernetes/pull/60978
So if possible, please update iptables to 1.6.2 (or backport changes)
to support -w in iptables-restore.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Look like a potential patchset to backport without having to bump
version in stable release:
21ba5b38 ip{,6}tables-restore: Don't accept wait-interval without wait
d89dc47a iptables-restore/save: exit when given an unknown option
65801d02 iptables-restore.8: document -w/-W options
999eaa24 iptables-restore: support acquiring the lock.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1791958
Title:
iptables-restore is missing -w option
Status in iptables package in Ubuntu:
Confirmed
Bug description:
For CRIU we need to have iptables version 1.6.2 which includes the
'-w' option in iptables-restore.
This is a request to update iptables to 1.6.2 in 18.10 and if possible
backport the necessary changes to 18.04.
The CRIU project gets right now many bug reports (mostly in the
combination LXD + CRIU) due to the missing '-w' option in iptables-
restore. Especially as 18.04 will be around for some time it would be
good to have iptables-restore available with '-w'.
This is one example bug report: https://github.com/checkpoint-
restore/criu/issues/551
But not only CRIU would benefit from this change. It seems also
problematic with Kubernetes:
https://github.com/kubernetes/kubernetes/pull/60978
So if possible, please update iptables to 1.6.2 (or backport changes)
to support -w in iptables-restore.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
** Description changed: [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) .sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) [Test plan] ** NOT REPRODUCIBLE ON MY SIDE ** This seems to be a corner case generated by the Defensics fuzzer test suite (proprietary software from synopsys). That's the only way this could have been reproduced so far. + Here's the details I could gather about the fuzzer test scenario: + + -- + Test Suite: SSHv2 Server Test Suite by Synopsys + Test Case Description: + SSHv2.Key-Exchange.DH-GROUP-EXCHANGE-SHA256.message-sequence.duplicate-message: + Insert extra message 'message-2' before message 'client-newkeys' + -- + [Where problem could occur] [Other information] Upstream fix: https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 Only Xenial requires the fix: # git describe --contains 2adbe1e V_7_5_P1~7 # rmadison openssh => openssh | 1:7.2p2-4ubuntu2.10 | xenial-updates | source openssh | 1:7.6p1-4 | bionic | source openssh | 1:7.6p1-4ubuntu0.3 | bionic-security | source openssh | 1:7.6p1-4ubuntu0.3 | bionic-updates | source openssh | 1:7.6p1-4ubuntu0.4 | bionic-proposed | source openssh | 1:8.2p1-4 | focal| source openssh | 1:8.2p1-4ubuntu0.2 | focal-security | source openssh | 1:8.2p1-4ubuntu0.2 | focal-updates| source openssh | 1:8.3p1-1 | groovy | source openssh | 1:8.3p1-1ubuntu0.1 | groovy-security | source openssh | 1:8.3p1-1ubuntu0.1 | groovy-updates | source openssh | 1:8.4p1-5ubuntu1| hirsute | source openssh | 1:8.4p1-5ubuntu1| impish | source -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics' synopsys fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Xenial: In Progress Bug description: [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) .sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
debdiff to go over the ESM process by security team. Thanks - Eric ** Patch added: "xenial_lp1930286.debdiff" https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+attachment/5502934/+files/xenial_lp1930286.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics' synopsys fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Xenial: In Progress Bug description: [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) .sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) [Test plan] ** NOT REPRODUCIBLE ON MY SIDE ** This seems to be a corner case generated by the Defensics fuzzer test suite (proprietary software from synopsys). That's the only way this could have been reproduced so far. [Where problem could occur] [Other information] Upstream fix: https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 Only Xenial requires the fix: # git describe --contains 2adbe1e V_7_5_P1~7 # rmadison openssh => openssh | 1:7.2p2-4ubuntu2.10 | xenial-updates | source openssh | 1:7.6p1-4 | bionic | source openssh | 1:7.6p1-4ubuntu0.3 | bionic-security | source openssh | 1:7.6p1-4ubuntu0.3 | bionic-updates | source openssh | 1:7.6p1-4ubuntu0.4 | bionic-proposed | source openssh | 1:8.2p1-4 | focal| source openssh | 1:8.2p1-4ubuntu0.2 | focal-security | source openssh | 1:8.2p1-4ubuntu0.2 | focal-updates| source openssh | 1:8.3p1-1 | groovy | source openssh | 1:8.3p1-1ubuntu0.1 | groovy-security | source openssh | 1:8.3p1-1ubuntu0.1 | groovy-updates | source openssh | 1:8.4p1-5ubuntu1| hirsute | source openssh | 1:8.4p1-5ubuntu1| impish | source To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
** Changed in: openssh (Ubuntu Xenial) Status: New => In Progress ** Description changed: + [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) + + [Test plan] + + ** NOT REPRODUCIBLE ON MY SIDE ** + + This seems to be a corner case generated by the Defensics fuzzer test + suite (proprietary software from synopsys). + + That's the only way this could have been reproduced so far. + + [Where problem could occur] + + [Other information] + + Upstream fix: + https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 + + Only Xenial requires the fix: + + # git describe --contains 2adbe1e + V_7_5_P1~7 + + # rmadison openssh + => openssh | 1:7.2p2-4ubuntu2.10 | xenial-updates | source + openssh | 1:7.6p1-4 | bionic | source + openssh | 1:7.6p1-4ubuntu0.3 | bionic-security | source + openssh | 1:7.6p1-4ubuntu0.3 | bionic-updates | source + openssh | 1:7.6p1-4ubuntu0.4 | bionic-proposed | source + openssh | 1:8.2p1-4 | focal| source + openssh | 1:8.2p1-4ubuntu0.2 | focal-security | source + openssh | 1:8.2p1-4ubuntu0.2 | focal-updates| source + openssh | 1:8.3p1-1 | groovy | source + openssh | 1:8.3p1-1ubuntu0.1 | groovy-security | source + openssh | 1:8.3p1-1ubuntu0.1 | groovy-updates | source + openssh | 1:8.4p1-5ubuntu1| hirsute | source + openssh | 1:8.4p1-5ubuntu1| impish | source ** Changed in: openssh (Ubuntu) Status: New => Fix Released ** Changed in: openssh (Ubuntu Xenial) Importance: Undecided => Medium ** Description changed: - [Impact] + [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) - As of today, I have no access to a reproducer. Still working on getting - access to one (if possible) in order to better understand what the - failing test scenario is doing. + As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
UA customer test pkg outcome: " We ran the Defensics test suite before and after installing the test packages. We could observe two core dumps before the test package installation. But after test package installation, core dumps were not generated. Can you provide this package as the fix? " This concludes that xenial + commit 2adbe1e63bc313d03e8e84e652cc623af8ebb163 fixes their fuzzer segfault situation. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics' synopsys fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: New Status in openssh source package in Xenial: New Bug description: Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
Hello Seth, So far no production impact has been reported, for now it is only reproducible using that particular fuzzer on xenial's openssh version. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics' synopsys fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: New Status in openssh source package in Xenial: New Bug description: Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] Re: Defensics fuzzer testing tool cause openssh to segfault
I have produced a test pkg including the potential fix candidate above for the impacted UA customer to test in their lab. Unfortunately, I have no access to a reproducer since this fuzzer is proprietary and need to be purchased. Meaning, the testing will rely on UA customer end. - Eric ** Description changed: - I'm reporting this bug to keep track of it, as of today I'm still - collecting informations. + Here's what has been brought to my attention by a UA customer: - Here's what I have gathered so far: + * Release: + Xenial/16.04LTS - Release: Xenial/16.04LTS - Openssh version :7.2p2-4ubuntu2.10 - Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) + * Openssh version: + 7.2p2-4ubuntu2.10 + + * Fuzzer tool used: + https://www.synopsys.com/software-integrity/security-testing/fuzz testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting - access to one and better understand what the failing test scenario is - doing. + access to one (if possible) in order to better understand what the + failing test scenario is doing. - gdb backtrace: + * coredump: + $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) ** Summary changed: - Defensics fuzzer testing tool cause openssh to segfault + Defensics' synopsys fuzzer testing tool cause openssh to segfault ** Description changed: Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 - * Fuzzer tool used: - https://www.synopsys.com/software-integrity/security-testing/fuzz testing.html (proprietary software) + * Fuzzer tool used: + https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html(proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x
[Touch-packages] [Bug 1930286] Re: Defensics fuzzer testing tool cause openssh to segfault
Potential fix candidate: https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 ** Tags added: seg sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: New Status in openssh source package in Xenial: New Bug description: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one and better understand what the failing test scenario is doing. gdb backtrace: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] [NEW] Defensics fuzzer testing tool cause openssh to segfault
Public bug reported: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one and better understand what the failing test scenario is doing. gdb backtrace: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Xenial) Importance: Undecided Status: New ** Description changed: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 - Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html + Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) + + As of today, I have no access to a reproducer. gdb backtrace: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) ** Description changed: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) - As of today, I have no access to a reproducer. + As of today, I have no access to a reproducer. Still working on getting + access to one and better understand what the failing test
[Touch-packages] [Bug 1856871] Re: i/o error if next unused loop device is queried
** Changed in: linux (Ubuntu) Assignee: Eric Desrochers (slashd) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1856871 Title: i/o error if next unused loop device is queried Status in linux package in Ubuntu: In Progress Status in parted package in Ubuntu: Invalid Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1754140] Re: Gnome gets stuck in overview mode
I also hit this within an hour of installing hippo (21.04) on a new machine, having made zero configuration changes anywhere. My guess is that it happened when I accidentally mashed a few keys at once (which may have included the windows key)...? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1754140 Title: Gnome gets stuck in overview mode Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: I'm running Ubuntu 17.10, and I have repeatedly had a problem with the desktop environment getting stuck in overview mode. When stuck, I can close and select windows, and access the menus at on the top bar, but I cannot exit overview mode. The only solution I've found is to log out and log back in. I'm not exactly sure what combination of circumstances causes it to happen, but it seems to happen more often if invoked via the corner hover point. It also happens in both Wayland and Xorg. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ubuntu-desktop 1.404.1 Uname: Linux 4.14.15-041415-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 CurrentDesktop: GNOME Date: Wed Mar 7 11:02:02 2018 InstallationDate: Installed on 2017-05-04 (307 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: ubuntu-meta UpgradeStatus: Upgraded to artful on 2017-10-29 (129 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1754140/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 439604] Re: boot process isn't paused while fsck runs on partition: boot process is completed with fsck running in the background preventing partition from mounting
Above, Steve Langasek (vorlon) wrote on 2009-10-10:
"Effectively, this is by design; filesystems that aren't required
to bring up the desktop should not block the desktop, they should be
handled in parallel."
My boot disk partition is DB001_F1, which contains the system files and
${HOME} directory.
However, my installation is configured such that the all the other
directories under the ${HOME} directory are on a second partition,
namely
Desktop -> /DB001_F2/home/ericthered.Desktop
Not every time, but often enough, when I do a pushbutton boot (cold) or
a warm boot (restart), it appears that the system mounts the ${HOME}
directory as if it were my Desktop, and I have to rebuild my Desktop
from scratch (please don't ask me the steps, because I always have to
muddle thru to get it back to how I want it.
Is there some setting, configuration or switch that I can set to force
the boot process to wait until it can access all disks properly, BEFORE
it attempts to build the GDM environment ?
System:Host: OasisMega1 Kernel: 5.4.0-67-generic x86_64 bits: 64 Desktop:
MATE 1.24.0
Distro: Ubuntu 20.04.2 LTS (Focal Fossa)
Machine: Type: Desktop Mobo: ASUSTeK model: M4A78-E v: Rev 1.xx serial:
10104858313
BIOS: American Megatrends v: 2603 date: 04/13/2011
CPU: Quad Core: AMD Phenom II X4 810 type: MCP speed: 800 MHz
min/max: 800/2600 MHz
Graphics: Device-1: AMD RS780D [Radeon HD 3300] driver: radeon v: kernel
Display: server: X.Org 1.20.9 driver: ati,radeon unloaded:
fbdev,modesetting,vesa
resolution: 1440x900~60Hz
OpenGL: renderer: AMD RS780 (DRM 2.50.0 / 5.4.0-67-generic LLVM
11.0.0) v: 3.3 Mesa 20.2.6
Info: Processes: 248 Uptime: 24m Memory: 2.92 GiB used: 1.24 GiB
(42.5%) Shell: bash inxi: 3.0.38
Filesystem Size Used Avail Use% Mounted on
/dev/sdb3 192G 16G 167G 9% /
/dev/sdb7 289G 153G 122G 56% /DB001_F2
/dev/sdb8 289G 246G 29G 90% /DB001_F3
/dev/sdb9 289G 258G 17G 95% /DB001_F4
/dev/sdb12 193G 29G 154G 16% /DB001_F5
/dev/sdb13 193G 149G 35G 82% /DB001_F6
/dev/sdb14 289G 166G 109G 61% /DB001_F7
/dev/sdb492G 35G 53G 40% /DB001_F8
/dev/sdc299G 60M 94G 1% /site/DB003_F1
/dev/sdc3 357G 67M 338G 1% /site/DB003_F2
/dev/sda2 108G 7.0G 96G 7% /site/DB004_F1
Thank you.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/439604
Title:
boot process isn't paused while fsck runs on partition: boot process
is completed with fsck running in the background preventing partition
from mounting
Status in Release Notes for Ubuntu:
Fix Released
Status in mountall package in Ubuntu:
Fix Released
Status in util-linux package in Ubuntu:
Won't Fix
Bug description:
Binary package hint: usplash
I had a problem mounting my /dev/sdb1 partition the last couple of
times after booting up Ubuntu. I got the following error when trying
to mount the partition:
mount: /dev/sdb1 already mounted or /media/data busy
so I tried issuing the following command and I could see that fsck was
running in the background, without having notified me, checking
/dev/sdb1, and not while showing the splash screen and a progress bar
like it usually does:
rune@runescomp:~$ sudo fuser -m /dev/sdb1
/dev/sdb1: 804
rune@runescomp:~$ ps aux | grep 804
root 804 5.0 3.4 72528 71164 ?D21:29 0:50 fsck.ext3 -a
/dev/sdb1
rune@runescomp:~/Desktop$ lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10
rune@runescomp:~/Desktop$ apt-cache policy usplash
usplash:
Installed: 0.5.39
Candidate: 0.5.39
Version table:
*** 0.5.39 0
500 http://archive.ubuntu.com karmic/main Packages
100 /var/lib/dpkg/status
ProblemType: Bug
Architecture: i386
Date: Wed Sep 30 21:54:05 2009
DistroRelease: Ubuntu 9.10
MachineType: . .
NonfreeKernelModules: kvm_intel kvm fglrx
Package: usplash 0.5.39
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-11-generic
root=UUID=55bcb986-d698-4aea-a3bb-c581262ea713 ro quiet splash elevator=deadline
ProcEnviron:
LANG=en_DK.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SourcePackage: usplash
Uname: Linux 2.6.31-11-generic i686
UsplashConf:
# Usplash configuration file
# These parameters will only apply after running update-initramfs.
xres=1920
yres=1440
dmi.bios.date: 05/26/2008
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: IP35 Pro XE(Intel P35-ICH9R)
dmi.board.vendor: http://www.abit.com.tw/
dmi.board.version: 1.0
dmi.chassis.type: 3
dmi.chassis.vend
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. - [TEST CASE] + [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. - [REGRESSION POTENTIAL] + [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. - [SCOPE] + [OTHER] - This is already in H, need backporting to B,G,F. - - Ubuntu-hirsute commits : - - https://git.launchpad.net/~ubuntu-core- - dev/ubuntu/+source/systemd/commit/?h=ubuntu- - hirsute&id=ce31df6711a8e112cff929ed3bbdcd194f876270 - - https://git.launchpad.net/~ubuntu-core- - dev/ubuntu/+source/systemd/commit/?h=ubuntu- - hirsute&id=ec1130fece7ca66273773119775e51045a74122c - - Debian commits : - - https://salsa.debian.org/systemd- - team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 - - https://salsa.debian.org/systemd- - team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c - - [OTHER] + This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch chang
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Changed in: systemd (Ubuntu Groovy) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [SCOPE] This is already in H, need backporting to B,G,F. Ubuntu-hirsute commits : https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute&id=ce31df6711a8e112cff929ed3bbdcd194f876270 https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute&id=ec1130fece7ca66273773119775e51045a74122c Debian commits : https://salsa.debian.org/systemd- team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 https://salsa.debian.org/systemd- team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c [OTHER] Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Tags added: sts-sponsors-ddstreet ** Changed in: systemd (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Groovy) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Bionic) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1856871] Re: i/o error if next unused loop device is queried
The upstream proposal fix that mfo and I worked on has been applied: https://patchwork.kernel.org/project/linux- block/patch/20210222154123.61797-1-...@canonical.com/ - Eric -- 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/1856871 Title: i/o error if next unused loop device is queried Status in linux package in Ubuntu: Incomplete Status in parted package in Ubuntu: New Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
d/rules: 91 CONFFLAGS_deb = \ 92 -Dselinux=true \ 93 -Dhwdb=true \ => 94 -Dsysusers=true \ Would it make sense to turn this off ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Groovy: New Status in systemd source package in Hirsute: New Status in systemd package in Debian: Unknown Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Groovy: New Status in systemd source package in Hirsute: New Status in systemd package in Debian: Unknown Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
** Bug watch added: Debian Bug tracker #982976 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982976 ** Also affects: systemd (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982976 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/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Status in systemd package in Debian: Unknown Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
Right, but it doesn't seem right to have it set by default 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/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
** Summary changed: - systemd-coredump user is create by something other than its derived systemd packages + systemd-coredump user is created by something other than its derived systemd packages -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is create by something other than its derived systemd packages
Home Directory¶ The home directory for a new system user. If omitted, defaults to the root directory. Only applies to lines of type u and should otherwise be left unset (or "-"). It is recommended to omit this, unless software strictly requires a home directory to be set. systemd-sysusers only sets the home directory record in the user database. To actually create the directory, consider adding a corresponding tmpfiles.d(5) fragment. ** Tags added: seg sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is create by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is create by something other than its derived systemd packages
https://www.freedesktop.org/software/systemd/man/sysusers.d.html# u Create a system user and group of the specified name should they not exist yet. The user's primary group will be set to the group bearing the same name unless the ID field specifies it. The account will be created disabled, so that logins are not allowed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is create by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is create by something other than its derived systemd packages
sudo /bin/systemd-sysusers --cat-config # /usr/lib/sysusers.d/systemd.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. g systemd-journal - - u systemd-network - "systemd Network Management" u systemd-resolve - "systemd Resolver" u systemd-timesync - "systemd Time Synchronization" u systemd-coredump - "systemd Core Dumper" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is create by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] [NEW] systemd-coredump user is create by something other than its derived systemd packages
Public bug reported: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Description changed: systemd-coredump binary package is instructed as follows: - #debian/systemd-coredump.postinst: + #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers - - # /var/log/installer/installer-journal.txt - Feb 17 15:27:19 ubuntu-server systemd-sysusers[844]: Creating group systemd-coredump with gid 998. - Feb 17 15:27:19 ubuntu-server systemd-sysusers[844]: Creating user systemd-coredump (systemd Core Dumper) with uid 998 and gid 998. + # /var/log/syslog + syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. + syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/sy
[Touch-packages] [Bug 1914467] [NEW] Problem with fractional scaling
Public bug reported: Hello, I would like to report a problem with fractional scaling. I have set it at 125%. I'm using a Huawei Matebook 13inch 2020 AMD (Ryzen 5 3500u) with Radeon Vega 8 Graphics. After starting the laptop, at the logon screen, the scaling seems to be at 200% but after I logon and go into my user session it turns to a scaling of 125%. At that moment I see 2 mouse pointers, one scaled 200% and one scaled at 125%. The mouse pointer which is scaled at 200% remains in its last position before the login process. It stays on top of any app or window that you open which is a bit annoying. The second mouse pointer (scaled at 125%) behaves normally. I tried to take a screenshot, but on a screenshot neither mouse pointer appear so I took a picture which I've added to this bug report. This bug is not specific to this version of Ubuntu, I can reproduce the problem in version 20.10. I haven't tried this in version 20.04. PopOS 20.10 does not exhibit this problem. It's a pity that Gnome has not yet made a better implementation of fractional scaling, high density display have been around for a while now. One would expect if one sets the scaling at 125%, that this would be applied system wide (sorry for the rant). Best regards, Eric P.S. : Sorry if this bug has been reported in a wrong category. ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: xorg 1:7.7+19ubuntu15 ProcVersionSignature: Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 ApportVersion: 2.20.11-0ubuntu55 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Feb 3 20:49:00 2021 DistUpgraded: Fresh install DistroCodename: hirsute DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev c2) (prog-if 00 [VGA controller]) Subsystem: Huawei Technologies Co., Ltd. Picasso [19e5:3e14] InstallationDate: Installed on 2021-02-03 (0 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Alpha amd64 (20210123) MachineType: HUAWEI HN-WX9X ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-36-generic root=UUID=b98eae12-e501-4bfe-88e5-b713ae9b9843 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/04/2020 dmi.bios.release: 1.13 dmi.bios.vendor: HUAWEI dmi.bios.version: 1.13 dmi.board.asset.tag: N/A dmi.board.name: HN-WX9X-PCB dmi.board.vendor: HUAWEI dmi.board.version: M1130 dmi.chassis.asset.tag: N/A dmi.chassis.type: 10 dmi.chassis.vendor: HUAWEI dmi.chassis.version: M1130 dmi.ec.firmware.release: 1.13 dmi.modalias: dmi:bvnHUAWEI:bvr1.13:bd09/04/2020:br1.13:efr1.13:svnHUAWEI:pnHN-WX9X:pvrM1130:rvnHUAWEI:rnHN-WX9X-PCB:rvrM1130:cvnHUAWEI:ct10:cvrM1130: dmi.product.family: MateBook dmi.product.name: HN-WX9X dmi.product.sku: C100 dmi.product.version: M1130 dmi.sys.vendor: HUAWEI version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.103-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.3.2-1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug hirsute reproducible third-party-packages ubuntu ** Attachment added: "picture of the screen as the problem occurs" https://bugs.launchpad.net/bugs/1914467/+attachment/5459480/+files/IMG_0508.jpeg -- 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/1914467 Title: Problem with fractional scaling Status in xorg package in Ubuntu: New Bug description: Hello, I would like to report a problem with fractional scaling. I have set it at 125%. I'm using a Huawei Matebook 13inch 2020 AMD (Ryzen 5 3500u) with Radeon Vega 8 Graphics. After starting the laptop, at the logon screen, the scaling seems to be at 200% but after I logon and go into my user session it turns to a scaling of 125%. At that moment I see 2 mouse pointers, one scaled 200% and one scaled at 125%. The mouse pointer which is scaled at 200% remains in its last position before the login process. It stays on top of any app or window that you open which is a bit annoying. The second mouse pointer (scaled at 125%) behaves normally. I tried to take a screenshot, but on a screenshot neither mouse pointer appear so I took a picture which I
[Touch-packages] [Bug 1304074] Re: [X550CC, Realtek ALC270, Black Headphone Out, Left] No sound at all
Hey guys. After 1 year with problems to make works headphone together with mic, I got a solution for my ASUS S46CA, I think this can works for you too. First, I try a lot of options snd-hda-intel, but only works this: options snd-hda-intel model=alc255-asus for my ALC270. But it is not enough. I needed use hdajackretask And force pin ID 0x1a to be "Headphone" pin ID 0x18 to be "Microphone" if alc255-asus don't works for you, you can try another options, like: alc269-dmic, alc271-dmic, headset-mic, alc283-headset. Don't forget to restart the machine after hdajackretask. -- 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/1304074 Title: [X550CC, Realtek ALC270, Black Headphone Out, Left] No sound at all Status in alsa-driver package in Ubuntu: Expired Bug description: I have sound from the laptop, but no sound when i use the jack. It works when running windows. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: alsa-base 1.0.25+dfsg-0ubuntu4 ProcVersionSignature: Ubuntu 3.11.0-19.33-generic 3.11.10.5 Uname: Linux 3.11.0-19-generic x86_64 ApportVersion: 2.12.5-0ubuntu2.2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: daniel 1734 F pulseaudio /dev/snd/pcmC0D0p: daniel 1734 F...m pulseaudio Date: Mon Apr 7 23:17:24 2014 InstallationDate: Installed on 2014-02-26 (40 days ago) InstallationMedia: Ubuntu-GNOME 13.10 "Saucy Salamander" - Release amd64 (20131017) MarkForUpload: True PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: daniel 1734 F pulseaudio /dev/snd/pcmC0D0p: daniel 1734 F...m pulseaudio Symptom_Jack: Black Headphone Out, Left Symptom_Type: No sound at all Title: [X550CC, Realtek ALC270, Black Headphone Out, Left] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/16/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550CC.217 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550CC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX550CC.217:bd10/16/2013:svnASUSTeKCOMPUTERINC.:pnX550CC:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX550CC:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.name: X550CC dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1304074/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1304074] Re: [X550CC, Realtek ALC270, Black Headphone Out, Left] No sound at all
Hey guys. After 1 year with problems to make works headphone together with mic, I got a solution for my ASUS S46CA, I think this can works for you too. First, I try a lot of options snd-hda-intel, but only works this: options snd-hda-intel model=alc255-asus for my ALC270. But it is not enough. I needed use hdajackretask And force pin ID 0x1a to be "Headphone" -- 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/1304074 Title: [X550CC, Realtek ALC270, Black Headphone Out, Left] No sound at all Status in alsa-driver package in Ubuntu: Expired Bug description: I have sound from the laptop, but no sound when i use the jack. It works when running windows. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: alsa-base 1.0.25+dfsg-0ubuntu4 ProcVersionSignature: Ubuntu 3.11.0-19.33-generic 3.11.10.5 Uname: Linux 3.11.0-19-generic x86_64 ApportVersion: 2.12.5-0ubuntu2.2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: daniel 1734 F pulseaudio /dev/snd/pcmC0D0p: daniel 1734 F...m pulseaudio Date: Mon Apr 7 23:17:24 2014 InstallationDate: Installed on 2014-02-26 (40 days ago) InstallationMedia: Ubuntu-GNOME 13.10 "Saucy Salamander" - Release amd64 (20131017) MarkForUpload: True PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: daniel 1734 F pulseaudio /dev/snd/pcmC0D0p: daniel 1734 F...m pulseaudio Symptom_Jack: Black Headphone Out, Left Symptom_Type: No sound at all Title: [X550CC, Realtek ALC270, Black Headphone Out, Left] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/16/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550CC.217 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550CC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX550CC.217:bd10/16/2013:svnASUSTeKCOMPUTERINC.:pnX550CC:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX550CC:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.name: X550CC dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1304074/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1871268] Re: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected
Cannot contribute much because the desktop is completely blank (except for the background) and a black bar at the top. There is no "Activities" control. Even worse, the mouse pointer is the spinning Ubuntu disk. I can click on the date, which is right. I will reboot and see what happens. Please wish me luck. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1871268 Title: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected Status in Ubuntu CD Images: Fix Released Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Confirmed Status in apt source package in Focal: Triaged Status in apt source package in Groovy: Triaged Status in apt package in Debian: Unknown Bug description: [Impact] Installations that really succeeded would then fail because APT could not immediately configure a package. Which is a pointless way to fail at that point, because everything did work out anyway. So what we do is change that to a warning. [Test case] Not available right now. Issues can flare up and then disappear again. [Regression potential] It's imaginable that we missed something somewhere and some path that checked for a set error doesn't check it anymore, and we report success when we hit an error, but it seems unlikely. Behavior of --simulate changes. This used to fail before as well, and will now only produce a warning. We don't believe that is a reason of concern. [Groovy SRU] The groovy SRU is a sync of the 2.1.11 micro release from Debian unstable which also incorporates changes to the documentation: A typo fix, replacing focal with groovy in examples, and minor Dutch manual pages translation updates. We do not have test cases for the documentation changes, and we do not consider there to be a huge regression potential. As long as they build, they should be readable - maybe some words are wrong in the translation, who knows. [Original bug report] Test Case 1. Install Ubuntu Desktop on hardware with an nVidia card and select to install 3rd party drivers 2. Proceed with installation The following error message is displayed in /var/log/syslog /plugininstall.py: Verifying downloads ... /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/gcc_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxcrypt/libcrypt-dev_4.4.10-10ubuntu4_amd64.deb: "Version: '4.4.10-10ubuntu4' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/g++_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/z/zlib/zlib1g_1.2.11.dfsg-2ubuntu1_i386.deb: "Version: '1.2.11.dfsg-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxau/libxau6_1.0.9-0ubuntu1_i386.deb: "Version: '1.0.9-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdmcp/libxdmcp6_1.1.3-0ubuntu1_i386.deb: "Version: '1.1.3-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-6_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxext/libxext6_1.3.4-0ubuntu1_i386.deb: "Version: '1.3.4-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/l/lm-sensors/libsensors5_3.6.0-2ubuntu1_i386.deb: "Version: '3.6.0-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-xcb1_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdamage/libxdamage1_1.1.5-1_i386.deb: "Version: '1.1.5-1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxfixes/libxfixes3_5.0.3-1_i386.deb: "Version: '5.0.3-1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxxf86vm/libxxf86vm1_1.1.4-1build1_i386.deb: "Version: '1.1.4-1build1' not found." /plugininstall.py: Downloads verified successfully ubiquity: Error in function: install /plugininstall.py: Exception during installation: /plugininstall.py: apt_pkg.Error: E:Could not configure 'libc6:i386'. , E:Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) /plugininstall.py: ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: ubiquity 20.04.9 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
This is fixed in active development release (hirsute): python-apt (2.1.7) unstable; urgency=medium * SECURITY UPDATE: various memory and file descriptor leaks (LP: #1899193) - python/arfile.cc, python/generic.h, python/tag.cc, python/tarfile.cc: fix file descriptor and memory leaks - python/apt_instmodule.cc, python/apt_instmodule.h, python/arfile.h: Avoid reference cycle with control,data members in apt_inst.DebFile objects - tests/test_cve_2020_27351.py: Test cases for DebFile (others not easily testable) * Regression fixes for the updates merged too: - arfile.cc: Fix segmentation fault when opening fd, track lifetime correctly (Closes: #977000) - arfile: Regression: Collect file<->deb/ar reference cycles -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: Fix Released Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. # dak scenario: dak crashes with a segmentation fault in python3-apt when processing uploads or processing the NEW queue on ftp-master; and also on my playground server (used to generate the backtrace). [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
@julian, thanks for the quick reply. Will do. ** Changed in: python-apt (Ubuntu) Status: New => Fix Released ** Description changed: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. - [Where problem could occurs] + # dak scenario: + dak crashes with a segmentation fault in python3-apt when processing + uploads or processing the NEW queue on ftp-master; and also on my + playground server (used to generate the backtrace). + + [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: Fix Released Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. # dak scenario: dak crashes with a segmentation fault in python3-apt when processing uploads or processing the NEW queue on ftp-master; and also on my playground server (used to generate the backtrace). [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
This package is 'native' and I don't want for instance to introduce 'quilt' before talking to the maintainer. @julian, how do you want to proceed to fix this bug in python-apt ? - Eric ** Description changed: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] - # Landscape scenario: + # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. [Where problem could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: Fix Released Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. # dak scenario: dak crashes with a segmentation fault in python3-apt when processing uploads or processing the NEW queue on ftp-master; and also on my playground server (used to generate the backtrace). [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
** Description changed: + [Impact] + USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. + [Test case] + + # Landscape scenario: + 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. + 2) On the Landscape server, apply the package profile to a client + 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' + 4) On the Landscape server, verify that the activity to apply the package profile ends with success. + + Step 3) would show a segfault and step 4), the activity would stay 'In + Progress' forever. + + [Where problem could occurs] + + [Other info] + See Debian bug: + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 + Fix: + https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: New Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. [Where problem could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
The current situation of python-apt is somewhat critical as no packages can be pushed via Landscape to machines at the moment. This is causing landscape-package-changer to segfault as follows: [apport-retrace] Core was generated by `/usr/bin/python3 /usr/bin/landscape-package-changer --quiet'. Program terminated with signal SIGSEGV, Segmentation fault. #0 ararchive_new (type=0x7f652626e0a0 , args=, kwds=) at python/arfile.cc:438 This seems to be a fix candidate: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 - Eric ** Tags added: seg sts ** Also affects: python-apt (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: python-apt (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: python-apt (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: python-apt (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: python-apt (Ubuntu Groovy) Importance: Undecided => High ** Changed in: python-apt (Ubuntu Focal) Importance: Undecided => High ** Changed in: python-apt (Ubuntu Xenial) Importance: Undecided => High ** Changed in: python-apt (Ubuntu) Importance: Undecided => High ** Changed in: python-apt (Ubuntu Bionic) Importance: Undecided => Critical ** Changed in: python-apt (Ubuntu Bionic) Importance: Critical => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: New Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
All regression failures, PASSED after a retry. There is no autopkgtest regression (failures) anymore. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter warnings. commit 816e529043de08f3f9dcc4097380de39478b0b16 Author: Simo Sorce Date: Thu Feb
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
I have retried all the FAILED tests. * postfix/3.3.0-1ubuntu0.3 (amd64) PASSED the 2nd time: http://autopkgtest.ubuntu.com/packages/p/postfix/bionic/amd64 * kimap/17.12.3-0ubuntu1 (armhf, ppc64el, arm64) are queued and waiting to retry. Stay tune ... - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
[sts-sponsors] cyrus-sasl2 has been sponsored in Bionic. I have already pinged sil2100 for its SRU verification. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
[sts-sponsors] adcli option #1 has been sponsored in Bionic with the following nitpicking: * Changed version from "0.8.2-1ubuntu2.1" to "0.8.2-1ubuntu1.1" * Changed debian/control to d/control. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse corre
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Matthew, I was thinking about possibly to declare some package relationships to not allow the offending packages' combination to occur, when I came across the exact same thought from cpaelzer. I don't know if you notice it, here it goes[0]: " One suggestion for the coming related uploads. Do you think it would make sense to ensure that the now-known-bad combinations of packages won't be allowed together. Maybe when you go for adcli and sssd in LP #1868703 again - they might have their dependency to libsasl2-modules-gssapi-mit be versioned to be greater or equal the fixed cyrus_sasl2? " Matthew do you have a plan to ensure the users will have the right combinations/package relationships ? - Eric [0]- https://lists.ubuntu.com/archives/ubuntu-server/2020-December/008613.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: a
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Matthew, I was thinking about possibly to declare some package relationships to not allow the offending packages' combination to occur, when I came across the exact same thought from cpaelzer. I don't know if you notice it, here it goes: " One suggestion for the coming related uploads. Do you think it would make sense to ensure that the now-known-bad combinations of packages won't be allowed together. Maybe when you go for adcli and sssd in LP #1868703 again - they might have their dependency to libsasl2-modules-gssapi-mit be versioned to be greater or equal the fixed cyrus_sasl2? " Matthew do you have a plan to ensure user will have the right combinations/package relationships ? - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Sug
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
** Changed in: systemd (Ubuntu Bionic)
Assignee: Eric Desrochers (slashd) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Confirmed
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_gro
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
(I have ping sil2100 internally for him to provide his 2 cents on this bug.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in GNOME Settings Daemon: Unknown Status in gdm3 package in Ubuntu: Confirmed Status in gnome-settings-daemon package in Ubuntu: In Progress Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: Won't Fix Status in pam source package in Bionic: Invalid Status in gdm3 source package in Focal: Confirmed Status in gnome-settings-daemon source package in Focal: New Status in pam source package in Focal: Invalid Status in gdm3 source package in Groovy: Confirmed Status in gnome-settings-daemon source package in Groovy: New Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
Lukasz (sil2100) can we have your SRU team input on this bug with regard to Bionic/18.04lTS ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in GNOME Settings Daemon: Unknown Status in gdm3 package in Ubuntu: Confirmed Status in gnome-settings-daemon package in Ubuntu: In Progress Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: Won't Fix Status in pam source package in Bionic: Invalid Status in gdm3 source package in Focal: Confirmed Status in gnome-settings-daemon source package in Focal: New Status in pam source package in Focal: Invalid Status in gdm3 source package in Groovy: Confirmed Status in gnome-settings-daemon source package in Groovy: New Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
I unfortunately don't have a smartcard device handy to test/debug/ but if I compare with RHEL which is known to be working... Redhat has the following configuration "gdm-smarcard" which includes "smartcard-auth", a symlink pointing to "smartcard-auth-local" I think we should 'mimic' this (at least as a starting point) without the selinux and other RHEL specific bits. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in gdm3 package in Ubuntu: Confirmed Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: New Status in pam source package in Bionic: Invalid Status in gdm3 source package in Focal: Confirmed Status in pam source package in Focal: Invalid Status in gdm3 source package in Groovy: Confirmed Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
# git clone https://gitlab.gnome.org/GNOME/gdm.git # find . -name "gdm-smartcard*" ./data/pam-arch/gdm-smartcard.pam ./data/pam-redhat/gdm-smartcard.pam ./data/pam-exherbo/gdm-smartcard.pam ./data/pam-lfs/gdm-smartcard.pam It seems like Ubuntu/Debian will have to start by having a 'compatible' PAM stack config. So far looking upstream, it seems to only be defined for 4 specific distros: - Archlinux - Redhat - Exherbo - Linux From Scratch (LFS) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in gdm3 package in Ubuntu: Confirmed Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: New Status in pam source package in Bionic: Invalid Status in gdm3 source package in Focal: Confirmed Status in pam source package in Focal: Invalid Status in gdm3 source package in Groovy: Confirmed Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1900105] Re: Arctis 5 Game output no longer works
I found the issue. The CTKI is an idiot who didn't realize System Volume is per device, and not global. Only took me 2 days to find out. I don't think I can close the issue myself, please close it before it wastes somebody's time. -- 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/1900105 Title: Arctis 5 Game output no longer works Status in pulseaudio package in Ubuntu: Invalid Bug description: The steelseries Arctis 5 headset is a USB device with 2 audio outputs: Game and Chat. In the system sound settings, I can clearly see 2 audio devices: "steelseries-arctis-output-game-common", and "steelseries-arctis-output-chat-common". Unfortunately, no sound comes out of the Game output. This has been working flawlessly up until yesterday (october 15th), a recent update may have caused this issue. No hardware/software changes were performed on my system, other than Ubuntu updates. Description: Ubuntu 20.04.1 LTS Release: 20.04 pulseaudio: Installed: 1:13.99.1-1ubuntu3.7 Candidate: 1:13.99.1-1ubuntu3.7 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: pulseaudio 1:13.99.1-1ubuntu3.7 ProcVersionSignature: Ubuntu 5.4.0-51.56-generic 5.4.65 Uname: Linux 5.4.0-51-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Oct 16 10:05:13 2020 InstallationDate: Installed on 2020-05-15 (154 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: pulseaudio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/02/2020 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F51f dmi.board.asset.tag: Default string dmi.board.name: B450 AORUS M dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF51f:bd07/02/2020:svnGigabyteTechnologyCo.,Ltd.:pnB450AORUSM:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450AORUSM:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: B450 MB dmi.product.name: B450 AORUS M dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1900105/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1900105] [NEW] Arctis 5 Game output no longer works
Public bug reported: The steelseries Arctis 5 headset is a USB device with 2 audio outputs: Game and Chat. In the system sound settings, I can clearly see 2 audio devices: "steelseries-arctis-output-game-common", and "steelseries-arctis-output-chat-common". Unfortunately, no sound comes out of the Game output. This has been working flawlessly up until yesterday (october 15th), a recent update may have caused this issue. No hardware/software changes were performed on my system, other than Ubuntu updates. Description:Ubuntu 20.04.1 LTS Release:20.04 pulseaudio: Installed: 1:13.99.1-1ubuntu3.7 Candidate: 1:13.99.1-1ubuntu3.7 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: pulseaudio 1:13.99.1-1ubuntu3.7 ProcVersionSignature: Ubuntu 5.4.0-51.56-generic 5.4.65 Uname: Linux 5.4.0-51-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Oct 16 10:05:13 2020 InstallationDate: Installed on 2020-05-15 (154 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: pulseaudio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/02/2020 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F51f dmi.board.asset.tag: Default string dmi.board.name: B450 AORUS M dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF51f:bd07/02/2020:svnGigabyteTechnologyCo.,Ltd.:pnB450AORUSM:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450AORUSM:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: B450 MB dmi.product.name: B450 AORUS M dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1900105 Title: Arctis 5 Game output no longer works Status in pulseaudio package in Ubuntu: New Bug description: The steelseries Arctis 5 headset is a USB device with 2 audio outputs: Game and Chat. In the system sound settings, I can clearly see 2 audio devices: "steelseries-arctis-output-game-common", and "steelseries-arctis-output-chat-common". Unfortunately, no sound comes out of the Game output. This has been working flawlessly up until yesterday (october 15th), a recent update may have caused this issue. No hardware/software changes were performed on my system, other than Ubuntu updates. Description: Ubuntu 20.04.1 LTS Release: 20.04 pulseaudio: Installed: 1:13.99.1-1ubuntu3.7 Candidate: 1:13.99.1-1ubuntu3.7 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: pulseaudio 1:13.99.1-1ubuntu3.7 ProcVersionSignature: Ubuntu 5.4.0-51.56-generic 5.4.65 Uname: Linux 5.4.0-51-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Oct 16 10:05:13 2020 InstallationDate: Installed on 2020-05-15 (154 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: pulseaudio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/02/2020 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F51f dmi.board.asset.tag: Default string dmi.board.name: B450 AORUS M dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF51f:bd07/02/2020:svnGigabyteTechnologyCo.,Ltd.:pnB450AORUSM:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450AORUSM:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: B450 MB dmi.product.name: B450 AORUS M dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1900105/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
** Changed in: gdm3 (Ubuntu Groovy) Importance: Medium => High ** Also affects: pam (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: gdm3 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: pam (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gdm3 (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: gdm3 (Ubuntu Focal) Status: New => Confirmed ** Changed in: gdm3 (Ubuntu Focal) Importance: Undecided => High ** Changed in: gdm3 (Ubuntu Bionic) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in gdm3 package in Ubuntu: Confirmed Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: New Status in pam source package in Bionic: New Status in gdm3 source package in Focal: Confirmed Status in pam source package in Focal: New Status in gdm3 source package in Groovy: Confirmed Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
