[Touch-packages] [Bug 1882034] Re: cannot start X session with NIS account

[Fabien]

> Do you seem to observe https://github.com/systemd/systemd/issues/2941
?

The message is the same, but I cannot see a "hidepid" mount option
anywhere.

As a standard user I can see all /proc/ directories, and read
the /proc//cgroup file of other users, including root.

So I'd say that it is not exactly the same issue.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1882034

Title:
  cannot start X session with NIS account

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  When login with a NIS account, X does not start, or more precisely it
  starts and exits immediately.

  Only errors in logs is:
   (EE) systemd-logind: failed to get session: PID 4335 does not belong to any 
known session

  X11/gdm login works fine with local accounts.

  SSH/terminal console login with NIS accounts works fine.

  /etc/X11/Xwrapper.config:
allowed_users=anybody

  I've seen several reports of such problems under other versions (eg
  19.10), but no working solutions was found. It seems that the problem
  is the same with lightdm.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gdm3 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30
  Uname: Linux 5.4.0-29-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.2
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun  4 08:59:25 2020
  InstallationDate: Installed on 2019-11-26 (190 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to focal on 2020-04-24 (40 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1882034/+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 1882034] Re: cannot start X session with NIS account

[Fabien]

** Changed in: systemd (Ubuntu)
   Status: Incomplete => Confirmed

-- 
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/1882034

Title:
  cannot start X session with NIS account

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  When login with a NIS account, X does not start, or more precisely it
  starts and exits immediately.

  Only errors in logs is:
   (EE) systemd-logind: failed to get session: PID 4335 does not belong to any 
known session

  X11/gdm login works fine with local accounts.

  SSH/terminal console login with NIS accounts works fine.

  /etc/X11/Xwrapper.config:
allowed_users=anybody

  I've seen several reports of such problems under other versions (eg
  19.10), but no working solutions was found. It seems that the problem
  is the same with lightdm.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gdm3 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30
  Uname: Linux 5.4.0-29-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.2
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Jun  4 08:59:25 2020
  InstallationDate: Installed on 2019-11-26 (190 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: gdm3
  UpgradeStatus: Upgraded to focal on 2020-04-24 (40 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1882034/+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 1781652] Re: should be possible to specify static routes on a dhcp-configured interface

[Fabien Toral]

I've the same problem.

I'm operating 17.10 systems with network initially configured with DHCP.
We need to add pemanent static routes and networkd failed with the same
error than reported here.

I think I've found the upstream bug in systemd :
https://github.com/systemd/systemd/issues/1850


** Bug watch added: github.com/systemd/systemd/issues #1850
   https://github.com/systemd/systemd/issues/1850

-- 
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/1781652

Title:
  should be possible to specify static routes on a dhcp-configured
  interface

Status in netplan:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  From , a user wants to add a static route to a
  network interface where the gateway is known, but the interface's
  local address is configured via dhcp.

  This doesn't work with direct netplan yaml, because networkd will try
  to apply the static routes before the interface has been configured
  via dhcp, failing because there is not yet a route to the gateway on
  that interface.

  Demonstrating in a lxd container locally, which has 10.44.49.0/24 as
  its network:

  $ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  eth0:
  dhcp4: true
  routes:
 - to: 10.44.48.0/24
   via: 10.44.49.2
   metric: 10
  $  systemctl status systemd-networkd --no-pager -l
  ● systemd-networkd.service - Network Service
 Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; 
vendor preset: enabled)
 Active: active (running) since Fri 2018-07-13 19:21:29 UTC; 8min ago
   Docs: man:systemd-networkd.service(8)
   Main PID: 165 (systemd-network)
 Status: "Processing requests..."
  Tasks: 1 (limit: 4915)
 CGroup: /system.slice/systemd-networkd.service
 └─165 /lib/systemd/systemd-networkd

  Jul 13 19:21:29 stable-dane systemd[1]: Starting Network Service...
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: Enumeration completed
  Jul 13 19:21:29 stable-dane systemd[1]: Started Network Service.
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Could not set route: 
Network is unreachable
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: DHCPv4 address 
10.44.49.32/24 via 10.44.49.1
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: Not connected to system 
bus, not setting hostname.
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Gained IPv6LL
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Configured
  Jul 13 19:21:55 stable-dane systemd-networkd[165]: Could not set hostname: 
Method call timed out
  $ ip route 
  default via 10.44.49.1 dev eth0 proto dhcp src 10.44.49.32 metric 100 
  10.44.49.0/24 dev eth0 proto kernel scope link src 10.44.49.32 
  10.44.49.1 dev eth0 proto dhcp scope link src 10.44.49.32 metric 100 
  $

  netplan and networkd should DTRT.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1781652/+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 1999881] [NEW] unmkinitramfs fails with symlinked zstd compressed initrds

