In practice, Debian (and Ubuntu) have fixed minimum system UIDs and GIDs
Debian, like many Linux distributions (and probably many Unixes)
has the idea of 'system' logins and groups as distinct from normal,
non-system users and groups. System users and groups are created
by Debian packages for their own use, for either or both of file
access permissions (such as making TLS keys accessible by group
'Debian-exim' so that your Exim can read them) or for processes and
daemons to run as. The UIDs and GIDs for these logins and groups
mostly aren't preassigned; instead, the package gets the next
available UID or GID from the system UID or GID range. In theory
Debian allows you to control these ranges through
that you can (for example) alter them to avoid a range of low UIDs
or GIDs that your environment has for historical reasons.
Unfortunately, in practice the start of the range for both system UIDs and GIDs is fixed. This comes about through two things combined together. First, a certain number of system logins and groups are created early in system installation, well before you can normally customize the system. These early system logins and groups will use the standard starting point for system UIDs and GIDs (currently 100 for both), and so be assigned low UIDs and GIDs. This includes things like the 'systemd-network' login and the 'systemd-journal' group.
(Systemd isn't the only only here, but as we'll see it's a pivotal one for the second issue. Other early logins include 'syslog', 'sshd', and '_apt', while early groups include 'crontab', 'syslog', and 'ssh'.)
The second problem is that Debian packages generally re-run their
install time postinstall commands on upgrades,
which includes re-running the commands that create their system
logins and groups. Unfortunately the Debian
commands include by default a safety measure that checks that
existing, theoretical 'system' logins and groups are within the
official UID and GID ranges for those, as set in your
If this check fails,
addgroup normally exit with a
failure status (as well as printing an error message).
The combined effect of these two together is that if you change the start of the system UID or GID range and then upgrade a core package like systemd, you will get errors during the upgrade of the form:
adduser: The user `systemd-network' already exists, but is not a system user. Exiting. The group `systemd-journal' already exists and is not a system group. Exiting.
As far as we know, there's no particularly good fix for this. As a result, in practice the minimum system UID and GID are fixed at 100. All you get to really control is the maximum system UID and GID, and there's usually not much point in changing them.
(All of this applies to Ubuntu as well, because Ubuntu inherits all of this stuff from Debian.)