General troubleshooting (Español)

Esta traducción de
General troubleshooting
fue revisada el
2021-02-12
. Si existen
cambios
puede
actualizarla
o avisar al
equipo de traducción
.
Artículos relacionados
Bug reporting guidelines (Español)
Step-by-step debugging guide
Debugging/Getting traces
Depuración colaborativa en IRC
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
¿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 de
sed
se describe en
https://stackpointer.io/unix/unix-linux-remove-ansi-escape-sequences/464/
.
¿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á.
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.
Nota
Soporte SOLO para la distribución Arch Linux
y no
Distribuciones basadas en Arch
.
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 arranque
systemd.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
pbpst
AUR
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
systemd
ignore_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 cambiar
vga
a
efi
para los sistemas
EFI
log_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/escribir
emergency
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 archivos
init=/bin/sh
(como último recurso) cambia el programa init a un intérprete de línea de órdenes de superusuario
(root)
.
rescue
y
emergency
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
.
Advertencia
Recuerde desactivar el servicio cuando lo haya hecho para evitar el riesgo de seguridad por dejar abierto un intérprete de línea de órdenes de superusuario en cada arranque.
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.
Nota
Los
Kernel panic
a veces se conocen como
oops
o
kernel oops
. Si bien estos y los errores ocurren como resultado de un estado de error, un
oops
es más general ya que no conducen
necesariamente
a una máquina bloqueada: a veces el kernel puede recuperarse de un
oops
eliminando la tarea afectada para poder continuar.
Sugerencia
Pase el parámetro del kernel
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
Sugerencia
En caso de que el mensaje de pánico se desplace demasiado rápido como para examinarlo, intente pasar el parámetro del kernel
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 y
systemd
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 presionando
Ctrl-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
y
nolapic
.
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 ejecute
arch-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.
Sugerencia
Puede ser necesario generar una nueva imagen de
disco RAM inicial
si la original se corrompe. Esto puede ocurrir cuando se interrumpe una actualización del kernel. Para crear una nueva, véase
mkinitcpio
.
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.
Nota
Si está en la consola y usando un programa IRC, puede pulsar Ctrl+Alt+F2 (F3, F4…) para acceder a otra consola para escribir una orden.
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
Nota
Debe utilizar
systemd
como su sistema de inicio para que las sesiones locales funcionen
[1]
—que se requiere para que
polkit
y
ACL
puedan definir permisos para distintos dispositivos (ver
/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.
Mensaje: "error while loading shared libraries"
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 ejecutando
arch-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
ejecutando
ldconfig
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