[Fabien Malfoy]

Public bug reported:

[Impact]

 * Cannot unpack zstd compressed initrds when accessed through a
symbolic link

[Test Case]

$ grep COMPRESS= /etc/initramfs-tools/initramfs.conf
COMPRESS=zstd
# This is the default

$ stat -c '%F %N' /boot/initrd.img*
symbolic link '/boot/initrd.img' -> 'initrd.img-5.15.0-53-generic'
regular file '/boot/initrd.img-5.15.0-53-generic'

$ lsinitramfs /boot/initrd.img-5.15.0-53-generic
... works as expected ...

$ lsinitramfs /boot/initrd.img
cpio: premature end of archive

[Regression Potential]

 * Ubuntu Jammy changes the default compression scheme for the initrd
from lz4 to zstd. Unpacking lz4 initrds had already been fixed by
https://bugs.launchpad.net/ubuntu/cosmic/+source/initramfs-
tools/+bug/1832108 but unpacking zstd initrds works as expected when
directly accessing the file. However, it fails when accessing it through
a symbolic link.

[Other Info]

A fix proposal is attached.

$ lsb_release -rd
Description:Ubuntu 22.04.1 LTS
Release:22.04
$ dpkg-query -W initramfs-tools
initramfs-tools 0.140ubuntu13

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New

** Patch added: "Proposed fix"
   
https://bugs.launchpad.net/bugs/1999881/+attachment/5635890/+files/proposed_fix.patch

-- 
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/1999881

Title:
  unmkinitramfs fails with symlinked zstd compressed initrds

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  [Impact]

   * Cannot unpack zstd compressed initrds when accessed through a
  symbolic link

  [Test Case]

  $ grep COMPRESS= /etc/initramfs-tools/initramfs.conf
  COMPRESS=zstd
  # This is the default

  $ stat -c '%F %N' /boot/initrd.img*
  symbolic link '/boot/initrd.img' -> 'initrd.img-5.15.0-53-generic'
  regular file '/boot/initrd.img-5.15.0-53-generic'

  $ lsinitramfs /boot/initrd.img-5.15.0-53-generic
  ... works as expected ...

  $ lsinitramfs /boot/initrd.img
  cpio: premature end of archive

  [Regression Potential]

   * Ubuntu Jammy changes the default compression scheme for the initrd
  from lz4 to zstd. Unpacking lz4 initrds had already been fixed by
  https://bugs.launchpad.net/ubuntu/cosmic/+source/initramfs-
  tools/+bug/1832108 but unpacking zstd initrds works as expected when
  directly accessing the file. However, it fails when accessing it
  through a symbolic link.

  [Other Info]

  A fix proposal is attached.

  $ lsb_release -rd
  Description:  Ubuntu 22.04.1 LTS
  Release:  22.04
  $ dpkg-query -W initramfs-tools
  initramfs-tools   0.140ubuntu13

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1999881/+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 1853203] [NEW] 30 seconds boot delay when usr fs is on lvm

[Fabien SK]

Public bug reported:

A bit similar to "30 seconds boot delay when root fs is on lvm": 
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1807499

I installed Kubuntu 19.04 with 2 LVM volume groups (one per disk). My root and 
my /usr are both located on the same LVM. Mounting /usr takes 30s, but if I 
move the /usr to a non-LVM partition then the mounting takes no time and the 
whole boot process is very fast.
In the script "scripts/local" of initramfs-tools, there is a 30s timeout called 
"slumber" passed to the "wait-for-root" program (from initramfs-tools-bin), and 
the wait comes from there (I could see it by adding traces before and after). 
If I decrease the timeout to 10s, the system can still boot correctly (and 20s 
faster).

I don't know if the problem comes from the initramfs-tools scripts, from
wait-for-root or from the integration in (K)Ubuntu.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: initramfs-tools-core 0.131ubuntu19.2 [modified: 
usr/share/initramfs-tools/scripts/local]
ProcVersionSignature: Ubuntu 5.0.0-36.39-generic 5.0.21
Uname: Linux 5.0.0-36-generic x86_64
ApportVersion: 2.20.10-0ubuntu27.3
Architecture: amd64
CurrentDesktop: KDE
Date: Tue Nov 19 22:11:18 2019
InstallationDate: Installed on 2017-08-26 (815 days ago)
InstallationMedia: Kubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
PackageArchitecture: all
SourcePackage: initramfs-tools
UpgradeStatus: Upgraded to disco on 2019-08-18 (93 days ago)

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug disco

-- 
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/1853203

