[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules
@chrisccoulson - I sponsored the changes as per normal, so they're in
the queue for -proposed in bionic and disco. Can I upload to the
security pocket? Does that just require debian/changelog to be changed?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1842651
Title:
Regression: after Uprade from udev_237-3ubuntu10.25 to
udev_237-3ubuntu10.26 network interfaces don't get renamed by 70
-persistent-network.rules
Status in OEM Priority Project:
In Progress
Status in systemd package in Ubuntu:
In Progress
Bug description:
[Impact]
* Many server users upgraded from previous Ubuntu LTS series, such as
14.04 and 16.04, will be affected by this regression.
* Because there is /etc/udev/rules/70-persistent-network.rules or
/etc/udev/rules.d/70-persistent-net.rules generated by
/lib/udev/write_net_rules left.
* The previous SRU commit of LP: #1837700 doesn't cover this
persistent network rule.
[Test Case]
* It needs to have two Ethernet devices and provides
/etc/udev/rules.d/70-persistent-net.rules as below.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
[Regression Potential]
* When users upgrade to next LTS 20.04, they may also encounter this
issue because Debian has dropped the same patch.
* We need to figure another way to avoid this regression for next LTS
20.04.
* Adding back the origial patch from Debian will casue another issue.
(LP: #1837700)
[Other Info]
Since the latest update from udev_237-3ubuntu10.25 and
systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and
systemd_237-3ubuntu10.26 the renaming of network interfaces by
/etc/udev/rules/70-persistent-network.rules does not work.
/etc/udev/rules/70-persistent-network.rules:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
/var/log/syslog:
systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File
exists
When I downgrade the packages to the version with 237-3ubuntu10.25 the
following messages are in /var/log/syslog:
Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2:
renamed from eth0
Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed
from eth1
The latest version does not rename the interfaces temporary if there
is a conflict!
Manually installing the old packages with
dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb
libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb
systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb
did fix the problem temporary.
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1842651/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841382] Re: Various programs crashed with SIGSEGV in g_str_hash() from g_hash_table_lookup_node() / g_hash_table_lookup() from accountsservice 0.6.55-0ubuntu5/6
** Changed in: accountsservice Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to accountsservice in Ubuntu. https://bugs.launchpad.net/bugs/1841382 Title: Various programs crashed with SIGSEGV in g_str_hash() from g_hash_table_lookup_node() / g_hash_table_lookup() from accountsservice 0.6.55-0ubuntu5/6 Status in accountsservice: Fix Released Status in accountsservice package in Ubuntu: Fix Committed Bug description: https://errors.ubuntu.com/problem/3a817938d76d231fdfc8f698392fbf5e3724084f https://errors.ubuntu.com/problem/597be858df957473f357a9249b002b0e39f42781 https://errors.ubuntu.com/problem/0075340d0f484f9b5d37821d3023970cc12d I do not know what triggered the crash. ProblemType: Crash DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.32.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-10.11-generic 5.2.4 Uname: Linux 5.2.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun Aug 25 20:45:09 2019 DisplayManager: gdm3 ExecutablePath: /usr/bin/gnome-shell InstallationDate: Installed on 2019-08-24 (1 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190819) ProcCmdline: /usr/bin/gnome-shell ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.32.2+git20190711-2ubuntu1 Signal: 11 SourcePackage: gnome-shell StacktraceTop: g_str_hash () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_hash_table_lookup () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () from /lib/x86_64-linux-gnu/libaccountsservice.so.0 ?? () ?? () Title: gnome-shell crashed with SIGSEGV in g_str_hash() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo separator: To manage notifications about this bug go to: https://bugs.launchpad.net/accountsservice/+bug/1841382/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841382] Re: Various programs crashed with SIGSEGV in g_str_hash() from g_hash_table_lookup_node() / g_hash_table_lookup() from accountsservice 0.6.55-0ubuntu5/6
The main issue is when I updated to 0.6.55 the new Meson based build systemd didn't build with systemd support by default. So I've uploaded a build with this enabled. There may still be an underlying issue, but this should fix the eoan issues. ** Changed in: accountsservice (Ubuntu) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to accountsservice in Ubuntu. https://bugs.launchpad.net/bugs/1841382 Title: Various programs crashed with SIGSEGV in g_str_hash() from g_hash_table_lookup_node() / g_hash_table_lookup() from accountsservice 0.6.55-0ubuntu5/6 Status in accountsservice: New Status in accountsservice package in Ubuntu: Fix Committed Bug description: https://errors.ubuntu.com/problem/3a817938d76d231fdfc8f698392fbf5e3724084f https://errors.ubuntu.com/problem/597be858df957473f357a9249b002b0e39f42781 https://errors.ubuntu.com/problem/0075340d0f484f9b5d37821d3023970cc12d I do not know what triggered the crash. ProblemType: Crash DistroRelease: Ubuntu 19.10 Package: gnome-shell 3.32.2-2ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-10.11-generic 5.2.4 Uname: Linux 5.2.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun Aug 25 20:45:09 2019 DisplayManager: gdm3 ExecutablePath: /usr/bin/gnome-shell InstallationDate: Installed on 2019-08-24 (1 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190819) ProcCmdline: /usr/bin/gnome-shell ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.32.2+git20190711-2ubuntu1 Signal: 11 SourcePackage: gnome-shell StacktraceTop: g_str_hash () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_hash_table_lookup () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () from /lib/x86_64-linux-gnu/libaccountsservice.so.0 ?? () ?? () Title: gnome-shell crashed with SIGSEGV in g_str_hash() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo separator: To manage notifications about this bug go to: https://bugs.launchpad.net/accountsservice/+bug/1841382/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session
Sorry I haven't got back to investigating this yet. I wonder though if it's related to: https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/690 -- 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/1841915 Title: black screen, unresponsive, after logout from gnome Wayland session Status in gdm3 package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: on logout the screen is black, the system is unresponsive and has to be restarted. (Untested by me yet, but I expect ssh-ing in and restarting gdm would work.) I believe this may be already reported upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've reported this against gdm3 even though I honestly don't know if it might be a gnome-shell, gnome-session or mutter based error. (FWIW without the upstream bug to link to I'd maybe suspect gnome-shell first.) NB: This machine's conf has AutomaticLogin enabled, but another machine also on 19.10 does not, and it's showing the same thing. On *this* machine I found that the *first* time I logged out, it was OK, but not the second time. On the other machine, it fails first time too. It's as if the gdm login screen can appear exactly once. That (and being on gnome 3.33) is why I don't think this is a dupe of #1824588. Nothing appears in /var/crash as a result of this. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gdm3 3.33.90-1ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8 Uname: Linux 5.2.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 29 10:51:22 2019 InstallationDate: Installed on 2018-09-11 (351 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gdm3 UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago) mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838208] Re: Wifi stops responding sporadically on lenovo-yoga-720-15ikb
On 5.2.0-15-generic my WiFi stopped working and I see this in dmesg. [52478.783342] iwlwifi :01:00.0: Microcode SW error detected. Restarting 0x200. [52478.783507] iwlwifi :01:00.0: Start IWL Error Log Dump: [52478.783510] iwlwifi :01:00.0: Status: 0x0080, count: 6 [52478.783511] iwlwifi :01:00.0: Loaded firmware version: 36.8fd77bb3.0 [52478.783513] iwlwifi :01:00.0: 0x0EDC | ADVANCED_SYSASSERT [52478.783514] iwlwifi :01:00.0: 0x00A00220 | trm_hw_status0 [52478.783515] iwlwifi :01:00.0: 0x | trm_hw_status1 [52478.783516] iwlwifi :01:00.0: 0x0002486C | branchlink2 [52478.783517] iwlwifi :01:00.0: 0x0003A7CE | interruptlink1 [52478.783518] iwlwifi :01:00.0: 0x | interruptlink2 [52478.783519] iwlwifi :01:00.0: 0x0BE7001C | data1 [52478.783520] iwlwifi :01:00.0: 0x2606 | data2 [52478.783521] iwlwifi :01:00.0: 0x0E4C | data3 [52478.783522] iwlwifi :01:00.0: 0x2EC0909D | beacon time [52478.783523] iwlwifi :01:00.0: 0x55F27F6B | tsf low [52478.783524] iwlwifi :01:00.0: 0x03B7 | tsf hi [52478.783525] iwlwifi :01:00.0: 0x | time gp1 [52478.783526] iwlwifi :01:00.0: 0xC9EF0F37 | time gp2 [52478.783527] iwlwifi :01:00.0: 0x0001 | uCode revision type [52478.783528] iwlwifi :01:00.0: 0x0024 | uCode version major [52478.783529] iwlwifi :01:00.0: 0x8FD77BB3 | uCode version minor [52478.783530] iwlwifi :01:00.0: 0x0230 | hw version [52478.783531] iwlwifi :01:00.0: 0x00C89000 | board version [52478.783532] iwlwifi :01:00.0: 0x2606 | hcmd [52478.783533] iwlwifi :01:00.0: 0x24022002 | isr0 [52478.783534] iwlwifi :01:00.0: 0x | isr1 [52478.783535] iwlwifi :01:00.0: 0x08001802 | isr2 [52478.783536] iwlwifi :01:00.0: 0x00417CC1 | isr3 [52478.783537] iwlwifi :01:00.0: 0x | isr4 [52478.783538] iwlwifi :01:00.0: 0x0BA8001C | last cmd Id [52478.783539] iwlwifi :01:00.0: 0x | wait_event [52478.783540] iwlwifi :01:00.0: 0x00C4 | l2p_control [52478.783541] iwlwifi :01:00.0: 0x00018030 | l2p_duration [52478.783542] iwlwifi :01:00.0: 0x0007 | l2p_mhvalid [52478.783543] iwlwifi :01:00.0: 0x0081 | l2p_addr_match [52478.783544] iwlwifi :01:00.0: 0x001D | lmpm_pmg_sel [52478.783545] iwlwifi :01:00.0: 0x29051704 | timestamp [52478.783546] iwlwifi :01:00.0: 0x5868 | flow_handler [52478.783615] iwlwifi :01:00.0: Start IWL Error Log Dump: [52478.783616] iwlwifi :01:00.0: Status: 0x0080, count: 7 [52478.783617] iwlwifi :01:00.0: 0x0070 | NMI_INTERRUPT_LMAC_FATAL [52478.783618] iwlwifi :01:00.0: 0x | umac branchlink1 [52478.783619] iwlwifi :01:00.0: 0xC0086934 | umac branchlink2 [52478.783620] iwlwifi :01:00.0: 0xC0083B0C | umac interruptlink1 [52478.783621] iwlwifi :01:00.0: 0xC0083B0C | umac interruptlink2 [52478.783622] iwlwifi :01:00.0: 0x0800 | umac data1 [52478.783623] iwlwifi :01:00.0: 0xC0083B0C | umac data2 [52478.783624] iwlwifi :01:00.0: 0xDEADBEEF | umac data3 [52478.783624] iwlwifi :01:00.0: 0x0024 | umac major [52478.783625] iwlwifi :01:00.0: 0x8FD77BB3 | umac minor [52478.783626] iwlwifi :01:00.0: 0xC088628C | frame pointer [52478.783627] iwlwifi :01:00.0: 0xC088628C | stack pointer [52478.783628] iwlwifi :01:00.0: 0x00F9014E | last host cmd [52478.783629] iwlwifi :01:00.0: 0x | isr status reg [52478.783657] iwlwifi :01:00.0: Fseq Registers: [52478.783667] iwlwifi :01:00.0: 0x38376E8E | FSEQ_ERROR_CODE [52478.783678] iwlwifi :01:00.0: 0x015B6011 | FSEQ_TOP_INIT_VERSION [52478.783688] iwlwifi :01:00.0: 0x3727C216 | FSEQ_CNVIO_INIT_VERSION [52478.783699] iwlwifi :01:00.0: 0xA10B | FSEQ_OTP_VERSION [52478.783710] iwlwifi :01:00.0: 0xEDE3F1DF | FSEQ_TOP_CONTENT_VERSION [52478.783720] iwlwifi :01:00.0: 0xDF1522B6 | FSEQ_ALIVE_TOKEN [52478.783731] iwlwifi :01:00.0: 0x6FAD1A96 | FSEQ_CNVI_ID [52478.783741] iwlwifi :01:00.0: 0xA16E30DC | FSEQ_CNVR_ID [52478.783752] iwlwifi :01:00.0: 0x0010 | CNVI_AUX_MISC_CHIP [52478.783760] iwlwifi :01:00.0: 0x0BADCAFE | CNVR_AUX_MISC_CHIP [52478.783770] iwlwifi :01:00.0: 0x0BADCAFE | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM [52478.783781] iwlwifi :01:00.0: 0x0BADCAFE | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR [52478.783794] iwlwifi :01:00.0: Collecting data: trigger 2 fired. [52478.783802] ieee80211 phy0: Hardware restart was requested [52479.289828] iwlwifi :01:00.0: Failing on timeout while stopping DMA channel 8 [0x07fd0001] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1838208 Title: Wifi stops responding sporadically on lenovo-yoga-720-15ikb Status in linux package in Ubuntu: Confirmed Status in network-manager package in
[Touch-packages] [Bug 1842902] Re: FFe: create zfs dataset for each user automatically
Didier - could you please add some checks on the return values from the various open/dup2/execvl syscalls? Whilst currently I can't see a huge problem if these silently fail (open returns -1, dup2 then fails, or if dup2 fails anyway - then the only consequence is stdout/stderr is not silenced) I think it would be better to be more defensive (or if not, at least add a comment explaining why NOT checking for failures is not a problem). Also instead of the strrstr() call (which again is unchecked but since this is running on a known string is unlikely to fail) - why not either just use zsys+6 since this is a fixed string OR just const char *pname = "zsys"; ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1842902 Title: FFe: create zfs dataset for each user automatically Status in shadow package in Ubuntu: New Status in zsys package in Ubuntu: New Bug description: Part of the zsys spec is creating/associating one user dataset for each HOME user. As zsys is an official experimentation for 19.10, we would like to include this feature in a safe way, and reachable for any tool creating users (adduser, gnome-control-center, ubiquity…). Those are using useradd under the scene. For this, the proposed implementation: - patch useradd trying to execute "zsys useradd create USER HOMEDIR". If zsys isn't present or zsys returns a status code != 0 (which will be the case if the running system isn't a zsys one: pure zfs or non zfs like / on ext4), it will fallback to mkdir. Then the code does the usual chmod() - patch usermod, trying as well to execute "zsys useradd rename-home OLDHOME NEWHOME". Same failing reason (not a zsys system, not installed, OLDHOME isn't a zsys handled datasets) and fallback to rename(). Then the code does the usual chmod(). Tested with and without zsys installed, the code does what we expect. I'm attaching the shadow (useradd/usermod) patches, as you can see it's very minimal. A new ZSYS release will be needed (https://github.com/ubuntu/zsys). As you can see, there are quite some commits since the last release, but it's all baked (as usual) by a huge suite of tests (in ZFS and machine layers) with corner cases tested and such. I'm confident on that change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1842902/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841654] Re: Consider replacing mawk with gawk in main
NetBSD pkgsrc has a more recent version of mawk than stated in this
report:
http://pkgsrc.se/lang/mawk
2019-02-15) Updated to version: mawk-1.3.4.20171017
MacPorts has the 2019-02-03 version:
https://github.com/macports/macports-
ports/blob/master/lang/mawk/Portfile
The report as worded implies that none of the various packages are newer
than "1.3.4" by omitting most of the details about patchlevel. In
practice, the age of packages says more about the ported platform than
the programs which are provided on that platform.
Regarding OpenCSW, the same comments about old version apply to gawk:
https://www.opencsw.org/packages/gawk/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mawk in Ubuntu.
https://bugs.launchpad.net/bugs/1841654
Title:
Consider replacing mawk with gawk in main
Status in mawk package in Ubuntu:
New
Bug description:
For POSIX compatibility reasons Ubuntu ships with mawk ("Mike's awk" =
mawk) in main. There is an awk-symlink to mawk, thus mawk is the
official awk implementation in Ubuntu.
== Reasons against keeping mawk ==
*The mawk package is synced from debian and it is heavily
undermaintained: Debian (and thus Ubuntu) still ships version
1.3.3-17, the same version at least since oldoldstable:
https://packages.debian.org/search?searchon=names=mawk
*maintainer Thomas E. Dickey (https://invisible-island.net/mawk/)
called officially out that Debian "neglected" mawk in 2014 ("As noted,
mawk has been neglected by some packagers (see for example this
http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mawk)". And
Debian (and Ubuntu) still ship the same version five years later
*Most other distributions ship mawk at least in its last official
incarnation 1.3.4 in their repositories. Dickey lists AIX, Fedora,
FinkPorts (Mac OS X), FreeBSD port, Gentoo, HPUX, MacPorts (Mac OS X),
NetBSD pkgsrc/lang, OpenCSW (Solaris). That version is from 2014 but
updated snapshots are released in regular intervals. The current
snapshot is from February 2019: https://github.com/ThomasDickey/mawk-
snapshots/blob/ab13a164013940e90c0b1ad36a039feae06a0b65/CHANGES
*A planned rewrite mawk2 was planned by original author Mike Brennan
in 2016 but obviously came to nothing:
https://github.com/ploxiln/mawk-2/commits/master
*Thus mawk sits in Ubuntu main in a version published upstream in 2009
and celebrates its 10th anniversary of negligence. In a state that
Debian was called out for 5 years ago.
*This year it is 10 years unmaintained and largely untouched. At the
end of the next LTS-support-cycle we can celebrate 15 years of not
supporting it.
*awk is included in Linux for POSIX standard compliance. Mawk is known
to be fast and small but it is the implementation that is farthest
from being POSIX compliant, missing things like named character
classes like [[:space:]] within its EREs.
== Reasons for gawk as a replacement ==
*It is the official GNU awk implementation and known to work well with
the rest of the GNU userland.
*It is actively maintained with the last version 5.01 shipping in
June, 2019 (even if Ubuntu will obviously still ship 4.2 for Eoan).
*It is mostly compliant with the POSIX standard.
*Most other distributions ship it as the standard POSIX
implementation, with a awk symlink. So it had security reviews already
by Red Hat and others.
== Possible problems with switching to gawk in time for Ubuntu 20.4 ==
- It might need to be MIRed by the Ubuntu security team and a review
might take some time. So I filed this bug early with Eoan not yet out
of the door.
- It is much larger than mawk, the Ubuntu package is 1600 kB in size,
while mawk is only about 190KB. Thus some might want to split out some
basic functionality to save size. Like what is vim-tiny to vim. To
start gawk in --traditional or --posix mode and disable the extensions
at compile time might be a good start to reduce the size. See:
https://www.gnu.org/software/gawk/manual/html_node/Additional-
Configuration-Options.html#Additional-Configuration-Options
=
ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: mawk 1.3.3-17ubuntu3
ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21
Uname: Linux 5.0.0-27-generic x86_64
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Aug 27 20:12:11 2019
Dependencies:
gcc-9-base 9.1.0-2ubuntu2~19.04
libc6 2.29-0ubuntu2
libgcc1 1:9.1.0-2ubuntu2~19.04
libidn2-0 2.0.5-1
libunistring2 0.9.10-1ubuntu2
InstallationDate: Installed on 2018-02-23 (550 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
ProcEnviron:
LANGUAGE=de_AT:de
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=de_AT.UTF-8
SHELL=/bin/bash
[Touch-packages] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev
Attaching the debdiff with the fix. This is waiting on validation from the reported user that the boot problem does not happen anymore -- but has already been validated on the running system to produce the correct/expected behavior (UUID / other values are printed by 'udevadm test-builtin blkdid'). I'll be out the next week, so this should probably be handled by Guilherme Piccoli during this time. ** Description changed: + [Impact] + + * Users / systemd can fail to mount a filesystem by UUID +(e.g., during boot, triggering emergency shell prompt) +if the magic bytes for the nilfs filesystem are written +to the right place in a partition of another filesystem, +(for whatever reason or coincidence). + + * Note this can happen after the filesystem/mount is working +correctly, so a change of behavior/problem can potentially +be noticed when trying to mount the filesystem again, which +can very well be the next time the system boots. + + * This happens because if udev blkid detects more than one +filesystem, it does not print the UUID env vars required +to create the /dev/disk/by-id symlinks and other things. + + * The fix enhances the check for valid nilfs superblock by +specifically checking a value read from disk to be valid/ +within a value range, which addresses this one occurrence +and prevents a lot more. + + [Test Case] + + * Synthetic test case written for this problem on comment #6. + + [Regression Potential] + + * Low. The code is contained in the probe for the nilfs filesystem. + + * This just makes it be more restrictive about the possibly valid +values for a few bytes read from disk (that now need to be within +the acceptable range of valid values) so this only decreases false- +positives, and cannot increase false-negatives of valid filesystems. + + [Original Description] + The nilfs filesystem has a backup superblock at the end of the device. If the magic number is coincidentally found at the right position and the filesystem is on a partition/not-wholedisk device, the only check left is for checksum verification, which is explicitly ignored in 'udev built-in blkid'. This causes blkid to detect one actually valid filesystem with a superblock at the beginning of the device (e.g., ext4), and then an invalid nilfs2 filesystem due to a coincidental magic number at the end of the device. And this causes blkid to break out of the safeprobe routine (which expects a single filesystem to be detected), and not print the UUIDs, thus not creating /dev/disk/by-uuid/ links which prevent mounting the partition by-uuid at boot time, causing emergency shell/boot failures. This upstream fix resolved the problem by introducing a check for the 'bytes' paramenters in the superblock, which is read from disk, and turns out to have an out-of-range value. - 'liblkid: Add length check in probe_nilfs2 before crc32' https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2 $ git describe --contains ac681a310c32319423297544833932f4d689a7a2 v2.29-rc1~172 Xenial, which is v2.27.1-based, is the only release that needs it. Bionic is v2.31.1, so all post-Xenial supported releases have it. ** Patch added: "lp1842437_util-linux.debdiff" https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+attachment/5287043/+files/lp1842437_util-linux.debdiff ** Changed in: util-linux (Ubuntu Xenial) Assignee: Mauricio Faria de Oliveira (mfo) => Guilherme G. Piccoli (gpiccoli) -- 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/1842437 Title: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: In Progress Bug description: [Impact] * Users / systemd can fail to mount a filesystem by UUID (e.g., during boot, triggering emergency shell prompt) if the magic bytes for the nilfs filesystem are written to the right place in a partition of another filesystem, (for whatever reason or coincidence). * Note this can happen after the filesystem/mount is working correctly, so a change of behavior/problem can potentially be noticed when trying to mount the filesystem again, which can very well be the next time the system boots. * This happens because if udev blkid detects more than one filesystem, it does not print the UUID env vars required to create the /dev/disk/by-id symlinks and other things. * The fix enhances the check for valid nilfs superblock by specifically checking a value read from disk to be valid/ within a value range, which addresses this one occurrence and prevents a lot more.
[Touch-packages] [Bug 1818918] Re: gdb doesn't search in debug-file-directory for .gnu_debugaltlink
I've discovered that I can workaround this issue by modifying the
argument passed to the 'set debug-file-directory' option of gdb e.g. by
using the following:
'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64
/report-sandbox/usr/lib/debug/.dwz/'
I no longer see the error message regarding "could not find
'.gnu_debugaltlink' file for...'. Originally the 'set debug-file-
directory' argument was:
'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64
/report-sandbox/usr/lib/debug/'
Additionally its worth noting that if I use both paths e.g.:
'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu 19.10/amd64
/report-sandbox/usr/lib/debug/.dwz/:/srv/vms/apport-sandbox-dir/Ubuntu
19.10/amd64/report-sandbox/usr/lib/debug/'
I receive the error message again.
--
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/1818918
Title:
gdb doesn't search in debug-file-directory for .gnu_debugaltlink
Status in gdb package in Ubuntu:
Incomplete
Bug description:
As far as I can tell gdb version 8.2.90 isn't searching the debug-
file-directory, which I set, for the '.gnu_debugaltlink' which is in
the debug symbols. Here's the error I'm seeing:
Type "apropos word" to search for commands related to "word".
Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox//usr/bin/gnome-calculator...
Reading symbols from /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug...
could not find '.gnu_debugaltlink' file for
/srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug
(No debugging symbols found in /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug)
Here's part of an strace of what's going on behind the scenes:
lstat("/srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug/.build-id/95/59c4c5ee30eb66d47bb9bd64784a69c9a6de6b.debug",
{st_mode=S_IFREG|0644, st_size=839744, ...}) = 0
openat(AT_FDCWD,
"/usr/lib/debug/.dwz/x86_64-linux-gnu/gnome-calculator.debug",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
This is the only time "/usr/lib/debug" is searched, generally
"/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
sandbox/usr/lib/debug/" is used. I'll attach the full strace though.
For completeness here's the gdb command I'm using:
Calling gdb command: '/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64
/report-sandbox/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' '/srv/vms
/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/usr/bin/gdb'
--ex 'set debug-file-directory /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox/usr/lib/debug' --ex 'set solib-absolute-
prefix /srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox'
--ex 'add-auto-load-safe-path /srv/vms/apport-sandbox-dir/Ubuntu
19.04/amd64/report-sandbox' --ex 'set solib-search-path /srv/vms
/apport-sandbox-dir/Ubuntu 19.04/amd64/report-sandbox/lib/x86_64
-linux-gnu' --ex 'set data-directory /srv/vms/apport-sandbox-
dir/Ubuntu 19.04/amd64/report-sandbox/usr/share/gdb' --ex 'file
"/srv/vms/apport-sandbox-dir/Ubuntu 19.04/amd64/report-
sandbox//usr/bin/gnome-calculator"' --ex 'core-file
/tmp/apport_core_1b6dn6np'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1818918/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1757375] Re: Desktop unable to Suspend when Inactive
Thanks for the response. Sorry for the delay, I didn't get a notification about this. If by admin you mean one that has sudo privileges or a member of group `adm`, then yes. It's the default user created by the installer. I could reproduce this on Arch Linux and other distros IIRC. The workaround works on them too. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-desktop- privileges in Ubuntu. https://bugs.launchpad.net/bugs/1757375 Title: Desktop unable to Suspend when Inactive Status in policykit-desktop-privileges package in Ubuntu: Confirmed Bug description: On 16.04 (XFCE session and others) and possibly later the power- manager is unable to suspend the system when the user is inactive. A PK user-agent dialog is presented for the user to authenticate first - and as this action occurs specifically when the user is idle and away the PC can end up having an unplanned loss of power when the battery is exhausted. /var/log/auth.log shows: polkitd(authority=local): Operator of unix-session:c2 FAILED to authenticate to gain authorization for action org.freedesktop.login1.suspend for system-bus-name::1.47 [xfce4-power- manager --restart --sm-client-id 2992705d4-6fa2-4fba-966c- f7631ecd0b46] (owned by unix-user:tj) The problem seems to be "com.ubuntu.desktop.pkla" is missing an entry to allow Suspend. Currently it only has an entry for hibernate. Adding the following stanza solves the issue: [Enable suspend by default in logind] Identity=unix-user:* Action=org.freedesktop.login1.suspend;org.freedesktop.login1.inhibit-handle-suspend-key;org.freedesktop.login1;org.freedesktop.login1.suspend-multiple-sessions;org.freedesktop.login1.suspend-ignore-inhibit ResultActive=yes ResultInactive=yes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-privileges/+bug/1757375/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1817123] Re: tmpfiles.d files pointing to legacy directory /var/run
** Changed in: spice-vdagent (Debian) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1817123 Title: tmpfiles.d files pointing to legacy directory /var/run Status in systemd package in Ubuntu: Confirmed Status in speech-dispatcher package in Debian: New Status in spice-vdagent package in Debian: Fix Released Bug description: Just updated cosmic and got: Setting up systemd (239-7ubuntu10.8) ... [/usr/lib/tmpfiles.d/speech-dispatcher.conf:1] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher → /run/speech-dispatcher; please update the tmpfiles.d/ drop-in file accordingly. [/usr/lib/tmpfiles.d/speech-dispatcher.conf:2] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher/.cache → /run/speech-dispatcher/.cache; please update the tmpfiles.d/ drop-in file accordingly. [/usr/lib/tmpfiles.d/speech-dispatcher.conf:3] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher/.speech-dispatcher → /run/speech-dispatcher/.speech-dispatcher; please update the tmpfiles.d/ drop-in file accordingly. [/usr/lib/tmpfiles.d/speech-dispatcher.conf:4] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher/.cache/speech-dispatcher → /run/speech-dispatcher/.cache/speech-dispatcher; please update the tmpfiles.d/ drop-in file accordingly. [/usr/lib/tmpfiles.d/speech-dispatcher.conf:5] Line references path below legacy directory /var/run/, updating /var/run/speech-dispatcher/log → /run/speech-dispatcher/log; please update the tmpfiles.d/ drop-in file accordingly. [/usr/lib/tmpfiles.d/spice-vdagentd.conf:2] Line references path below legacy directory /var/run/, updating /var/run/spice-vdagentd → /run/spice-vdagentd; please update the tmpfiles.d/ drop-in file accordingly. andre@thinkpad:~$ lsb_release -rd Description:Ubuntu 18.10 Release:18.10 andre@thinkpad:~$ apt-cache policy systemd systemd: Installed: 239-7ubuntu10.8 Candidate: 239-7ubuntu10.8 Version table: *** 239-7ubuntu10.8 500 500 http://br.archive.ubuntu.com/ubuntu cosmic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu cosmic-security/main amd64 Packages 100 /var/lib/dpkg/status 239-7ubuntu10 500 500 http://br.archive.ubuntu.com/ubuntu cosmic/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1817123/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules
If this change is being reverted, it needs to be done via the security
pocket rather than proposed, as Tuesday's security update was based on
the version with this regression.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1842651
Title:
Regression: after Uprade from udev_237-3ubuntu10.25 to
udev_237-3ubuntu10.26 network interfaces don't get renamed by 70
-persistent-network.rules
Status in OEM Priority Project:
In Progress
Status in systemd package in Ubuntu:
In Progress
Bug description:
[Impact]
* Many server users upgraded from previous Ubuntu LTS series, such as
14.04 and 16.04, will be affected by this regression.
* Because there is /etc/udev/rules/70-persistent-network.rules or
/etc/udev/rules.d/70-persistent-net.rules generated by
/lib/udev/write_net_rules left.
* The previous SRU commit of LP: #1837700 doesn't cover this
persistent network rule.
[Test Case]
* It needs to have two Ethernet devices and provides
/etc/udev/rules.d/70-persistent-net.rules as below.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
[Regression Potential]
* When users upgrade to next LTS 20.04, they may also encounter this
issue because Debian has dropped the same patch.
* We need to figure another way to avoid this regression for next LTS
20.04.
* Adding back the origial patch from Debian will casue another issue.
(LP: #1837700)
[Other Info]
Since the latest update from udev_237-3ubuntu10.25 and
systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and
systemd_237-3ubuntu10.26 the renaming of network interfaces by
/etc/udev/rules/70-persistent-network.rules does not work.
/etc/udev/rules/70-persistent-network.rules:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
/var/log/syslog:
systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File
exists
When I downgrade the packages to the version with 237-3ubuntu10.25 the
following messages are in /var/log/syslog:
Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2:
renamed from eth0
Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed
from eth1
The latest version does not rename the interfaces temporary if there
is a conflict!
Manually installing the old packages with
dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb
libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb
systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb
did fix the problem temporary.
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1842651/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1756595] Autopkgtest regression report (apt/1.6.12)
All autopkgtests for the newly accepted apt (1.6.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: sbuild/0.75.0-1ubuntu1 (ppc64el) apport/2.20.9-0ubuntu7.7 (amd64, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1756595 Title: disk space info inadvertently provides all installed snaps Status in apport package in Ubuntu: Invalid Status in apt package in Ubuntu: Fix Released Status in apport source package in Bionic: Invalid Status in apt source package in Bionic: Fix Committed Status in apport source package in Disco: New Status in apt source package in Disco: Fix Committed Status in apport source package in Eoan: Invalid Status in apt source package in Eoan: Fix Released Bug description: [Impact] When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1% /var/lib/lxd/storage-pools/default/containers/squid-ds216 /dev/loop0 83712 83712 0 100% /snap/core/4206 /dev/loop1 102144 102144 0 100% /snap/git-ubuntu/402 You can see I have the core snap at revision 4206, and git-ubuntu at revision 402. There are already many bug reports in launchpad where one can see this information. Granted, the user can review it, refuse to send this data, etc. This bug is about the unexpectedness of having that information in the disk space data. If the user sees a prompt like "Would you like to include disk free space information in your report?", or "Would you like to include the output of the df(1) command in your report?", that doesn't immediately translate to "Would you like to include disk free space information and a list of all installed snaps and their revision numbers in your report?". [Test case] Do something that triggers the apport hook and make sure you don't see snaps in there. For example, install xterm, then add exit 1 to the start of the prerm, then run apt remove xterm, and investigate /var/crash/xterm.0.crash after that (delete before running apt). [Regression potential] Fix consists of adding -x squashfs to df output, so might hide other non-snap squashfs images. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1756595/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1829861] Autopkgtest regression report (apt/1.6.12)
All autopkgtests for the newly accepted apt (1.6.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: sbuild/0.75.0-1ubuntu1 (ppc64el) apport/2.20.9-0ubuntu7.7 (amd64, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829861 Title: handle TLS session renegotiation Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Status in apt source package in Eoan: Fix Released Bug description: [Impact] TLS sessions can renegotiate keys, but APT does not support it; meaning their HTTPS connections stop working. [Test case] We don't really have a reproducer. You'd need a server that re-negotiates by path; e.g. because it requires a a certain client certificate for a certain path. We know it does not break other use cases, having run that for quite some time in eoan and Debian stretch, and the patch was tested by the patch submitter @ Akamai (see https://github.com/Debian/apt/pull/93). [Regression potential] - Could we get stuck on renegotiation? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1829860] Autopkgtest regression report (apt/1.6.12)
All autopkgtests for the newly accepted apt (1.6.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: sbuild/0.75.0-1ubuntu1 (ppc64el) apport/2.20.9-0ubuntu7.7 (amd64, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829860 Title: APT unlocks in same order as it locks Status in apt package in Ubuntu: Fix Released Status in apt source package in Xenial: New Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Bug description: [Impact] APT releases the locks in the same order it acquires them, rather than reverse order. Given that we have no waiting for locks, this is not _super_ problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, rather than lock-frontend. [Test case] Watch lock release with strace and see that it unlocks the right way. [Regression potential] Some other locking races or something? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838771] Autopkgtest regression report (apt/1.6.12)
All autopkgtests for the newly accepted apt (1.6.12) for bionic have finished running. The following regressions have been reported in tests triggered by the package: sbuild/0.75.0-1ubuntu1 (ppc64el) apport/2.20.9-0ubuntu7.7 (amd64, i386) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#apt [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1838771 Title: http:Fix Host header in proxied https connections Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Bug description: [Impact] Currently CONNECT requests use the name of the proxy as Host value, instead of the origin server's name. According to RFC 2616 "The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL." The current implementation causes problems with some proxy vendors. This commit[0] fixes this. [0] - https://salsa.debian.org/apt- team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f [Test Case] Here's one reproducer an impacted user brought to my attention: # /etc/environment http_proxy="http://internal:8080; https_proxy="http://interal:8080; To support application development activities in-house, I had to configure Azure CLI APT repository following the instructions from "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view =azure-cli-latest": $ sudo apt-get update $ sudo apt-get install curl apt-transport-https lsb-release gnupg $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \ $ gpg --dearmor | \ $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null $ AZ_REPO=$(lsb_release -cs) $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ AZ_REPO main" | \ $ sudo tee /etc/apt/sources.list.d/azure-cli.list $ sudo apt update In the final "apt update" command, APT respects system-wide network proxy variables and successfully fetched Canonical repository data over HTTP. However, it was unable to fetch the newly added Microsoft packages repository served via HTTPS. By using Wireshark to examine the HTTPS request made by APT, the request body reveals as: CONNECT packages.microsoft.com:443 HTTP/1.1\r\n Host: internal:8080\r\n User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n ... ... There also is an automated test case in the package that runs as part of autopkgtest that tests a scenario like this, see the commit. [Regression Potential] * Fix already in debian, and Eoan * Has been reviewed/approved by juliank * A test package (pre-sru) has been provided to an impacted user, and he confirms it solves the situation. [Other Info] # salsa $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72 1.9.0~8 # rmadison apt => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1800167] Re: fstrim: /var/spool/postfix/etc/sasldb2: not a directory
Fixed in upstream tree. Thanks for your report. -- 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/1800167 Title: fstrim: /var/spool/postfix/etc/sasldb2: not a directory Status in util-linux package in Ubuntu: New Bug description: I've started getting weekly cron emails starting on Oct 7, 2018 that say /etc/cron.weekly/fstrim: fstrim: /var/spool/postfix/etc/sasldb2: not a directory The previous week's email did not have any complaints from fstrim, and I'm not sure what changed since then. There was a kernel upgrade (to 4.4.0-137.163), maybe that's related? My /etc/fstab contains the following line /etc/sasldb2 /var/spool/postfix/etc/sasldb2 none bind 0 0 because I need postfix's smtpd to access /etc/sasldb2 inside the postfix chroot. FWIW the root partition (that contains /etc/sasldb2) on this server resides on a pair of SSDs (inside a raid1 LVM volume), but only since Sep 27 when I moved it there. I'm not sure it's relevant since, as I mentioned before, the weekly email on Sep 30 did not have any fstrim complaints, just the usual "new 18.04 LTS update available, consider upgrading". ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: util-linux 2.27.1-6ubuntu3.6 ProcVersionSignature: Ubuntu 4.4.0-138.164-generic 4.4.155 Uname: Linux 4.4.0-138-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Fri Oct 26 17:56:06 2018 SourcePackage: util-linux UpgradeStatus: Upgraded to xenial on 2016-11-07 (718 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1800167/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error
** Changed in: openldap (Debian)
Status: Unknown => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1838370
Title:
slapd segfault on filter parse error
Status in openldap:
Fix Released
Status in openldap package in Ubuntu:
Fix Released
Status in openldap source package in Xenial:
Fix Released
Status in openldap source package in Bionic:
Fix Released
Status in openldap source package in Disco:
Fix Released
Status in openldap package in Debian:
Fix Released
Bug description:
[Impact]
Users willing to use the slapd rwm overlay will face a slapd
segmentation fault when trying to rewrite some rules. Backporting this
fix will allow users using stable releases to take advantage of this
feature without crashing slapd. This issue was fixed by upstream not
freeing the rwm overlay filter memory without prior checking.
[Test Case]
In this test case, the rwm overlay will be used and a rule will be
created to deny any search request for uid=root, then the 'ldapsearch'
will be invoked to trigger the failure. It is important to mention
that the 'ldapsearch' command should fail regardless the presence of
the bug in the package, the target here is the slapd crash. To
reproduce this bug one can follow the procedure below in Ubuntu
xenial, bionic or disco:
$ sudo apt-get update
Use debconf to pre-seed slapd questions before install it:
$ debconf-set-selections << EOF
slapd slapd/no_configuration boolean false
slapd slapd/domain string example.com
slapd shared/organization string example.com
slapd slapd/password1 password test
slapd slapd/password2 password test
slapd slapd/backend select MDB
slapd slapd/move_old_database boolean false
EOF
$ sudo apt-get install slapd ldap-utils -y
Create a file called 'add-rwm.ldif' with the following content:
$ cat add-rwm.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: rwm
dn: olcOverlay=rwm,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: rwm
olcRwmRewrite: {0} rwm-rewriteEngine "on"
olcRwmRewrite: {1} rwm-rewriteContext "searchFilter"
olcRwmRewrite: {2} rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"
With this file in place, run:
$ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f add-rwm.ldif
Now, to trigger the crash:
$ ldapsearch -x -h localhost -b dc=example,dc=com -LLL uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/searchFilterAttrDN massage error
slapd process will die, and /var/crash will have a crash file for
slapd. You can run the following command to confirm the error:
$ cat /var/log/syslog | grep filter_free
Aug 9 19:51:05 popular-gorilla slapd[1479]: filter_free: unknown filter
type=28530
-> Expected behavior
In this test case, as mentioned before, the 'ldapsearch' command
should fail but the 'slapd' process should not die. As result, we
don't expect a slapd crash report in /var/crash directory.
[Regression Potential]
Since the fix is a patch provided by upstream (reviewed by maintainers
and us) simple mistakes like typos are not expected. The patch impacts
only the rwm module which is not loaded by default. So any regression
would affect only the users that make use of this overlay. If an user
is not using rwm overlay and is facing any issue, it should be related
to other problems related to LDAP directory services.
[Original message]
Hello!
We have faced slapd crash, seems an attacker was trying to brute force one
of our services and uid parsing failures caused slapd crash:
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH
base="ou=test,dc=test,dc=com" scope=2 deref=0
filter="(&(uid=aistar123<>!n)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid
userPassword uidNumber gidNumber gecos homeDirectory loginShell
krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp
shadowLastChange shadowMin shadow
Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
krbPasswordExpiration pwdAttribute authorizedService accountExpires
userAccountControl nsAccountLock host loginDisabled loginExpirationTime
loginAllowedTimeMap sshPublic
Key
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0
nentries=0 text=massaged filter parse error
Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip
7fc8d18ec512 sp 7fc8889e2810 error 4 in libc-2.23.so
[7fc8d1868000+1c]
Another faulty filter example:
filter="(&(uid=sql<>?)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0"
[Touch-packages] [Bug 1756595] Re: disk space info inadvertently provides all installed snaps
** Description changed: [Impact] When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1% /var/lib/lxd/storage-pools/default/containers/squid-ds216 /dev/loop0 83712 83712 0 100% /snap/core/4206 /dev/loop1 102144 102144 0 100% /snap/git-ubuntu/402 You can see I have the core snap at revision 4206, and git-ubuntu at revision 402. There are already many bug reports in launchpad where one can see this information. Granted, the user can review it, refuse to send this data, etc. This bug is about the unexpectedness of having that information in the disk space data. If the user sees a prompt like "Would you like to include disk free space information in your report?", or "Would you like to include the output of the df(1) command in your report?", that doesn't immediately translate to "Would you like to include disk free space information and a list of all installed snaps and their revision numbers in your report?". [Test case] - N/A + Do something that triggers the apport hook and make sure you don't see snaps in there. [Regression potential] Fix consists of adding -x squashfs to df output, so might hide other non-snap squashfs images. ** Description changed: [Impact] When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1%
[Touch-packages] [Bug 1803993] Re: Password appears on the VT1 screen
It would be good adding this information to the upstream bug tracker. -- 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/1803993 Title: Password appears on the VT1 screen Status in gdm3 package in Ubuntu: Invalid Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Bug description: [Impact] * The keyboard on the graphical login screen started on VT1 may stop working and or keypresses including passwords are leaked to the terminal console running 'behind' the graphical login screen or environment. [Test Case] * Reboot after installing the fixed systemd package. * Install sysdig * Start sysdig on a remote connection or on a terminal console: $ sudo sysdig evt.type=ioctl | grep request=4B4 * While sysdig is running log in and out 3 times in GDM and press a few keys in the graphical session to see if keyboard still works * Log in and out on an other terminal console, too, running a few commands while being logged in to ensure that keyboard is working. * Observe that on terminal consoles the monitored keyboard setter ioctl is called with argument=3, but where the graphical screen is active only argument=4 is used, unlike with the buggy version observed in https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/comments/14 [Regression Potential] * The fix checks the current keyboard mode of the VT and allows only safe mode switches. The potential regression could be not allowing a valid mode switch keeping a keyboard in a non-operational mode. Testing covers that by typing the keyboard. (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1831252] Re: panic=-1 is completely ignored by the initrd causing unexpected behaviour
This bug was fixed in the package initramfs-tools - 0.133ubuntu10
---
initramfs-tools (0.133ubuntu10) eoan; urgency=medium
* Add support for panic=-1 value (LP: #1831252)
-- Julian Andres Klode Thu, 05 Sep 2019 12:31:43
+0200
** Changed in: initramfs-tools (Ubuntu Eoan)
Status: New => Fix Released
--
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/1831252
Title:
panic=-1 is completely ignored by the initrd causing unexpected
behaviour
Status in initramfs-tools package in Ubuntu:
Fix Released
Status in initramfs-tools source package in Xenial:
New
Status in initramfs-tools source package in Bionic:
New
Status in initramfs-tools source package in Eoan:
Fix Released
Bug description:
in Ubuntu Core we default to using panic=-1 on the kernel command line
(documented at [1]) to speed up the auto-rollback mechanism of the
kernel. on a kernel level this works just fine and the system reboots
immediately ...
when in the initramfs during boot and a panic occurs, no reboot
happens at all, the initrd spawns a shell regardless of the panic=
value ...
this is caused by a filter in /usr/share/initramfs-tools/init
panic=*)
panic="${x#panic=}"
case ${panic} in
*[![:digit:].]*)
panic=
;;
esac
;;
this function only lets positive values through, else panic= simply
gets unset
the panic() function itself is also not capable of handling negative
values, it has a sleep call that interprets negative values as
commandline options instead of simply ignoring a negative sleep time
[2] (line 11).
the filter in the init script should allow the -1 value (to comply
with the kernel documentation and behaviour) and the panic() function
should properly skip the sleep call when a negative value for panic=
is set.
[1]
https://github.com/torvalds/linux/blob/v4.17/Documentation/admin-guide/kernel-parameters.txt#L2931
[2] https://paste.ubuntu.com/p/mswD8Cd869/
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831252/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1803993] Re: Password appears on the VT1 screen
> Looking at the discussion at https://gitlab.freedesktop.org/xorg/xserver/issues/857#note_201402 this might be a bug in plymouth which is supposedly fixed in plymouth 0.9.4. I noticed that, however that points to: https://gitlab.freedesktop.org/plymouth/plymouth/commit/28ee4012c94b4045b97e5a2a66f66b7688b2dff3 which was added to plymouth in the bug preceeding this one, bug 1767918 https://launchpad.net/ubuntu/+source/plymouth/0.9.3-1ubuntu7.18.04.1 so, that specific patch doesn't seem to fix it, or at least not entirely... -- 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/1803993 Title: Password appears on the VT1 screen Status in gdm3 package in Ubuntu: Invalid Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Bug description: [Impact] * The keyboard on the graphical login screen started on VT1 may stop working and or keypresses including passwords are leaked to the terminal console running 'behind' the graphical login screen or environment. [Test Case] * Reboot after installing the fixed systemd package. * Install sysdig * Start sysdig on a remote connection or on a terminal console: $ sudo sysdig evt.type=ioctl | grep request=4B4 * While sysdig is running log in and out 3 times in GDM and press a few keys in the graphical session to see if keyboard still works * Log in and out on an other terminal console, too, running a few commands while being logged in to ensure that keyboard is working. * Observe that on terminal consoles the monitored keyboard setter ioctl is called with argument=3, but where the graphical screen is active only argument=4 is used, unlike with the buggy version observed in https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/comments/14 [Regression Potential] * The fix checks the current keyboard mode of the VT and allows only safe mode switches. The potential regression could be not allowing a valid mode switch keeping a keyboard in a non-operational mode. Testing covers that by typing the keyboard. (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1803993] Re: Password appears on the VT1 screen
Looking at the discussion at https://gitlab.freedesktop.org/xorg/xserver/issues/857#note_201402 this might be a bug in plymouth which is supposedly fixed in plymouth 0.9.4. Could users who can reliably reproduce the issue post if they have plymouth installed and if so, which version? ** Bug watch added: gitlab.freedesktop.org/xorg/xserver/issues #857 https://gitlab.freedesktop.org/xorg/xserver/issues/857 -- 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/1803993 Title: Password appears on the VT1 screen Status in gdm3 package in Ubuntu: Invalid Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Bug description: [Impact] * The keyboard on the graphical login screen started on VT1 may stop working and or keypresses including passwords are leaked to the terminal console running 'behind' the graphical login screen or environment. [Test Case] * Reboot after installing the fixed systemd package. * Install sysdig * Start sysdig on a remote connection or on a terminal console: $ sudo sysdig evt.type=ioctl | grep request=4B4 * While sysdig is running log in and out 3 times in GDM and press a few keys in the graphical session to see if keyboard still works * Log in and out on an other terminal console, too, running a few commands while being logged in to ensure that keyboard is working. * Observe that on terminal consoles the monitored keyboard setter ioctl is called with argument=3, but where the graphical screen is active only argument=4 is used, unlike with the buggy version observed in https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/comments/14 [Regression Potential] * The fix checks the current keyboard mode of the VT and allows only safe mode switches. The potential regression could be not allowing a valid mode switch keeping a keyboard in a non-operational mode. Testing covers that by typing the keyboard. (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1803993] Re: Password appears on the VT1 screen
@rbalint if you can reliably reproduce the issue, it would probably be a good idea if you follow up on that upstream bug tracker -- 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/1803993 Title: Password appears on the VT1 screen Status in gdm3 package in Ubuntu: Invalid Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Bug description: [Impact] * The keyboard on the graphical login screen started on VT1 may stop working and or keypresses including passwords are leaked to the terminal console running 'behind' the graphical login screen or environment. [Test Case] * Reboot after installing the fixed systemd package. * Install sysdig * Start sysdig on a remote connection or on a terminal console: $ sudo sysdig evt.type=ioctl | grep request=4B4 * While sysdig is running log in and out 3 times in GDM and press a few keys in the graphical session to see if keyboard still works * Log in and out on an other terminal console, too, running a few commands while being logged in to ensure that keyboard is working. * Observe that on terminal consoles the monitored keyboard setter ioctl is called with argument=3, but where the graphical screen is active only argument=4 is used, unlike with the buggy version observed in https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/comments/14 [Regression Potential] * The fix checks the current keyboard mode of the VT and allows only safe mode switches. The potential regression could be not allowing a valid mode switch keeping a keyboard in a non-operational mode. Testing covers that by typing the keyboard. (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842118] Re: [FFe] Update tracker(-miners) to 2.3.0
I already did upload this, thanks!
** Changed in: tracker (Ubuntu)
Status: New => Fix Released
** Changed in: tracker-miners (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tracker in Ubuntu.
https://bugs.launchpad.net/bugs/1842118
Title:
[FFe] Update tracker(-miners) to 2.3.0
Status in tracker package in Ubuntu:
Fix Released
Status in tracker-miners package in Ubuntu:
Fix Released
Bug description:
Ubuntu is stuck with tracker 2.1.8 and tracker miners 2.1.6, while
GNOME 3.34 will ship versions 2.3.0 of both.
Main changes since archive version, in tracker:
- Support for storing Musicbrainz metadata in the multimedia ontology.
- Fix detection of files that need writeback
- Fix crashes and invalid memory writes
- Fixed initialization of virtual tables
- Fixed segmentation fault in libtracker-miner
- Don't try to create JSON-LD nodes with unsigned integers
- Handle correctly backreferences in TrackerResource tree
- Fixed handling doubles with exponents in SPARQL
- Don't limit to specific desktop environments
- Fix unichar unescaping
- Correctly Handle BIND in first place of a triples block
- Fix possible deadlock on WAL checkpoint
- Fix some double values not being deleted
- Fixed CHANGES_DONE_HINT handling in TrackerMonitor
- Ported data generator utilities to python3
- Ported functional tests to python3, reformatted to PEP-8
- Correctly apply ignored-directories-with-content filter on monitor updates
- Multiple memory leak and memory corruption fixes
- New SPARQL parser, able to generate SQL that is generally more readable
and at places performs better. Multiple buglets fixed in the process
- Much improved support of SPARQL1.1 features and syntax that was missing:
* Property paths: Allowing to match connectivity between two resources
by an arbitrary length path. There is a number of supported operators
(alternative, sequence, oneOrMany, ...) that can be combined, e.g:
SELECT ?s ?p { ?s ^(nfo:belongsToContainer*)/(nie:url|nie:title)
?p }
Only the negated path operator (!) is not supported at the
moment.
* Support for fully unrestricted queries, eg:
SELECT ?s ?p ?o { ?s ?p ?o } ORDER BY ?o ?p ?s
Queries with unrestricted predicate (?p in the example above) were
just supported in a very restricted set of situations. All those
limitations are gone.
* MINUS allows subtracting the solutions that match the given triples
template, eg:
SELECT ?s { ?s a nfo:Media } MINUS { ?s a nfo:MusicPiece }
- Support for prepared statements. TrackerSparqlStatement can be built
with SELECT queries containing (custom) ~var syntax, and updating
their values before obtaining a cursor.
- tracker-store now automatically shuts down on inactivity.
- More property paths supported, new operators supported are -, +, ? and |,
only the ! operator is not supported yet.
- Improve error handling in DBus backend
- New SPARQL parser, able to support more 1.1 features and generating
friendlier SQL at places. There is initial support for property
paths (/ and ^), and other missing 1.1 syntax (MINUS, SHA384, ...).
More improvements are expected to happen in the future thanks to this.
- Support for prepared statements. TrackerSparqlStatement can be built
with SELECT queries containing (custom) ~var syntax, and updating
their values before obtaining a cursor.
NEWS upstream file changes:
https://gitlab.gnome.org/GNOME/tracker/compare/2.1.8...2.2.99.0#9f621eb5fd3bcb2fa5c7bd228c9b1ad42edc46c8
While in tracker-miners:
- Support for reading Musicbrainz metadata from audio files.
- Tracker Writeback now uses GStreamer to write metadata to audio files,
instead of depending on taglib directly.
- Directories will now be ignored if they contain a file named `.nomedia`.
A file named `.trackerignore` has the same effect, but the `.nomedia` file
brings us in line with Android.
- Removed obsolete 'max-media-art-width' setting.
- Functional tests now use python3
- Fix text extractor handling of non-existent files
- Fix indexing of tracks in FLAC files
- Whitelist syscall fadvise64_64
- Fix failed functional tests being reported as successful
- Fixes to desktop file indexing
- The functionality of tracker-miner-apps has been adopted by
tracker-miner-fs/tracker-extract.
- Updated tracker-miner-fs and tracker-miner-rss to use TrackerResource
NEWS upstream file changes:
https://gitlab.gnome.org/GNOME/tracker-miners/compare/2.1.6...2.2.99.0#9f621eb5fd3bcb2fa5c7bd228c9b1ad42edc46c8
So changes are quite a lot and with lots of improvements, that it's
quite important to test a bit
[Touch-packages] [Bug 1829861] Re: handle TLS session renegotiation
Hello Julian, or anyone else affected, Accepted apt into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apt/1.6.12 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apt (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829861 Title: handle TLS session renegotiation Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Status in apt source package in Eoan: Fix Released Bug description: [Impact] TLS sessions can renegotiate keys, but APT does not support it; meaning their HTTPS connections stop working. [Test case] We don't really have a reproducer. You'd need a server that re-negotiates by path; e.g. because it requires a a certain client certificate for a certain path. We know it does not break other use cases, having run that for quite some time in eoan and Debian stretch, and the patch was tested by the patch submitter @ Akamai (see https://github.com/Debian/apt/pull/93). [Regression potential] - Could we get stuck on renegotiation? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838771] Re: http:Fix Host header in proxied https connections
Hello Eric, or anyone else affected, Accepted apt into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apt/1.6.12 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apt (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1838771 Title: http:Fix Host header in proxied https connections Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Bug description: [Impact] Currently CONNECT requests use the name of the proxy as Host value, instead of the origin server's name. According to RFC 2616 "The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL." The current implementation causes problems with some proxy vendors. This commit[0] fixes this. [0] - https://salsa.debian.org/apt- team/apt/commit/86d4d98060f36c7e71c34af20a1193a75496ef72#54d3193c5d10a0032c80c3a6d3f069507265547f [Test Case] Here's one reproducer an impacted user brought to my attention: # /etc/environment http_proxy="http://internal:8080; https_proxy="http://interal:8080; To support application development activities in-house, I had to configure Azure CLI APT repository following the instructions from "https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view =azure-cli-latest": $ sudo apt-get update $ sudo apt-get install curl apt-transport-https lsb-release gnupg $ curl -sL https://packages.microsoft.com/keys/microsoft.asc | \ $ gpg --dearmor | \ $ sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg > /dev/null $ AZ_REPO=$(lsb_release -cs) $ echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $ $ AZ_REPO main" | \ $ sudo tee /etc/apt/sources.list.d/azure-cli.list $ sudo apt update In the final "apt update" command, APT respects system-wide network proxy variables and successfully fetched Canonical repository data over HTTP. However, it was unable to fetch the newly added Microsoft packages repository served via HTTPS. By using Wireshark to examine the HTTPS request made by APT, the request body reveals as: CONNECT packages.microsoft.com:443 HTTP/1.1\r\n Host: internal:8080\r\n User-Agent: Debian APT-HTTP/1.3 (1.6.11)\r\n ... ... There also is an automated test case in the package that runs as part of autopkgtest that tests a scenario like this, see the commit. [Regression Potential] * Fix already in debian, and Eoan * Has been reviewed/approved by juliank * A test package (pre-sru) has been provided to an impacted user, and he confirms it solves the situation. [Other Info] # salsa $ git describe --contains 86d4d98060f36c7e71c34af20a1193a75496ef72 1.9.0~8 # rmadison apt => apt | 1.6.11 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x => apt | 1.8.1 | disco-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.9.1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1838771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1829860] Re: APT unlocks in same order as it locks
Hello Julian, or anyone else affected, Accepted apt into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apt/1.6.12 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apt (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- 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/1829860 Title: APT unlocks in same order as it locks Status in apt package in Ubuntu: Fix Released Status in apt source package in Xenial: New Status in apt source package in Bionic: Fix Committed Status in apt source package in Disco: Fix Committed Bug description: [Impact] APT releases the locks in the same order it acquires them, rather than reverse order. Given that we have no waiting for locks, this is not _super_ problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, rather than lock-frontend. [Test case] Watch lock release with strace and see that it unlocks the right way. [Regression potential] Some other locking races or something? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1756595] Re: disk space info inadvertently provides all installed snaps
Hello Andreas, or anyone else affected, Accepted apt into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apt/1.6.12 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apt (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- 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/1756595 Title: disk space info inadvertently provides all installed snaps Status in apport package in Ubuntu: Invalid Status in apt package in Ubuntu: Fix Released Status in apport source package in Bionic: Invalid Status in apt source package in Bionic: Fix Committed Status in apport source package in Disco: New Status in apt source package in Disco: Fix Committed Status in apport source package in Eoan: Invalid Status in apt source package in Eoan: Fix Released Bug description: [Impact] When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1% /var/lib/lxd/storage-pools/default/containers/squid-ds216 /dev/loop0 83712 83712 0 100% /snap/core/4206 /dev/loop1 102144 102144 0 100% /snap/git-ubuntu/402 You can see I have the core snap at revision 4206, and git-ubuntu at revision 402. There are already many bug reports in launchpad where one can see this information. Granted, the user can review it, refuse to send this data, etc. This bug is about the unexpectedness of having that information in the disk space data. If the user sees a prompt like "Would you like to include disk free space information in your report?", or "Would you like to include the output of the df(1) command in your report?", that doesn't immediately translate to "Would you like to include disk free space information and a list of all installed snaps and their revision numbers in your report?". [Test case] N/A [Regression potential] Fix consists of adding -x squashfs to df output, so might hide other non-snap squashfs images. To manage notifications about this bug go to:
[Touch-packages] [Bug 1800167] Re: fstrim: /var/spool/postfix/etc/sasldb2: not a directory
Forwarded upstream: https://github.com/karelzak/util-linux/issues/857 ** Bug watch added: github.com/karelzak/util-linux/issues #857 https://github.com/karelzak/util-linux/issues/857 -- 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/1800167 Title: fstrim: /var/spool/postfix/etc/sasldb2: not a directory Status in util-linux package in Ubuntu: New Bug description: I've started getting weekly cron emails starting on Oct 7, 2018 that say /etc/cron.weekly/fstrim: fstrim: /var/spool/postfix/etc/sasldb2: not a directory The previous week's email did not have any complaints from fstrim, and I'm not sure what changed since then. There was a kernel upgrade (to 4.4.0-137.163), maybe that's related? My /etc/fstab contains the following line /etc/sasldb2 /var/spool/postfix/etc/sasldb2 none bind 0 0 because I need postfix's smtpd to access /etc/sasldb2 inside the postfix chroot. FWIW the root partition (that contains /etc/sasldb2) on this server resides on a pair of SSDs (inside a raid1 LVM volume), but only since Sep 27 when I moved it there. I'm not sure it's relevant since, as I mentioned before, the weekly email on Sep 30 did not have any fstrim complaints, just the usual "new 18.04 LTS update available, consider upgrading". ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: util-linux 2.27.1-6ubuntu3.6 ProcVersionSignature: Ubuntu 4.4.0-138.164-generic 4.4.155 Uname: Linux 4.4.0-138-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Fri Oct 26 17:56:06 2018 SourcePackage: util-linux UpgradeStatus: Upgraded to xenial on 2016-11-07 (718 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1800167/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1813430] Re: fstrim.service should not run inside container
*** This bug is a duplicate of bug 1589289 *** https://bugs.launchpad.net/bugs/1589289 ** This bug has been marked a duplicate of bug 1589289 fstrim: cannot open /dev/.lxd-mounts: Permission denied -- 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/1813430 Title: fstrim.service should not run inside container Status in util-linux package in Ubuntu: New Bug description: On LXD containers, the fstrim.service will errored permanently. /sbin/fstrim -av fstrim: /: FITRIM ioctl failed: Operation not permitted The unit file should contain ConditionVirtualization=!container to prevent errors inside containers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1813430/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules
** Merge proposal linked:
https://code.launchpad.net/~fourdollars/ubuntu/+source/systemd/+git/systemd/+merge/372334
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1842651
Title:
Regression: after Uprade from udev_237-3ubuntu10.25 to
udev_237-3ubuntu10.26 network interfaces don't get renamed by 70
-persistent-network.rules
Status in OEM Priority Project:
In Progress
Status in systemd package in Ubuntu:
In Progress
Bug description:
[Impact]
* Many server users upgraded from previous Ubuntu LTS series, such as
14.04 and 16.04, will be affected by this regression.
* Because there is /etc/udev/rules/70-persistent-network.rules or
/etc/udev/rules.d/70-persistent-net.rules generated by
/lib/udev/write_net_rules left.
* The previous SRU commit of LP: #1837700 doesn't cover this
persistent network rule.
[Test Case]
* It needs to have two Ethernet devices and provides
/etc/udev/rules.d/70-persistent-net.rules as below.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
[Regression Potential]
* When users upgrade to next LTS 20.04, they may also encounter this
issue because Debian has dropped the same patch.
* We need to figure another way to avoid this regression for next LTS
20.04.
* Adding back the origial patch from Debian will casue another issue.
(LP: #1837700)
[Other Info]
Since the latest update from udev_237-3ubuntu10.25 and
systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and
systemd_237-3ubuntu10.26 the renaming of network interfaces by
/etc/udev/rules/70-persistent-network.rules does not work.
/etc/udev/rules/70-persistent-network.rules:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
/var/log/syslog:
systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File
exists
When I downgrade the packages to the version with 237-3ubuntu10.25 the
following messages are in /var/log/syslog:
Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2:
renamed from eth0
Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed
from eth1
The latest version does not rename the interfaces temporary if there
is a conflict!
Manually installing the old packages with
dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb
libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb
systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb
did fix the problem temporary.
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1842651/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules
** Description changed:
[Impact]
- * Many server users upgraded from previous Ubuntu LTS series, such as
+ * Many server users upgraded from previous Ubuntu LTS series, such as
14.04 and 16.04, will be affected by this regression.
- * Because there is /etc/udev/rules/70-persistent-network.rules or
+ * Because there is /etc/udev/rules/70-persistent-network.rules or
/etc/udev/rules.d/70-persistent-net.rules generated by
/lib/udev/write_net_rules left.
- * The previous SRU commit of LP: #1837700 doesn't cover this persistent
+ * The previous SRU commit of LP: #1837700 doesn't cover this persistent
network rule.
[Test Case]
- * It needs to have two Ethernet devices and provides
+ * It needs to have two Ethernet devices and provides
/etc/udev/rules.d/70-persistent-net.rules as below.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
[Regression Potential]
- * When users upgrade to 19.04/19.10/20.04, they may also encounter this
+ * When users upgrade to next LTS 20.04, they may also encounter this
issue because Debian has dropped the same patch.
- * We need to figure another way to avoid this regression for next LTS
+ * We need to figure another way to avoid this regression for next LTS
20.04.
- * Adding back the origial patch from Debian will casue another issue.
+ * Adding back the origial patch from Debian will casue another issue.
(LP: #1837700)
[Other Info]
-
- Since the latest update from udev_237-3ubuntu10.25 and
systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and systemd_237-3ubuntu10.26
the renaming of network interfaces by
/etc/udev/rules/70-persistent-network.rules does not work.
+
+ Since the latest update from udev_237-3ubuntu10.25 and
+ systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and
+ systemd_237-3ubuntu10.26 the renaming of network interfaces by
+ /etc/udev/rules/70-persistent-network.rules does not work.
/etc/udev/rules/70-persistent-network.rules:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
/var/log/syslog:
systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File
exists
When I downgrade the packages to the version with 237-3ubuntu10.25 the
following messages are in /var/log/syslog:
Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2:
renamed from eth0
Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed
from eth1
The latest version does not rename the interfaces temporary if there is
a conflict!
Manually installing the old packages with
dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb
libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb
systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb
did fix the problem temporary.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1842651
Title:
Regression: after Uprade from udev_237-3ubuntu10.25 to
udev_237-3ubuntu10.26 network interfaces don't get renamed by 70
-persistent-network.rules
Status in OEM Priority Project:
In Progress
Status in systemd package in Ubuntu:
In Progress
Bug description:
[Impact]
* Many server users upgraded from previous Ubuntu LTS series, such as
14.04 and 16.04, will be affected by this regression.
* Because there is /etc/udev/rules/70-persistent-network.rules or
/etc/udev/rules.d/70-persistent-net.rules generated by
/lib/udev/write_net_rules left.
* The previous SRU commit of LP: #1837700 doesn't cover this
persistent network rule.
[Test Case]
* It needs to have two Ethernet devices and provides
/etc/udev/rules.d/70-persistent-net.rules as below.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
[Regression Potential]
* When users upgrade to next LTS 20.04, they may also encounter this
issue because Debian has dropped the same patch.
* We need to figure another way to avoid this regression for next LTS
20.04.
* Adding back the origial patch from Debian will casue another issue.
(LP: #1837700)
[Other Info]
Since the latest update from udev_237-3ubuntu10.25 and
systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and
systemd_237-3ubuntu10.26 the renaming of network interfaces by
/etc/udev/rules/70-persistent-network.rules does not work.
/etc/udev/rules/70-persistent-network.rules:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add",
[Touch-packages] [Bug 1352975] Re: GUI symbol for Wi-fi in 14.10 shows not connected even when connected
Ubuntu 14.10 (utopic) reached end-of-life on July 23, 2015. This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue using a maintained version of Ubuntu please let us know. Paul White [Ubuntu Bug Squad] ** Changed in: hundredpapercuts Status: Confirmed => Incomplete ** Changed in: network-manager (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1352975 Title: GUI symbol for Wi-fi in 14.10 shows not connected even when connected Status in One Hundred Papercuts: Incomplete Status in network-manager package in Ubuntu: Incomplete Status in wifi-radar package in Ubuntu: Invalid Bug description: Using Ubuntu 14.10 alpha 2 with all updates. Clean install. Network manager 0.9.8.8-0ubuntu23 Wifi-card: Intel Wireless 7260 (Rev 73) The Wi-fi symbol in the top right corner does not indicate that it is connected to Wi-fi even when it is connected. (It shows a question mark instead) Expected behavior is that it would show signal strength, or at the very least "make it grey" and remove the question mark. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu23 ProcVersionSignature: Ubuntu 3.16.0-6.11-generic 3.16.0-rc7 Uname: Linux 3.16.0-6-generic x86_64 NonfreeKernelModules: fglrx ApportVersion: 2.14.5-0ubuntu3 Architecture: amd64 CurrentDesktop: GNOME Date: Tue Aug 5 17:42:57 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-08-05 (0 days ago) InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 (20140730) IpRoute: default via 192.168.0.1 dev wlan0 proto static 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.110 metric 9 SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH Wired connection 18b6987c1-3f15-4b41-be88-ea9f5ae9eff6 802-3-ethernet1407252000 ti. 05. aug. 2014 kl. 17.20 +0200 yes no /org/freedesktop/NetworkManager/Settings/1 Diskokatt 5Ghz6a2433b7-9e20-4c4a-9c9d-455fee3505ef 802-11-wireless 1407253201 ti. 05. aug. 2014 kl. 17.40 +0200 yes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetunavailable /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1352975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842651] Re: Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules
** Description changed:
- Since the latest update from udev_237-3ubuntu10.25 and
- systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and
- systemd_237-3ubuntu10.26 the renaming of network interfaces by
- /etc/udev/rules/70-persistent-network.rules does not work.
+ [Impact]
+
+ * Many server users upgraded from previous Ubuntu LTS series, such as
+ 14.04 and 16.04, will be affected by this regression.
+
+ * Because there is /etc/udev/rules/70-persistent-network.rules or
+ /etc/udev/rules.d/70-persistent-net.rules generated by
+ /lib/udev/write_net_rules left.
+
+ * The previous SRU commit of LP: #1837700 doesn't cover this persistent
+ network rule.
+
+ [Test Case]
+
+ * It needs to have two Ethernet devices and provides
+ /etc/udev/rules.d/70-persistent-net.rules as below.
+
+ SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
+ SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
+
+ [Regression Potential]
+
+ * When users upgrade to 19.04/19.10/20.04, they may also encounter this
+ issue because Debian has dropped the same patch.
+
+ * We need to figure another way to avoid this regression for next LTS
+ 20.04.
+
+ * Adding back the origial patch from Debian will casue another issue.
+ (LP: #1837700)
+
+ [Other Info]
+
+ Since the latest update from udev_237-3ubuntu10.25 and
systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and systemd_237-3ubuntu10.26
the renaming of network interfaces by
/etc/udev/rules/70-persistent-network.rules does not work.
/etc/udev/rules/70-persistent-network.rules:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
/var/log/syslog:
systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File
exists
When I downgrade the packages to the version with 237-3ubuntu10.25 the
following messages are in /var/log/syslog:
Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2:
renamed from eth0
Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed
from eth1
The latest version does not rename the interfaces temporary if there is
a conflict!
- Manually installing the old packages with
+ Manually installing the old packages with
dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb
libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb
systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb
did fix the problem temporary.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1842651
Title:
Regression: after Uprade from udev_237-3ubuntu10.25 to
udev_237-3ubuntu10.26 network interfaces don't get renamed by 70
-persistent-network.rules
Status in OEM Priority Project:
In Progress
Status in systemd package in Ubuntu:
In Progress
Bug description:
[Impact]
* Many server users upgraded from previous Ubuntu LTS series, such as
14.04 and 16.04, will be affected by this regression.
* Because there is /etc/udev/rules/70-persistent-network.rules or
/etc/udev/rules.d/70-persistent-net.rules generated by
/lib/udev/write_net_rules left.
* The previous SRU commit of LP: #1837700 doesn't cover this
persistent network rule.
[Test Case]
* It needs to have two Ethernet devices and provides
/etc/udev/rules.d/70-persistent-net.rules as below.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
[Regression Potential]
* When users upgrade to 19.04/19.10/20.04, they may also encounter
this issue because Debian has dropped the same patch.
* We need to figure another way to avoid this regression for next LTS
20.04.
* Adding back the origial patch from Debian will casue another issue.
(LP: #1837700)
[Other Info]
Since the latest update from udev_237-3ubuntu10.25 and
systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and systemd_237-3ubuntu10.26
the renaming of network interfaces by
/etc/udev/rules/70-persistent-network.rules does not work.
/etc/udev/rules/70-persistent-network.rules:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55",
NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56",
NAME="eth1"
/var/log/syslog:
systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File
exists
When I downgrade the packages to the version with 237-3ubuntu10.25 the
following messages are in /var/log/syslog:
Sep 4 13:10:09 brutus kernel: [4.518507] igb :04:00.0 rename2:
renamed from eth0
Sep 4 13:10:09 brutus kernel: [4.565081] igb :07:00.0 eth0: renamed
from eth1
The latest version
[Touch-packages] [Bug 1842902] [NEW] FFe: create zfs dataset for each user automatically
Public bug reported: Part of the zsys spec is creating/associating one user dataset for each HOME user. As zsys is an official experimentation for 19.10, we would like to include this feature in a safe way, and reachable for any tool creating users (adduser, gnome-control-center, ubiquity…). Those are using useradd under the scene. For this, the proposed implementation: - patch useradd trying to execute "zsys useradd create USER HOMEDIR". If zsys isn't present or zsys returns a status code != 0 (which will be the case if the running system isn't a zsys one: pure zfs or non zfs like / on ext4), it will fallback to mkdir. Then the code does the usual chmod() - patch usermod, trying as well to execute "zsys useradd rename-home OLDHOME NEWHOME". Same failing reason (not a zsys system, not installed, OLDHOME isn't a zsys handled datasets) and fallback to rename(). Then the code does the usual chmod(). Tested with and without zsys installed, the code does what we expect. I'm attaching the shadow (useradd/usermod) patches, as you can see it's very minimal. A new ZSYS release will be needed (https://github.com/ubuntu/zsys). As you can see, there are quite some commits since the last release, but it's all baked (as usual) by a huge suite of tests (in ZFS and machine layers) with corner cases tested and such. I'm confident on that change. ** Affects: shadow (Ubuntu) Importance: Undecided Status: New ** Affects: zsys (Ubuntu) Importance: Undecided Status: New ** Patch added: "1015_add_zsys_support.patch" https://bugs.launchpad.net/bugs/1842902/+attachment/5286949/+files/1015_add_zsys_support.patch ** Also affects: shadow (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1842902 Title: FFe: create zfs dataset for each user automatically Status in shadow package in Ubuntu: New Status in zsys package in Ubuntu: New Bug description: Part of the zsys spec is creating/associating one user dataset for each HOME user. As zsys is an official experimentation for 19.10, we would like to include this feature in a safe way, and reachable for any tool creating users (adduser, gnome-control-center, ubiquity…). Those are using useradd under the scene. For this, the proposed implementation: - patch useradd trying to execute "zsys useradd create USER HOMEDIR". If zsys isn't present or zsys returns a status code != 0 (which will be the case if the running system isn't a zsys one: pure zfs or non zfs like / on ext4), it will fallback to mkdir. Then the code does the usual chmod() - patch usermod, trying as well to execute "zsys useradd rename-home OLDHOME NEWHOME". Same failing reason (not a zsys system, not installed, OLDHOME isn't a zsys handled datasets) and fallback to rename(). Then the code does the usual chmod(). Tested with and without zsys installed, the code does what we expect. I'm attaching the shadow (useradd/usermod) patches, as you can see it's very minimal. A new ZSYS release will be needed (https://github.com/ubuntu/zsys). As you can see, there are quite some commits since the last release, but it's all baked (as usual) by a huge suite of tests (in ZFS and machine layers) with corner cases tested and such. I'm confident on that change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1842902/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1836979] Re: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed”
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: mesa (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1836979 Title: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed” Status in mesa package in Ubuntu: Confirmed Status in mesa source package in Bionic: Confirmed Bug description: Buggy as Kodi is, this seems to be a problem specifically with mesa- va-drivers. Kodi has worked just fine on my system, as recently as July 6th of this year, but yesterday (July 16) I tried Kodi again: I got a blank screen and a pause for a few moments, followed by an unceremonious crash-to-desktop. This happens every time I start Kodi, now. If I run it through the command-line, I get this: libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 kodi-x11: ../src/gallium/drivers/nouveau/nouveau_vp3_video.c:91: nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed. Aborted (core dumped) I’ve been using the same version of Kodi (“18.3 Git:20190621-89472b7”, package version 2:18.3+git20190621.1610-final-0bionic, from the Team- XBMC PPA) since its release in June, but in between July 6th and 16th, I did upgrade the Mesa packages, from 18.2.8-0ubuntu0~18.04.2 19.0.2-1ubuntu1.1~18.04.1. If I downgrade the “mesa-va-drivers” package to 18.0.0~rc5-1ubuntu1 (the version in the base, non-updates Bionic repository), however, Kodi works again, without even requiring me to restart my machine. So, this is likely a problem with “mesa-va- drivers”. I tried looking in Xorg.0.log: [ 17185.557] (II) NOUVEAU(0): EDID vendor "SEC", prod id 12620 [ 17185.557] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 17185.558] (II) NOUVEAU(0): Modeline "1366x768"x0.0 72.33 1366 1414 1446 1526 768 770 775 790 -hsync -vsync (47.4 kHz eP) …that’s all that appears in the log when I try to load Kodi and a crash happens. I’m using Ubuntu MATE 18.04.2 LTS 64-bit on a Compaq Presario CQ60; if you need more information, I’ve attached a hardinfo report, too. I hope this bug can get fixed, soon. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1836979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1768230] Re: Long time booting : Failed to connect to lvmetad. Falling back to device scanning.
Resolved by tossing the entire VM and then performing a fresh install of the latest Ubuntu Desktop 18.04 with default deviations: - minimal installation - NO LVM (this is the default selection) - do NOT install updates while installing -- 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/1768230 Title: Long time booting : Failed to connect to lvmetad. Falling back to device scanning. Status in initramfs-tools package in Ubuntu: Fix Released Status in ubiquity package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Fix Released Status in ubiquity source package in Bionic: Fix Released Bug description: [SRU Justification] A regression in initramfs-tools causes it to autogenerate config in the initramfs saying to resume from any available swap devices, but references the swap device by UUID, which is not a canonical form for referring to LVM volumes (because of snapshotting, they are not unique). Ubiquity also generates a file in /etc at install time which references the swap partition in the same way. Since the lvm2 initramfs hooks also only activate precisely those LVs that are detected as needed at boot, this adds an inappropriate 30-second boot delay to any system with swap on LVM, which includes any desktop system that was configured with LVM (but not full-disk encryption) at install time. [Test case] 1. Install using the "Use LVM" option in the desktop installer. 4. Reboot. 5. Verify that dmesg shows a 30-second delay before mounting the root filesystem. 6. Install initramfs-tools from bionic-proposed. 7. Reboot. 8. Verify that dmesg no longer shows a 30-second delay before mounting the root filesystem. 9. Install using the bionic daily image that contains the ubiquity from bionic-proposed. 10. Reboot. 11. Verify that /etc/initramfs-tools/conf.d/resume is not present and that there is no delay before mounting the root filesystem. [Regression potential] This makes changes to shell scripts, and shell is a perilous language. An unnoticed bug could cause all initramfs generation, and thus all kernel installation, to fail for some users. A regression could also cause a user to lose hiberation support that they currently have. [Original description] After choosing "Erase disk and install ubuntu" + "Use LVM with the new Ubuntu installation", the system is very slow to reboot. It shows the message : "WARNING:Failed to connect to lvmetad. Falling back to device scanning.", then waits 32 seconds, then continues as it should. I think this is a ubiquity bug, since the d-i based installer is not affected. - ubuntu-18.04-desktop-amd64.iso (a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34) : affected - xubuntu-18.04-desktop-amd64.iso (7c24318d3b1de1efd584b5aea034ce1aafd2d0f06c59812d989a5fc95bf947e3) : affected - ubuntu-18.04-server-amd64.iso (a7f5c7b0cdd0e9560d78f1e47660e066353bb8a79eb78d1fc3f4ea62a07e6cbc) : not affected To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768230/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
