Si YaST se cierra con XIO: fatal IO error 11 (Resource temporarily unavailable)a través de SSH, primero intente la solución alternativa de Qt documentada por SUSE: QT_XCB_GL_INTEGRATION=none yast.ssh. Para un sistema SLES instalado y un módulo YaST específico, use la misma variable antes de ese módulo, como QT_XCB_GL_INTEGRATION=none yast2 disk. Si no se puede abrir ninguna aplicación gráfica, primero repare el reenvío de X11: conéctese con ssh -X, verifique que el shell remoto tenga un DISPLAYvalor y verifique que el servidor tenga habilitado el reenvío de X11.
La guía de implementación de SLES 15 SP7 de SUSE documenta este fallo específico de XIO, así como la solución alternativa con Qt y la alternativa con ncurses. El fragmento aparece en el contexto de la instalación remota, por lo que debe utilizarse como una solución específica para el comportamiento de YaST sobre SSH correspondiente; no establece que todos los fallos de inicio de YaST tengan la misma causa. Las comprobaciones que se describen a continuación permiten diferenciar este caso de la ausencia de un servidor X local, la desactivación del reenvío SSH o un problema de autenticación X.
El reenvío de X11 envía el tráfico de la ventana de una aplicación remota a través de SSH a un servidor X en su equipo local. Por lo tanto, su equipo local necesita un servidor X en ejecución y el cliente SSH debe solicitar el reenvío. En un escritorio X11, abra una terminal nueva y conéctese de esta manera:
ssh -X admin@server.example.comReemplaza la cuenta y el host con los tuyos. Después de iniciar sesión, ejecuta:
echo "$DISPLAY"Un valor como este localhost:10.0indica que SSH configuró una pantalla reenviada. Es un ejemplo, no un valor fijo: el número de pantalla puede variar. Si la salida está en blanco, cierre la sesión y vuelva a conectarse con -X. Si permanece en blanco, revise la configuración SSH del cliente y la configuración del servidor en la siguiente sección. No establezca manualmente DISPLAYun valor al azar; SSH crea una pantalla proxy para la sesión.
Si utiliza PuTTY en Windows, habilite el reenvío X11 en la configuración de Conexión > SSH > X11 de la sesión y asegúrese de que haya un servidor X local en ejecución. La guía de implementación de SUSE menciona este requisito. Un host remoto no puede mostrar una ventana si la máquina local no tiene un servidor X, incluso si el inicio de sesión SSH es exitoso.
En el host SLES, un administrador puede inspeccionar la configuración del demonio SSH:
sudo grep -i '^X11Forwarding' /etc/ssh/sshd_config
command -v xauthLa política de servidor efectiva debe permitir el reenvío X11 y xauthdebe estar disponible para la transferencia de autenticación. SUSE documenta X11Forwarding Yesla configuración del lado del servidor y señala que SSH establece el remoto DISPLAYcuando un cliente se conecta con -X. Una simple greppuede omitir configuraciones en los archivos de configuración incluidos o Matchbloques condicionales; si la salida parece entrar en conflicto con el comportamiento, pida al administrador de SSH que inspeccione la configuración efectiva en lugar de agregar líneas duplicadas.
Si realiza algún cambio sshd_config, valide el archivo antes de recargar el demonio:
sudo sshd -t
sudo systemctl reload sshdEjecute estas tareas únicamente con autorización de administrador. Mantenga abierta su sesión SSH actual mientras prueba una nueva, para evitar que un error de configuración le impida el acceso. A continuación, desconéctese y vuelva a conectarse; la configuración de reenvío se negocia al iniciar la sesión SSH. Evite abrir el puerto TCP 6000 en el servidor o usarlo xhost +como acceso directo. El reenvío SSH está diseñado para tunelizar el tráfico X y gestionar su autenticación; el acceso directo a X puede exponer la pantalla a otras máquinas.
Si DISPLAYestá configurado y se abre otra aplicación X reenviada, pero YaST falla con el error XIO anterior, intente la anulación del entorno documentada para ese lanzamiento en particular:
QT_XCB_GL_INTEGRATION=none yast.sshPara un sistema instalado de forma estándar, ejecute el módulo necesario en lugar de asumir que el asistente de instalación está presente. Por ejemplo, SUSE documenta este formulario de módulo:
QT_XCB_GL_INTEGRATION=none yast2 disk
La variable se aplica únicamente al comando que la sigue; no modifica permanentemente la configuración de Qt ni la política SSH. yast.sshSUSE utiliza el comando exacto para su sistema de instalación, mientras que un host SLES instalado suele iniciar los módulos YaST con yast2. Si falla un módulo diferente, sustituya su nombre de módulo documentado por disk. No considere esta configuración de entorno como una solución para un archivo vacío DISPLAYo para un cliente sin servidor X.
Si solo necesita completar la administración y no necesita una ventana gráfica, utilice la interfaz ncurses de YaST en la terminal SSH. Para el módulo de disco, consulte la documentación de SUSE:
yast2 disk --ncursesTambién puede solicitar explícitamente el backend de ncurses para el módulo:
YUI_PREFERRED_BACKEND=ncurses yast2 disk
La interfaz de texto evita por completo el reenvío de X11 y suele ser la opción más sencilla para un servidor remoto. Sigue siendo YaST y, por lo tanto, modifica la configuración del sistema; revise cuidadosamente los cambios en el disco, las particiones, el cortafuegos y la red antes de confirmarlos. Para el sistema de instalación SLES, SUSE indica que YaST proporciona una interfaz ncurses cuando no hay un servidor X local disponible.
Abra una nueva sesión SSH con ssh -X, confirme echo "$DISPLAY"que no esté vacío y, a continuación, inicie YaST con el comando correspondiente. Si todo va bien, la ventana de YaST aparecerá en el escritorio local o el módulo ncurses se abrirá en la terminal si seleccionó ese backend. Si el reenvío funciona correctamente, pero el error XIO exacto persiste tras la anulación de Qt, capture el error completo de la terminal y consulte las notas de la versión de SLES o la base de conocimientos de soporte de SUSE para obtener información sobre un problema específico de la versión; este procedimiento no permite identificar un defecto de Qt o YaST no relacionado a partir únicamente del fragmento de error.
-Xy confiable -Y.Identifique si Btrfs es intencionalmente de solo lectura, tiene poco espacio o está protegiendo datos después de errores, y luego elija una ruta de recuperación que se ajuste a la causa.
Prepare canales duplicados, cree una clave de activación e inicie un cliente SLES 15 sin acceso directo a Internet, manteniendo la conexión necesaria para las comprobaciones de entrada del administrador.
Solucione el error de inicio de XIO de YaST a través de SSH, verifique el reenvío de X11 y xauth, y cambie a la interfaz ncurses cuando no sea necesario usar una ventana remota.
Localiza la instantánea Btrfs previa a la actualización, pruébala en modo de solo lectura y haz que la recuperación sea permanente con Snapper, comprendiendo qué datos quedan fuera de la reversión raíz.
Envía los registros del sistema SLES a un recolector rsyslog remoto a través de TLS autenticado, con comprobaciones de certificados, almacenamiento en búfer de interrupciones y pruebas de entrega.
Utilice los registros de RAM, swap, kernel y Zypper para identificar la presión real sobre la memoria, proteger el estado de los paquetes y elegir un método más seguro para reintentar la actualización de SLES.
Habilita las actualizaciones de seguridad desatendidas de Debian a través de SSH, mantén las fuentes de paquetes predeterminadas y verifica las ejecuciones programadas mediante los registros de systemd y APT.
Compara las opciones de entrega de correo, configura smartd en Ubuntu y verifica que las advertencias sobre el estado del disco lleguen a tu bandeja de entrada.
Restaure las consultas DNS en Debian 12 comprobando systemd-resolved, reparando resolv.conf cuando sea necesario y verificando la resolución DNS y de aplicaciones ascendente.
Configura Ubuntu para que detecte tu monitor o televisor como salida de audio, selecciónalo en la configuración de sonido y comprueba la conexión o la lista de dispositivos PipeWire si falta la salida HDMI.