Title:
  30 seconds boot delay when usr fs is on lvm

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  A bit similar to "30 seconds boot delay when root fs is on lvm": 
  https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1807499

  I installed Kubuntu 19.04 with 2 LVM volume groups (one per disk). My root 
and my /usr are both located on the same LVM. Mounting /usr takes 30s, but if I 
move the /usr to a non-LVM partition then the mounting takes no time and the 
whole boot process is very fast.
  In the script "scripts/local" of initramfs-tools, there is a 30s timeout 
called "slumber" passed to the "wait-for-root" program (from 
initramfs-tools-bin), and the wait comes from there (I could see it by adding 
traces before and after). If I decrease the timeout to 10s, the system can 
still boot correctly (and 20s faster).

  I don't know if the problem comes from the initramfs-tools scripts,
  from wait-for-root or from the integration in (K)Ubuntu.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: initramfs-tools-core 0.131ubuntu19.2 [modified: 
usr/share/initramfs-tools/scripts/local]
  ProcVersionSignature: Ubuntu 5.0.0-36.39-generic 5.0.21
  Uname: Linux 5.0.0-36-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.3
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Tue Nov 19 22:11:18 2019
  InstallationDate: Installed on 2017-08-26 (815 days ago)
  InstallationMedia: Kubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: Upgraded to disco on 2019-08-18 (93 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1853203/+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 1853203] Re: 30 seconds boot delay when usr fs is on lvm

[Fabien SK]

I upgraded to Kubuntu 19.10 and the delay disappeared.

-- 
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/1853203

Title:
  30 seconds boot delay when usr fs is on lvm

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  A bit similar to "30 seconds boot delay when root fs is on lvm": 
  https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1807499

  I installed Kubuntu 19.04 with 2 LVM volume groups (one per disk). My root 
and my /usr are both located on the same LVM. Mounting /usr takes 30s, but if I 
move the /usr to a non-LVM partition then the mounting takes no time and the 
whole boot process is very fast.
  In the script "scripts/local" of initramfs-tools, there is a 30s timeout 
called "slumber" passed to the "wait-for-root" program (from 
initramfs-tools-bin), and the wait comes from there (I could see it by adding 
traces before and after). If I decrease the timeout to 10s, the system can 
still boot correctly (and 20s faster).

  I don't know if the problem comes from the initramfs-tools scripts,
  from wait-for-root or from the integration in (K)Ubuntu.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: initramfs-tools-core 0.131ubuntu19.2 [modified: 
usr/share/initramfs-tools/scripts/local]
  ProcVersionSignature: Ubuntu 5.0.0-36.39-generic 5.0.21
  Uname: Linux 5.0.0-36-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.3
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Tue Nov 19 22:11:18 2019
  InstallationDate: Installed on 2017-08-26 (815 days ago)
  InstallationMedia: Kubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  PackageArchitecture: all
  SourcePackage: initramfs-tools
  UpgradeStatus: Upgraded to disco on 2019-08-18 (93 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1853203/+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 1241101]

[Fabien-toral]

So, after few tries in Virtual Machines to test different Debian/gtk
versions, and other researches on the net, I found a workaround to make
Luna work on my Debian laptop :

export SWT_GTK3=0

That aims to fallback to the GTK2 SWT implementation and bring my
Eclipse back!

I was not on the right bug report, and found my way with a comment on
bug #430736 https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736#c26

With that, it comes to me that the only solution, as i don't want to
upgrade my glibc, is to fallback to GTK2...

And thanks to
http://www.eclipse.org/swt/R4_4/new_and_noteworthy.html#m3, the
information was there...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity in Ubuntu.
https://bugs.launchpad.net/bugs/1241101

Title:
  Java crash in libglib-2.0 after upgrade from 13.04 to 13.10

Status in Eclipse:
  Confirmed
Status in “gtk+2.0” package in Ubuntu:
  Triaged
Status in “unity” package in Ubuntu:
  Invalid
Status in “gtk+2.0” package in Suse:
  New

Bug description:
  Running smartgit 4.6.4 on 13.10 64 bits. After registering the
  product, smartgit crash when trying to open a new repository. Java
  error log :

  # A fatal error has been detected by the Java Runtime Environment:
  #
  #  SIGSEGV (0xb) at pc=0x7fa59061f9c0, pid=12494, tid=140349308167936
  #
  # JRE version: 7.0_25-b30
  # Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 
compressed oops)
  # Problematic frame:
  # C  [libglib-2.0.so.0+0x389c0]  g_str_hash+0x0

  I tried different version of Java (Oracle v7 and v6 jre) with same
  result. Also, Eclipse display blank menus so there's a general java
  problem with displays.

To manage notifications about this bug go to:
https://bugs.launchpad.net/eclipse/+bug/1241101/+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