Concepts·LPIC-1

Targets, runlevels, and what the kernel found

Objective 101.3 is runlevels and boot targets, and on a current machine the honest answer is that runlevels are a compatibility layer over systemd targets. This guide shows the target the machine boots to - and the surprise that the file supposedly defining it does not exist - then uses /proc and /sys to inventory the hardware without installing anything.

101: System Architecture Guide 5 of 33 Beginner

OSUbuntu 26.04 LTS
Kernel7.0.0-30-generic
systemd259
TimeAbout 17 min

One Debian-family host. Every command reads firmware, kernel or systemd state - nothing is configured, enabled or changed.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC1-A01	192.168.0.76	Ubuntu 26.04 LTS	Debian-family host - dpkg and apt, which objective 102.4 names	2 Core	4 GB	50 GB

This guide includes

Use this for the runlevels objective on a machine that no longer has them. This matters because the compatibility layer answers some of these questions and not others - and the file the objective describes is not there at all.

reading the default target, with nothing configured
using the runlevel compatibility layer, and finding its limits
reading hardware from files that are not on any disk

Before you start

boot-firmware-and-what-the-kernel-was-told

The default target, and the file that is not there
get-default answers even with nothing configured.
bash Example session
```
$systemctl get-default; echo "---"; ls -l /etc/systemd/system/default.targetgraphical.target---ls: cannot access '/etc/systemd/system/default.target': No such file or directory[exit 2]$systemctl list-units --type=target --state=active --no-pager | head -6  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION  basic.target            loaded active active Basic System  boot-complete.target    loaded active active Boot Completion Check  cryptsetup.target       loaded active active Local Encrypted Volumes  getty-pre.target        loaded active active Preparation for Logins  getty.target            loaded active active Login Prompts
```
Note
The answer and the missing file are both correct, and the pair is the lesson. systemctl get-default reports graphical.target while /etc/systemd/system/default.target does not exist. That symlink is an OVERRIDE - it is created when someone runs systemctl set-default. With no override, systemd falls back to the vendor default shipped in /usr/lib/systemd/system/.

Which is the general rule for the whole of systemd, and it is worth learning here: /usr/lib/systemd/system is what the package provides, /etc/systemd/system is what the administrator overrides, and /etc wins. An empty /etc does not mean unconfigured, it means unmodified.

Several targets are active at once, and that is not a contradiction. Targets are groups of units, not exclusive modes. graphical.target pulls in multi-user.target, which pulls in basic.target, and all of them are active together. A runlevel was one number at a time; a target is a set.

graphical.target on a server with no desktop is normal, because it is the vendor default for the distribution. systemctl set-default multi-user.target is the change worth making on a machine that will never have a display.

Expected resultgraphical.target - and then ls: cannot access '/etc/systemd/system/default.target': No such file or directory, followed by the targets currently active.

Success conditionYou know where a default comes from when nobody has set one.
Runlevels, and why the command is missing
The compatibility layer, and its limits.
zsh Example session
```
$systemctl list-dependencies multi-user.target --no-pager 2>/dev/null | head -6multi-user.target● ├─apport.service● ├─chrony.service● ├─console-setup.service● ├─cron.service● ├─dbus.service$runlevel; who -r; echo "--- the old interface, still answered for compatibility"zsh:2: command not found: runlevel--- the old interface, still answered for compatibility
```
Note
runlevel is not installed, and that IS the answer to the objective. The command lives in sysvinit-utils and is not part of a default install any more. A candidate who has only ever read about runlevels would conclude the machine is broken; it is simply a machine where the compatibility shim was never needed.

The mapping still exists as target aliases. runlevel3.target is a symlink to multi-user.target and runlevel5.target to graphical.target, so systemctl isolate runlevel3.target works. Know the pairs: 0 poweroff, 1 rescue, 3 multi-user, 5 graphical, 6 reboot - they are asked directly.

