Resolución de problemas
Fedora Silverblue es una manera nueva de despliegue y gestión de su sistema operativo del escritorio, tal que pueda ejecutar ocasionalmente en algún problema mientras lo utiliza todos los días. A continuación están algunos de los problemas más comunes reportados y cualquier solución para aquellos problemas.
«Sustituciones de paquete base prohibido»
Esto puede suceder cuando un paquete que está siendo utilizado en capas tiene una dependencia en un paquete que está dentro del SO base. En el caso problemático, las capas del paquete requiere una versión más nueva del paquete dependiente el cual no está disponible dentro del SO base.
En muchos casos, esperando un conjunto del árbol del SO más nuevo resolverá este problema. El paquete dependiente será actualizado en la composición y el paquete que estaba yendo a la capa será correcto.
Sin embargo, si continúa para encontrar este problema con una composición más nueva, puede intentar vaciar los metadatos con rpm-ostree cleanup -m
y después reintentar el rpm-ostree install
.
Alternativamente, puede intentar rebasar a cualquier ref updates
, como fedora/30/updates/x86_64
tras la operación cleanip
.
Para más información, consulte rpm-ostree#415.
Instalar paquetes a /opt
o /usr/local
Instalar en /opt
comúnmente fue alzado como un problema cuando los usuarios donde intentan instalar Google Chrome. Una solución parcial ha sido implementada que permite a los usuarios poner en capas a Google Chrome, sin embargo no es una solución completa para aplicaciones que escriben datos mutables a /opt
.
Este problema está seguido en rpm-ostree#233.
Utilizando controladores NVIDIA
Puede instalar los controladores binarios oficiales de NVIDIA desde repositorios de RPM Fusion.
Los controladores binarios de NVIDIA no están mantenidos por el Proyecto Fedora y algunas veces no pude estar disponible para la versión del kernel incluida en Fedora Silverblue. |
El proyecto Universal Blue crea imágenes de sistemas operativos desde Fedora Silverblue con los controladores NVIDIA incluidos. Las imágenes Universal Blue están basadas en las imágenes oficiales de Fedora con cambios adicionales en su discreción. Las imágenes Universal Blue no están oficialmente avaladas por el Proyecto Fedora. Utilícelas según si propia discreción. |
-
Primero, asegure que su sistema está completamente actualizado ejecutando
sudo rpm-ostree upgrade
y reiniciando. -
Entonces configure los repos de RPM Fusion siguiente la documentación, incluyendo los dos reinicios.
-
Finalmente, instale los controladores:
# rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia # rpm-ostree kargs --append=rd.driver.blacklist=nouveau --append=modprobe.blacklist=nouveau --append=nvidia-drm.modeset=1 --append=initcall_blacklist=simpledrm_platform_driver_init # systemctl reboot
Cuando utilice Secure Boot, los controladores NVIDIA instalados localmente tienen que estar firmados con una clave local que esté instruita utilizando mokutil . Consulte la cuestión de fedora-silverblue#499 para más detalles.
|
Gracias a Alex Larsson quien hizo los cambios requeridos para los paquetes akmods
y kmodtools
. Puede leer más sobre el trabajo que Alex hizo en este blog.
Fuera de árbol de kernel, módulos y controladores utilizando DKMS
Fedora Silverblue actualmente no tiene mantenimiento para DKMS. Consulte el problema de arriba rpm-ostree#1091.
En su lugar, recomendamos que haga paquetes de kmods para salir de módulos del árbol del kernel y envíelos entonces a los repos RPM Fusion. Los paquetes kmod entonces serán utilizados por akmods el cual está mantenido en Fedora Silverblue.
Añadiendo repositorios de paquete externo
Esta sesión discute las fuentes de software de terceros no afiliados oficialmente con o avalado por el Proyecto Fedora. Utilícelas a su propia prudencia. |
Si desea utilizar repositorios de RPM Fusion, siga la sección Activar repos Fusion RPM. |
Algún software puede solo estar disponible desde un repositorio de tercer parte. Puede añadir un repositorio externo manualmente en Fedora Silverblue colocando el archivo .repo
en /etc/yum.reps.d/
y la clave GPG en /etc/pki/rpm-gpg/
. Lo siguiente es un ejemplo completo para configurar el repo Tailscale:
-
Obtener e instalar el config del repo:
$ curl -O https://pkgs.tailscale.com/stable/fedora/tailscale.repo [tailscale-stable] name=Tailscale stable baseurl=https://pkgs.tailscale.com/stable/fedora/$basearch enabled=1 type=rpm repo_gpgcheck=1 gpgcheck=0 gpgkey=https://pkgs.tailscale.com/stable/fedora/repo.gpg $ sudo install -o 0 -g 0 -m644 tailscale.repo /etc/yum.repos.d/tailscale.repo
-
Obtener e instalar las claves GPG:
$ curl -O https://pkgs.tailscale.com/stable/fedora/repo.gpg $ sudo install -o 0 -g 0 -m644 repo.gpg /etc/pki/rpm-gpg/tailscale.gpg
-
Sustituir la URL
gpgkey=
en la config del repo por la ruta a las claves GPG:$ sudo $EDITOR /etc/yum.repos.d/tailscale.repo $ cat /etc/yum.repos.d/tailscale.repo [tailscale-stable] name=Tailscale stable baseurl=https://pkgs.tailscale.com/stable/fedora/$basearch enabled=1 type=rpm repo_gpgcheck=1 gpgcheck=0 # Actualiza esta líonea gpgkey=file:///etc/pki/rpm-gpg/tailscale.gpg # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
Instalar el paquete nuevo con:
$ rpm-ostree install tailscale
Mejor asistencia en rpm-ostree
para este caso de uso está seguido en rpm-ostree#4014.
Problemas SELinux
Como los usuarios trabajan con Fedora Silverblue día a día, es posible que tenga modificada la normativa SELinux por defecto en un esfuerzo para solucionar uno o más problemas relacionados con SELinux. Esto es hecho usualmente cunado un usuario ve una denegación de SELinux en el diario. Si este es el caso y uno desde revertir a la normativa por defecto de SELinux, puede internar este conjunto de acciones.
-
Compruebe el estado de la normativa SELinux
$ sudo ostree admin config-diff | grep policy M selinux/targeted/active/policy.linked M selinux/targeted/active/policy.kern M selinux/targeted/policy/policy.31 A selinux/targeted/policy/policy.30
Si cualquier cosa es devuelta por este comando, entonces su normativa de SELinux ha sido modificada desde la predeterminada.
-
Copia la normativa por defecto se SELinux trasportada en la composición de OSTree
$ sudo cp -al /etc/selinux{,.bak} $ sudo rsync -rlv /usr/etc/selinux/ /etc/selinux/
Tras hacer esto, la salida desde
ostree admin config-diff | grep policy
no indicará más la normativa es modificada.Si su normativa aún aparece para ser modificada, puede intentar abordar lo siguiente.
-
Retire la normativa SELinux; copie dentro de la normativa por defecto
$ sudo rm -rf /etc/selinux $ sudo cp -aT /usr/etc/selinux /etc/selinux
Tras esto, el comando
ostree admin config-diff | grep policy
no devolvería ninguna de las modificaciones.
No es capaz de añadir usuario a grupo
Debido a como manipula rpm-ostree
a los apuntes de usuario + grupo, puede que no sea posible utilizar usermod -a -G`para añadir un usuario a un grupo correctamente. Hasta que `rpm-ostree
vaya a utilizar systemd sysusers
, los usuarios tendrán que rellenar el archivo /etc/group
desde el archivo /usr/lib/group
antes de que pueda añadirse ellos mismos al grupo.
Por ejemplo, si deseaba añadir un usuario al grupo libvirt
:
$ grep -E '^libvirt:' /usr/lib/group | sudo tee -a /etc/group $ sudo usermod -aG libvirt $USER
Necesitará cerrar sesión y volver a acceder para aplicar estos cambios. |
Este problema está seguido en rpm-ostree#29 y en rpm-ostree#49.
ostree fsck
informa corrupción de archivo
Es posible terminar en una situación donde uno o más archivos en el disco se han vuelto corruptos o ausentes. En este caso, ostree fsck
reportará errores en ciertos commints. La solución alternativa en este caso es marcar el commit de OSTree completo como parcialmente recuperado y entonces re-descargar el commit.
Solo-lectura de /boot/efi
previene cualquier mejora
Este asunto es visto comúnmente cuando los usuarios han instalados Fedora Silverblue en hardware de Apple. La partición /boot/efi
en el hardware Apple está formateado como HFS+ y no siempre es resiliente para fallos de energía u otras causas de eventos de energía.
Desde Fedora Silverblue ahora incluye el paquete hfsplus-tools
en la composición base, se ha convertido relativamente fácil para usuarios evitar esta clase de error.
# umount /boot/efi # fsck.hfsplus /dev/sda1 # mount -o rw /boot/efi
Consulte el asunto rpm-ostree#1380 de GitHub para detalles adicionales.
No es capaz de instalar Fedora Silverblue en sistemas EFI
Los usuarios han informado que no pueden instalar Fedora Silverblue en un sistema basado en EFI donde previamente tuvieron otro SO instalado. El error que es observado a menudo parece como:
ostree ['admin', '--sysroot=/mnt/sysimage', 'deploy', '--os=fedora-workstation', 'fedora-workstation:fedora/28/x86_64/workstation'] ha salido con código -6`
Existe un par de posibles métodos alternativos:
-
Durante el proceso de instalación, seleccione «Particionado Personal» y cree una partición EFI adicional. Asigne la partición EFI creada nuevamente a
/boot/efi
. Entocnes será capaz de arrancar el anterior SO(s) junto a Fedora Silverblue. Si esta solución alternativa no es fructuosa siga el paso a continuación. -
Reformatea la partición EFI en el host durante el proceso de instalación. Esto puede hacerse seleccionando «Particionado Personal» y compruebe que la caja
Reformatear
cuando cree la partición/boot/efi
.
Eligiendo reformatear /boot/efi resultará como en la inhabilidad de arrancar cualquier otro sistema operativo que fuera anteriormente instalado.
Asegúrese que ha respaldado cualquier dato importante antes de utilizar esta segunda solución.
|
Este asunto es tratado en Bugzilla #1575957.
toolbox: ha fallado al listar imágenes con com.redhat.component=fedora-toolbox
Como de podman versión 1.4.0 esta segunda solución no es necesaria.
Asegure que podman está actualizado a la fecha por el emisor rpm-ostree upgrade antes de intentar esta segunda solución.
|
Cuando emita el comando toolbox list, los sistemas utilizando versiones de `podman
más modernas que 1.2.0
, generará el error siguiente:
toolbox: ha fallado al listar imágenes con com.redhat.component=fedora-toolbox
La siguiente solución quizá sea útil para otros errores de toolbox causados por podman versión mayor que 1.2.0 .
Consulte Repo Github Toolbox
|
Como una solución alternativa, es posible invalidar los paquetes podman
más nuevos que la versión 1.2.0
emitiendo:
$ rpm-ostree override --remove=podman-manpages replace https://kojipkgs.fedoraproject.org//packages/podman/1.2.0/2.git3bd528e.fc30/x86_64/podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm
Rearranque el sistema para aplicar los cambios.
Para referencia, también es posible cubrir el paquete siguiente estos pasos:
-
Descargue
podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm
desde Koji -
Desinstale
podman-manpages
emitiendo:rpm-ostree override remove podman-manpages
-
Invalida el paquete
podman
actualmente instalado (utilizando el paquete tiene descargado en el primer paso) por:rpm-ostree override replace podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm
Ahora puede reiniciar el sistema para el cambio para tomar efecto.
Para revertir este problema de solución alternativa con el siguiente comando:
$ rpm-ostree override reset podman; rpm-ostree override reset podman-manpages
No es capaz de introducir un toolbox debido a errores de permisos
Con ciertas versiones de podman
, intente introducir un toolbox resultará en errores. Puede reparar esto restableciendo los permisos en los contenedores-cubiertos con el comando siguiente.
$ sudo chown -R $USER ~/.local/share/containers/storage/overlay-containers
Esto restaurará los permisos en sus contenedores y le permite introducirlas de nuevo.
Consulte el tema podman más moderno: podman#3187.
Ejecutando restorecon
Nunca ejecutaría restorecon sobre un host Fedora Silverblue.
Consulte el defecto siguiente para detalles - https://bugzilla.redhat.com/show_bug.cgi?id=1259018
|
Sin embargo, si sucedió hacer esto, es posible recuperar.
-
Arranque con
enforcing=0
en la línea de instrucción del kernel -
Cree un nuevo, "fixed" commit localmente
-
Despliegue al nuevo commit "fixed"
-
Ejecuta
restorecon
-
Reiniciar
-
Limpieza
$ rpm-ostree status -b | grep BaseCommit
BaseCommit: 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee
$ sudo ostree checkout -H 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee /ostree/repo/tmp/selinux-fix
$ sudo ostree fsck --delete
$ sudo ostree commit --consume --link-checkout-speedup --orphan --selinux-policy=/ /ostree/repo/tmp/selinux-fix
$ sudo restorecon -Rv /var
$ sudo restorecon -Rv /etc
$ sudo ostree admin deploy fedora:fedora/41/x86_64/silverblue
$ sudo reboot
La advertencia para esta recuperación es que su paquete cubierto será desinstalado; necesitará recaparlo después de la recuperación.
Consulte este comentario en el upstream para detalles adicionales: ostree#1265.
Restableciendo contraseñas en Modo Rescate
En el caso donde sea incapaz de recordar su contraseña de usuario o contraseña root, puede restablecer la contraseña utilizando los siguientes pasos.
-
Mientras el sistema está arrancando, interrumpa la secuencia de arranque en el menú GRUB2 utilizando la tecla Esc.
-
Seleccione el apunte de arrancar que desee para editar utilizando las teclas de fecha.
-
Edite el apunte seleccionado con la tecla e.
-
Utilice las teclas de flecha para seleccionar la línea comenzando con
linux
,linux16
, olinuxefi
. -
Vaya al final de esa línea y adjunte
init=/bin/bash
al final de la línea. -
Presione Ctrl-x o F10 para arrancar el apunte.
-
En el intérprete
bash
resultante, ejecute los comandos siguientes:
# mount -t selinuxfs selinuxfs /sys/fs/selinux
# /sbin/load_policy
# passwd
# sync
# /sbin/reboot -ff
Si desea cambiar la contraseña para una cuenta de usuario, remplace el comando passwd
con passwd <nombreusuario>
.
Tras el sistema finalice rearranque, sería capaz de acceder con el nombre de usuario y la contraseña nueva.
Want to help? Learn how to contribute to Fedora Docs ›