What's new in the Buster release?
This page is still a work in progress. See the official buster release notes for additional information. Be sure to consult section 4.5 "Possible issues during upgrade", and chapter 5 "Issues to be aware of for buster".
New Features
AppArmor enabled by default
Wayland 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 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/default/su (create it) to get an approximation of the old behavior. This is documented in su(1).
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 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 systemd have been tightened. People using nis with systemd may encounter bug 878625 which breaks a variety of things related to login sessions. Workarounds include installing the 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 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 906436, 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.
Talking about nis setup, the buster default NIS server configuration prevents the clients being able to work in broadcast mode (its default). You have a couple of alternatives: either specifying an explicit server IP address in /etc/yp.conf on the NIS client, or add -r to rpcbind daemon on - at least - one of the NIS servers. That could be done as follows:
# echo "OPTIONS=-w -r" >/etc/default/rpcbind # systemctl daemon-reload
on the servers, before running the client ypbind. This is also required on each server in order to use it also as a client of itself: in that case the best thing to do is usually using the loopback address in /etc/yp.conf.
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 timidity-daemon package. See also 901148
Network interface name migration
The buster release notes (section 5.1.6., "Migrating from legacy network interface names") 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.