Conteúdo movido / bin para / usr / bin, possível desfazer?

Question

Rodando o Ubuntu 17.04, eu estava instalando um software a partir da distribuição sem repositório, eu deveria mover o conteúdo da pasta bin do software para / usr / bin (que já era um conselho duvidoso)

É um daqueles dias, então o que eu fiz em vez disso:

mv /bin/* /usr/bin

Então eu estraguei tudo e movi acidentalmente todos os arquivos em bin para / usr / bin e / bin estava vazio. Como eu considero que / bin é crítico para o sistema, para solução rápida, copiei o conteúdo de / usr / bin para / bin.

Agora meus conteúdos / bin e / usr / bin são idênticos e ambos contêm os arquivos originalmente em / bin e / usr / bin separados.

1. O meu Ubuntu está em um estado quebrado agora? (Não tente reiniciar o computador ainda, agora tudo parece ainda funcionar)
2. Existe uma maneira de saber quais arquivos foram movidos / copiados para / usr / bin mais recentemente, então eu poderia apenas cuidar manualmente da situação? 2.1 Existem arquivos sobrepostos em / bin e / usr / bin
3. Existem outras maneiras de desfazer o que eu fiz?

Eu não tenho o Timeshift instalado, então restaurar backups não é uma opção, mas não há nada crítico no computador atualmente, então eu poderia admitir que você deve reinstalar toda a partição linux.

    

Answer 1

Is my Ubuntu in a broken state now?

Sim, o seu Ubuntu está quebrado

Você estragou algo importante para o gerenciamento de pacotes .

Portanto, na prática, faça backup de seus dados importantes (pelo menos /etc e /home ), talvez também a lista de pacotes instalados, por exemplo, saída de dpkg -l e reinstale o Ubuntu.

^{(um não principiante poderia tentar gerenciar - como em outras respostas -, mas então ele não teria cometido um erro tão grande e básico)}

I could just admit to screwup reinstall the whole linux partition.

Isso é provavelmente o que consumiria menos do seu tempo. Manter seu sistema atual com a ajuda de outras respostas é mantê-lo em um estado muito confuso (o que lhe daria dores de cabeça futuras).

Como você está reformatando seu disco, considere colocar /home em uma partição separada (para que futuros erros não percam seus dados). Antes de fazer essa impressão em papel, a saída de df -h e df -hi e fdisk -l (eles fornecem informações sobre o espaço em disco - ambos usados e disponíveis - ...). Seja prudente ter uma partição de sistema grande o suficiente (o sistema de arquivos raiz); se você puder pagar 100 Gbytes é mais que suficiente.

I was supposed to move the software bin -folder contents to /usr/bin

(terminologia: Unix tem diretórios, não "pastas").

Isso ( movendo para /usr/bin/ ) está muito errado. Ou melhore o seu $ PATH (de preferência) ou no máximo adicione symlinks em /usr/bin/ e, de preferência, mova (ou adicione links simbólicos) executáveis para /usr/local/bin/ .

A abordagem mais inteligente é nunca alterar /usr/bin/ , /bin , /sbin , /usr/sbin/ fora das ferramentas de gerenciamento de pacotes (por exemplo, dpkg , apt-get , aptitude , etc ...). Leia o FHS .

    

Answer 2

No Linux (e na maioria dos outros sistemas, embora o POSIX não lhe garanta essa garantia a menos que a mudança fosse através de sistemas de arquivos), isso teria atualizado sua hora, assumindo que nenhuma das outras em /usr/bin foram tocado nas últimas 24 horas, você deve ser capaz de movê-los de volta com:

find /usr/bin/. ! -name . -prune -ctime -1 -exec sh -c '
   echo mv -i "$@" /bin' sh {} +

Remova o echo se parecer correto. Observe que você não poderá recuperar os arquivos que existiam com o mesmo nome em /bin e /usr/bin (os originais em /usr/bin teriam sido perdidos)

Uma advertência em potencial: se alguns arquivos estivessem com link físico em /bin e /usr/bin , todos os links físicos em /usr/bin seriam movidos para /bin .

Agora, você pode pensar que, como /bin e /usr/bin estão no padrão $PATH , e /bin está disponível em /boot pelo menos antes de /usr ser montado, não importa se o executáveis estão em /bin em vez de /usr/bin .

Mas isso seria ignorar que muitos comandos codificam os caminhos dos executáveis e esperam que eles estejam em algum caso específico. Um caso comum é she-bangs. Todos os scripts que possuem:

#! /usr/bin/env bash

não funcionará depois que você executar mv /usr/bin/env /bin/env . A esse respeito, ter os comandos em ambos os locais é mais seguro, pois não quebrará esses scripts.

    

Answer 3

1. Sua instalação deve ser na maior parte OK; não deve haver arquivos diferentes com o mesmo nome em /usr e /usr/bin (que responde ao seu 2.1), portanto, ter todos os arquivos em /bin e /usr/bin não quebrará nada (até que você faça upgrade de pacotes ). O único problema que você pode ter agora é links simbólicos quebrados, se você sobrescreveu um binário com um symlink para ele. Para corrigir isso, procure por links simbólicos quebrados:

   find -L /bin /usr/bin -type l -ls
   

   e reinstale todos os pacotes correspondentes aos arquivos listados (por exemplo, se /usr/bin/zsh aparecer como quebrado, dpkg -S /bin/zsh /usr/bin/zsh informará de qual pacote o arquivo veio; reinstale-o com apt --reinstall install zsh ).

2. Você pode mostrar e ordenar por ctime para ver os arquivos que foram alterados recentemente (que incluirão os arquivos que você moveu):

   ls -ltc /bin
   

3. A melhor abordagem para desfazer o que você fez é usar o pacote cruft e excluir os arquivos encontrados em /bin ou /usr/bin que não são de um pacote:

   sudo apt install cruft
   sudo cruft -d "/ /usr"
   

   a menos que os arquivos sejam links simbólicos para arquivos em /etc/alternatives (caso em que você deve deixá-los em paz).

Answer 4

Pode ser educativo elaborar apenas por que seu sistema é, em maior ou menor grau, "quebrado".

1. Como aponta o basile-starynkevitch, o sistema de gerenciamento de pacotes tem o potencial de ficar muito confuso se encontrar binários em /bin quando eles devem estar em /usr/bin e vice-versa.
2. Alguns scripts (possivelmente importantes) podem ter hard-wired para encontrar um binário específico em um diretório ou outro (em algumas circunstâncias, é uma boa prática, por exemplo, do ponto de vista da segurança, não para confiar no conteúdo do $PATH ).
3. A razão pela qual há uma distinção entre /bin e /usr/bin é que a primeira pode estar em uma partição montada em um estágio anterior da inicialização. Neste contexto (isto é, ao inicializar o sistema), não apenas /bin/xxx binários provavelmente seriam referenciados por um caminho completo, mas o diretório /usr/bin poderia não estar disponível no sistema naquele ponto. (Se você for df /bin e df /usr/bin , poderá ver o mesmo sistema de arquivos listado, ou diferentes, provavelmente a maioria das instalações padrão, atualmente, deixará os dois diretórios na mesma partição).

Assim, você pode deixar claro que, se você tiver os mesmos binários em /bin e /usr/bin , os problemas 2 e 3 não ocorrerão, e os danos de 1 poderão ser menor. Re 1, por exemplo, os pacotes podem não ser adequadamente desinstalados se você tentar removê-los; e as atualizações podem ficar distorcidas se a atualização tentar atualizar a cópia no local "correto", mas ignorar a cópia no lugar "errado". Assim, se os remédios acima parecerem muito drásticos ou complicados, você pode escapar do sistema nesse estado.

Mas se este for um sistema importante, eu realmente não apostaria nisso.

Uma regra geral (novamente ecoar @ basile-starynkevitch) é nunca manipular com /usr/bin , /bin e amigos - eles 'pertencem' à distribuição - e um pacote que sugere fazê-lo como parte de sua instalação normal não é um bom pacote.

Edit: Relevante para o ponto 3, há uma discussão no contexto do systemd / Fedora e amigos de por que faz sentido mover todo o conteúdo de /bin para /usr/bin e criar uma ligação simbólica do primeiro para o segundo. Isto não é uma recomendação de que você faça isso, você mesmo - essa página é endereçada às pessoas que fazem distribuições - mas inclui um histórico de por que essa distinção existe (e por implicação porque agora é meramente poeirento). tradição).