SDB:Actualizaciones transaccionales
| Probado en openSUSE | Artículos recomendados | Artículos relacionados | |||
|
|
|
|
||
Contenido
Acerca de
Las actualizaciones transaccionales son un sistema que usan btrfs para utilizar una raíz en modo solo-lectura de forma que los cambios se realizan en una instantánea del sistema diferente a la que está en uso.
Esto permite realizar cambios en el sistema sin afectar al sistema que está en uso y también en su caso descartar los cambios si se da alguna circunstancia que lo requiera. Una vez el proceso de actualización de la nueva instantánea acabe sin errores, esta instancia se incorporará al sistema una vez que se reinicie.
Uso básico
El comando para manejar actualizaciones transaccionales es transactional-update y se ha de ejecutar como root o bien con sudo:
- Instalar un paquete rpm:
transactional-update pkg install nombre_paquete
- Desinstalar un paquete rpm:
transactional-update pkg remove nombre_paquete
- Actualizar el sistema a la siguiente versión:
transactional-update dup
- Abrir un shell de la siguiente instancia:
transactional-update shell
- Revertir a una instancia:
transactional-update rollback número_intantánea
- o bien para revertir a la última anterior instantánea:
transactional-update rollback last
- o en el caso de haber arrancado la instantánea a la que se quiere revertir:
transactional-update rollback
Actualización automática
De forma predeterminada, transaccional-update.timer maneja las actualizaciones automáticas del sistema. Está configurado en diario, lo que significa que la tarea se ejecutará todos los días a las 00:00:00.
En el caso de que esto pueda ser en un momento en que la computadora esté apagada, ya que el temporizador está configurado en persistencia = true, la actualización se realizará en la primera oportunidad posible.
Algunas de las razones por las que es posible que no pueda activar una actualización podrían ser:
- la computadora estaba apagada.
- la conexión a Internet se interrumpió, durante la hora prevista.
Esto no debería causar problemas debido a la forma en que funciona la actualización transaccional, ya que los nuevos paquetes se instalan en una nueva instantánea que necesita que se reinicie para entrar en vigor.
Para realizar un seguimiento de si la actualización transaccional puede actualizarse y ejecutarse correctamente, puede utilizar journalctl:
$ sudo journalctl -u actualización-transaccional.servicio
También puedes utilizar journalctl con el indicador -f para seguir los registros en tiempo real.
Ajustar el temporizador para la actualización transaccional
Para editar el temporizador para la actualización transaccional ejecuta el siguiente comando:
sudo systemctl edit transactional-update.timer
### Editing /etc/systemd/system/transactional-update.timer.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
### Edits below this comment will be discarded
### /usr/lib/systemd/system/transactional-update.timer
# [Unit]
# Description=Daily update of the system
# Documentation=man:transactional-update(8)
# After=network.target local-fs.target
#
# [Timer]
# OnCalendar=daily
# AccuracySec=1m
# RandomizedDelaySec=2h
# Persistent=true
#
# [Install]
# WantedBy=timers.target
El editor de texto que tengas configurado (nano, vim) abrirá una copia comentada del fichero de configuración del temporizador. En la parte de arriba se añaden unas líneas para indicar que se introduzcan los cambios a realizar en esa sección, a continuación de la línea Anything between here and the comment below will become the contents of the drop-in file (cualquier cosa desde aquí hasta la línea comentada más abajo será el contenido del fichero de reemplazo).
### Editing /etc/systemd/system/transactional-update.timer.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
[Timer]
RandomizedDelaySec=15m
### Edits below this comment will be discarded
### /usr/lib/systemd/system/transactional-update.timer
...
Esto introduce un retraso de 15 minutos en las actualizaciones. Puedes consultar en el manual cómo especificar otras unidades de tiempo. También puedes consultar el manual para aprender qué variables puedes configurar.
Las actualizaciones transaccionales y arranque
Por defecto, cada comando transactional-update produce una instantánea separada y autocontenida que incluye los cambios requeridos por el comando transactioal-update.
Esta instantánea está basada en la última instantánea bien conocida/arrancada. La última de las instantáneas producidas por múltiples comandos transactional-update tomará efecto al reiniciar. En otras palabras, sudo transactional-update pkg install $pkg1 seguido de sudo transactional-update pkg install $pkg2 y luego el reinicio resulta en un sistema que tiene $pkg2 instalado, pero no $pkg1.
Esto es el esperado y sensible comportamiento esperado. Los sistemas que usan actualizaciones transaccionales siempre quieren moversa a la última instantánea conocida buena/arrancada a su nuevo estado en la forma más pequeña y menos disruptida posible.
Esto es especialmente sensible cuando pinesas que las actualización de sistemas de escritorio basados en MicroOS no deberían ni usar transactional-update de forma interactiva. Con transactional-update dup teniendo lugar en segundo plano automáticamente con regularidad, estos sistemas quieren asegurar que su actualización tiene lugar al último estado de sistema actualizado de forma limpia, no a ningún extraño híbrido de sistema previo sin arrancar, sin chequear, intermedio.
De todas formas, cuando ignorando esta mejor práctica uses transactional-update de forma interactiva, habrá ocasiones en las que desees ejecutar transactional-update contra una instantánea no arrancada. Para ello utiliza transactional-update --continue
Ejemplo:
sudo transactional-update pkg install $pkg1 seguido de sudo transactional-update --continue pkg install $pkg2 instalará $pkg1, y después $pkg2 en la misma instantánea que $pkg1, marcando que esa instantánea combinada es el objetivo en el próximo arranque.
Si de todas formas ocurre algún problema, no hay ninguna forma compleja de determinar si fue $pkg1 o $pkg lo que provocó que se rompiera algo, así que las personas usuarias tendrán que revertir a la instantánea anterior a la instalación de $pkg1 para volver al último buen estado conocido.