[Touch-packages] [Bug 1827328] [NEW] ModemManager does not honor blacklisted ttys (ID_MM_DEVICE_IGNORE)

2019-05-02 Thread Tommy Vestermark 
Public bug reported:

In Ubuntu 19.04 (and likely earlier) Modem Manager is installed with
filter policy 'strict' as opposed to 'default', which actually makes
Modem Manager _less_ strict regarding explicitly blacklisted ttys (see
man modemmanager).

This means that ttys, that are explicitly blacklisted from Modem Manager
by using ENV{ID_MM_DEVICE_IGNORE}="1" in its udev rule is still opened
and probed by Modem Manager although it should not.

This is a common cause of problems and frustrations for people working
with actual serial devices, e.g. within embedded development (e.g.
Arduino and the like). See https://nick.zoic.org/art/failed-to-set-dtr-
rts-systemd-modemmanager/ for an example.

A proposed solution is to change the following line in: 
/lib/systemd/system/ModemManager.service
from:
ExecStart=/usr/sbin/ModemManager --filter-policy=strict
to:
ExecStart=/usr/sbin/ModemManager --filter-policy=paranoid

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: modemmanager 1.10.0-1 [modified: 
lib/systemd/system/ModemManager.service]
ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
Uname: Linux 5.0.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu May  2 15:35:58 2019
EcryptfsInUse: Yes
InstallationDate: Installed on 2018-05-26 (340 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: modemmanager
UpgradeStatus: Upgraded to disco on 2019-04-18 (13 days ago)

** Affects: modemmanager (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 modemmanager in Ubuntu.
https://bugs.launchpad.net/bugs/1827328

Title:
  ModemManager does not honor blacklisted ttys (ID_MM_DEVICE_IGNORE)

Status in modemmanager package in Ubuntu:
  New

Bug description:
  In Ubuntu 19.04 (and likely earlier) Modem Manager is installed with
  filter policy 'strict' as opposed to 'default', which actually makes
  Modem Manager _less_ strict regarding explicitly blacklisted ttys (see
  man modemmanager).

  This means that ttys, that are explicitly blacklisted from Modem
  Manager by using ENV{ID_MM_DEVICE_IGNORE}="1" in its udev rule is
  still opened and probed by Modem Manager although it should not.

  This is a common cause of problems and frustrations for people working
  with actual serial devices, e.g. within embedded development (e.g.
  Arduino and the like). See https://nick.zoic.org/art/failed-to-set-
  dtr-rts-systemd-modemmanager/ for an example.

  A proposed solution is to change the following line in: 
/lib/systemd/system/ModemManager.service
  from:
  ExecStart=/usr/sbin/ModemManager --filter-policy=strict
  to:
  ExecStart=/usr/sbin/ModemManager --filter-policy=paranoid

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: modemmanager 1.10.0-1 [modified: 
lib/systemd/system/ModemManager.service]
  ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
  Uname: Linux 5.0.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu May  2 15:35:58 2019
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2018-05-26 (340 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: modemmanager
  UpgradeStatus: Upgraded to disco on 2019-04-18 (13 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1827328/+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 1438612] Re: remote file systems hang on shutdown, D-BUS stops too early

2016-04-19 Thread Tommy Vestermark 
Apparently this is not a solved problem, as my fresh 16.04 install hangs on 
shutdown with NFS drives mounted.
My fstab:
10.10.10.10:/media/storage1 /nasnfs 
noauto,x-systemd.automount,soft,timeo=20,retrans=10 0   0
Un-mounting before shutdown makes it shutdown correctly.

Is this bug still active or should I file a new one?

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

Title:
  remote file systems hang on shutdown, D-BUS stops too early

Status in D-Bus:
  Won't Fix
Status in dbus package in Ubuntu:
  Fix Released

Bug description:
  (part of bug 1431774). During shutdown, D-Bus stops too early. In
  particular, it stops before NetworkManager and remote-fs.target,  so
  that any network unmount  will cause errors and hang the boot. This
  can be seen with

  $ journalctl -b -1 | egrep 'Stop.*(D-Bus|Network M|Remote F)'
  Mär 30 19:05:19 donald systemd[1]: Stopping D-Bus System Message Bus...
  Mär 30 19:05:19 donald systemd[1]: Stopped D-Bus System Message Bus.
  Mär 30 19:05:19 donald systemd[1]: Stopped target Remote File Systems.
  Mär 30 19:05:19 donald systemd[1]: Stopping Remote File Systems.
  Mär 30 19:05:19 donald systemd[1]: Stopped target Remote File Systems (Pre).
  Mär 30 19:05:19 donald systemd[1]: Stopping Remote File Systems (Pre).
  Mär 30 19:05:19 donald systemd[1]: Stopping Network Manager...
  Mär 30 19:05:42 donald systemd[1]: Stopped Network Manager.
  Mär 30 19:05:42 donald systemd[1]: Stopping D-Bus System Message Bus Socket.

  A quick workaround is to add After=dbus.service to
  /lib/systemd/system/NetworkManager.service's [Unit] section, but this
  should be fixed in a more general fashion.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1438612/+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 1438682] Re: Shutdown hangs with systemd and NFS mount

2016-04-19 Thread Tommy Vestermark 
*** This bug is a duplicate of bug 1438612 ***
https://bugs.launchpad.net/bugs/1438612

Hi Hasan,

As you can see, this bug is duplicate. Please make your comment and
"this bug affects me" indication on the other bug.

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

Title:
  Shutdown hangs with systemd and NFS mount

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I have the following line in /etc/fstab:
  192.168.1.5:/srv/nsf4/main  /shares nfs 
noauto,nofail,x-systemd.automount,_netdev,x-systemd.device-timeout=14,size=32768,wsize=32768
 0 0

  This works properly in the sense that systemd does not hold up the
  system when booting, and it does mount the directory upon first
  access, however the system hangs at shutdown in a manner consistent
  with systemd shutting down the network before attempting to unmount
  the drive. Indeed, even when the system is running, I can manually run

  systemctl stop NetworkManager.service

  and/or

  systemctl stop network.target

  and a call to

  systemctl status shares.mount

  shows that the mount is still active.

  Finally, I will describe the debugging I have done to this point.
  First, if I manually unmount the share before shutting down, it shuts
  down immediately. Second, it should be noted that this does not in
  anyway depend on using the x-systemd.automount option. The same thing
  happens without automount (or fstab for that matter - simply manually
  mounting an NFS share and shutting down results in the computer
  getting stuck on the shutdown screen). I also tried adding additional
  items to the Require= and After= lines for shares.mount, specifically
  I tried adding network.target, NetworkManager.service, and
  wpa_supplicant.service. In each case, I did observe that manually
  running

  systemctl stop NetworkManager.service

  (for instance) now did cause the share to be unmounted, however if I
  shutdown the computer without manually stopping these services it
  would still stall on the shutdown screen. I can leave it for over 10
  minutes, at which point I manually power it off.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-5ubuntu1
  ProcVersionSignature: Ubuntu 3.19.0-10.10-generic 3.19.2
  Uname: Linux 3.19.0-10-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.17-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Mar 31 09:05:25 2015
  InstallationDate: Installed on 2015-03-31 (0 days ago)
  InstallationMedia: Ubuntu-GNOME 15.04 "Vivid Vervet" - Beta amd64 (20150326)
  MachineType: Dell Inc. Dell Precision M3800
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/usr/bin/fish
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-10-generic 
root=/dev/mapper/AntergosVG-UbuntuRoot ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/14/2014
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A08
  dmi.board.name: Dell Precision M3800
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A08
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: Not Specified
  dmi.modalias: 
dmi:bvnDellInc.:bvrA08:bd11/14/2014:svnDellInc.:pnDellPrecisionM3800:pvrA08:rvnDellInc.:rnDellPrecisionM3800:rvrA08:cvnDellInc.:ct8:cvrNotSpecified:
  dmi.product.name: Dell Precision M3800
  dmi.product.version: A08
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1438682/+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 1391296] [NEW] 14.10: NFS drives in fstab not mounted automatically

2014-11-10 Thread Tommy Vestermark 
Public bug reported:

After upgrading to 14.10 (fresh install) my NFS drive does no longer
mounts automatically at boot when the network is up and running.
Manually running mount -a mounts the drive as expected and hacking a
mount -a command into mountall-net.conf makes my system function
normally again. Trying to manually to killall -USR1 mountall does not
work.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: mountall 2.54build1
ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4
Uname: Linux 3.16.0-24-generic x86_64
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Nov 10 20:37:39 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-11-09 (1 days ago)
InstallationMedia: Ubuntu 14.10 Utopic Unicorn - Release amd64 (20141022.1)
ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic 
root=UUID=e1197618-b55d-40d3-9b81-df2dcb847c1f ro quiet splash vt.handoff=7
SourcePackage: mountall
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.init.mountall.net.conf: 2014-11-10T20:26:00.795161

** Affects: mountall (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

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

Title:
  14.10: NFS drives in fstab not mounted automatically

Status in “mountall” package in Ubuntu:
  New

Bug description:
  After upgrading to 14.10 (fresh install) my NFS drive does no longer
  mounts automatically at boot when the network is up and running.
  Manually running mount -a mounts the drive as expected and hacking a
  mount -a command into mountall-net.conf makes my system function
  normally again. Trying to manually to killall -USR1 mountall does not
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: mountall 2.54build1
  ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4
  Uname: Linux 3.16.0-24-generic x86_64
  ApportVersion: 2.14.7-0ubuntu8
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Nov 10 20:37:39 2014
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-11-09 (1 days ago)
  InstallationMedia: Ubuntu 14.10 Utopic Unicorn - Release amd64 (20141022.1)
  ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic 
root=UUID=e1197618-b55d-40d3-9b81-df2dcb847c1f ro quiet splash vt.handoff=7
  SourcePackage: mountall
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.init.mountall.net.conf: 2014-11-10T20:26:00.795161

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