list-dependencies is how you answer "what does this target actually start". The tree is recursive, which is why graphical.target ultimately reaches every service on the machine, and it is the tool for working out why something you never enabled is running.

isolate is the verb that means "switch to", stopping anything not required by the new target. systemctl isolate rescue.target is the modern init 1, and running it on a remote machine will disconnect you.

Expected resultThe services multi-user.target pulls in - chrony, cron, dbus - and then zsh: command not found: runlevel.

Success conditionYou can answer a runlevel question on a machine that has no runlevels.
Hardware, from files that are not on a disk
/proc and /sys are generated when you read them.
bash Example session
```
$lscpu | grep -E '^(Architecture|CPU$s$|Model name|Hypervisor vendor|Virtualization)'Architecture:                            x86_64CPU(s):                                  2Model name:                              Intel(R) Core(TM) i9-14900KHypervisor vendor:                       MicrosoftVirtualization type:                     full$lsblk -d -o NAME,SIZE,ROTA,TYPE | head -6; echo "--- ROTA 1 = spinning, 0 = solid state"NAME  SIZE ROTA TYPEfd0     4K    1 disksda     5G    1 disksdb     5G    1 disksdc     5G    1 disksdd     5G    1 disk--- ROTA 1 = spinning, 0 = solid state$df -h /proc /sys | tail -2; echo "--- size 0: they are generated on read"proc               0     0     0    - /procsysfs              0     0     0    - /sys--- size 0: they are generated on read
```
Note
Size 0 is the point. /proc and /sys are pseudo-filesystems: nothing is stored, and each file is generated by the kernel at the moment you read it. cat /proc/uptime is a function call wearing a filename. That is why they cost no disk and why their contents cannot be stale.

lscpu and lsblk are readers, not sources. Everything they print comes from /sys, formatted. Knowing that means you can answer a hardware question on a minimal container where those tools are absent - /proc/cpuinfo and /sys/class/net/*/address are always there.

Hypervisor vendor: Microsoft tells you this is a guest. The model name is the physical host's CPU, passed through - so a virtual machine reports impressive silicon and two cores of it. Reading that as bare metal is a common mistake.

ROTA 1 on every disk here is the hypervisor being conservative, not evidence of spinning platters. Virtual disks report rotational unless the host says otherwise, and the scheduler makes different choices depending - which is worth knowing before tuning anything on storage.

/proc/uptime gives two numbers: seconds since boot, and total idle seconds summed across every core. On a two-core machine the second can be nearly twice the first, which looks wrong and is not.

Expected resultx86-64, 2 CPUs, an i9-14900K under a Microsoft hypervisor; the disks with ROTA 1; and /proc and /sys reporting size 0.

Success conditionYou can inventory a machine without installing a single tool.

Troubleshooting

systemctl get-default answers, but /etc/systemd/system/default.target does not exist.

Why: When no local override has been set, systemd falls back to the distribution default and there is no symlink in /etc to see.

Fix:Trust systemctl get-default. Running systemctl set-default <target> is what creates the symlink; before that, nothing in /etc records the choice.
runlevel or telinit is not found.

Why: These are SysV compatibility commands. On a systemd-only installation the package that provides them may not be installed at all.

Fix:Use the systemd equivalents: systemctl get-default, systemctl list-units --type=target --state=active, and systemctl isolate <target> instead of telinit.
lshw, dmidecode or lspci is unavailable and hardware still has to be identified.

Why: Those are separate packages. The kernel already exposes the same information through generated filesystems.

Fix:Read /proc/cpuinfo, /proc/meminfo and /sys/class/dmi/id/*. They are generated on read, exist on every machine, and need no package.

Official sources

← All LPIC-1 guides

Targets, runlevels, and what the kernel found

This guide includes

Before you start

The default target, and the file that is not there

Runlevels, and why the command is missing

Hardware, from files that are not on a disk

Troubleshooting

Official sources