identifique todos os rpm quebrados / conflitantes e corrija-os * corretamente * Fedora 23, persistente usb

Question

Hoje instalei o Fedora 23 em um USB. Depois que a instalação foi concluída, eu estava fazendo o padrão dnf upgrade , configurações de shell e, finalmente, os preparativos para instalar os drivers NVIDIA (todos os computadores que eu usarei isso têm GPUs NVIDIA).

Eu empurrei meu pen drive USB um pouco demais, já que eu estava fazendo um rsync da minha pasta de 20 GB + ao mesmo tempo como dnf upgrade . Eu percebi que essa era uma idéia terrível, mas eu já paguei mais do que isso.

Diferente do Fedora 23 destruindo o gerenciador de inicialização do meu /dev/sda no computador que ele instalou (independente do fato de eu ter instalado do /dev/sdd ao /dev/sde - USB para USB), em algum momento tudo morreu e o desligamento do computador durante a atualização. Os resultados foram um pouco surpreendentes, e estou muito interessado em tentar descobrir

1. Onde procurar ou melhor como analisar coisas como /var/log* ,
2. Como identificar programaticamente todos os pacotes quebrados e
3. Qual é a maneira correta de corrigi-los é wrt dnf .

Um grande número de pacotes importantes do sistema parece ter duas versões, a anterior à atualização e a que estava sendo atualizada. Isso está tornando a vida difícil de se desenvolver em ...

Exemplos:

Em um computador diferente, terminei o dnf upgrade e tudo parecia bem. Eu atualizei para um novo e brilhante kernel, etc. Após a reinicialização, percebi que, embora o kernel 4.4 tenha sido instalado, o grub é listado apenas como 4.2. Eu estava no processo de desistir e criar vmlinuz do código-fonte quando encontrei um relatório de bug obscuro para o F20 mencionando o mesmo problema, e eles o corrigiram instalando grubby . Muitos comentários depois, descobri que precisava de dnf reinstall kernel-core (eu já tinha grubby e a versão mais recente).

Este tem sido o tema de muitas correções ao longo do caminho, apenas está ocorrendo com alguns pacotes importantes, o que me faz sentir como se alguma outra coisa estivesse acontecendo.

• Tive de remover o conflitante hplip-libs-3.{15,16} (ambos foram instalados e dnf não estava disposto a fazer nada sem remover ambos e, em seguida, instalar 3.16 ).

• Sempre que um comando que não é real foi inserido (por exemplo, typo):

  Failed to search for file: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PackageKit was not provided by any .service files

  • Eu vi muitos posts sobre isso online, especialmente para o gedit. Mas não para um comando não encontrado no terminal.
  • Ok NP dnf search PackageKit oh ok Vou tentar e install então. Mas, como aconteceu, mesmo com reinstall --allowerasing , eu ainda tinha 1.0.10 e 1.0.11 instalado e dnf não cedia.

  • Eu tenho um pouco imprudente neste momento, considerando tudo o que está envolvido com este pacote ...

    dnf remove PackageKit-*
    dnf install PackageKit-*
    dnf list PackageKit-*    # shows 1.0.10
    dnf check-update && dnf upgrade
    dnf list PackageKit-*    # shows 1.0.11 now
    

  • Mas funciona agora, porque as versões conflitantes são reduzidas a uma singularidade novamente.

Algum apontador? Eu tenho andado pelas páginas logs / man do dnf / tentando alguns dos vários utilitários como distro-sync (provavelmente mais do que deveria), mas não consigo descobrir o que está acontecendo.

Esses conflitos continuam aparecendo inesperadamente. Eles têm que acabar, certo?

Olhando para os logs, a única coisa que parece significativa é que em algum momento provavelmente em torno do local onde ocorreu a falha inicial há um monte de caracteres não ascii em /var/log/dnf.rpm.log , ou pelo menos com less aparece como um longa fila de ^@ antes do próximo logging initialized poucas horas depois.