5. Problemas a ter en conta con trixie

As veces os cambios introducidos nunha nova versión teñen efectos secundarios imposibles de prever ou amosan fallos en algures. Esta sección documenta os problemas que coñecemos. Consulte tamén a lista de erratas, a documentación do paquete axeitada, informes de fallo e outra información mencionada en Lecturas recomendadas.

5.1. Actualizar elementos específicos para trixie

Esta sección trata da actualización de bookworm a trixie.

5.1.1. Reduced support for i386

From trixie, i386 is no longer supported as a regular architecture: there is no official kernel and no Debian installer for i386 systems. Fewer packages are available for i386 because many projects no longer support it. The architecture's sole remaining purpose is to support running legacy code, for example, by way of multiarch or a chroot on a 64-bit (amd64) system.

The i386 architecture is now only intended to be used on a 64-bit (amd64) CPU. Its instruction set requirements include SSE2 support, so it will not run successfully on most of the 32-bit CPU types that were supported by Debian 12.

Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware. Cross-grading without a reinstall is a technically possible, but risky, alternative.

5.1.2. openssh-server no longer reads ~/.pam_environment

The Secure Shell (SSH) daemon provided in the openssh-server package, which allows logins from remote systems, no longer reads the user's ~/.pam_environment file by default; this feature has a history of security problems and has been deprecated in current versions of the Pluggable Authentication Modules (PAM) library. If you used this feature, you should switch from setting variables in ~/.pam_environment to setting them in your shell initialization files (e.g. ~/.bash_profile or ~/.bashrc) or some other similar mechanism instead.

Existing SSH connections will not be affected, but new connections may behave differently after the upgrade. If you are upgrading remotely, it is normally a good idea to ensure that you have some other way to log into the system before starting the upgrade; see Preparase para a recuperación.

5.1.3. OpenSSH no longer supports DSA keys

Digital Signature Algorithm (DSA) keys, as specified in the Secure Shell (SSH) protocol, are inherently weak: they are limited to 160-bit private keys and the SHA-1 digest. The SSH implementation provided by the openssh-client and openssh-server packages has disabled support for DSA keys by default since OpenSSH 7.0p1 in 2015, released with Debian 9 ("stretch"), although it could still be enabled using the HostKeyAlgorithms and PubkeyAcceptedAlgorithms configuration options for host and user keys respectively.

The only remaining uses of DSA at this point should be connecting to some very old devices. For all other purposes, the other key types supported by OpenSSH (RSA, ECDSA, and Ed25519) are superior.

As of OpenSSH 9.8p1 in trixie, DSA keys are no longer supported even with the above configuration options. If you have a device that you can only connect to using DSA, then you can use the ssh1 command provided by the openssh-client-ssh1 package to do so.

In the unlikely event that you are still using DSA keys to connect to a Debian server (if you are unsure, you can check by adding the -v option to the ssh command line you use to connect to that server and looking for the "Server accepts key:" line), then you must generate replacement keys before upgrading. For example, to generate a new Ed25519 key and enable logins to a server using it, run this on the client, replacing username@server with the appropriate user and host names:

$ ssh-keygen -t ed25519
$ ssh-copy-id username@server

5.1.4. The last, lastb and lastlog commands have been replaced

The util-linux package no longer provides the last or lastb commands, and the login package no longer provides lastlog. These commands provided information about previous login attempts using /var/log/wtmp, /var/log/btmp, /var/run/utmp and /var/log/lastlog, but these files will not be usable after 2038 because they do not allocate enough space to store the login time (the Year 2038 Problem), and the upstream developers do not want to change the file formats. Most users will not need to replace these commands with anything, but the util-linux package provides a lslogins command which can tell you when accounts were last used.

There are two direct replacements available: last can be replaced by wtmpdb from the wtmpdb package (the libpam-wtmpdb package also needs to be installed) and lastlog can be replaced by lastlog2 from the lastlog2 package (libpam-lastlog2 also needs to be installed). If you want to use these, you will need to install the new packages after the upgrade, see the util-linux NEWS.Debian for further information. The command lslogins --failed provides similar information to lastb.

If you do not install wtmpdb then we recommend you remove old log files /var/log/wtmp*. If you do install wtmpdb it will upgrade /var/log/wtmp and you can read older wtmp files with wtmpdb import -f <dest>. There is no tool to read /var/log/lastlog* or /var/log/btmp* files: they can be deleted after the upgrade.

5.1.5. RabbitMQ no longer supports HA queues

High-availability (HA) queues are no longer supported by rabbitmq-server starting in trixie. To continue with an HA setup, these queues need to be switched to "quorum queues".

