我正在为嵌入式解决方案开发基于 Debian 8 (Jessie) 的系统，使用 multistrap 构建 rootfs。该系统是无头的，可以通过用于调试的串行控制台和 SSH 进行访问。
我在该系统中遇到 ModemManager 问题。它安装没有问题，但是一旦我启用它并且它实际启动，它通常（并非总是但通常）开始淹没调试控制台。输出通常只是无意义的字符流，但有时也有各种 AT 命令。我知道这种洪水是由 ModemManager 引起的，因为一旦我删除 ModemManager，它就会停止。
我可以忍受一些随机的洪水，但问题是这种洪水几乎总是以某种方式使控制台无响应，从而阻止我登录。有时，尽管很少，尽管有这种洪水，我还是能够登录，检查设备的IP，然后通过SSH登录。不过，通常情况下，解决该问题的选项不可用，因为我什至无法找到 DHCP 服务器为设备提供的 IP。
我发现这个问题是由于ModemManager扫描该串行端口中的调制解调器造成的。我还发现有一种方法可以使用 udev 规则来解决该问题。应该起作用的规则是这样的：
ATTRS{idVendor}=="0ca6" ATTRS{idProduct}=="a050", ENV{ID_MM_DEVICE_IGNORE}="1"
我的情况有点不同，因为串口是CPU的外设，即不是USB串口，所以我将规则修改为这种形式：
KERNEL=="ttyS0", ENV{ID_MM_DEVICE_IGNORE}="1"
udevadm 现在告诉我该线路正在被识别，并且该属性（或任何名称）已添加到设备的属性中。
但问题还没有解决。由于某种原因，ModemManager 仍然不断淹没控制台并导致无法登录。
删除 ModemManager 不是一个选项，因为我的应用程序需要它。
答案1
回答我自己的问题...
我检查了ModemManager的代码，发现当设备属于tty子系统时，ModemManager根本不检查udev规则。在我看来，解决这个问题的唯一方法是修补 ModemManager，但这完全是另一个主题。
答案2
如果您有一个/lib/udev/rules.d/77-mm-platform-serial-whitelist.rules文件，请将其从系统中删除并重新启动（或重新加载+触发 udev 规则）。这已经已打补丁在ModemManager 源中。