NanoPi R76S - Unknown runlevel

[oxoocoffee]

Creating a bug report/issue

• [ x] I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=19
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN

trixie

• Kernel version | uname -a

Linux nano 6.1.115-vendor-rk35xx #1 SMP Tue Nov  4 14:07:09 UTC 2025 aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

NanoPi R76S (aarch64) # 16G RAm and Wi-Fi add-on card

• Power supply used | (EG: 5V 1A RAVpower)

100W USB-C PD charger

• SD card used | (EG: SanDisk ultra)

SanDisk Extreme Black

Additional Information (if applicable)

• Software title | (EG: Nextcloud) run level
• Was the software title installed freshly or updated/migrated? Yes
• Can this issue be replicated on a fresh installation of DietPi? Yes

• Bug report ID | echo $G_HW_UUID

e5e16fdf-6783-47cd-bae7-b6aef2a8b38e

Steps to reproduce

1. Downloaded latest DietPi_NanoPiR76S-ARMv8-Trixie.img.xz and dd to SD card
2. Complete first time configuration. No desktop desktop install level 3
3. Reboot and login back and run runlevel

Expected behaviour

• return proper runlevel

Actual behaviour

• it prints unknown

Extra details

• I also noticed on clean rPI4/5 install I get N 5 or N 3.

73,

[MichaIng]

TL;DR: Forget about runlevels. They are a SysV concept and do not exist with systemd.

systemd implemented some target-runlevel mapping for backwards compatibility, but it never was accurate, since things work just differently in systemd, with concurrency and targets being able to be reached in different order. There are no such hard system states like it was with SysV, but instead you can check via targets whether certain things should work, like network-online.target, getty.target, graphical.target. Some, but not all of these targets are directly or indirectly ordered relative to each other.

The runlevel command uses the utmp database to get its info, which however has been removed with Debian Trixie, since it is inherently not year 2038 safe. There are replacements for wtmp and lastlog, but not for utmp. Since runlevel is part of the systemd-sysv package, and upstream systemd suggest to use logind as replacement instead, maybe the runlevel command has been adjusted, while only the manpage has not been updated accordingly. If you want to test:

sudo systemctl unmask systemd-logind
sudo apt install dbus
sudo systemctl start dbus systemd-logind

I guess a reboot is needed to assure things are registrierend with logind, then test runlevel again.

But I highly recommend to not use runlevel anymore, forget about the concept, and check systemd targets or service states, whichever thing you need to know about the system state.

Hence what is your use case/aim?