I logged into dietpi on rpi zero 2 WH. it said to run apt upgrade, I did, and at the end of the script, i see it went and created all these new users and groups. What the heck ? Why ?
dracut: Generating /boot/initrd.img-6.18.34+rpt-rpi-v8
Creating group 'tty' with GID 5.
Creating group 'disk' with GID 6.
Creating group 'man' with GID 12.
Creating group 'kmem' with GID 15.
Creating group 'dialout' with GID 20.
Creating group 'fax' with GID 21.
Creating group 'voice' with GID 22.
Creating group 'cdrom' with GID 24.
Creating group 'floppy' with GID 25.
Creating group 'tape' with GID 26.
Creating group 'sudo' with GID 27.
Creating group 'audio' with GID 29.
Creating group 'dip' with GID 30.
Creating group 'operator' with GID 37.
Creating group 'src' with GID 40.
Creating group 'shadow' with GID 42.
Creating group 'video' with GID 44.
Creating group 'sasl' with GID 45.
Creating group 'plugdev' with GID 46.
Creating group 'staff' with GID 50.
Creating group 'games' with GID 60.
Creating group 'users' with GID 100.
Creating group 'nogroup' with GID 65534.
Creating group 'systemd-journal' with GID 999.
Creating user 'root' (n/a) with UID 0 and GID 0.
Creating group 'daemon' with GID 1.
Creating user 'daemon' (n/a) with UID 1 and GID 1.
Creating group 'bin' with GID 2.
Creating user 'bin' (n/a) with UID 2 and GID 2.
Creating group 'sys' with GID 3.
Creating user 'sys' (n/a) with UID 3 and GID 3.
Creating user 'sync' (n/a) with UID 4 and GID 65534.
Creating user 'games' (n/a) with UID 5 and GID 60.
Creating user 'man' (n/a) with UID 6 and GID 12.
Creating group 'lp' with GID 7.
Creating user 'lp' (n/a) with UID 7 and GID 7.
Creating group 'mail' with GID 8.
Creating user 'mail' (n/a) with UID 8 and GID 8.
Creating group 'news' with GID 9.
Creating user 'news' (n/a) with UID 9 and GID 9.
Creating group 'uucp' with GID 10.
Creating user 'uucp' (n/a) with UID 10 and GID 10.
Creating group 'proxy' with GID 13.
Creating user 'proxy' (n/a) with UID 13 and GID 13.
Creating group 'www-data' with GID 33.
Creating user 'www-data' (n/a) with UID 33 and GID 33.
Creating group 'backup' with GID 34.
Creating user 'backup' (n/a) with UID 34 and GID 34.
Creating group 'list' with GID 38.
Creating user 'list' (n/a) with UID 38 and GID 38.
Creating group 'irc' with GID 39.
Creating user 'irc' (n/a) with UID 39 and GID 39.
Creating user '_apt' (n/a) with UID 42 and GID 65534.
Creating user 'nobody' (n/a) with UID 65534 and GID 65534.
'/boot/initrd.img-6.18.34+rpt-rpi-v8' -> '/boot/firmware/initramfs8'
root@DietPi:~#
This package is not maintained nor managed by DietPi. It’s an original package from RPi. These are all global system groups. Not sure why they are generated now. Maybe @MichaIng knows.
ut oh. then why did dietpi recommend to do the upgrade? Do i have something set wrong in my apt sources? is there a cmd i can run to set my apt sources to only apply updates from dietpi? thank you.
These are all common system users and groups, present on all Debian systems. I saw this when switching from initramfs-tools to dracut (the new default initramfs implementation). As this output is generated while the initamfs image is built, I am sure these are created within the initramfs image, not on the host system.
EDIT: What is actually bad is, that the initramfs image is generated at all. There should be SKIP_INITRAMFS_GEN=yes in /etc/default/raspi-firmware, which should set INITRD=No in the package maintainer script, which should cause the initramfs build to be skipped.
@stevech which Debian version do you use? EDIT: Seems to be Trixie. I think I saw this on one of my RPis as well, but missed to investigate.
And you are on latest DietPi version?
If you do not explicitly require the initramfs, you could run this script:
# Raspberry Pi with new kernel stack
if (( $G_HW_MODEL < 10 )) && dpkg-query -s 'raspi-firmware' 2> /dev/null | grep -q '^Status: install ok installed$' &&
! grep -q '^[[:blank:]]*auto_initramfs=' /boot/firmware/config.txt &&
! grep -q '^[[:blank:]]*initramfs[[:blank:]]' /boot/firmware/config.txt
then
G_DIETPI-NOTIFY 2 'Disabling initramfs generation, since it is not explicitly enabled in config.txt'
G_CONFIG_INJECT 'SKIP_INITRAMFS_GEN=' 'SKIP_INITRAMFS_GEN=yes' /etc/default/raspi-firmware
G_EXEC rm -f /boot/initrd.img-* /boot/firmware/initramfs*
fi
So if the config.txt does not make explicit use of an initramfs, it is assured to be disabled in /etc/default/raspi-firmware, and existing images removed. Hopefully, the RPi kernel upgrades will respect that from now on.
version, after SSH login, shows DietPi v10.5.2
and it also says MOTD v10.5 has been released. it appears i am on latest.
cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.6
and it appears you are correct, the users are not actually on the running OS…
cut -d: -f1 /etc/passwd
root
daemon
bin
sys
sync
games
man
lp
mail
news
uucp
proxy
www-data
backup
list
irc
_apt
nobody
systemd-network
systemd-timesync
dietpi
sshd
messagebus
if I run your script, will it reset or erase anything on my rpi? I foolishly did not make an image backup before running the apt upgrade.
It will only remove the initramfs images, if the configuration does not explicitly use them. They are otherwise used if present, skipped if not. Most importantly: They are not needed on Raspberry Pi. The kernel has all drivers, needed to mount the rootfs, builtin. So an initramfs is only needed for extra features, like decrypting an encrypted rootfs via Dropbear SSH inside the initramfs: https://packages.debian.org/trixie/dropbear-initramfs
But a common setup does not need it, and can skip the overhead at boot, and the I/O implied when the initramfs is generated/updated.
ok, i don’t use dropbear, so i will run the script thank you.
This is not about whether you use Dropbear as SSH server in the OS, but whether you install this dedicated package to integrate it into the initramfs, as an additional SSH server that runs before the actual OS boots, e.g. to enter a passphrase to decrypt an encrypted root filesystem. Just an example of a custom setup where an initramfs would be required even with the official RPi OS kernel.
So yes, safe to run the script in your case.
sorry i didn’t understand the first time
I found out why the initramfs image is kept being created: dracut skips it on kernel upgrade, if the kernel declares INITRD=No, which is the case when SKIP_INITRAMFS_GEN=yes is set. However, there is an “update-initramfs” dpkg trigger, that is called in various other circumstances, like when systemd or udev are upgraded, or dracut itself. In this case, it creates initramfs images for all installed kernel versions which do not have one, and refreshes the initramfs image for the latest one. This is bad, since it ignores INITRD=No, and also consequently, all existing initramfs images should be refreshed, not just the latest.
The correct behavior is what initramfs-tools’ actual update-initramfs command does: It just refreshes all existing initramfs images, but does not create any new one. Debian 14 Forky switches from initramfs-tools to dracut as highest priority package to satisfy the initramfs dependency of their kernel packages. The bad behaviour of dracut was recognized in turn, hence Debian implemented the update-initramfs command into dracut as well, and uses it for the respective dpkg trigger, to behave exactly like the one from initramfs-tools: https://salsa.debian.org/kernel-team/dracut/-/commit/1d49619
However, this has not been backported to Debian 13 Trixie.
Hence, until we drop support for Debian Trixie in 2030, we should explicitly satisfy the formal initramfs package dependency of the RPi kernel with initramfs-tools, to avoid unnecessary initramfs image generations. I implemented this with Raspberry Pi: satisfy RPi kernel dependency with initramfs-tools · MichaIng/DietPi@c6a9f58 · GitHub for upcoming release. So @stevech next DietPi update will replace dracut with initramfs-tools in your case.