Bonsoir !
 
Bon, belle boulette qui j'imagine est arrivé à d'autres (j'espère histoire d'avoir l'air moins ridicule...)
 
Depuis la racine, voulant effacer le contenu d'un répertoire, j'ai taper comme un idiot la commande :

 
bien sur, avec "*" en 1er au lieu de le foutre après le répertoire pour en désigner son contenu...
 
bref, erreur sur la suppression des répertoires (encore heureux que j'ai pas fait un rm -R, bien que je ne suis pas sur que ça soit récupérable)
 
j'ai une bécane quasi identique à coté, quand je regarde le contenu de la racine, je n'ai que des répertoires, et 3 liens symboliques, aucun fichiers. Donc j'imagine que ma commande précédente n'a supprimé que les liens symboliques (init.img, lib64 et vmlinuz) mais ça doit suffire pour empêcher tout reboot j'imagine...
 
Je ne peux plus ouvrir d'autre console ssh, mon serveur ne tient donc plus que par un fil ^^
 
par contre toute commande lancer dans la console ssh se solde par un

 
Même en tapant directement "/bin/ls" j'obtiens la même erreur, pourtant j'imagine que le contenu de /bin est toujours présent...
 
la commande "cd" marche encore, je peux au moins naviguer dans les répertoires ! mais bon je ne suis pas sorti d'affaire...
 
pour info, qu'est-ce que mon "rm" a pu supprimer pour que je perde l'accès aux commandes ?
 
Bizarrement si je tape "ls" depuis la racine il sait que ls se situe dans /bin/ mais il indique ne pas le trouver alors qu'il y ai bien...
 

 
c'est grave docteur ?
 
1ère question, si seuls ces 3 liens ont étés supprimés, les recréer permettrait-il de récupérer cette énorme erreur ?
2ème question, comment faire pour exécuter quoique ce soit si les commandes ne me renvoient que des erreurs ?
 
Au moins celle là je m'en souviendrai...
 
Merci pour ceux qui sauront m'aider, ainsi qu'à ceux qui sauront être compatissant ^^

Ta session SSH est toujours ouverte ?

Déjà récupères busybox par wget :

Tu pourra récupérer les commandes de base déjà.

edit oublié un petit détail pour que ce soit plus simple :

récupérer d'ici (sans la partie wget) :
http://www.busybox.net/FAQ.html#getting_started

car tu as deux moyens d'utiliser busybox :
soit directement : busybox <le_nom_de_la_commande>
soit indirectement : faire ln -s busybox <le_nom_de_la_commande> et utiliser <le_nom_de_la_commande> après

Tu peux mettre ceci en place pour éviter que le problème ne se reproduise.

Y a que moi qui trouve bizarre qu'un rm sans être root, sans -r produise cet effet ?
Tu étais bien en utilisateur normal ?

Possible que l'absence de /lib64 fasse que le ls ne marche plus.
 
Je vais tester dans une VM, tiens

Je confirme
 
Le plus simple pour réparer, vu que quasiment toutes les commandes vont merder, y compris le ln, c'est de passer par un LiveCD (si possible).

tu peux essayer echo * pour lister les fichiers.

ce topic me fait tout de suite penser à cet article que j'ai lu l'autre jour, un rattrapage légendaire d'un rm -rf * en root, en 1986.
Ils avaient perdu le /bin, /etc/, /dev, /lib donc plutôt dans la merde! mais la commande ayant été interrompue il leur restait au moins le /usr et ils pouvaient exécuter des programmes qui se trouvaient dedans.

http://www.ee.ryerson.ca/~elf/hack/recovery.html

Ils avaient un shell root et un emacs (pas mal quand même mais disent-ils, ils auraient pu bricoler avec /usr/bin/grep) et des bandes magnétiques pour restaurer ce qui avait été détruit mais.. comment les lire? et impossible de rebooter également.

Le echo marchera pas plus AMHA

sauf si echo est aussi intégrée au shell.

sinon, qu'est-ce que c'est comme lien symbolique, /lib64? (je n'ai pas de système 64bits sous la main)

imaginons que ce soit /lib/tartempion, ne peut-on pas faire un export LD_LIBRARY_PATH=/lib/tartempion, et recréer les liens.