Por que a atualização alternativa define o modo "manual"?

1

Eu tenho um sistema mais antigo, onde tudo funciona bem, e um sistema mais novo, onde não funciona. Para ser específico: o X não inicia.

Eu rastreei o erro até o fato de que update-alternatives por algum motivo está no modo manual para os grupos glx e nvidia .

Isto do sistema de trabalho:

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'.

E isso do sistema que tem o erro:

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'.

Como você pode ver, por algum motivo, o grupo glx está definido como manual . Este também é o caso do grupo nvidia. Todas as prioridades estão definidas corretamente.

Agora, eu conheço uma solução manual (que estaria rodando 'update-alternatives --config glx' corretamente) já que meu sistema é automaticamente instalado e deveria rodar perfeitamente depois (basta olhar o sistema mais antigo). Então eu quero entender a causa raiz.

Você deve saber que este problema já está presente logo após uma nova instalação . Nenhuma intervenção manual aconteceu. Estou tentando entender por que e quando isso acontece no modo manual.

A manpage de update-alternatives implica que apenas um - set ou - config alterna um grupo para o modo manual. No entanto, não consigo encontrar nada que execute qualquer um desses comandos.

A única diferença entre os dois sistemas, acredito, é que o mais novo usa pacotes mais recentes do Debian Wheezy. Eu já comparei todos os scripts do mantenedor postinst entre as versões mais antigas e mais recentes, e nada mudou nos pacotes relevantes.

Eu não sei muito sobre update-alternatives, então espero que alguém possa me ajudar.

    
por Jedyte 12.12.2013 / 11:36

2 respostas

0

Eu mesmo encontrei as respostas. Aparentemente, em uma atualização do script de gancho live-build do Debian foram adicionados para definir os grupos de links glx e nvidia. Nós usamos live-build para criar o sistema que eu estava falando. Um exemplo /usr/share/live/build/hooks/0320-update-glx-alternative.chroot

    
por 16.12.2013 / 09:33
0

I've already compared all the postinst maintainer scripts between the older and newer versions, and nothing has changed there in the relevant packages.

Pode ser uma versão muito antiga do pacote, ou outro pacote, ou você, nas suas tentativas de reparo, o fez. Há muitos possíveis suspeitos (você incluído) que é difícil encontrar exatamente qual foi realmente o processo que mudou isso ... mas pelo menos você pode saber quando. alternativas de atualização tem um arquivo de log, em /var/log/alternatives.log . Se você não tem seu sistema por muito tempo instalado é possível que a resposta de quando está lá e de lá você pode descobrir quem. Suas premissas estão corretas.

    
por 12.12.2013 / 12:34