Forum Linux.debian/ubuntu problème avec le /lib

Posté par  .
Étiquettes : aucune
0
2
mai
2008
Bonjour,

Voila par mégarde j'ai lancer une commande fatale mv /lib /home/.... Je n'ai pas fait attention et du coup j'ai bougé l'emplacement de toutes les librairies et je n'ai plus accès à mes commandes de base ype cp, mv etc ...pour rétablir mon dossier (les commandes ne trouvent plus les librairies nécessaires :(). Si je ferme ma console ssh je ne pourrai plus la rouvrir et du coup je cherche une solution.

Est il possible de redéfinir par une variable l'emplacement du /lib pour dire a mes commande système de ne plus aller chercher les lib dans /lib mais dans le répertoire ou j'ai par mégarde déplace les fichiers.
J'ai vu la variable $LD_LIBRARY_PATH mais en changeant, cela ne résout pas mon problème.

Quelqu'un peut il m'aider ?

Merci d'avance
  • # livecd

    Posté par  . Évalué à 2.

    à mon avis tu devrais essayer avec un livecd. Mais vu que tu parles de console ssh, je présume que tu es à distance.
    Tu peux essayer avec un lien symbolique (genre ln -s /home/lib /lib ) mais je ne sais pas si cela fonctionnera aussi.
    Il y a également busybox, si c'est installé tu peux tenter le coup, mais pareil, cela utilise des appels à des bibl. dans /lib

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: livecd

      Posté par  . Évalué à 1.

      Oui je suis à distance j'ai bien pensé avec avec un livecd type Ubuntu mais ca me fait me déplacer ce que je voudrai éviter mais si a priori il n'y pas de solutions comme dit le proverbe "quand on a pas de tetes on a des jambes " dommage :(
      Mais si quelqu'un voit une soluce j suis preneur :)
      • [^] # Re: livecd

        Posté par  . Évalué à 2.

        Bonjour,

        Tu peux essayer la méthode suivante:

        export LD_LIBRARY_PATH=le_nouveau_chemin

        Ensuite, le mv réparateur devrait passer...
    • [^] # Re: livecd

      Posté par  . Évalué à 2.

      pour le LD_LIBRARY_PATH je présume que tu as fait correctement l'exportation ? Sinon la syntaxe devrait être (en bash) :

      export LD_LIBRARY_PATH=/home/lib

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: livecd

        Posté par  . Évalué à 1.

        oui c'est ce que j'ai fait
      • [^] # Re: livecd

        Posté par  . Évalué à 1.

        Oui c'est bien ce que je fais et quand je fais un echo de la variable, elle s'affiche bien avec la nouvelle valeur
      • [^] # Re: livecd

        Posté par  (site web personnel) . Évalué à 2.

        tu peux essayer de voir les autres variables d'environnement dans man ld-linux.so

        Mais je trouve ça bizarre que LD_LIBRARY_PATH ne marche pas.

        Je suppose que su ou sudo doivent supprimer ces variables (pour des raisons de sécurité). Et ld-linux.so ne les prend pas en compte si le binaire est suid ou sgid. mais je doute que ce soit le cas pour mv.

        Tu peux peut être essayer de faire:

        LD_PRELOAD=/home/.../lib/{libc.so,libacl.so,libattr.so} mv /home/.../lib /

        Et vérifie en utilisant cd et echo * que le dossier lib est lien la ou tu penses. Car si ça se trouve tu avait un dossier lib dans ton homedir, et du coup il aurait déplacé le tout dans ~/lib/lib
  • # RE

    Posté par  . Évalué à 1.

    OUi quand je fais un echo j'ai bien la bonne valeur
  • # un shell avec des builtins

    Posté par  (site web personnel) . Évalué à 2.

    Si tu as un autre shell d'installé (et compilé en statique), tu peux essayer de le lancer. Avec un peu de chance, la commande ln ou mv sera en builtin et ça marchera.

    Sinon, tu peux essayer de compiler une commande mv statique (ou la libc) et de l'envoyer avec scp (si ça marche)

    si tu utilise bash, de mémoire echo est un builtin. Donc echo * est un peu équivalent à un ls
    • [^] # Re: un shell avec des builtins

      Posté par  . Évalué à 1.

      effectivement le echo marche ainsi que le cd, mais impossible de compiler car je ne peux envoyer en scp. lorsque je veux me connecter en ssh , la session plante et ne s'ouvre pas. Il ne reste que ma session ssh que j'ai peur de fermer ...
      • [^] # Re: un shell avec des builtins

        Posté par  (site web personnel) . Évalué à 2.

        J'ai essayé avec dash de faire

        zcat -f >mv
        (contenu de mv.gz)
        Ctrl-D

        Mais ça ne marche pas :(

        Si tu avais quelque chose comme uudecode compilé en static ça serait super :/
    • [^] # Re: un shell avec des builtins

      Posté par  (site web personnel) . Évalué à 3.

      Et regarde dans /bin les commande statiques que tu peux utiliser. Chez moi (ArchLinux) j'obtiens (avec ldd):

      /bin/bashbug:
      not a dynamic executable
      /bin/dash:
      not a dynamic executable
      /bin/gunzip:
      not a dynamic executable
      /bin/uncompress:
      not a dynamic executable
      /bin/zcat:
      not a dynamic executable

      ça ne fait pas beaucoup ...
      Mais avec un peu de chance dash a peut être des builtins intéressants ... Mais en regardant la page man, ça n'en a pas l'air. :(

      Sinon, tu peux peut être essayer quelque chose du style

      cat >mv
      (colle le code binaire de la commande mv)Ctrl-D

      Par contre tu n'aura peut être pas les permissions d'exécution, chmod n'est peut être pas un builtin mais umask l'est probablement.

      Le problème c'est que cat n'est pas un builtin chez moi. Tu peux peut être alors essayer zcat qui est compilé en static.
  • # RE

    Posté par  . Évalué à 1.

    Je n'ai ni gunzip, ni cat ni zcat, je crois que je suis parti pour me déplacer :(
    • [^] # Re: RE

      Posté par  . Évalué à 2.

      Salut,

      Pour répondre à un message, utilise le lien en bas de ce dernier ;)

      Sinon c'est pas très lisible.
    • [^] # Re: RE

      Posté par  . Évalué à 2.

      je pense que tu n'as pas moyen de télécharger non plus. Car sinon tu te compiles chez toi un busybox en statique, et tu lances tes commandes depuis celui-ci après l'avoir téléchargé sur l'autre machine. Mais wget ou curl font tous appel à des fichiers dans /lib

      Qqu'un a une autre idée pour télécharger à distance ? Ftp cela risque d'être pareil, etc

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # RE

    Posté par  . Évalué à 1.

    j'y ai pensé aussi, mais impossible de faire un wget ou un ftp

    Mais merci en tout cas a tous pour votre aide
  • # ld-linux.so.2

    Posté par  (site web personnel) . Évalué à 1.

    Essaye un :

    /home/.../lib/ld-linux.so.2 /bin/mv /home/.../lib /

    Et normalement tout devrait rentrer dans l'ordre ;-)
    • [^] # Re: ld-linux.so.2

      Posté par  (site web personnel) . Évalué à 4.

      Je reprends, après test dans une machine virtuelle :

      naupetit:/# mv lib /home/
      mv: ne peut détruire le répertoire `lib/init/rw': Device or resource busy

      (Avec un petit reste de /lib/init/rw/ occupé par un montage tmpfs qui complique un peu les choses)

      naupetit:/# ls
      -bash: /bin/ls: No such file or directory

      naupetit:/# /home/lib/ld-linux.so.2 /bin/ls
      /bin/ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory


      naupetit:/# LD_LIBRARY_PATH=/home/lib /home/lib/ld-linux.so.2 /bin/ls
      bin boot dev etc home initrd lib lost+found media mnt opt proc root sbin srv sys tmp usr var


      naupetit:/# LD_LIBRARY_PATH=/home/lib /home/lib/ld-linux.so.2 /bin/mv /home/lib/* /lib/
      /bin/mv: échec de déplacement inter-périphérique: `/home/lib/init' vers `/lib/init'; incapable de détruire la cible: Is a directory

      (Pas très grave comme erreur)

      naupetit:/# ls
      bin boot dev etc home initrd lib lost+found media mnt opt proc root sbin srv sys tmp usr var

      Et là ça fonctionne :-)
  • # rm -rf

    Posté par  . Évalué à 2.

    Ton histoire me fait un peu penser à cette histoire de rm -rf : http://www.justpasha.org/folk/rm.html.

    Dans les deux cas, c'est impressionnant de voir de quelle manière on peut s'en tirer sous Unix avec les outils de base et un peu de réflexion, là où beaucoup d'autres systèmes seraient à genoux.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.