General troubleshooting (Español)
Este artículo explica algunos métodos para solucionar problemas generales. Para cuestiones específicas relativas a una aplicación, remítase a la página wiki para ese programa en particular.
Procedimientos generales
Atención al detalle
Para resolver un problema que esté teniendo, es absolutamente crucial comprender básicamente cómo funciona ese subsistema específico. ¿Cómo funciona y qué necesita para ejecutarse sin error? Si no puede contestar cómodamente a estas preguntas, entonces es mejor que revise el artículo Archwiki del subsistema con el que tiene problemas. Una vez que sienta que lo ha entendido, le será más fácil identificar la causa del problema.
Preguntas/lista de control
A continuación se presentan una serie de preguntas que deberá hacerse a sí mismo cuando se trata de un sistema que no funciona bien. Debajo de cada pregunta, hay notas que explican el método para dar respuesta a cada pregunta, seguido de algunos ejemplos claros sobre cómo recopilar fácilmente los datos y qué herramientas se pueden usar para revisar los registros y el diario (journal).
- ¿Cuál es el problema?
- Sea lo más preciso posible. Esto le ayudará a no confundirse y/o no seguir un camino incorrecto cuando al buscar información específica.
- ¿Hay mensajes de error? (si los hay)
- Copie y pegue las salidas completas que contienen los mensajes de error relacionadas con su problema en un archivo separado como
$HOME/issue.log
. Por ejemplo, para enviar la salida de la siguiente orden de mkinitcpio a$HOME/issue.log
: $ mkinitcpio -p linux >> $HOME/issue.log
- Copie y pegue las salidas completas que contienen los mensajes de error relacionadas con su problema en un archivo separado como
- ¿Puede reproducir el problema?
- Si es así, indique exactamente paso a paso las instrucciones/órdenes necesarias para reproducirlo. Para situaciones de línea de órdenes, puede comenzar simplemente grabando sus órdenes y su salida. Por ejemplo, con la orden script(1), que es parte de util-linux. Para deshacerse de los caracteres de control no imprimibles y de otro tipo incrustados en el archivo
typescript
, se pueden utilizar herramientas básicas de Unix. Por ejemplo,tr
. Las secuencias ANSI son más difíciles de manejar porque son más complejas. El uso desed
se describe en https://stackpointer.io/unix/unix-linux-remove-ansi-escape-sequences/464/.
- Si es así, indique exactamente paso a paso las instrucciones/órdenes necesarias para reproducirlo. Para situaciones de línea de órdenes, puede comenzar simplemente grabando sus órdenes y su salida. Por ejemplo, con la orden script(1), que es parte de util-linux. Para deshacerse de los caracteres de control no imprimibles y de otro tipo incrustados en el archivo
- ¿Cuándo se encontró por primera vez con este problema, y qué cambió entre ese momento y antes de que el sistema comenzase a funcionar erróneamente?
- Si ocurrió justo después de una actualización, enumere todos los paquetes que se han actualizado. Incluya los números de versión, copiando toda la actualización de pacman.log (
/var/log/pacman.log
). También tome nota de los estados de cualquier servicio necesario para dar soporte a la(s) aplicación(es) que está funcionando mal, usando las herramientas systemctl de systemd. Por ejemplo, para reenviar la salida del siguiente comando de systemd a$HOME/issue.log
: $ systemctl status dhcpcd@eth0.service >> $HOME/issue.log
- Nota: Utilizar
>>
asegurará que cualquier texto presente en$HOME/issue.log
no se sobrescribirá.
- Si ocurrió justo después de una actualización, enumere todos los paquetes que se han actualizado. Incluya los números de versión, copiando toda la actualización de pacman.log (
Enfoque
En lugar de abordar un problema diciendo,
La aplicación X no funciona.
le resultará más útil formular su problema en el contexto del sistema como un todo, como:
La aplicación X produce el/los error(es) Y al realizar las tareas Z bajo las condiciones A y B.
Soporte adicional
Con toda la información delante suya, debe tener una buena idea de lo que está sucediendo con el sistema y ahora puede comenzar a trabajar en una solución adecuada.
Si necesita soporte adicional, puede encontrarlo en los foros o el IRC en irc.libera.chat #archlinux. Véase Canales de IRC para otras opciones.
Cuando solicite ayuda, publique las salidas/registros completas/os, no solo las secciones que considere importantes. Las fuentes de información incluyen:
- Salida completa de cualquier comando involucrado - no seleccione únicamente lo que considere relevante.
- Salida de
journalctl
de systemd. Para una salida más extensa, utilice el parámetro de arranquesystemd.log_level=debug
. - Archivos de registro (eche un vistazo a
/var/log
) - Archivos de configuración relevantes
- Controladores involucrados
- Versiones de paquetes involucrados
- Kernel:
dmesg
. Para un problema de arranque, al menos las últimas 10 líneas mostradas, preferiblemente más - Redes: Salida exacta de los comandos involucrados, y cualquier archivo de configuración
- Xorg:
/var/log/Xorg.0.log
, y registros (logs) anteriores si ha sobrescrito el problemático - Pacman: si una actualización reciente rompió algo, busque en
/var/log/pacman.log
Una de las mejores formas de publicar esta información es usar un pastebin en línea. Puede instalar el paquete pbpstAUR o gist para enviar información automáticamente. Por ejemplo, para enviar el contenido de su diario systemd desde este arranque, debe hacer lo siguiente:
# journalctl -xb | pbpst -S
Luego se mostrará un enlace que puede pegar en el foro o IRC.
Además, antes de publicar su pregunta, puede revisar cómo hacer preguntas inteligentes. Véase también Código de conducta.
Problemas de arranque
El diagnóstico de errores durante el proceso de arranque implica cambiar los parámetros del kernel y reiniciar el sistema.
Si no es posible arrancar el sistema, inicie desde una imagen en vivo y cambie la raíz al sistema existente.
Mensajes de la consola
Después del proceso de inicio, la pantalla se borra y aparece el mensaje de inicio de sesión, lo que deja a los usuarios incapaces de leer los mensajes del arranque y los de error. Este comportamiento predeterminado puede cambiarse utilizando los métodos descritos en las secciones siguientes.
Tenga en cuenta que, independientemente de la opción elegida, los mensajes del kernel pueden mostrarse para su inspección después del arranque utilizando journalctl -k
o dmesg
. Para mostrar todos los registros del arranque actual utilice journalctl -b
.
Control de flujo
Esta es una administración básica que se aplica a la mayoría de los emuladores de terminal, incluidas las consolas virtuales (vc):
- Pulse
Ctrl+s
para pausar la salida - Y
Ctrl+q
para reanudarla
Esto pausa no solo la salida, sino también los programas que intentan imprimir en el terminal, ya que bloquearán sobre las llamadas write()
mientras la salida esté en pausa. Si su init parece congelado, asegúrese de que la consola del sistema no esté en pausa.
Para ver los mensajes de error que ya han mostrado, véase Mantener los mensajes de arranque en tty1.
Salida de depuración
La mayoría de los mensajes del kernel están ocultos durante el arranque. Puede ver más de estos mensajes añadiendo diferentes parámetros de kernel. Los más simples son:
debug
habilita los mensajes de depuración tanto para el kernel como para systemdignore_loglevel
fuerza a que se impriman todos los mensajes del kernel
Otros parámetros que puede añadir y que podrían ser útiles en ciertas situaciones son:
earlyprintk=vga,keep
imprime los primeros mensajes en el proceso de arranque del kernel, en caso de que el kernel falle antes de que se muestre el resultado. Debe cambiarvga
aefi
para los sistemas EFIlog_buf_len=16M
asigna un búfer de mensajes del kernel más grande (16 MiB), para garantizar que la salida de depuración no se sobrescriba
También hay una serie de parámetros de depuración separados para permitir la depuración en subsistemas específicos, poe ejemplo bootmem_debug
, sched_debug
. Véase la documentación de los parámetros del kernel para obtener información específica.
netconsole
netconsole es un módulo del kernel que envía todos los mensajes de registro del kernel (es decir, dmesg) a través de la red a otra computadora, sin involucrar el espacio del usuario (por ejemplo, syslogd). El nombre "netconsole" es inapropiado porque en realidad no es una "consola", sino más bien un servicio de registro remoto.
Se puede utilizar de forma integrada o como módulo. netconsole se inicializa inmediatamente después de las tarjetas NIC y mostrará la interfaz especificada lo antes posible. El módulo se utiliza principalmente para capturar la salida de pánico del kernel (kernel panic) de una máquina sin monitor, o en otras situaciones donde el espacio de usuario ya no es funcional.
Intérprete de línea de órdenes de recuperación
Obtener un intérprete de línea de órdenes interactivo en algún momento del proceso de arranque puede ayudarle a identificar exactamente dónde y por qué está fallando algo. Hay varios parámetros del kernel para hacerlo, pero todos ellos lanzan un intérprete de línea de órdenes normal que le permite ejecutar exit
, lo que posibilita al kernel reanudar lo que estaba haciendo:
rescue
inicia un intérprete de línea de órdenes poco después de que el sistema de archivos raíz se vuelva a leer/escribiremergency
inicia un intérprete de línea de órdenes incluso más temprano, antes de que se instalen la mayoría de los sistemas de archivosinit=/bin/sh
(como último recurso) cambia el programa init a un intérprete de línea de órdenes de superusuario (root).rescue
yemergency
dependen de systemd, pero esto debería funcionar incluso si systemd falla
Otra opción es el intérprete de línea de órdenes de depuración de systemd que añade un intérprete de línea de órdenes de superusuario en tty9
(accesible con Ctrl+Alt+F9
). Se puede habilitar añadiendo systemd.debug_shell
a los parámetros del kernel, o activando debug-shell.service
.
Pantalla en blanco con una tarjeta gráfica Intel
Esto es debido muy probablemente a un problema con la configuración del modo del kernel. Pruebe a desactivar modesetting o cambiar el puerto de la tarjeta gráfica.
Atascado mientras se carga el kernel
Pruebe a desactivar ACPI añadiendo acpi=off
a los parámetros del kernel.
Sistema no arrancable
Si el sistema no arranca en absoluto, simplemente arranque desde una imagen live y realice chroot para iniciar sesión en el sistema y solucionar el problema.
Depurar los errores de los módulos del kernel
Véase como obtener información de los módulos del kernel.
Depurar errores de hardware
- Puede visualizar información adicional de depuración sobre su hardware siguiendo udev#Debug output.
- Asegúrese de que las actualizaciones de microcódigo se aplican en su sistema.
- Para comprobar la memoria RAM, véase Stress testing#MemTest86+.
Kernel panics
Un pánico del kernel (o Kernel panic) ocurre cuando el kernel de Linux entra en un estado de fallo irrecuperable. El estado generalmente se origina en controladores de hardware defectuosos que provocan que la máquina quede estancada, no responda y requiera un reinicio. Justo antes del interbloqueo, se genera un mensaje de diagnóstico que consiste en: el "estado de la máquina" cuando ocurrió el fallo, un "seguimiento de la llamada" (call trace) que conduce a la función del kernel que reconoció el fallo y una lista de módulos cargados en ese momento. Afortunadamente, estos pánicos no ocurren muy a menudo usando versiones mainline del kernel, como los suministrados por los repositorios oficiales, pero cuando suceden, debe saber como manejarlos.
oops=panic
al arrancar o escriba 1
en /proc/sys/kernel/panic_on_oops
para forzar a un oops recuperable a emitir un panic en su lugar. Esto es aconsejable si le preocupa la pequeña posibilidad de sufrir una inestabilidad en el sistema como resultado de un oops recuperable que pueda hacer que los futuros errores sean difíciles de diagnosticar.Examinar los mensajes de pánico
Si se produce un kernel panic al inicio del proceso de arranque, es posible que aparezca un mensaje en la consola que contenga "Kernel panic - not syncing:" pero una vez que Systemd se está ejecutando, los mensajes del kernel serán capturados y escritos en el registro del sistema. Sin embargo, cuando se produce un kernel panic, el mensaje de diagnóstico generado por el kernel "casi nunca" se escribe en el archivo de registro en el disco porque los interbloqueos de la máquina antes de system-journald
tienen la ocasión. Por lo tanto, la única forma de examinar el mensaje de pánico es verlo en la consola como sucede (sin recurrir a la configuración de un kdump crashkernel). Puede hacerlo arrancando con los siguientes parámetros del kernel e intentando reproducir el mensaje de pánico en tty1:
systemd.journald.forward_to_console=1 console=tty1
pause_on_oops=segundos
al arrancar.Escenario de ejemplo: módulo defectuoso
Es posible adivinar qué subsistema o módulo está causando el pánico usando la información en el mensaje de diagnóstico. En este escenario, tenemos un pánico en una máquina (imaginaria) durante el arranque. Preste atención a las líneas resaltadas en negrita:
kernel: BUG: unable to handle kernel NULL pointer dereference at (null) [1] kernel: IP: fw_core_init+0x18/0x1000 [firewire_core] [2] kernel: PGD 718d00067 kernel: P4D 718d00067 kernel: PUD 7b3611067 kernel: PMD 0 kernel: kernel: Oops: 0002 [#1] PREEMPT SMP kernel: Modules linked in: firewire_core(+) crc_itu_t cfg80211 rfkill ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_ipv4 ... [3] kernel: CPU: 6 PID: 1438 Comm: modprobe Tainted: P O 4.13.3-1-ARCH #1 kernel: Hardware name: Gigabyte Technology Co., Ltd. H97-D3H/H97-D3H-CF, BIOS F5 06/26/2014 kernel: task: ffff9c667abd9e00 task.stack: ffffb53b8db34000 kernel: RIP: 0010:fw_core_init+0x18/0x1000 [firewire_core] kernel: RSP: 0018:ffffb53b8db37c68 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 kernel: RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffc16d3af4 kernel: RBP: ffffb53b8db37c70 R08: 0000000000000000 R09: ffffffffae113e95 kernel: R10: ffffe93edfdb9680 R11: 0000000000000000 R12: ffffffffc16d9000 kernel: R13: ffff9c6729bf8f60 R14: ffffffffc16d5710 R15: ffff9c6736e55840 kernel: FS: 00007f301fc80b80(0000) GS:ffff9c675dd80000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000000 CR3: 00000007c6456000 CR4: 00000000001406e0 kernel: Call Trace: kernel: do_one_initcall+0x50/0x190 [4] kernel: ? do_init_module+0x27/0x1f2 kernel: do_init_module+0x5f/0x1f2 kernel: load_module+0x23f3/0x2be0 kernel: SYSC_init_module+0x16b/0x1a0 kernel: ? SYSC_init_module+0x16b/0x1a0 kernel: SyS_init_module+0xe/0x10 kernel: entry_SYSCALL_64_fastpath+0x1a/0xa5 kernel: RIP: 0033:0x7f301f3a2a0a kernel: RSP: 002b:00007ffcabbd1998 EFLAGS: 00000246 ORIG_RAX: 00000000000000af kernel: RAX: ffffffffffffffda RBX: 0000000000c85a48 RCX: 00007f301f3a2a0a kernel: RDX: 000000000041aada RSI: 000000000001a738 RDI: 00007f301e7eb010 kernel: RBP: 0000000000c8a520 R08: 0000000000000001 R09: 0000000000000085 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000c79208 kernel: R13: 0000000000c8b4d8 R14: 00007f301e7fffff R15: 0000000000000030 kernel: Code: <c7> 04 25 00 00 00 00 01 00 00 00 bb f4 ff ff ff e8 73 43 9c ec 48 kernel: RIP: fw_core_init+0x18/0x1000 [firewire_core] RSP: ffffb53b8db37c68 kernel: CR2: 0000000000000000 kernel: ---[ end trace 71f4306ea1238f17 ]--- kernel: Kernel panic - not syncing: Fatal exception [5] kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff kernel: ---[ end Kernel panic - not syncing: Fatal exception
- [1] Indica el tipo de error que causó el pánico. En este caso, era un error del programador.
- [2] Indica que el pánico ocurrió en una función llamada fw_core_init en el módulo firewire_core.
- [3] Indica que firewire_core fue el último módulo que se inició.
- [4] Indica que la función que llamó a la función fw_core_init fue do_one_initcall.
- [5] Indica que este mensaje de oops es, de hecho, un kernel panic y el sistema está ahora bloqueado.
Podemos suponer entonces que el pánico ocurrió durante la rutina de inicialización del módulo firewire_core al iniciarse. (Podríamos suponer, entonces, que el hardware firewire de la máquina es incompatible con esta versión del módulo del controlador firewire debido a un error del programador, y tendrá que esperar una nueva versión.) Mientras tanto, la forma más fácil de hacer funcionar la máquina nuevamente es evitar que el módulo se inicie. Podemos hacer esto de una de estas dos maneras:
- Si el módulo se está iniciando durante la ejecución de initramfs, reinicie con el parámetro del kernel
rd.blacklist=firewire_core
. - De lo contrario, reinicie con el parámetro del kernel
module_blacklist=firewire_core
.
Reiniciar en un intérprete de línea de órdenes de superusuario y solucionar el problema
Necesitará un intérprete de línea de órdenes de superusuario para realizar cambios en el sistema para que no se produzca el pánico. Si se produce un pánico durante el arranque, existen varias estrategias para obtener un intérprete de línea de órdenes de superusuario antes de que la máquina se bloquee:
- Reinicie con el parámetro del kernel
emergency
,rd.emergency
, o-b
para obtener una manera de iniciar sesión justo después de que se monte el sistema de archivos raíz ysystemd
se ha iniciado.
- Nota: En este punto, el sistema de archivos raíz se montará como solo lectura. Ejecute
mount -o remount,rw /
como superusuario para poder realizar cambios.
- Reinicie con el parámetro del kernel
rescue
,rd.rescue
,single
,s
,S
, o { {ic|1}} para poder iniciar sesión justo después de montar los sistemas de archivos locales. - Reinicie con el parámetro del kernel
systemd.debug_shell
para obtener un intérprete de línea de órdenes de superusuario al iniciar en tty9. Cambie a este presionandoCtrl-Alt-F9
. - Experimente reiniciando con diferentes conjuntos de parámetros del kernel para posibilitar la deshabilitación de la función del kernel que está causando el pánico. Pruebe los "viejos recursos"
acpi=off
ynolapic
.
- Sugerencia: Véase kernel-parameters.html para ver todos los parámetros.
- Como último recurso, arranque con el CD de instalación de Arch Linux y monte el sistema de archivos raíz en
/mnt
y luego ejecutearch-chroot /mnt
como superusuario. - Desactive el servicio o programa que está causando el problema, revierta la actualización defectuosa o solucione el problema de configuración.
Administrar paquetes
Véase solución de problemas con pacman para los temas más generales, y solución de problemas de cifrado de paquetes con pacman para los problemas con las claves PGP.
Arreglar un sistema roto
Si realizó una actualización parcial que rompió algo, intente actualizar todos los paquetes y, si tiene éxito, posiblemente reinicie:
# pacman -Syu
Si generalmente inicia en una GUI y eso está fallando, tal vez pueda presionar desde Ctrl+Alt+F1
hasta Ctrl+Alt+F6
y llegar a un tty de trabajo para ejecutar pacman.
Si el sistema está lo suficientemente dañado como para que no pueda ejecutar pacman, inicie utilizando un ISO mensual de Arch desde una unidad flash USB, un disco óptico o una red con PXE. (No siga el resto de la guía de instalación).
Monte su sistema de archivos raíz:
[ISO] # mount /dev/dispositivoconelsistemadearchivosraiz /mnt
Monte cualquier otra partición que haya creado por separado, añadiendo el prefijo /mnt
a todas ellas, es decir:
[ISO] # mount /dev/dispositivodearranque /mnt/boot
Intente utilizar pacman en su sistema:
[ISO] # arch-chroot /mnt [chroot] # pacman -Syu
Si falla, salga del chroot e intente:
[ISO] # pacman -Syu --sysroot /mnt
Si eso falla, intente:
[ISO] # pacman -Syu --root /mnt --cachedir /mnt/var/cache/pacman/pkg
Depuración colaborativa en IRC
Para solicitar ayuda de un canal de ayuda de IRC (como #archlinux), puede utilizar servicios de depuración colaborativa (como pastebin) para dar a los usuarios de IRC detalles sobre los problemas que está viendo o archivos de configuración que necesite referenciar.
Utilización del IRC
Cuando le indique a las personas en la sala de charla cuál es su problema, a veces necesitarán conocer información adicional. Esto podría ser la salida (por ejemplo) de una orden o el contenido de un archivo de configuración. Es una regla general para los canales de IRC nunca pegar texto de más de tres líneas. Cuando necesite más, los servicios de pegado (por ejemplo, pastebin) permiten el uso temporal del almacenamiento de información de texto. Para evitar tener que escribir la información físicamente y luego escribirla manualmente en un canal de IRC, aquí es donde resulta útil utilizar un programa de depuración colaborativo que pueda enviar la información a un servicio de pegado. Hay varias herramientas que se pueden utilizar para enviar información a un servicio pastebin.
Enviar errores/mensajes al archivo
Muchos de estos programas necesitarán tener un archivo para subirlo. Si está utilizando un programa que necesita compartir su salida, puede escribirlo en un archivo de texto haciendo:
programa > salida-programa.txt 2>&1
Por ejemplo:
fdisk -l > particiones.txt 2>&1
Redirigirá toda la salida a un archivo de texto (tanto la salida estándar como la salida de error estándar) y se puede subir a un servicio pastebin.
Preguntas sobre el instalador de la consola
Ocasionalmente, es posible que deba mostrar una imagen de lo que trata su pregunta (por ejemplo, si tiene una pregunta sobre un instalador basado en consola). Para ello, puede utilizar fbshot. fbshot es un programa de captura de pantalla framebuffer. Para tomar una captura de pantalla de la primera consola (Ctrl+Alt+F1
):
fbshot -c 1 consola1.png
Luego, puede utilizar enlaces y un sitio web de alojamiento de imágenes para subir la imagen.
fuser
fuser es una utilidad de línea de órdenes para la identificación de los procesos que utilizan recursos como archivos, sistemas de archivos y puertos TCP/UDP.
fuser está incluido en el paquete psmisc, que debe estar ya instalado como dependencia del meta paquete base. Véase fuser(1) para más detalles.
Permisos de sesión
/usr/lib/udev/rules.d/70-uaccess.rules
y [2])—.En primer lugar, asegúrese de que tiene una sesión local válida dentro de X:
$ loginctl show-session $XDG_SESSION_ID
Esta debe contener Remote=no
y Active=yes
en la salida. Si no es así, asegúrese de que X se ejecuta en la misma tty donde se produjo el inicio de sesión. Esto es necesario a fin de preservar la sesión iniciada. Esto es manejado de forma predeterminada por /etc/X11/xinit/xserverrc
.
Las acciones polkit no requieren una configuración posterior. Algunas acciones polkit requieren una autenticación adicional, incluso con una sesión local. Un agente de autenticación polkit debe estar en ejecución para que esto funcione. Véase Agentes de autenticación para más información.
Si, durante el uso de un programa, se produce un error similar al siguiente:
error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory
Utilice pacman o pkgfile para buscar el paquete al cual pertenece la biblioteca que falta:
$ pacman -F libusb-0.1.so.4
extra/libusb-compat 0.1.5-1 usr/lib/libusb-0.1.so.4
En este caso, el paquete libusb-compat necesita ser instalado.
El error también puede significar que el paquete que ha utilizado para instalar el programa no enumera la biblioteca como una dependencia en su PKGBUILD: si se trata de un paquete oficial, informe del error; si se trata de un paquete de AUR, informe a su mantenedor en su página del sitio web de AUR.
Mensaje: "file: could not find any magic files!"
Si ve este mensaje, es probable que indique que la actualización de un paquete ha dañado el archivo de enlaces de tiempo de ejecución del vinculador dinámico y su sistema ahora está esencialmente lisiado. No podrá volver a compilar o reinstalar el paquete responsable ni reconstruir el initramfs hasta que lo solucione.
Problema
Es probable que una actualización del paquete haya agregado un archivo.conf
no válido al directorio /etc/ld.so.conf.d
o editado /etc/ld.so.conf
incorrectamente. El resultado es que el archivo de enlaces de tiempo de ejecución del vinculador dinámico /etc/ld.so.cache
se vuelve a generar con datos no válidos. Esto puede causar que fallen todos los programas del sistema que dependan de bibliotecas compartidas (es decir, casi todos).
Solución
- Arranque con el CD de instalación de Arch Linux.
- Monte su sistema de archivos raíz
/
en/mnt
y su sistema de archivos/boot
en/mnt/boot
y entre en el sistema dañado ejecutandoarch-chroot /mnt
como superusuario. - Examine el archivo
/etc/ld.so.conf
y elimine las líneas no válidas encontradas. - Examine los archivos ubicados en el directorio
/etc/ld.so.conf.d/
y elimine los archivos no válidos. - Reconstruya el archivo de enlaces de tiempo de ejecución del vinculador dinámico
/etc/ld.so.cache
ejecutandoldconfig
como superusuario. - Reconstruya el initramfs ejecutando
mkinitcpio -p linux
como superusuario. - Salga del chroot, desmonte los sistemas de archivos y reinicie de nuevo el sistema.
Véase también
- A how-to in troubleshooting for newcomers
- List of Tools for UBCD - Memtest-like tools to add to grub.cfg on UltimateBootCD.com
- Wikipedia:BIOS Boot partition
- REISUB
- Debug Logging to a Serial Console en Freedesktop.org
- How to Isolate Linux ACPI Issues en Archive.org