☰

为什么 update-alternative 设置“手动”模式？

tag-icon • tag-icon installation debian nvidia-graphics-card
为什么 update-alternative 设置“手动”模式？

我有一个旧系统，它一切正常，但有一个新系统，它却不行。具体来说：X 无法启动。

我把错误追溯到更新替代方案由于某种原因手动的团体模式格莱克斯和英伟达。

这是来自工作系统的信息：

update-alternatives --display glx   
glx - auto mode
  link currently points to /usr/lib/nvidia
/usr/lib/mesa-diverted - priority 5
  slave glx--libGL.so.1-i386-linux-gnu: /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
/usr/lib/nvidia - priority 100
  slave glx--libGL.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libGL.so.1
  slave glx--libXvMCNVIDIA.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA.so.1
  slave glx--libXvMCNVIDIA_dynamic.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA_dynamic.so.1
  slave glx--libnvidia-cfg.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave glx--linux-libglx.so: /usr/lib/nvidia/libglx.so
  slave glx--nvidia-bug-report.sh: /usr/lib/nvidia/nvidia-bug-report.sh
  slave glx--nvidia_drv.so: /usr/lib/nvidia/nvidia_drv.so
Current 'best' version is '/usr/lib/nvidia'.

这是出现错误的系统信息：

update-alternatives --display glx  
glx - manual mode
  link currently points to /usr/lib/mesa-diverted
/usr/lib/mesa-diverted - priority 5
  slave glx--libGL.so.1-i386-linux-gnu: /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
/usr/lib/nvidia - priority 100
  slave glx--libGL.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libGL.so.1
  slave glx--libXvMCNVIDIA.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA.so.1
  slave glx--libXvMCNVIDIA_dynamic.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA_dynamic.so.1
  slave glx--libnvidia-cfg.so.1-i386-linux-gnu: /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave glx--linux-libglx.so: /usr/lib/nvidia/libglx.so
  slave glx--nvidia-bug-report.sh: /usr/lib/nvidia/nvidia-bug-report.sh
  slave glx--nvidia_drv.so: /usr/lib/nvidia/nvidia_drv.so
Current 'best' version is '/usr/lib/nvidia'.

如您所见，由于某种原因，glx 组被设置为手动的。nvidia 组也是如此。所有优先级都设置正确。

现在我知道了手动的解决方案（将运行‘更新替代方案--配置 glx’因为我的系统是自动安装的，之后应该可以完美运行（只需查看旧系统）。所以我想了解根本原因。

你应该知道这个问题已经存在全新安装后。没有发生任何人工干预。我试图了解为什么以及何时发生这种情况。

update-alternatives 的手册页暗示只有- 放或者--配置将组切换为手动模式。但是我找不到任何可以执行这些命令的东西。

我认为，这两个系统之间的唯一区别在于，较新的系统使用了 Debian Wheezy 较新的软件包。我已经比较了所有后安装新旧版本之间的维护者脚本，并且相关软件包中没有任何变化。

我不太了解更新替代方案，所以我希望有人可以帮助我。

答案1

我已经比较了新旧版本之间的所有 postinst 维护者脚本，相关软件包中没有任何变化。

这可能是软件包的版本太旧了，也可能是其他软件包，或者您在尝试修复时确实发生了问题。有太多可能的嫌疑人（包括您在内），很难找到到底是哪个过程改变了它……但至少您可以知道什么时候。更新替代方案有一个日志文件，位于/var/log/alternatives.log。如果您的系统安装时间太长，那么可能存在何时的答案，您可以从那里找出是谁。您的前提都是正确的。

答案2

我自己找到了答案。显然在 Debian live-build 的更新中，添加了挂钩脚本来设置 glx 和 nvidia 链接组。我们使用 live-build 来创建我所说的系统。一个例子 /usr/share/live/build/hooks/0320-update-glx-alternative.chroot

相关内容