If you have an OpenStack deployment, please switch the queues to quorum before upgrading. Please also note that beginning with OpenStack's "Caracal" release in trixie, OpenStack supports only quorum queues.

5.1.6. RabbitMQ cannot be directly upgraded from bookworm

There is no direct, easy upgrade path for RabbitMQ from bookworm to trixie. Details about this issue can be found in bug 1100165.

The recommended upgrade path is to completely wipe the rabbitmq database and restart the service (after the trixie upgrade). This may be done by deleting /var/lib/rabbitmq/mnesia and all of its contents.

5.1.7. MariaDB major version upgrades only work reliably after a clean shutdown

MariaDB does not support error recovery across major versions. For example if a MariaDB 10.11 server experienced an abrupt shutdown due to power loss or software defect, the database needs to be restarted with the same MariaDB 10.11 binaries so it can do successful error recovery and reconcile the data files and log files to roll-forward or revert transactions that got interrupted.

If you attempt to do crash recovery with MariaDB 11.8 using the data directory from a crashed MariaDB 10.11 instance, the newer MariaDB server will refuse to start.

To ensure a MariaDB Server is shut down cleanly before going into major version upgrade, stop the service with

# service mariadb stop

followed by checking server logs for Shutdown complete to confirm that flushing all data and buffers to disk completed successfully.

If it didn't shut down cleanly, restart it to trigger crash recovery, wait, stop again and verify that second stop was clean.

For additional information about how to make backups and other relevant information for system administrators, please see /usr/share/doc/mariadb-server/README.Debian.gz.

5.1.8. Ping no longer runs with elevated privileges

The default version of ping (provided by iputils-ping) is no longer installed with access to the CAP_NET_RAW linux capability, but instead uses ICMP_PROTO datagram sockets for network communication. Access to these sockets is controlled based on the user's Unix group membership using the net.ipv4.ping_group_range sysctl. In normal installations, the linux-sysctl-defaults package will set this value to a broadly permissive value, allowing unprivileged users to use ping as expected, but some upgrade scenarios may not automatically install this package. See /usr/lib/sysctl.d/50-default.conf and the kernel documentation for more information on the semantics of this variable.

5.1.9. Significant changes to libvirt packaging

The libvirt-daemon package, which provides an API and toolkit for managing virtualization platforms, has been overhauled in trixie. Each driver and storage backend now comes in a separate binary package, which enables much greater flexibility.

Care is taken during upgrades from bookworm to retain the existing set of components, but in some cases functionality might end up being temporarily lost. We recommend that you carefully review the list of installed binary packages after upgrading to ensure that all the expected ones are present; this is also a great time to consider uninstalling unwanted components.

In addition, some conffiles might end up marked as "obsolete" after the upgrade. The /usr/share/doc/libvirt-common/NEWS.Debian.gz file contains additional information on how to verify whether your system is affected by this issue and how to address it.

5.1.10. Cousas que facer despois da actualización antes de reiniciar

Cando remate apt full-upgrade, a actualización "en sí" rematou. Para actualizar a trixie non é necesario facer máis cousas antes de reiniciar.

5.2. Cousas non exclusivas do proceso de actualización

5.2.1. Limitacións na asistencia técnica sobre seguridade

Hai algúns paquetes onde Debian non pode prometer manter unha modernización mínima por razóns de seguridade. Estes paquetes trátanse nas seguintes subseccións.

Note

O paquete debian-security-support axuda a manterse ao día sobre a asistencia técnica de seguridade dos paquetes.

5.2.1.1. O estado da seguridade dos navegadores de internet e os seus motores de renderizado

Debian 13 inclúe varios motores de navegador da rede que están afectados polo fluxo constante de vulnerabilidades de seguridade. A gran cantidade de vulnerabilidades, e a falta parcial de soporte técnico da fonte orixinal na forma de pólas de desenvolvemento a longo prazo, fan moi difícil manter a compatibilidade con estes navegadores e motores con arranxos de mantemento de seguridade. Ademais, as dependencias entre bibliotecas fan moi difícil actualizar a versións máis novas da fonte orixinal. As aplicacións que usen o paquete fonte webkit2gtk (como pode ser epiphany) teñen cobertura de seguridade, pero as aplicacións que usen qtwebkit (paquete fonte qtwebkit-opensource-src) non teñen.

Como navegador de uso diario recomendamos Firefox ou Chromium. Estes navegadores mantéñense ao día recompilando as versións ESR actuais para Debian estable. A mesma estratexia usarase para Thunderbird.

Despois de que unha versión pase a oldstable os navegadores con actualizacións oficiais non as recibirán fora do período de cobertura normal. Por exemplo, Chromium só recibirá 6 meses de actualizacións de seguridade en oldstable, en comparación cos 12 meses normais.

