[Touch-packages] [Bug 1902109] [NEW] rsync uses lchmod and fails in Ubuntu >= 20.10
Public bug reported:
Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it
returned "no" before.
Steps to reproduce:
# Emulate /proc not being mounted
$ mount --bind / /mnt
$ chroot /mnt rsync -a /bin/ls .
rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not
supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code
3) at main.c(1330) [sender=3.2.3]
I reported this issue upstream in
https://github.com/WayneD/rsync/issues/109 but the rsync developer says
it's a problem in libc, and it might well be.
Simple C code to reproduce the problem without rsync:
printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));
If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails when
/proc isn't mounted, yet it succeeds if it is mounted.
Python had a similar issue, and they ended up avoiding
AC_CHECK_FUNC(lchmod) under Linux:
https://bugs.python.org/issue34652
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140
```c
if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
fi
```
So I'm not sure which package is causing the bug here. Should autoconf
return false? Should libc implement lchown without the bug? Or should
rsync skip lchmod under Linux, like python did?
** Affects: rsync (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1902109
Title:
rsync uses lchmod and fails in Ubuntu >= 20.10
Status in rsync package in Ubuntu:
New
Bug description:
Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it
returned "no" before.
Steps to reproduce:
# Emulate /proc not being mounted
$ mount --bind / /mnt
$ chroot /mnt rsync -a /bin/ls .
rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not
supported (95)
rsync error: some files/attrs were not transferred (see previous errors)
(code 3) at main.c(1330) [sender=3.2.3]
I reported this issue upstream in
https://github.com/WayneD/rsync/issues/109 but the rsync developer
says it's a problem in libc, and it might well be.
Simple C code to reproduce the problem without rsync:
printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));
If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails
when /proc isn't mounted, yet it succeeds if it is mounted.
Python had a similar issue, and they ended up avoiding
AC_CHECK_FUNC(lchmod) under Linux:
https://bugs.python.org/issue34652
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140
```c
if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
fi
```
So I'm not sure which package is causing the bug here. Should autoconf
return false? Should libc implement lchown without the bug? Or should
rsync skip lchmod under Linux, like python did?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1902109/+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 1662244] Re: lightdm causes all greeters to fail to start
What torel proposed in https://bugs.launchpad.net/ubuntu/+source/unity- greeter/+bug/1662244/comments/14 avoids the segfault: * soft memlock 262144 * hard memlock 262144 Should all lightdm users manually put that in limits.conf, or should we expect some update? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1662244 Title: lightdm causes all greeters to fail to start Status in Light Display Manager: Invalid Status in LightDM GTK+ Greeter: Invalid Status in lightdm package in Ubuntu: Invalid Status in unity-greeter package in Ubuntu: Invalid Bug description: lightdm is failing to start. Best guess is because of unity-session- manager. This is from .xsession-errors. dbus-update-activation-environment: setting _=/usr/bin/dbus-update-activation-environment upstart: click-user-hooks main process (4028) terminated with status 1 upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon respawning too fast, stopped upstart: indicator-application main process ended, respawning upstart: indicator-application main process ended, respawning upstart: indicator-application respawning too fast, stopped xbrlapi: window 0x03a00084 changed to NULL name xbrlapi: window 0x03a00084 changed to NULL name xbrlapi: window 0x03c00084 changed to NULL name xbrlapi: window 0x03c00084 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name upstart: dbus main process (4023) killed by TERM signal I've tried to move aside $HOME/.config/dconf/user and that didn't work. I've reverted kernel versions and that didn't work. I've moved aside $HOME/.cache and that didn't work. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: lightdm 1.19.5-0ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-30.32-generic 4.8.6 Uname: Linux 4.8.0-30-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 Date: Mon Feb 6 10:21:29 2017 InstallationDate: Installed on 2015-07-20 (566 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: lightdm UpgradeStatus: Upgraded to yakkety on 2016-12-14 (53 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1662244/+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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)
Thank you Łukasz, I filed it in LP: #1902879.
--
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/1830746
Title:
memlock setting in systemd (pid 1) too low for containers (bionic)
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Cosmic:
Won't Fix
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in systemd source package in Focal:
Fix Released
Bug description:
[Impact]
* Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb],
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an
adjustable limit, but the default (in previous Ubuntu releases/systemd
versions) was really small.
* Although bumping this value was a good thing, 16M is not enough and we can
see failures on mlock'ed allocations on Bionic, like the one hereby reported by
Kees or the recent introduced cryptsetup build failures (due to PPA builder
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.
* It's especially harmful in containers to have such "small" limit, so
we are hereby SRUing a more recent bump from upstream systemd, in the
form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
[https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
releases, like Focal and subsequent ones, already include this patch
so effectively we're putting Bionic on-par with newer releases.
* A discussion about this topic (leading to this SRU) is present in
ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
devel/2020-September/041159.html.
[Test Case]
* The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a
current Bionic system, and then install an updated version with the hereby
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely
to be deleted in next month or so).
* A more interesting test is to run a Focal container in a current
Bionic system and try to build the cryptsetup package - it'll fail in
some tests. After updating the host (Bionic) systemd to include the
mlock bump patch, the build succeeds in the Focal container.
[Regression Potential]
* Since it's a simple bump and it makes Bionic behave like Focal, I don't
foresee regressions. One potential issue would be if some users rely on the
lower default limit (16M) and this value is bumped by a package update, but
that could be circumvented by setting a lower limit in limits.conf. The
benefits for such bump are likely much bigger than any "regression" caused for
users relying on such default limit.
[0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)
Hi, this update makes slick-greeter segfault, so Ubuntu MATE 18.04 users
doing normal updates now get a black screen with a flicking cursor.
A temporary workaround is to enable autologin in
/etc/lightdm/lightdm.conf:
[Seat:*]
autologin-guest=false
autologin-user=administrator
autologin-user-timeout=0
*** What would be a proper fix for this? ***
A related discussion about memory limits and lightdm issues exists in this bug
report:
https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1662244
--
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/1830746
Title:
memlock setting in systemd (pid 1) too low for containers (bionic)
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Cosmic:
Won't Fix
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in systemd source package in Focal:
Fix Released
Bug description:
[Impact]
* Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb],
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an
adjustable limit, but the default (in previous Ubuntu releases/systemd
versions) was really small.
* Although bumping this value was a good thing, 16M is not enough and we can
see failures on mlock'ed allocations on Bionic, like the one hereby reported by
Kees or the recent introduced cryptsetup build failures (due to PPA builder
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.
* It's especially harmful in containers to have such "small" limit, so
we are hereby SRUing a more recent bump from upstream systemd, in the
form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
[https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
releases, like Focal and subsequent ones, already include this patch
so effectively we're putting Bionic on-par with newer releases.
* A discussion about this topic (leading to this SRU) is present in
ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
devel/2020-September/041159.html.
[Test Case]
* The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a
current Bionic system, and then install an updated version with the hereby
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely
to be deleted in next month or so).
* A more interesting test is to run a Focal container in a current
Bionic system and try to build the cryptsetup package - it'll fail in
some tests. After updating the host (Bionic) systemd to include the
mlock bump patch, the build succeeds in the Focal container.
[Regression Potential]
* Since it's a simple bump and it makes Bionic behave like Focal, I don't
foresee regressions. One potential issue would be if some users rely on the
lower default limit (16M) and this value is bumped by a package update, but
that could be circumvented by setting a lower limit in limits.conf. The
benefits for such bump are likely much bigger than any "regression" caused for
users relying on such default limit.
[0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 1662244] Re: lightdm causes all greeters to fail to start
Hi, a recent systemd update in 18.04 makes slick-greeter segfault. So all Ubuntu MATE 18.04 users now get black screens instead of lightdm. It's related to memory limits so I'm cross-referencing it here: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746 This didn't help: [LightDM] lock-memory=false Can I put something in /etc/security/limits.conf to see if it helps? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1662244 Title: lightdm causes all greeters to fail to start Status in Light Display Manager: Invalid Status in LightDM GTK+ Greeter: Invalid Status in lightdm package in Ubuntu: Invalid Status in unity-greeter package in Ubuntu: Invalid Bug description: lightdm is failing to start. Best guess is because of unity-session- manager. This is from .xsession-errors. dbus-update-activation-environment: setting _=/usr/bin/dbus-update-activation-environment upstart: click-user-hooks main process (4028) terminated with status 1 upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon main process ended, respawning upstart: unity-settings-daemon respawning too fast, stopped upstart: indicator-application main process ended, respawning upstart: indicator-application main process ended, respawning upstart: indicator-application respawning too fast, stopped xbrlapi: window 0x03a00084 changed to NULL name xbrlapi: window 0x03a00084 changed to NULL name xbrlapi: window 0x03c00084 changed to NULL name xbrlapi: window 0x03c00084 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name xbrlapi: window 0x0484 changed to NULL name upstart: dbus main process (4023) killed by TERM signal I've tried to move aside $HOME/.config/dconf/user and that didn't work. I've reverted kernel versions and that didn't work. I've moved aside $HOME/.cache and that didn't work. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: lightdm 1.19.5-0ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-30.32-generic 4.8.6 Uname: Linux 4.8.0-30-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.3-0ubuntu8.2 Architecture: amd64 Date: Mon Feb 6 10:21:29 2017 InstallationDate: Installed on 2015-07-20 (566 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) SourcePackage: lightdm UpgradeStatus: Upgraded to yakkety on 2016-12-14 (53 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1662244/+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 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)
What torel proposed in https://bugs.launchpad.net/ubuntu/+source/unity-
greeter/+bug/1662244/comments/14 avoids the segfault:
* soft memlock 262144
* hard memlock 262144
Should all lightdm users manually put that in limits.conf, or should we
expect some update?
--
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/1830746
Title:
memlock setting in systemd (pid 1) too low for containers (bionic)
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Cosmic:
Won't Fix
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in systemd source package in Focal:
Fix Released
Bug description:
[Impact]
* Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb],
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an
adjustable limit, but the default (in previous Ubuntu releases/systemd
versions) was really small.
* Although bumping this value was a good thing, 16M is not enough and we can
see failures on mlock'ed allocations on Bionic, like the one hereby reported by
Kees or the recent introduced cryptsetup build failures (due to PPA builder
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.
* It's especially harmful in containers to have such "small" limit, so
we are hereby SRUing a more recent bump from upstream systemd, in the
form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
[https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
releases, like Focal and subsequent ones, already include this patch
so effectively we're putting Bionic on-par with newer releases.
* A discussion about this topic (leading to this SRU) is present in
ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
devel/2020-September/041159.html.
[Test Case]
* The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a
current Bionic system, and then install an updated version with the hereby
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely
to be deleted in next month or so).
* A more interesting test is to run a Focal container in a current
Bionic system and try to build the cryptsetup package - it'll fail in
some tests. After updating the host (Bionic) systemd to include the
mlock bump patch, the build succeeds in the Focal container.
[Regression Potential]
* Since it's a simple bump and it makes Bionic behave like Focal, I don't
foresee regressions. One potential issue would be if some users rely on the
lower default limit (16M) and this value is bumped by a package update, but
that could be circumvented by setting a lower limit in limits.conf. The
benefits for such bump are likely much bigger than any "regression" caused for
users relying on such default limit.
[0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 206924] Re: Make it possible to create a guest account
** No longer affects: ltsp -- 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/206924 Title: Make it possible to create a guest account Status in accountsservice: Confirmed Status in gdm: Fix Released Status in GNOME Shutdown: Fix Released Status in Xubuntu: New Status in accountsservice package in Ubuntu: Confirmed Status in kde-workspace package in Ubuntu: Won't Fix Status in lxdm package in Ubuntu: Opinion Status in sdm package in Ubuntu: Opinion Status in slim package in Ubuntu: Opinion Status in wdm package in Ubuntu: Opinion Status in wing package in Ubuntu: Opinion Status in xdm package in Ubuntu: Won't Fix Bug description: Make a guest account that people can login to, and check their mail, surf web, etc. Every time the guest account logs out, its purged so the next user who login is a clean fresh account. This would be great in public terminals, libraries, hotels, lobbys, etc. To manage notifications about this bug go to: https://bugs.launchpad.net/accountsservice/+bug/206924/+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 1772859] Re: Network Manager is not able to manage the devices on Ubuntu 18.04
While working on a remote server, it took me 2-3 hours to locate this bug report and apply its workarounds. It's certainly not a good default behavior. In case someone has already removed netplan, the recommended steps to get network-manager to manage the interfaces, as I understood them, are: ``` sudo -i apt install ubuntu-minimal echo "# Let NetworkManager manage all devices on this system network: version: 2 renderer: NetworkManager" >/etc/netplan/01-network-manager-all.yaml update-initramfs -u # Not sure if this is needed or not reboot ``` I.e. I think that /etc/netplan/01-network-manager-all.yaml comes from some installer and it's not part of some package and it needs to be manually re-created. -- 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/1772859 Title: Network Manager is not able to manage the devices on Ubuntu 18.04 Status in Ubuntu on IBM z Systems: Invalid Status in network-manager package in Ubuntu: Invalid Bug description: NetworkManager is not able to manage the devices on latest Ubuntu(18.04) ---uname output--- Linux (none) 4.15.0-12-generic #13-Ubuntu SMP Wed Mar 7 21:36:36 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = z14 s390 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Install the latest Ubuntu(18.04) with Network Manager(1.10.4). 2. Configure a network device and login to the partition through ssh. 3. Now you can see the following output root@(none):~# nmcli d s DEVICE TYPE STATE CONNECTION eth0ethernet unmanaged -- eth1ethernet unmanaged -- lo loopback unmanaged -- Userspace tool common name: 1.10.6-2ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The userspace tool has the following bit modes: 64-bit Userspace rpm: NetworkManager --version 1.10.4 Userspace tool obtained from project website: na Some more information about the issue: Network device has been configured manually after the image is up from Support Element(SE): - znetconf -a - cat /sys/bus/ccwgroup/drivers/qeth//if_name - ifconfig netmask 255.255.255.0 - route add default gw - SSH service has been configured This helped us to login to the Lpar. In Lpar - output of znetconf -c Device IDs TypeCard Type CHPID Drv. Name State - 0.0.1a80,0.0.1a81,0.0.1a82 1731/01 OSD_10GIG A8 qeth eth0 online 0.0.1810,0.0.1811,0.0.1812 1731/01 OSD_1000 D0 qeth eth1 online - output of nmcli c s root@(none):~# nmcli c s NAME UUID TYPE DEVICE - output of nmcli d s root@(none):~# nmcli d s DEVICE TYPE STATE CONNECTION eth0ethernet unmanaged -- eth1ethernet unmanaged -- lo loopback unmanaged -- * The above output shows that devices are not managed by nmcli After some investigation we found couple of suggestions like 1. Ubuntu(version <17.04): Creating an empty file(/etc/NetworkManager/conf.d/10-globally-managed-devices.conf) and restarting NM, solved the issue. 2. Ubuntu(version 17.10): Copying the said file(10-globally-managed-devices.conf) from /usr/lib to /etc/ and modifying the "unmanaged-devices" to none, resolved the issue. * link for reference: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1638842 For the latest version(18.04), none of the above solutions worked. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1772859/+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 1892014] Re: 18.04.14.7 regression: no alt_shift_toggle in XKBOPTIONS
The issue is still there in today's Ubuntu MATE 22.04 daily built.
Greeks cannot even type their names in the installer (ubiquity)...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to console-setup in Ubuntu.
https://bugs.launchpad.net/bugs/1892014
Title:
18.04.14.7 regression: no alt_shift_toggle in XKBOPTIONS
Status in console-setup package in Ubuntu:
Confirmed
Status in ubiquity package in Ubuntu:
Confirmed
Bug description:
Up to ubuntu-mate-18.04.1.iso, everything was fine. Starting with
18.04.2, XKB_OPTIONS does not contain "alt_shift_toggle" anymore and
we cannot switch the keyboard layout to e.g. Greek using Alt+Shift.
Reading the changelog, I see:
$ ~/source/ubiquity$ git show 786a5325ef
+console-setup (1.178ubuntu6) cosmic; urgency=medium
+
+ * keyboard-configuration.{config,templates}: There is no good default for
+layout toggling, stop pretending there is. Console users can set one
+with dpkg-reconfigure or editing /etc/defaults/keyboard (LP: #1762952)
I'm guessing that ubiquity duplicates some code from console-setup,
and LP: #1762952 caused this regression.
To reproduce:
1) Start ubuntu-mate-18.04.1-desktop-amd64.iso
2) Select Ελληνικά (Greek) and start installing Ubuntu using the default
options
3) Right after the keyboard layout step, run:
$ grep XKBOPTIONS /etc/default/keyboard
XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll"
4) Verify that you can switch to Greek with Alt+Shift
Starting from ubuntu-mate-18.04.2-desktop-amd64.iso (.1=OK, .2=BAD), we
cannot switch to Greek using Alt+Shift anymore:
$ grep XKBOPTIONS /etc/default/keyboard
XKBOPTIONS="grp_led:scroll"
Does ubiquity really expect the users to run `dpkg-reconfigure
console-setup`?
Note that selecting Greek in the syslinux menu produces the correct
XKBOPTIONS, yet ubiquity overwrites them later on with the wrong ones.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1892014/+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 964705] Re: System policy prevents modification of network settings for all users
My problem is a bit different: everything works fine, but the dialog appears when we ACTIVATE a VPN connection, even if we don't want to modify it. 1) I've prepared a VPN connection for my non-admin users and put it in /etc/NetworkManager/system-connections/vpn.nmconnection. 2) When they click to activate it, they get the "System policy prevents..." dialog. 3a) If I do enter the root password there, the vpn.nmconnection file isn't modified. Why did it ask for permission then? 3b) If the users cancel the dialog (twice), they're able to properly connect to the VPN. Why did it show up then? That's on fully updated Ubuntu 20.04.4. -- 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/964705 Title: System policy prevents modification of network settings for all users Status in NetworkManager: Invalid Status in network-manager package in Ubuntu: Confirmed Status in network-manager package in Debian: Fix Released Status in network-manager package in openSUSE: Fix Released Bug description: This seems like a regression? The screen shot is at http://thesii.org/Screenshot.jpg The nearest link I can find is from the forum area at http://ubuntuforums.org/showthread.php?p=1146 ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1 ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12 Uname: Linux 3.2.0-20-generic x86_64 ApportVersion: 1.95-0ubuntu1 Architecture: amd64 CRDA: Error: [Errno 2] No such file or directory Date: Sun Mar 25 19:36:45 2012 IfupdownConfig: auto lo iface lo inet loopback InstallationMedia: Lubuntu 12.04 "Precise Pangolin" - Alpha amd64 (20120323) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true ProcEnviron: LANGUAGE=en_GB:en TERM=xterm LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/964705/+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 2041491] [NEW] Provide an option to avoid the yaml NM backend
Public bug reported: Hi, recently netplan added support for a yaml NM backend: https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml- settings/32420 The rationale is that "the descriptive YAML layer is especially useful in cloud environments": https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556 It's great that you care about that user group! Please also care for the rest of us that do not use cloud environments! For example, I routinely review, clone, backup or even directly edit the /etc/NetworkManager/system-connections files in my desktops and servers, in all distributions. Having an Ubuntu-specific way to do things will make things harder for me. I will have to learn a new Ubuntu-specific syntax, develop scripts and methods to convert my connections between distributions, I will need to discover and report bugs in the netplan <=> nm mapping etc... I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide a unified yaml-based experience for cloud-init etc. But Ubuntu is also great outside the cloud; please allow us to continue having a unified experience between distributions (i.e. directly using nm or systemd-networkd) without enforcing an Ubuntu-specific way of doing things (netplan) to us. For Ubuntu 24.04+, please provide an option to avoid the yaml NM backend, thank you very much! ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New -- 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/2041491 Title: Provide an option to avoid the yaml NM backend Status in network-manager package in Ubuntu: New Bug description: Hi, recently netplan added support for a yaml NM backend: https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml- settings/32420 The rationale is that "the descriptive YAML layer is especially useful in cloud environments": https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556 It's great that you care about that user group! Please also care for the rest of us that do not use cloud environments! For example, I routinely review, clone, backup or even directly edit the /etc/NetworkManager/system-connections files in my desktops and servers, in all distributions. Having an Ubuntu-specific way to do things will make things harder for me. I will have to learn a new Ubuntu-specific syntax, develop scripts and methods to convert my connections between distributions, I will need to discover and report bugs in the netplan <=> nm mapping etc... I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide a unified yaml-based experience for cloud-init etc. But Ubuntu is also great outside the cloud; please allow us to continue having a unified experience between distributions (i.e. directly using nm or systemd-networkd) without enforcing an Ubuntu-specific way of doing things (netplan) to us. For Ubuntu 24.04+, please provide an option to avoid the yaml NM backend, thank you very much! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2041491/+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 2041707] [NEW] Phased updates block release upgrades
Public bug reported: I updated my Kubuntu 23.04 to 23.10 using do-release-upgrade. It finished 100% successfully. But after rebooting into 23.10, I noticed that network-manager was kept back to the 23.04 version due to phased updates. Specifically: # apt policy network-manager network-manager: Installed: 1.42.4-1ubuntu2 Candidate: 1.44.2-1ubuntu1.2 Version table: 1.44.2-1ubuntu1.2 500 (phased 70%) 500 http://gr.archive.ubuntu.com/ubuntu mantic-updates/main amd64 Packages 1.44.2-1ubuntu1 500 500 http://gr.archive.ubuntu.com/ubuntu mantic/main amd64 Packages *** 1.42.4-1ubuntu2 100 100 /var/lib/dpkg/status I.e. the phased version (1.44.2-1ubuntu1.2) prevents me from getting the current mantic version (1.44.2-1ubuntu1) and I'm stuck with the lunar version (1.42.4-1ubuntu2). ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- 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/2041707 Title: Phased updates block release upgrades Status in apt package in Ubuntu: New Bug description: I updated my Kubuntu 23.04 to 23.10 using do-release-upgrade. It finished 100% successfully. But after rebooting into 23.10, I noticed that network-manager was kept back to the 23.04 version due to phased updates. Specifically: # apt policy network-manager network-manager: Installed: 1.42.4-1ubuntu2 Candidate: 1.44.2-1ubuntu1.2 Version table: 1.44.2-1ubuntu1.2 500 (phased 70%) 500 http://gr.archive.ubuntu.com/ubuntu mantic-updates/main amd64 Packages 1.44.2-1ubuntu1 500 500 http://gr.archive.ubuntu.com/ubuntu mantic/main amd64 Packages *** 1.42.4-1ubuntu2 100 100 /var/lib/dpkg/status I.e. the phased version (1.44.2-1ubuntu1.2) prevents me from getting the current mantic version (1.44.2-1ubuntu1) and I'm stuck with the lunar version (1.42.4-1ubuntu2). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2041707/+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 2041491] Re: Provide an option to avoid the yaml NM backend
Thank you; if I understood correctly, that method would render all the NM GUI/console tools unusable; it's not a viable workaround, as I would like to be able to use these tools as well... E.g.: - Create a new bond => GUI, nmtui, nmcli - Did I forget any setting while creating that bond? Let's compare it with a Debian box => `meld ubuntu-box:/etc/NetworkManager/system-connections debian-box:/etc/NetworkManager/system-connections` -- 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/2041491 Title: Provide an option to avoid the yaml NM backend Status in netplan.io package in Ubuntu: New Status in network-manager package in Ubuntu: New Bug description: Hi, recently netplan added support for a yaml NM backend: https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml- settings/32420 The rationale is that "the descriptive YAML layer is especially useful in cloud environments": https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556 It's great that you care about that user group! Please also care for the rest of us that do not use cloud environments! For example, I routinely review, clone, backup or even directly edit the /etc/NetworkManager/system-connections files in my desktops and servers, in all distributions. Having an Ubuntu-specific way to do things will make things harder for me. I will have to learn a new Ubuntu-specific syntax, develop scripts and methods to convert my connections between distributions, I will need to discover and report bugs in the netplan <=> nm mapping etc... I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide a unified yaml-based experience for cloud-init etc. But Ubuntu is also great outside the cloud; please allow us to continue having a unified experience between distributions (i.e. directly using nm or systemd-networkd) without enforcing an Ubuntu-specific way of doing things (netplan) to us. For Ubuntu 24.04+, please provide an option to avoid the yaml NM backend, thank you very much! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+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 1982218] Re: wait-online does not correctly identify managed links
I too got affected by this regression. On servers with network-manager, without netplan (01-network-manager-all.yaml), systemd-networkd-wait-online.service started failing after the latest updates and leaves systemd in a degraded state. Example: root@gldap:/var/log/apt# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens18: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:10:20:64 brd ff:ff:ff:ff:ff:ff altname enp0s18 inet 10.16.32.100/21 brd 10.16.39.255 scope global noprefixroute ens18 valid_lft forever preferred_lft forever inet6 fe80::843e:3702:1c3b:2854/64 scope link noprefixroute valid_lft forever preferred_lft forever root@gldap:~# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 loloopback carrier unmanaged 2 ens18 etherroutableunmanaged 2 links listed. root@gldap:~# /lib/systemd/systemd-networkd-wait-online --any --timeout=5 Timeout occurred while waiting for network connectivity. -- 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/1982218 Title: wait-online does not correctly identify managed links Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Status in systemd source package in Lunar: Fix Released Bug description: [Impact] systemd-networkd-wait-online will exit prematurely when the --any flag is passed, due to an incorrect patch in Ubuntu that is supposed to make systemd-networkd-wait-online exit when *no* links are managed. [Test Plan] This test uses a VM managed by libvirt. In this scenario we have the "default" network which provides DHCP to the VM, and the "no-dhcp" network which does not provide DHCP. To setup the VM (this assumes Jammy, but the same steps apply for Lunar using appropriate names and install media): 1. Define the default and no-dhcp networks: $ cat > /tmp/net-default.xml << EOF default 04260896-2701-422d-84e0-8e0df1122db3 $ virsh net-create --file /tmp/net-default.xml $ cat > /tmp/net-default.xml << EOF no-dhcp 2c047740-caab-4c90-8421-70da6732a759 $ virsh net-create --file /tmp/net-no-dhcp.xml $ virsh net-start --network default $ virst net-start --network no-dhcp 2. Create the VM using virt-install: virt-install \ --connect=qemu:///system \ --name=jammy \ --arch=x86_64 \ --cpu=host-passthrough \ --ram=4096 \ --vcpus=1 \ --disk=path=/var/lib/libvirt/images/jammy.qcow2,size=24,format=qcow2,sparse=true,bus=virtio \ --virt-type=kvm \ --accelerate \ --hvm \ --cdrom=/tmp/ubuntu-22.04.2-live-server-amd64.iso \ --os-type=linux \ --os-variant=generic \ --graphics=spice \ --input=tablet \ --network=network=default,model=virtio \ --video=qxl \ --noreboot 3. Complete the installation steps. Reboot the VM. Run the test: 1. Detach the network interface so that the test starts with no interfaces attached: $ virsh detach-interface $VM network 2. In the VM, write a network config for all en* links to use DHCP: $ cat > /etc/systemd/network/10-dhcp.network << EOF [Match] Name=en* [Network] DHCP=yes EOF 3. Restart systemd-networkd: $ systemctl restart systemd-networkd 4. On the host, attach an interface to the VM on the no-dhcp network, so that an IP is not assigned: $ virsh attach-interface $VM network no-dhcp 5. Back in the VM, confirm that the device is in the degraded/configuring state: $ networkctl networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 8 ens3 etherdegradedconfiguring 2 links listed. 6. Run systemd-networkd-wait-online --any, and confirm that it does timeout instead of returning while the device is is still not configured: $ /lib/systemd/systemd-networkd-wait-online --any --timeout=10 Timeout occurred while waiting for network connectivity. 7. Confirm that the device is STILL in the degraded/configuring state: $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 8 ens3 etherdegradedconfiguring 2 links listed. 8. Now, leave systemd-network-wait-online --any running while we attach another interface: $ /lib/systemd/systemd-networkd-wait-online --any --timeout=0 9. On the host, attach another interface to the VM on the default network, so that DHCP assigns the interface an IP: $ virsh attach-interface $VM network default 10. Back in the VM, the systemd-networkd-wait-online
[Touch-packages] [Bug 1922414] Re: ssh-agent fails to start (has_option: command not found)
I also see it on Ubuntu MATE Jammy. Will the fix come from Xorg, or should we add LightDM to the affected projects list? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1922414 Title: ssh-agent fails to start (has_option: command not found) Status in gdm3 package in Ubuntu: Fix Released Status in xorg package in Ubuntu: Confirmed Bug description: Hi, I have been using ssh-agent for years and since I upgraded my system to Ubuntu 21.04/groovy, ssh-agent fails to start. Here is the error message: # journalctl | grep ssh-agent [...] Apr 02 20:16:32 vougeot /usr/libexec/gdm-x-session[3752]: /etc/X11/Xsession.d/90x11-common_ssh-agent: line 9: has_option: command not found ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: x11-common 1:7.7+22ubuntu1 Uname: Linux 5.11.11-05-lowlatency x86_64 ApportVersion: 2.20.11-0ubuntu61 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: KDE Date: Sat Apr 3 09:02:46 2021 Dependencies: lsb-base 11.1.0ubuntu2 DistUpgraded: Fresh install DistroCodename: hirsute DistroVariant: ubuntu DkmsStatus: tuxedo-keyboard, 3.0.4, 5.11.0-13-generic, x86_64: installed tuxedo-keyboard, 3.0.4, 5.11.0-13-lowlatency, x86_64: installed tuxedo-keyboard, 3.0.4, 5.11.11-05-lowlatency, x86_64: installed ExtraDebuggingInterest: No GraphicsCard: Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Iris Xe Graphics [1558:51a1] MachineType: TUXEDO TUXEDO InfinityBook S 15 Gen6 PackageArchitecture: all ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.11-05-lowlatency root=/dev/mapper/MonVolume2-UbuntuRacine ro vsyscall=none security=apparmor quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/07/2020 dmi.bios.release: 7.3 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 1.07.03RTR dmi.board.name: NS50MU dmi.board.vendor: TUXEDO dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.ec.firmware.release: 7.2 dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.03RTR:bd09/07/2020:br7.3:efr7.2:svnTUXEDO:pnTUXEDOInfinityBookS15Gen6:pvrNotApplicable:rvnTUXEDO:rnNS50MU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A: dmi.product.family: Not Applicable dmi.product.name: TUXEDO InfinityBook S 15 Gen6 dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: TUXEDO version.compiz: compiz 1:0.9.14.1+20.10.20200813-0ubuntu4 version.libdrm2: libdrm2 2.4.104-1build1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.1-1 version.libgl1-mesa-glx: libgl1-mesa-glx 21.0.1-1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.10-3ubuntu5 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.6-2build1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1922414/+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 48734] Re: Home permissions too open
Schools have started installing/upgrading to 22.04.1 and we're just now
seeing this.
This change takes away the ability of the users to share some of their data
WITHOUT involving the administrator.
It's not "privacy by default", it's "mandatory privacy".
Privacy by default could be done with umask.
Administrative actions can mitigate the issue, but they're tricky as they
cannot easily be applied to users that haven't logged in yet and folders that
don't exist yet.
Sudoer scripts that would give the ability to the users to share stuff by
themselves can be a worse security risk.
On the other hand, encrypted home directories is a trend with similar
issues.
I guess it'll be a bit easier to rewrite all the programs that need access to
/home/username to use other locations such as /run/user/XXX, /home/shared/XXX,
/home/public_html/XXX, /var/lib/AccountsService/users/user/face.png,
/var/spool/* etc,
than to introduce an XDG specification for a new /home/user/private directory,
and rewrite all the programs that need private or encryped data to use that
one. That would be a much cleaner solution, but it can't be a goal for a single
distribution.
So while this change does require us to spend some weeks reimplementing
our shared folders software, it might be for the best, let's see how it
goes. Cheers!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/48734
Title:
Home permissions too open
Status in adduser package in Ubuntu:
Fix Released
Status in shadow package in Ubuntu:
Fix Released
Status in adduser source package in Hirsute:
Fix Released
Status in shadow source package in Hirsute:
Fix Released
Status in Ubuntu RTM:
Opinion
Bug description:
Binary package hint: debian-installer
On a fresh dapper install i noticed that the file permissons for the
home directory for the user created by the installer is set to 755,
giving read access to everyone on the system.
Surely this is a bad idea? If your set on the idea can we atleast have
a option during the boot proccess?
Also new files that are created via the console ('touch' etc.) are
done so with '644' permissons, is there anything that can be done
here? nautlius seems to create files at '600', which is a better
setting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+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 1992731] Re: The cursor can be freely moved around and used to erase characters on the TTY while at the login prompt
Reproduced in Ubuntu 22.04 and 20.04. Could NOT reproduce in Ubuntu 18.04. I think the problem is in `agetty` though, not in `login`. Added `util-linux` to affected packages. ** Also affects: util-linux (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/1992731 Title: The cursor can be freely moved around and used to erase characters on the TTY while at the login prompt Status in shadow package in Ubuntu: New Status in util-linux package in Ubuntu: New Bug description: Welp, this is a weird one. Known to affect Ubuntu Server and multiple flavors of Ubuntu. Steps to reproduce: 1: If you are shown a graphical login prompt (e.g. GDM or SDDM), switch to a TTY. 2. At the login prompt, press the up arrow key twice. 3: Press Backspace twice. 4: Press Enter. Expected result: Nothing should happen, or possibly key codes should appear when the arrow keys are pressed, and those key codes should be erased when backspace is pressed. Actual result: The cursor moves up two lines when the up arrow key is pressed twice, and the "." and "4" of "22.04.1" are erased when Backspace is pressed twice. Upon pressing Enter, the TTY seems to freeze (no user input causes anything to happen), then the login prompt reverts back to its original state and the cursor assumes its proper location. Notes: This bug was first reported by a user named Liver_K on IRC as happening on Ubuntu Server 22.04 after upgrading from 20.04. alkisg then confirmed it on Ubuntu MATE 22.04, and I confirmed it on Kubuntu Focus Suite 22.04. Yes, you can indeed use this to erase everything in the TTY screen and leave the cursor in the upper-left corner as if the system was stuck. Pressing Enter resolves it after a while. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: login 1:4.8.1-2ubuntu2 ProcVersionSignature: Ubuntu 5.17.0-1017.18-oem 5.17.15 Uname: Linux 5.17.0-1017-oem x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Thu Oct 13 00:44:03 2022 InstallationDate: Installed on 2022-10-04 (8 days ago) InstallationMedia: Kubuntu 22.04.1 LTS "Jammy Jellyfish" (20220916) SourcePackage: shadow UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1992731/+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 1998713] [NEW] Don't add universe to cdrom: sources
Public bug reported: Please do not add "universe" in "deb cdrom:" lines of /etc/apt/sources.list. To reproduce the issue, boot Ubuntu GNOME 22.04, and at the live session, run: sudo add-apt-repository universe After that, `apt update` will keep complaining: W: Skipping acquire of configured file 'universe/binary-amd64/Packages' as repository 'cdrom://Ubuntu 22.04.1 LTS _Jammy Jellyfish_ - Release amd64 (20220809.1) jammy InRelease' doesn't have the component 'universe' (component misspelt in sources.list?) ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1998713 Title: Don't add universe to cdrom: sources Status in software-properties package in Ubuntu: New Bug description: Please do not add "universe" in "deb cdrom:" lines of /etc/apt/sources.list. To reproduce the issue, boot Ubuntu GNOME 22.04, and at the live session, run: sudo add-apt-repository universe After that, `apt update` will keep complaining: W: Skipping acquire of configured file 'universe/binary- amd64/Packages' as repository 'cdrom://Ubuntu 22.04.1 LTS _Jammy Jellyfish_ - Release amd64 (20220809.1) jammy InRelease' doesn't have the component 'universe' (component misspelt in sources.list?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1998713/+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 2023266] [NEW] Please re-add [pm]mnormalize
Public bug reported: The Debian packaging contains these lines: https://salsa.debian.org/debian/rsyslog/-/blob/debian/master/debian/rules#L43 --enable-pmnormalize \ --enable-mmnormalize \ AFAIK these were removed because liblognorm was in universe: - Drop [mm|pm]normalize modules, depending on liblognorm from universe. + d/rules: drop --enable-mmnormalize & --enable-pmnormalize + d/control: drop build dependency on liblognorm-dev -- Steve Langasek Wed, 29 Dec 2021 17:15:17 -0800 But later on liblognorm was re-added: * Re-add build-dependency on liblognorm-dev, also needed for rsyslog-kubernetes. -- Steve Langasek Thu, 30 Dec 2021 07:22:05 + So these very useful modules are now excluded from the build for no reason. Please re-enable them as they're needed in order to receive logs from switches that send non-standard dates, for example: https://github.com/rsyslog/rsyslog/issues/5148#issuecomment-1568687769 ** Affects: rsyslog (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/2023266 Title: Please re-add [pm]mnormalize Status in rsyslog package in Ubuntu: New Bug description: The Debian packaging contains these lines: https://salsa.debian.org/debian/rsyslog/-/blob/debian/master/debian/rules#L43 --enable-pmnormalize \ --enable-mmnormalize \ AFAIK these were removed because liblognorm was in universe: - Drop [mm|pm]normalize modules, depending on liblognorm from universe. + d/rules: drop --enable-mmnormalize & --enable-pmnormalize + d/control: drop build dependency on liblognorm-dev -- Steve Langasek Wed, 29 Dec 2021 17:15:17 -0800 But later on liblognorm was re-added: * Re-add build-dependency on liblognorm-dev, also needed for rsyslog-kubernetes. -- Steve Langasek Thu, 30 Dec 2021 07:22:05 + So these very useful modules are now excluded from the build for no reason. Please re-enable them as they're needed in order to receive logs from switches that send non-standard dates, for example: https://github.com/rsyslog/rsyslog/issues/5148#issuecomment-1568687769 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2023266/+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 1854588] Re: gdebi-gtk calls pkexec inappropriately
> I will point out that Firefox, regardless of how it's launched, seems to not be affected anymore. If you're testing firefox.snap, that might be the cause, i.e. maybe snap does the parenting. While e.g. firefox.deb from the mozillateam PPA (or firefox in Debian) could still have the issue. Thanks for working on this! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdebi in Ubuntu. https://bugs.launchpad.net/bugs/1854588 Title: gdebi-gtk calls pkexec inappropriately Status in gdebi package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu with gdebi-gtk installed 2. Open Firefox 3. Visit some site with deb-package download link or use direct link like https://github.com/jgm/pandoc/releases/download/2.9.2.1/pandoc-2.9.2.1-1-amd64.deb 4. Proceed with file downloading 5. In Firefox select Library → Downloads, click on downloaded deb-file Expected results: * gdebi-gtk is opened, the package installs normally after users clicks Install button Actual results: * gdebi-gtk is opened, the package is not installed because of vanishing of gdebi-gtk window just after clicking Install button Before anyone says this bug already exists... it doesn't (at least as far as I can see). It's just that a lot of similar bugs do/did exist where people have also experienced the same symptoms (of gdebi-gtk vanishing upon clicking 'Install'). So yes this is the same symptoms, but it must be a different cause as the circumstances are different and doesn't have the same resolution. The meat of it... Basically on a fresh install of Ubuntu MATE 18.04.3 amd64... with Firefox (or with Chrome if you installed that) go to any site that offers a .deb package and either... a) choose to open it directly from the browser (rather than saving it to 'Downloads' folder) b) or... save the file (e.g. to the 'Downloads' folder), BUT!.. open that file from within the browser itself. You should find that gdebi-gtk appears but vanishes the moment you click 'Install' without a prompt for a password, an explanation or the package actually getting installed. This bug has existed since the beginning of Ubuntu 18.04 however it's been largely confused with other similar bugs. I've had it on half a dozen machines and confirmed it exists with IRC users on #ubuntu-mate of freenode. However with *this* bug (compared to others) gdebi-gtk works perfectly fine if you run it from the terminal or just double click the .deb package from your file manager. It's the kind of bug which if you're a hardened desktop Linux user, you'd just work around it... But if you're a novice and you can't get a simple thing like Teamviewer installed (which is a .deb, and a thing I might ask someone to do over the phone to try to help them) you likely get fed up and re-install Windows :S Any input on this would be brilliant as I can't seem to get any logs/output. ~lantizia To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/1854588/+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 2019940] Re: Directly manipulating NetworkManager keyfiles
** Changed in: ltsp (Ubuntu) Status: New => Invalid -- 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/2019940 Title: Directly manipulating NetworkManager keyfiles Status in augeas package in Ubuntu: New Status in calamares package in Ubuntu: New Status in cloud-init package in Ubuntu: New Status in cruft-ng package in Ubuntu: New Status in dracut package in Ubuntu: New Status in forensic-artifacts package in Ubuntu: New Status in guestfs-tools package in Ubuntu: New Status in guix package in Ubuntu: New Status in ltsp package in Ubuntu: Invalid Status in netcfg package in Ubuntu: Won't Fix Status in netplan.io package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: New Status in refpolicy package in Ubuntu: New Status in sosreport package in Ubuntu: New Status in uhd package in Ubuntu: New Status in vagrant package in Ubuntu: New Bug description: The affected packages can manipulate NetworkManager keyfiles directly on disk, which might not be appropriate anymore on Ubuntu, since the Netplan integration was enabled in NetworkManager (starting with Mantic), migrating any keyfile configuration from /etc/NetworkManager/system-connections/*[.nmconnection] to /etc/netplan/90-NM-*.yaml See Netplan's documentation for how connections are handled: https://netplan.readthedocs.io/en/latest/netplan-everywhere/ PS: Packages were queried using: https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+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
