← Back to Linux Admin SCRIPT HOUSE — LINUX ADMIN
CH06 — LAB

Initialization & X Windows — Hands-On

Five exercises covering Linux boot process investigation, systemd target management, X11 and Wayland session identification, display manager configuration, and system localization — the foundation of understanding how Linux starts and presents its interface.

Platform: Linux Terminal
Exercises: 5
Difficulty: Intermediate
Est. Time: 50–65 min

Lab Objectives

1
Boot Process Investigation
BOOT ANALYSIS ▼
SCENARIOA server took unusually long to boot after a kernel update. You need to analyze the boot timeline — identify which services added latency, check for hardware detection errors, and understand the complete sequence from firmware to login prompt.
  1. View boot messages with timestamps: dmesg -T | head -50 (kernel ring buffer, human-readable timestamps)
  2. Show only errors and warnings from boot: dmesg -T --level=err,warn | head -30
  3. View the systemd boot log with timing: journalctl -b --no-pager | head -60
  4. Get a full boot timing report: systemd-analyze — shows total boot time
  5. See which services took the longest to start: systemd-analyze blame | head -20
  6. Visualize the boot chain (generates SVG if display is available, or text): systemd-analyze critical-chain
  7. Check when the system last booted: who -b and uptime -s
  8. View GRUB timeout (if accessible): grep -E "GRUB_TIMEOUT|GRUB_CMDLINE" /etc/default/grub 2>/dev/null
  9. Check loaded kernel modules: lsmod | wc -l (count) and lsmod | grep -i nvidia 2>/dev/null (specific module)
# systemd-analyze output: total boot time breakdown $ systemd-analyze Startup finished in 1.523s (firmware) + 2.871s (loader) + 1.204s (kernel) + 18.432s (userspace) = 24.031s graphical.target reached after 17.981s in userspace. # systemd-analyze blame: identify slow services $ systemd-analyze blame | head -10 12.431s NetworkManager-wait-online.service 4.892s snapd.service 2.341s apt-daily.service 1.823s ModemManager.service 1.244s plymouth-quit-wait.service # Critical chain: shows the dependency path that determined boot time $ systemd-analyze critical-chain graphical.target @17.981s └─display-manager.service @17.792s +0.188s └─plymouth-quit-wait.service @7.612s +10.179s
PERFORMANCE INSIGHT: BOOT OPTIMIZATION
The most common boot bottleneck is NetworkManager-wait-online.service, which waits for full network connectivity before continuing. On servers, this is often unnecessary. Disable it safely: systemctl disable NetworkManager-wait-online.service. Another common offender is snapd. The boot time breakdown (firmware + loader + kernel + userspace) is diagnostically useful: if firmware time is high, the BIOS is the bottleneck; if userspace is high, a service is the culprit. The critical chain output directly shows which service was the last dependency holding back the final target — that is your highest-impact optimization candidate.
2
systemd Target Management
TARGETS
SCENARIOYou need to switch a GUI desktop server to run as a headless server to reclaim memory, then later restore graphical mode. You also need to temporarily boot into rescue mode to fix a configuration error. Practice safe target switching without rebooting.
  1. Check the current default boot target: systemctl get-default
  2. List all available targets: systemctl list-units --type=target
  3. See the full list of target unit files: systemctl list-unit-files --type=target
  4. Check what the current active target is: systemctl status default.target
  5. Switch live to multi-user (no GUI) without rebooting: sudo systemctl isolate multi-user.target — the GUI will close if running
  6. Switch back to graphical mode: sudo systemctl isolate graphical.target
  7. Set the permanent default to multi-user (headless server): sudo systemctl set-default multi-user.target
  8. Restore graphical as permanent default: sudo systemctl set-default graphical.target
  9. Verify the default was changed: systemctl get-default
