Le contenu de / bin a été déplacé vers / usr / bin, il est possible d'annuler?


18

Sous Ubuntu 17.04, j'installais un logiciel à partir d'une distribution non référentielle, je devais déplacer le contenu du dossier du logiciel vers / usr / bin (ce qui était déjà un conseil)

C'est un de ces jours, alors ce que j'ai fait à la place:

mv /bin/* /usr/bin

J'ai donc foiré et j'ai accidentellement déplacé tous les fichiers du bac vers / usr / bin et / bin était vide. Comme je considère que / bin est critique pour le système, pour y remédier rapidement, j'ai copié le contenu de / usr / bin dans / bin.

Maintenant, mon contenu / bin et / usr / bin sont identiques et contiennent tous les deux les fichiers à l'origine dans / bin et / usr / bin séparés.

  1. Mon Ubuntu est-il en panne maintenant? (N'a pas encore essayé de redémarrer l'ordinateur, en ce moment tout semble toujours fonctionner)
  2. Existe-t-il un moyen de savoir quels fichiers ont été déplacés / copiés vers / usr / bin le plus récemment, afin que je puisse simplement gérer manuellement la situation? 2.1 Y a-t-il généralement des fichiers qui se chevauchent dans / bin et / usr / bin
  3. Y a-t-il d'autres façons d'annuler ce que j'ai fait?

Je n'ai pas installé Timeshift, donc la restauration des sauvegardes n'est pas une option, mais il n'y a actuellement rien de critique sur l'ordinateur, donc je pourrais juste admettre de bousiller réinstaller toute la partition linux.


2
dpkg-query -l | awk '{system ("dpkg-query -L" $ 2 "| grep -E \" ^ / usr / bin /.*$ \ "")}' Cela vous donnera tous les fichiers initialement dans / usr / bin en fonction de les packages installés
Raman Sailopal

7
@ SatōKatsura /binest critique pour le système. Son contenu doit être présent dès les premières étapes de démarrage. Vous ne voulez pas créer un lien symbolique vers une partition ( /usrici) qui ne peut pas être montée au démarrage.
xhienne

1
@xhienne Je n'ai jamais dit qu'il survivrait à un redémarrage. C'est un correctif temporaire, pour obtenir suffisamment de fonctionnalités pour pouvoir réparer le système.
Satō Katsura

1
@xhienne qui dépend de la façon dont vous configurez la distribution. Arch, par exemple, ne conserve pas de séparation /binpar défaut. Le partitionnement par défaut d'Ubuntu ne fait pas de /usrpartitions distinctes . Je suis curieux de savoir combien de personnes font réellement une séparation /usravec une distribution moderne.
muru

1
@muru Prenez mon commentaire comme générique. Vous pouvez supposer ce que vous voulez sur le nombre de partitions, je préfère ne pas le faire et je mets en garde contre la liaison de / usr / bin / * à / bin, ce qui au mieux est complètement inutile et au pire peut rendre le système inutilisable au prochain démarrage . Aucun système qui suit le FHS ne devrait contenir de liens symboliques vers / usr / bin. OP était bien avisé de copier les fichiers à la place.
xhienne

Réponses:


19

Mon Ubuntu est-il en panne maintenant?

Oui, votre Ubuntu est cassé

Vous avez gâché quelque chose d'important pour la gestion des packages .

Donc, dans la pratique, sauvegardez vos données importantes (au moins /etcet /home), peut-être aussi la liste des packages installés, par exemple la sortie de dpkg -l, et réinstallez Ubuntu.

(un non-novice pourrait essayer de gérer - comme dans d'autres réponses -, mais il n'aurait pas fait une erreur aussi énorme et fondamentale)

Je pourrais juste admettre de bousiller réinstaller toute la partition Linux.

C'est probablement ce qui consommerait moins de votre temps. Garder votre système actuel à l'aide d'autres réponses, c'est le garder dans un état très désordonné (ce qui vous donnerait de futurs maux de tête).

Puisque vous reformatez votre disque, envisagez de placer /homeune partition distincte (afin que de telles erreurs futures ne perdent pas vos données). Avant de faire cela, imprimez sur papier la sortie de df -het df -hiet fdisk -l(ils donnent des informations sur l'espace disque -les deux utilisés et disponibles- ...). Soyez sage d'avoir une partition système suffisamment grande (le système de fichiers racine); si vous pouvez vous le permettre, 100 Go sont plus que suffisants.

Je devais déplacer le contenu du dossier du logiciel bin vers / usr / bin

(terminologie: Unix a des répertoires, pas des "dossiers").

Cela ( passer à /usr/bin/) est très faux. Améliorez votre $ PATH (de préférence) ou tout au plus ajoutez des liens symboliques dans /usr/bin/et de préférence déplacez (ou ajoutez des liens symboliques) aux exécutables /usr/local/bin/.

L'approche sage est de ne jamais changer /usr/bin/, /bin, /sbin, en /usr/sbin/ dehors des outils de gestion des paquets (par exemple dpkg, apt-get, aptitude, etc ...). Lisez le FHS .


4
J'accepte cette réponse: il semble qu'après avoir essayé de récupérer, cela a fonctionné jusqu'au redémarrage, qui n'a plus pu lancer de session d'environnement de bureau. Plutôt que d'essayer de résoudre ce problème, je vais admettre mon erreur totale et je réinstallerai simplement la partition Linux. Comme tout était sous contrôle de version et que j'utilisais le système depuis seulement une semaine, tout ce que j'ai vraiment perdu, c'est ma dignité et j'ai eu une petite crise de panique, mais cela semble normal lorsque la vie m'apprend une leçon.
oneOfThoseDays

1
Comme /binet /usr/binsont maintenant identiques, je ne sais pas pourquoi la gestion des paquets serait bousillée. Existe-t-il vraiment un cas où /bin/fooet /usr/bin/foosont tous deux fournis par un ou des packages. Sinon, il y a juste quelques fichiers supplémentaires qui flottent.
StrongBad

3
@Basile non ce ne serait pas (être mécontent); la gestion des paquets ne se soucie que des fichiers qu'elle connaît, elle ne se plaindra pas des fichiers qu'elle ne connaît pas. Même pour les fichiers , il ne sait au sujet, il ne sera pas particulièrement dérangé s'ils ont changé ...
Stephen Kitt

2
@Basile aussi je ne compterais pas sur cette dernière partie "(un non-novice pourrait essayer de gérer - comme dans d'autres réponses -, mais il n'aurait pas fait une erreur aussi énorme et basique)" étant vrai ;-). Même les experts se trompent parfois!
Stephen Kitt

1
FWIW la /partition de mon système principal est de 12 Go et je n'ai jamais rencontré de problème d'espace malgré son utilisation pour le développement (lire les fichiers d'en-tête et de nombreux outils), le bureau et la conception (lire les outils lourds), sur KDE (lire pas le plus mince). Ajoutez 4 Go de plus si vous ne vous séparez pas /var, gonflez de 25% si vous voulez une marge plus grande que moi, et à 20 Go, vous êtes plus que bon.
spectres

36

Sous Linux (et sur la plupart des autres systèmes, bien que POSIX ne vous donne pas cette garantie à moins que le déplacement n'ait eu lieu sur les systèmes de fichiers), cela aurait mis à jour leur heure de connexion, donc en supposant qu'aucun des autres /usr/binn'a été touché au cours des dernières 24 heures , vous devriez pouvoir les reculer avec:

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

Retirez le echosi cela vous semble correct. Notez que vous ne pourrez pas récupérer les fichiers qui existaient sous le même nom dans /binet /usr/bin(ceux d'origine dans /usr/binauraient été perdus)

Une mise en garde potentielle: si certains fichiers étaient liés en dur dans les deux /binet /usr/bin, tous les liens en dur /usr/binseraient déplacés vers /bin.

Maintenant, vous pouvez penser que puisque /binet /usr/binsont dans la valeur par défaut $PATH, et /binest disponible /bootau moins avant le /usrmontage, peu importe que les exécutables soient à la /binplace de /usr/bin.

Mais ce serait ignorer que de nombreuses commandes codent en dur les chemins des exécutables et s'attendent à ce qu'elles le soient dans certains cas spécifiques. Un cas commun est la frange. Tous les scripts qui ont:

#! /usr/bin/env bash

ne fonctionnera pas après vous mv /usr/bin/env /bin/env. À cet égard, avoir les commandes dans les deux emplacements est plus sûr car il ne cassera pas ces scripts.


3
Comme mentionné ci-dessus (j'ai supprimé mon commentaire car il y avait une grave erreur qui tenterait de tout déplacer vers un répertoire appelé - idésolé à ce sujet!) Sur les systèmes GNU / Linux comme Ubuntu, on peut utiliser find /usr/bin/. ! -name . -prune -ctime -1 -exec echo mv -it /bin {} +depuis GNU Coreutilsmv prend en charge -t. Les autres systèmes d'exploitation ne le prennent généralement pas en charge et ne fonctionnent pas dans l'alternative mvfournie par BusyBox .
Eliah Kagan

17
  1. Votre installation devrait être en grande partie OK; il ne devrait pas y avoir de fichiers différents avec le même nom dans /usret /usr/bin(qui répond à votre 2.1), donc avoir tous les fichiers dans les deux /binet /usr/binne cassera rien (jusqu'à ce que vous mettiez à jour les packages). Le seul problème que vous pourriez avoir maintenant est celui des liens symboliques cassés, si vous avez remplacé un binaire par un lien symbolique. Pour résoudre ce problème, recherchez les liens symboliques rompus:

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

    et réinstallez tous les packages correspondant aux fichiers répertoriés (par exemple, s'il /usr/bin/zshapparaît comme cassé, dpkg -S /bin/zsh /usr/bin/zshvous indiquera de quel package provient le fichier; réinstallez-le avec apt --reinstall install zsh).

  2. Vous pouvez afficher et trier par ctime pour voir les fichiers qui ont été récemment modifiés (qui incluront les fichiers que vous avez déplacés):

    ls -ltc /bin
    
  3. La meilleure approche pour annuler ce que vous avez fait est d'utiliser le cruftpackage et de supprimer les fichiers qu'il trouve /binou /usr/binqui ne proviennent pas d'un package:

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

    sauf si les fichiers sont des liens symboliques vers des fichiers dans /etc/alternatives(auquel cas vous devez les laisser seuls).


Sauf pour les scripts commençant par #! /bin/shou similaires.
Satō Katsura

@ SatōKatsura, ils fonctionneraient toujours bien si se shtrouve dans les deux /binet /usr/bin(tous les fichiers sont dupliqués maintenant).
Stephen Kitt

1
Une boîte à outils spéciale comme cruftn'est pas nécessaire pour ce travail car le gestionnaire de packages garde également une trace des fichiers installés. Voir unix.stackexchange.com/questions/153260/… .
Ned64

1
comm -12 <(ls /bin) <(ls /usr/bin)montrer quelques entrées sur un système Ubuntu sur lequel je l'ai testé. Certains avec un /bin/foo -> /usr/bin/foomoyen fooqui aurait été perdu.
Stéphane Chazelas

@ Stéphane ah oui, déplacer le lien nuke l'original ...
Stephen Kitt

6

Il peut être instructif d'expliquer pourquoi votre système est, dans une plus ou moins grande mesure, «cassé».

  1. Comme le souligne @ basile-starynkevitch, le système de gestion des packages a le potentiel de devenir très confus s'il trouve des fichiers binaires /binquand ils devraient l'être /usr/bin, et vice versa.
  2. Certains scripts (peut-être importants) peuvent être câblés pour trouver un binaire particulier dans un répertoire ou dans l'autre (dans certaines circonstances, c'est une bonne pratique, par exemple du point de vue de la sécurité, de ne pas se fier au contenu du $PATH).
  3. La raison pour laquelle il existe une distinction entre /binet /usr/binest que la première peut potentiellement se trouver sur une partition qui est montée à un stade antérieur du démarrage. Dans ce contexte (c'est-à-dire lors du démarrage du système), non seulement les /bin/xxxbinaires seraient probablement référencés par un chemin complet, mais le répertoire /usr/binpourrait ne pas être disponible sur le système à ce stade. (Si vous df /binet df /usr/bin, vous pouvez voir le même système de fichiers répertorié, ou différents; probablement la plupart des installations par défaut, de nos jours, laissez les deux répertoires dans la même partition).

Ainsi, vous pouvez doubler voir que, si vous avez les mêmes binaires dans les deux /binet /usr/bin, alors les problèmes 2 et 3 ne se produiront pas, et les dégâts de 1 pourraient être mineurs. Par exemple, les packages peuvent ne pas être correctement désinstallés si vous essayez de les supprimer; et les mises à niveau peuvent se brouiller si la mise à niveau tente de mettre à niveau la copie au bon endroit, mais ignore la copie au mauvais endroit. Ainsi, si les remèdes ci-dessus semblent trop drastiques ou compliqués, vous pourriez vous en sortir en laissant le système dans cet état.

Mais s'il s'agit d'un système important, je ne miserais vraiment pas là-dessus.

Une règle générale (faisant écho à @ basile-starynkevitch) est de ne jamais faire de singe avec /usr/bin, /binet amis - ils `` appartiennent '' à la distribution - et un paquet qui suggère de le faire dans le cadre de son installation normale n'est ... pas un bon paquet.

Edit: Relevant du point 3, il y a une discussion dans le contexte de systemd / Fedora et ses amis pour savoir pourquoi il est logique de déplacer tout le contenu de /binvers /usr/binet de créer un lien symbolique entre le premier et le second. Ce n'est pas une recommandation que vous le fassiez vous-même - cette page s'adresse aux personnes qui font des distributions - mais elle comprend un historique des raisons pour lesquelles cette distinction existe (et implicitement pourquoi elle est maintenant simplement une tradition poussiéreuse).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.