如何修复缺少的libudev.so.0让Chrome再次启动？
尝试在命令行中跟随错误时启动chrome产生：
/opt/google/chrome/chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory 该错误首先出现在Ubuntu 13.04中，我尝试清除并重新安装Chrome。 升级到Ubuntu 13.10后它仍然存在。
如果在Ubuntu从≤12.10升级到≥13.04后Chrome无法启动，请打开终端并运行以下命令：
sudo dpkg-reconfigure google-chrome-stable
解释如下。
至少对于格式为28到37的Chrome版本，Chrome二进制文件可以使用系统中存在的libudev.so.0或libudev.so.1任何一个。 通过修复Chromium / Chrome Issue 226002 （2013年4月进入不稳定频道），安装程序确定使用哪一个。 二进制引用libudev.so.0 ; 如果libudev.so.0 ，安装程序会在libudev.so.1上创建一个符号链接到系统上的libudev.so.0 。
请注意，在/usr/lib创建一个是一个坏主意。 当较新版本不兼容时，库中的主要版本号会更改。 创建此符号链接适用于Chrome，因为它仅使用版本0和版本1之间兼容的function。如果强制它们以错误的版本运行，其他应用程序可能会崩溃或生成损坏的数据。
Chrome软件包使用的方法在大多数情况下运行良好，但它仍然是一个肮脏的黑客，它有一个限制。 如果在安装Chrome后卸载了libudev0软件包，这在升级Ubuntu时可能会发生，那么Chrome仍将设置为使用libudev.so.0但该文件将不再可用。 要解决此问题，请使安装脚本再次运行，这次检测到libudev.so.0不可用，因此应创建符号链接以使用libudev.so.1 。 您可以通过以root身份运行dpkg-reconfigure google-chrome-stable来重新运行安装脚本。
正如吉尔斯所指出的，这种方法可能导致不必要的行为。 请先尝试他的解决方案 。 如果它不适合您并且您了解这可能导致静默数据损坏 ，则您可以执行以下操作：
假设一个64位系统，可以通过以下方式创建丢失的符号链接：
sudo ln -s /lib/x86_64-linux-gnu/libudev.so.1.3.5 /usr/lib/libudev.so.0
对于Ubuntu 18：
sudo ln -s /lib/x86_64-linux-gnu/libudev.so.1.6.9 /usr/lib/libudev.so.0
对于32位系统：
sudo ln -s /lib/i386-linux-gnu/libudev.so.1.3.5 /usr/lib/libudev.so.0
您可能需要检查本地版本的libudev。