# Runlevel to systemd target mapping reference # runlevel 0 → poweroff.target (halt) # runlevel 1 → rescue.target (single user, maintenance) # runlevel 3 → multi-user.target (full multi-user, no GUI) # runlevel 5 → graphical.target (multi-user + GUI) # runlevel 6 → reboot.target (reboot) $ systemctl get-default graphical.target # Switch to headless mode (multi-user, no display manager) $ sudo systemctl isolate multi-user.target # GUI shuts down; you are now in a text console session # Set headless as the permanent default (for server use) $ sudo systemctl set-default multi-user.target Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/multi-user.target. # Verify $ systemctl get-default multi-user.target
CAUTION — ISOLATE COMMANDsystemctl isolate immediately switches to the target and stops all services not in that target's dependency tree. If you isolate to multi-user.target while using a GUI, your desktop session will end. Always verify you have console access or SSH access before isolating on a remote machine. Never isolate to rescue.target on a production system without physical console access — you will lock yourself out.
TARGETS VS RUNLEVELS
systemd targets are more expressive than SysVinit runlevels because they are dependency-based rather than ordered levels. Multiple targets can be active simultaneously — graphical.target does not replace multi-user.target, it extends it. The isolate command is the equivalent of telinit N from SysVinit, but acts on targets. The /etc/systemd/system/default.target symlink is how the default is set — if you ever need to diagnose a broken default, verify which target that symlink points to. On servers, set multi-user.target as default: it saves the memory overhead of the entire display stack (~50-200MB depending on the desktop environment).
3
X11 vs Wayland Session Identification
X WINDOWS
SCENARIOA developer reports that their screen recording software and remote desktop tool behave differently on two supposedly identical machines. You investigate and discover one is running X11 and the other Wayland. Identify and document the session type and understand the architectural implications.
  1. Check the display session type: echo $XDG_SESSION_TYPE — outputs "x11" or "wayland"
  2. Check the WAYLAND_DISPLAY variable: echo $WAYLAND_DISPLAY — set only in Wayland sessions
  3. Check the DISPLAY variable: echo $DISPLAY — typically set in X11 sessions (e.g., :0)
  4. List running display-related processes: ps aux | grep -E "Xorg|wayland|weston|sway|gnome-shell" | grep -v grep
  5. Check the X11 socket if present: ls -la /tmp/.X*-lock 2>/dev/null — X11 creates lock files per display
  6. Check available display capabilities: xdpyinfo 2>/dev/null | head -20 (X11 only; fails on Wayland)
  7. On a running X session, find the X server binary: which Xorg Xwayland 2>/dev/null
  8. View installed X packages: dpkg -l | grep -E "^ii.*xorg|wayland" 2>/dev/null | head -20 or rpm -qa | grep -E "xorg|wayland" 2>/dev/null | head -20

X11 / X Window System

  • $DISPLAY=:0 is set
  • /tmp/.X0-lock file exists
  • Xorg process in ps output
  • xdpyinfo returns data
  • XWayland not running
  • ~40 years old, widely compatible

Wayland

  • $WAYLAND_DISPLAY is set
  • No /tmp/.X lock files
  • mutter/weston/sway in ps
  • xdpyinfo fails (no X server)
  • XWayland may run for compat
  • Modern, more secure isolation
# X11 session indicators $ echo $XDG_SESSION_TYPE x11 $ echo $DISPLAY :0 $ ls /tmp/.X*-lock /tmp/.X0-lock # Wayland session indicators $ echo $XDG_SESSION_TYPE wayland $ echo $WAYLAND_DISPLAY wayland-0 $ echo $DISPLAY :0 # May still be set if XWayland is running for X11 app compatibility # Check if XWayland is bridging X11 apps in a Wayland session $ ps aux | grep -i xwayland | grep -v grep user 1523 0.1 1.2 Xwayland :0 -rootless -noreset -accessx
WAYLAND SECURITY ARCHITECTURE
Wayland's key security advantage is process isolation: each application can only see its own window contents, not the entire screen. In X11, any application can read keyboard input and capture screenshots of other windows — a fundamental security flaw exploited by keyloggers and screen scrapers. Wayland enforces that applications request explicit capture permissions. The tradeoff is compatibility: many legacy tools (remote desktop protocols like VNC, some screen recorders, older accessibility tools) require X11. XWayland is a compatibility bridge — it provides an X11 server as a Wayland client, allowing X11 apps to run inside a Wayland session at the cost of the security boundary for those apps.
4
Display Manager Management
DISPLAY MGR
SCENARIOA university lab is switching from GDM3 (GNOME Display Manager) to LightDM to reduce memory usage on older hardware. You need to identify the current display manager, understand how it is managed as a systemd service, switch to a different one, and verify the change takes effect.
  1. Identify the current display manager: cat /etc/X11/default-display-manager 2>/dev/null
  2. Alternative identification: systemctl status display-manager.service — the loaded unit shows the active DM
  3. Check which display managers are installed: dpkg -l | grep -E "gdm|lightdm|sddm|xdm" 2>/dev/null or rpm -qa | grep -E "gdm|lightdm|sddm"
  4. View the display-manager symlink: ls -la /etc/systemd/system/display-manager.service
  5. Check which DM service file the symlink points to: systemctl cat display-manager.service | head -5
  6. If on Ubuntu/Debian, switch DMs via: sudo dpkg-reconfigure lightdm (interactive) or manually: sudo systemctl disable gdm3 && sudo systemctl enable lightdm
  7. After switching, verify the new active DM: systemctl status display-manager.service
  8. View the LightDM configuration (if installed): cat /etc/lightdm/lightdm.conf 2>/dev/null
  9. To apply the change: sudo systemctl restart display-manager.service — this will restart the GUI login screen
