What's new in the Debian Buster release?
This page is still a work in progress. See the official buster release notes and buster issues/warnings for additional information.
New Features
AppArmor enabled by default.
Kayland is the default session type for GNOME 3. (You may also choose an X session from the display manager.)
SecureBoot support.
Kernel new enough to support mounting SMBv3 encrypted shares
Tool “find-dbgsym-packages” (in package debian-goodies)
The rust compiler 1.34 ships with more than 450 libraries (crates) with new great software like ripgrep, fd or exa.
Changes
The `su` command in buster is provided by the util-linux source package, instead of the shadow source package, and no longer alters the `PATH` variable by default.
This means that after doing `su`, your `PATH` may not contain directories like `/sbin`, and many system administration commands will fail. There are several workarounds:
Use 'su -
' instead; this launches a login shell, which forces `PATH` to be changed, but also changes everything else including the working directory.
Use DebianPkg:sudo instead. `sudo` still runs commands with an altered `PATH` variable.
To get a regular root shell with the correct `PATH`, you may use 'sudo -s
'.
To get a login shell as root (equivalent to `su -`), you may use 'sudo -i
'.
Put 'ALWAYS_SET_PATH yes
' in '/etc/login.defs
' to get an approximation of the old behavior. This is documented in su(1) but not in login.defs(5). It may also cause a harmless error message to appear in some situations (see DebianBug:905564).
Put the system administration directories (`/sbin`, `/usr/sbin`, `/usr/local/sbin`) in your regular account's `PATH` (see EnvironmentVariables for help with this).
The default Wayland session for GNOME stops some packages like DebianPkg:synaptic from working. Graphical system administration packages that need superuser privileges will generally be problematic until major rewrites occur. Workarounds include using GNOME on X11 instead of Wayland, or using non-graphical alternative tools.
The security settings for some components of DebianPkg:systemd have been tightened. People using DebianPkg:nis with systemd may encounter bug DebianBug:878625 which breaks a variety of things related to login sessions. Workarounds include installing the DebianPkg:nscd package, or reconfiguring `systemd-logind.service` to allow it to use the network.
Upgrade issues
If you previously ran buster during its time as “testing”, you may see this error when you run `apt-get update`:
{{{ E: Repository 'http://ftp.us.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. }}}
. In order to accept this change, you should run 'apt update
' instead, at least one time. `apt` will prompt you for confirmation, and then everything proceeds normally.
If you use the DebianPkg:nis client (`ypbind`), you must make sure that the 'YPBINDARGS=
' option in '/etc/default/nis
' does 'not
' include `-no-dbus`. The upgrade will not modify this file, and if the `-no-dbus` option remains present, `ypbind` will fail to start, and you may not be able to login. See also: bugs DebianBug:906436, DebianBug:834298.
If you have user accounts in NIS, you should also double-check the '/etc/nsswitch.conf
' file, and make sure the 'passwd
', 'group
' and 'shadow
' lines use 'compat
' rather than `files`. Upgrades from systems installed as stretch should be OK, but systems originally installed as previous releases may be using deprecated configurations.
Timidity starts early in the boot process and can take control of the sound card leaving PulseAudio with only a Dummy Output. Check if Timidity is running with:
{{{ # systemctl status timidity }}}
Stop and disable timidity from future boots with:
{{{ # systemctl stop timidity # systemctl disable timidity }}}
Or you may choose to remove the DebianPkg:timidity-daemon package. See also DebianBug:901148
Network interface name migration
The buster release notes warn that the `/etc/udev/rules.d/70-persistent-net.rules` method for assigning persistent network interface names is no longer supported. However, it may be difficult to predict what the new “predictable” interface name will be.
The `udevadm` command suggested in the release notes, when run under stretch, may not show all of the possible interface name choices. Even in the cases where the name is
shown, it may be difficult to see which of the choices will be the correct one.
On remote systems, where having the interface come up is critically important, it may be wise to adopt a pessimistic strategy, and add stanzas in `/etc/network/interfaces` for every possible interface name, even ones that aren't shown under stretch.
Here is an example stretch system's output:
{{{ root@svr4:/# udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null ID_NET_NAME_MAC=enxe4115b0dc990 ID_OUI_FROM_DATABASE=Hewlett Packard ID_NET_NAME_PATH=enp2s0 }}}
This system has two onboard network interfaces, but the onboard interface names are not
shown in stretch's output. It's not possible to predict whether the new interface name will be `enp2s0` or `eno0` or `eno1`. So, the best strategy is to put all three of them into the `/etc/network/interfaces` file. Then, whichever two are not used may be removed from that file after rebooting into buster.
{{{ auto enp2s0 iface enp2s0 inet static address 10.76.142.85 netmask 255.255.254.0 gateway 10.76.142.1 auto eno0 iface eno0 inet static address 10.76.142.85 netmask 255.255.254.0 gateway 10.76.142.1 auto eno1 iface eno1 inet static address 10.76.142.85 netmask 255.255.254.0 gateway 10.76.142.1 }}}(For the curious, this particular interface on this system ended up being `eno0`.)
On systems that use the interface names in other configuration files besides `/etc/network/interfaces`, such as firewalls, it might be preferable to assign persistent names through the systemd.link(5) configuration, rather than relying on the “predictable” names.