/ bin / etc / lib64 / root / sbin eliminado o movido por la carpeta mv / * / * mientras su


11

El sistema operativo es Centos 6.5 de 64 bits

Descargué un archivo tar y quería descomprimirlo mv.

Me desligé, luego accidentalmente (como root) ejecuté en mv folder/* /*lugar de mv folder/* .bash, dije que no podía sobrescribir algunos archivos, luego pedí permiso para otros. Ctrl-c'd fuera.

He dejado abierta la sesión de terminal, pero he salido su.

Ahora he perdido el acceso a la mayoría de los shellcomandos, no puedo lsningún directorio y no puedo volver a su.

El servidor web y los servicios todavía parecen estar ejecutándose. Puedo ejecutar muy pocos comandos, cdes uno de ellos y cuando trato de cdhacerlo /etco /binerrores no directory found.

EDITAR Sólo se dio cuenta de todas las carpetas que faltan de /( bin, etc, lib64, root, sbin) nos trasladaron al /vardirectorio, probé /var/bin/suy sale: -bash: /var/bin/su: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory


1
¿No puedes correr /var/bin/sudirectamente?
Darkhogg

Por favor, no edite la pregunta con soluciones. En la red de intercambio de pila, prefiere agregar una respuesta, dejar un comentario en una respuesta existente para mejorar una respuesta.
Bernhard

@Darkhogg /var/bin/su: user root does not existCreo que determinamos que no se puede hacer porque / etc está en / var / etc
webaholik

@Bernhard trató de corregir
webaholik

Respuestas:


22

Si su sistema se ha busyboxinstalado, puede usar esto para volver a poner las cosas.

busyboxes un binario con muchas utilidades estándar incorporadas. Las cosas tales como mv, sh, ls, etc.

Por su comentario sobre la respuesta de Pavel, parece que todo terminó en /var. Puedes intentar hacerlo /var/bin/busybox mv /var/{bin,etc,lib32,lib64,root,sbin,usr} /. Eso debería volver a poner en funcionamiento la mayor parte de su sistema. Hay algunos directorios como los /tmpque también existen como /var/tmp, por lo que no puede simplemente moverlos. Con suerte, esos son los que se mvquejaron y se quedaron solos.

 

Conseguir un shell de raíz

También mencionó que perdió su shell raíz, y eso le suestá dando un ld-linuxerror de biblioteca. Es posible que pueda usar lo siguiente:

LD_LIBRARY_PATH=/var/lib64 /var/lib64/ld-linux-x86-64.so.2 /var/bin/su

Nota: Al intentar esto, no funciona. Esto se debe a que surequiere varios archivos en /etc( passwd, pam.dy otros). Si /etcaún estuviera intacto, esto tendría una buena posibilidad de tener éxito.

 

Sin busybox

Si no tiene busybox disponible, es posible que pueda usar el mismo truco ld-linux que para su:

LD_LIBRARY_PATH=/var/lib64 /var/lib64/ld-linux-x86-64.so.2 /var/bin/mv /var/{bin,etc,lib32,lib64,root,sbin,usr} /

 

De un CD en vivo

Como se discutió en los comentarios, si ha perdido el shell raíz, está bastante atascado. Básicamente para solucionar esto, necesita privilegios de root. La única forma de llegar allí es tener una utilidad como suo sudoescalar sus permisos (ambos no son funcionales en este momento), o secuestrar otro programa que ya se está ejecutando como root (dependiendo de lo que se está ejecutando, no es posible).

Esto deja la única opción de ser un CD en vivo. Una vez arrancado en un CD en vivo (o USB en vivo, o lo que sea), simplemente monte el volumen raíz y mueva los directorios afectados de /varregreso a su hogar original /.


Sinopsis de lo sucedido

folder/*se habría expandido a algo como folder/fooy folder/bar.
/*se habría expandido a algo así /bin /lib32 /lib64 /etc /home /root /var. Observando que /vares el último artículo.
Entonces, cuando el caparazón expandió todos esos globos, habría corrido algo como esto:

mv folder/foo folder/bar /bin /lib32 /lib64 /etc /home /root /var

Como /vares el último elemento de la lista, todo se movió a él.


¿Por qué /var/bin/suerrores con/lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

Casi todos los binarios en Linux están vinculados dinámicamente ld-linux. ld-linuxes la biblioteca responsable de cargar las otras bibliotecas que necesita un binario. En su sistema esto vive en /lib64/ld-linux-x86-64.so.2. Como este directorio se movió, cualquier ejecutable vinculado dinámicamente ya no funcionará.

La razón por la que busybox funciona es porque busybox está estáticamente vinculado. No utiliza ld-linux.


Buena idea. CentOS generalmente tiene un busybox instalado debido a initramfs , por lo que podría funcionar bien.
Pavel Šimerda

busyboxParece que la solución perfecta, desafortunadamente no está instalada, después de que esto se solucione ... Mientras tanto, ¿hay alguna forma de corregir la ruta para que los comandos se ejecuten en /var/lib64/ld-linux-x86-64.so.2lugar de /lib64/ld-linux-x86-64.so.2? Esto parece ser lo que está matando los comandos en/var/bin
webaholik

@Patrick: ¿Podría agregar la información de que también el comando OP destinado a utilizar es incorrecto? Entonces podría eliminar mi respuesta ya que ahora es (casi) redundante. ¿Es la forma correcta de usar el intercambio de pila, por cierto?
Pavel Šimerda

1
Está buscando varias cosas en /etcque no hay ( /etc/passwd, /etc/nsswitch, /etc/pam.d, y probablemente más). Para sutrabajar, /etcdebe estar de vuelta en su ubicación original. A menos que tenga una cáscara de raíz por ahí, creo que está atrapado :-(
Patrick

2
@ user1296209 Una vez que obtenga un livecd, simplemente monte el volumen raíz y mueva esos directorios hacia atrás. Eso debería ser todo lo que necesita para volver a funcionar.
Patrick

10

mv folder/* ./*Está mal también. Debe tener más cuidado con la semántica de los comandos que ejecuta. El mvcomando con más de dos argumentos solo toma todos los argumentos excepto el último y mueve las rutas a las que apuntan al directorio especificado en el último argumento.

Para mover todos los directorios (excepto los ocultos) de la carpeta al directorio actual, debe usar:

mv folder/* .

Has roto tu sistema en ejecución. Sus comandos de shell y de construcción continúan funcionando. Tendrá que iniciar un CD en vivo y mover los directorios hacia atrás. No conozco un bash incorporado para mover / cambiar el nombre de los archivos que le permitiría solucionar la situación sin reiniciar, consulte la respuesta de Patrick para obtener más detalles.


No me di cuenta de eso: puedo cd a / var / bin & / var / etc, parece que las carpetas se movieron a var, de todos modos, ¿puedo moverlas de nuevo? ... ¿sin livecd?
webaholik

Intenté / var / bin / su & get: -bash: / var / bin / su: /lib64/ld-linux-x86-64.so.2: mal intérprete ELF: No
existe

Ajá ... arreglaré la respuesta.
Pavel Šimerda

¿Cuál debería mvhaber sido mi comando para mover todos los archivos y carpetas de la carpeta al directorio actual?
webaholik

1
@ user1296209: Si inicia un sistema en vivo, ciertamente tiene acceso de root en su sistema de vida. Su sistema actual es solo una partición montada sin un significado especial para el sistema en vivo. La única complicación es que sus directorios /y /varpueden estar en particiones diferentes, en cuyo caso debe montar ambos.
celtschk

2

Accidentalmente me mudé / usr a / usr_old y todo se fue al infierno. Afortunadamente, me quedé en el indicador y pude ejecutar el siguiente comando para restaurar la carpeta usr:

LD_LIBRARY_PATH=/usr_old/lib64 /usr_old/lib64/ld-linux-x86-64.so.2 /usr_old/bin/mv /usr_old /usr

Bienvenido a U&L, ¿fue ese el único comando que escribió? Proporcione un procedimiento más detallado. (especialmente para una pregunta de diez meses, no hay necesidad de apurarse)
Archemar

1
Sí, después de escribir ese comando, todo fue restaurado. Tal vez debería mencionar que fui root durante todo esto.
Mansehr

1

IMPORTANTE Si está aquí y se ha ejecutado mvincorrectamente, no puede ejecutar shellcomandos y faltan carpetas en el directorio raíz ( /), en primer lugar, si tiene SU, NO salga SUhasta que se solucione, porque no lo recuperará. Si está conectado de forma remota, si se desconecta, no podrá ssh, deje el servidor solo, no lo haga reboot: la mayoría de los servicios en ejecución deberían estar bien. Puede intentar una de las muchas soluciones sugeridas por Patrick ... sin embargo, es probable que necesite acceso físico si cometió un error como lo hice yo.

Una vez frente a la máquina, la reinicié. Como se esperaba, recibí un kernel panic.

Pensé que esto sería una solución bastante fácil, inserte livecd, ingrese al modo de rescate HASTA ESTE PUNTO FUE FÁCIL, luego tuve que intentar montar mi directorio raíz. Sin embargo, necesitaba más que un simple comando de montaje.

Esto se debió a que, como muchas personas, tenía un sistema de archivos lvm, y esta fue la primera vez que tuve que lidiar con un rescate como este. Tuve que buscar en la web para ver lo que necesitaba hacer. He consolidado esa información en esta publicación. Aquí estaba mi proceso para solucionar mi problema.

1) insertado Centos_6.4_min cd

2) La interfaz GUI me preguntó qué quería hacer, elegí Rescue

3) Rescue intentó montar el sistema actual, pero indicó que no tenía particiones de Linux

4) Elija ingresar shellcuando se le dio la opción

En este punto intenté muchas cosas para montar el sistema, sin suerte, estoy bastante seguro de que estos son todos los pasos que tuve que seguir (debido a lvm):

5) Escaneé mis volúmenes,

lvmdiskscan

6) Ran lvscan, mostró todos los listados como "inactivos"

lvscan

7) cargar el módulo del dispositivo

modprobe dm-mod

8) cambie los volúmenes que existen a activos

vgchange -ay

9) lvscanVolvió a funcionar , ahora todos los elementos enumerados como "activos"

10) Creó el punto de montaje y montó la partición lógica

mkdir /mnt/root

mount /dev/VolGroup00/LogVol00 /mnt/root

11) Carpetas movidas hacia atrás (puede que necesite otras):

mv /var/{bin,etc,lib64,mnt,root,sbin} /

12)reboot

13) ¡ÉXITO!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.