# Identify current display manager $ cat /etc/X11/default-display-manager /usr/sbin/gdm3 $ systemctl status display-manager.service ● gdm.service - GNOME Display Manager Loaded: loaded (/lib/systemd/system/gdm.service; enabled) Active: active (running) # The display-manager.service is a generic alias $ ls -la /etc/systemd/system/display-manager.service lrwxrwxrwx 1 root root ... display-manager.service → /lib/systemd/system/gdm.service # Switch: disable old, enable new (requires restart to take effect) $ sudo systemctl disable gdm3 $ sudo systemctl enable lightdm Created symlink /etc/systemd/system/display-manager.service → /lib/systemd/system/lightdm.service
CAUTION — DISPLAY MANAGER RESTARTRestarting display-manager.service will close all active graphical sessions on the machine, logging out all users with unsaved work. On a shared machine, notify all users before running systemctl restart display-manager. On a remote headless server, changing the display manager without physical or console access can leave you locked out if the new DM fails to start correctly. Always test on a non-production machine first.
DISPLAY MANAGER ROLE IN THE BOOT CHAIN
The display manager is the graphical equivalent of getty (the text login prompt). It provides the visual login screen, authenticates the user, launches the user session (window manager + desktop environment), and sets session environment variables. The chain is: systemd starts display-manager.service → DM starts the X server or Wayland compositor → DM shows the login screen → user logs in → DM launches the session (GNOME, KDE, i3, etc.) → user's ~/.profile and ~/.xinitrc are sourced. Understanding this chain explains why changing a DM can affect which desktop environments are available at login, and why a crashing DM drops you to a blank screen with no way to log in graphically.
5
Locale, Timezone, and Keyboard Configuration
LOCALIZATION
SCENARIOYou are setting up a server for a client whose team is in Tokyo and whose log analysis tool requires all timestamps to be UTC. Additionally, a second workstation needs a French keyboard layout and French locale. Configure both scenarios correctly and verify each setting with the appropriate tools.
  1. Check current locale settings: localectl or locale
  2. Check current timezone: timedatectl — shows local time, UTC time, and timezone
  3. List all available timezones: timedatectl list-timezones | grep -E "Tokyo|UTC|New_York" | head -10
  4. Set timezone to UTC for the log server: sudo timedatectl set-timezone UTC
  5. Verify the change: timedatectl | grep "Time zone"
  6. List available locales: localectl list-locales | grep -E "fr_FR|en_US" | head -10
  7. Set the system locale to US English UTF-8: sudo localectl set-locale LANG=en_US.UTF-8
  8. List available keyboard layouts: localectl list-keymaps | grep -E "^fr$|^us$|^de$" | head -10
  9. Set the keyboard layout to French: sudo localectl set-keymap fr
  10. Verify all settings: localectl — should show locale and keymap
  11. Confirm timezone is reflected in date output: date and date -u (UTC comparison)
# Current state inspection $ timedatectl Local time: Fri 2025-01-15 14:32:11 EST Universal time: Fri 2025-01-15 19:32:11 UTC RTC time: Fri 2025-01-15 19:32:11 Time zone: America/New_York (EST, -0500) System clock synchronized: yes NTP service: active # Set timezone to UTC for log server consistency $ sudo timedatectl set-timezone UTC $ timedatectl | grep "Time zone" Time zone: UTC (UTC, +0000) # Locale configuration $ localectl System Locale: LANG=en_US.UTF-8 VC Keymap: us X11 Layout: us # Switch to French keyboard layout $ sudo localectl set-keymap fr $ sudo localectl set-x11-keymap fr $ localectl | grep -E "Keymap|Layout" VC Keymap: fr X11 Layout: fr
UTC AS THE UNIVERSAL LOG STANDARD
Always run servers in UTC, never local time. Here is why: when correlating logs across multiple servers, mixed timezones create forensic nightmares — an event in EST and a response in PST look like they happened 3 hours apart in raw logs. UTC is the ground truth. Set timedatectl set-timezone UTC on every server. Let your log aggregation tool (Splunk, Elasticsearch, Graylog) convert to local time for display. Also note: LANG controls the locale for the entire system (date formats, number formats, error message language), while LC_ALL overrides all locale settings including LANG. In scripts, always set LANG=C or LC_ALL=C to get predictable English ASCII output regardless of system locale — locale-aware commands like sort behave differently with different locales.

Linux Administration Course Complete

You have finished all six chapters. Mark complete to record your progress.

Course complete! All six chapters of Linux Administration finished.