5.2.1.2. Paquetes baseados en Go e Rust

A infraestrutura de Debian inda ten problemas ao recompilar os tipos de paquetes que abusan do ligado estático. O crecemento do ecosistema de Go e Rust fai que os paquetes baseados neses ecosistemas terán unha asistencia técnica de seguridade limitada ata que a infraestrutura mellore o suficiente como para xestionalos sen problemas.

As actualizacións das bibliotecas de desenvolvemento de Go, se se precisaren, só poderían vir nas versións regulares principais.

5.3. Obsolescencia e deprecación

5.3.1. Paquetes obsoletos importantes

Esta é unha lista dos paquetes obsoletos que se consideran importantes (véxase Paquetes obsoletos para a definición).

A lista de paquetes obsoletos inclúe:

• The libnss-gw-name package has been removed from trixie. The upstream developer suggests using libnss-myhostname instead.

• The pcregrep package has been removed from trixie. It can be replaced with grep -P (--perl-regexp) or pcre2grep (from pcre2-utils).

5.3.2. Compoñentes deprecados para trixie

Na seguinte versión de Debian 14 (alcumada forky) quitáronse algunhas características. Os usuarios terán que migrar a outras alternativas para evitar problemas ao actualizaren a Debian 14.

Isto inclúe as seguintes características:

• The sudo-ldap package will be removed in forky. The Debian sudo team has decided to discontinue it due to maintenance difficulties and limited use. New and existing systems should use libsss-sudo instead.

  Upgrading Debian trixie to forky without completing this migration may result in the loss of intended privilege escalation.

  For further details, please refer to bug 1033728 and to the NEWS file in the sudo package.

• The sudo_logsrvd feature, used for sudo input/output logging, may be removed in Debian forky unless a maintainer steps forward. This component is of limited use within the Debian context, and maintaining it adds unnecessary complexity to the basic sudo package.

  For ongoing discussions, see bug 1101451 and the NEWS file in the sudo package.

• The libnss-docker package is no longer developed upstream and requires version 1.21 of the Docker API. That deprecated API version is still supported by Docker Engine v26 (shipped by Debian trixie) but will be removed in Docker Engine v27+ (shipped by Debian forky). Unless upstream development resumes, the package will be removed in Debian forky.

• The openssh-client and openssh-server packages currently support GSS-API authentication and key exchange, which is usually used to authenticate to Kerberos services. This has caused some problems, especially on the server side where it adds new pre-authentication attack surface, and Debian's main OpenSSH packages will therefore stop supporting it starting with forky.

  If you are using GSS-API authentication or key exchange (look for options starting with GSSAPI in your OpenSSH configuration files) then you should install the openssh-client-gssapi (on clients) or openssh-server-gssapi (on servers) package now. On trixie, these are empty packages depending on openssh-client and openssh-server respectively; on forky, they will be built separately.

• sbuild-debian-developer-setup has been deprecated in favor of sbuild+unshare

  sbuild, the tool to build Debian packages in a minimal environment, has had a major upgrade and should work out of the box now. As a result the package sbuild-debian-developer-setup is no longer needed and has been deprecated. You can try the new version with:

  $ sbuild --chroot-mode=unshare --dist=unstable hello
  

• The fcitx packages have been deprecated in favor of fcitx5

  The fcitx input method framework, also known as fcitx4 or fcitx 4.x, is no longer maintained upstream. As a result, all related input method packages are now deprecated. The package fcitx and packages with names beginning with fcitx- will be removed in Debian forky.

  Existing fcitx users are encouraged to switch to fcitx5 following the fcitx upstream migration guide and Debian Wiki page.

5.4. Fallos graves coñecidos

Que Debian saque as novas versións cando estean listas non significa que non teña fallos coñecidos. Parte do proceso de edición consiste en que o Equipo de Edición (ou equipo «Release») seguir os fallos de gravidade seria («serious») ou superior. Pódese atopar no Sistema de Seguimento de Fallos de Debian un resumo dos fallos que foran clasificados para ser ignorados no remate do lanzamento de trixie. Os seguintes fallos suficientemente notables afectaban a trixie no momento de sacar esa versión:

Nº do fallo	Paquete (fonte ou binario)	Descrición
1032240	akonadi-backend-mysql	o servidor akonadi non se inicia por que non se pode conectar á base de datos mysql
1032177	faketime	faketime non falsifica a data (en i386)
918984	src:fuse3	provide upgrade path fuse -> fuse3 for bookworm
1016903	g++-12	tree-vectorize: Código incorrecto no nivel O2 (-fno-tree-vectorize funciona)
1034752	src:gluegen2	inclúe as cabeceiras non libres