Debian 11: Resolving the Failed to Start GNOME Display Manager Error

Encountering a black screen after a systemctl reboot on your Debian 11 system, especially one that culminates in a message indicating a “Failed to start Update UTMP about System Boot/Shutdown” and subsequently the GNOME Display Manager (GDM), can be a perplexing issue. This scenario often leaves users staring at an unresponsive terminal or a frozen Plymouth splash screen, with the only recourse being a manual switch to a TTY. At revWhiteShadow, we understand the frustration this can cause, particularly for those new to the intricacies of Linux system administration. Our aim with this comprehensive guide is to dissect this common yet disruptive problem, providing clear, actionable steps to diagnose and resolve the underlying causes, thereby restoring your graphical environment.

The diagnostic outputs you’ve provided are invaluable. The failure of systemd-update-utmp.service with the specific error “Failed to write utmp record: No space left on device” is a critical clue. This immediately points towards a fundamental system resource issue: disk space exhaustion. When the root partition, or indeed any critical partition, is completely full, numerous system services can falter, as they are unable to write necessary log files, temporary data, or update essential system records.

Following this, the repeated failures of gdm.service, stemming from ExecStartPre=/usr/share/gdm/generate-config, further underscore the impact of this disk space constraint. GDM, the GNOME Display Manager, relies on various configuration files and temporary directories to initialize the graphical session. If the system cannot write to these locations due to a lack of disk space, GDM will inevitably fail to start.

Let’s embark on a detailed exploration of how to systematically address this problem, starting with the most probable culprit: disk space.

Diagnosing and Resolving Disk Space Exhaustion

The initial and most crucial step is to confirm and address the “No space left on device” error. Your observation that /dev/mapper/D20--vg-root mounted on / is 100% used is the smoking gun.

Accessing a TTY for Disk Cleanup

Since your graphical environment is not loading, you will need to access a text-based console, commonly referred to as a TTY.

Switching to a TTY: After the system boots and displays the failure messages, try pressing Ctrl+Alt+F2 (or F3, F4, F5, or F6). This should present you with a login prompt for a virtual console. Log in with your regular username and password.

Identifying Space-Consuming Files and Directories

Once logged into a TTY, the immediate priority is to free up disk space. We need to identify what is consuming the most space on your root partition.

Using df -h: This command provides a human-readable overview of disk space usage for all mounted file systems.
```
df -h
```
Confirm that your root partition (/) is indeed at 100%.
Using du -sh * in relevant directories: The du command (disk usage) is essential for drilling down into directories to find what’s taking up space. Start by examining common locations that tend to grow over time.
- /var/log: This directory often accumulates log files. If log rotation isn’t functioning correctly or if there’s an underlying issue causing excessive logging, this directory can expand significantly.
```
sudo du -sh /var/log/* | sort -rh | head -n 10
```
  This command will list the top 10 largest files or directories within /var/log, sorted by size in reverse order (largest first). Look for unusually large log files, particularly .log files or compressed archives like .gz.
- /var/cache: Package manager caches, particularly from apt, can consume considerable space.
```
sudo du -sh /var/cache/apt/archives/* | sort -rh | head -n 10
```
  This will help identify large .deb package files that are no longer needed.
- /tmp: While typically cleaned up on reboot, if the system didn’t shut down cleanly, temporary files might persist.
```
sudo du -sh /tmp/* | sort -rh | head -n 10
```
- /home: User data, especially large downloads or media files, can fill up partitions.
```
sudo du -sh /home/* | sort -rh | head -n 10
```
  If you have multiple users, you’ll need to investigate each user’s home directory.
- /var/lib: This directory can contain various data, including Docker images and volumes if you use Docker, or other application data.
```
sudo du -sh /var/lib/* | sort -rh | head -n 10
```

Cleaning Up Disk Space

Once you’ve identified the major space consumers, you can start removing them. Exercise caution when deleting files, especially system files.

Cleaning APT Cache:

sudo apt autoremove  # Removes unused dependencies
sudo apt clean       # Clears out the local repository of retrieved package files

After running these, check df -h again.

Removing Old Log Files: If you find large log files in /var/log, you can carefully remove older ones. It’s generally safer to remove specific large log files after ensuring they are not critical. For example, if syslog.1.gz is massive:
```
sudo rm /var/log/syslog.1.gz
```
Be extremely cautious here. Avoid deleting syslog, auth.log, or other currently active logs. If log rotation is the issue, fixing that is a longer-term solution, but for immediate recovery, targeted deletion is necessary.
Removing Unnecessary User Files: Navigate to your home directory (cd ~) and use rm to delete files you no longer need. For example:
```
rm Downloads/large_file.iso
```
Handling LVM Snapshots (if applicable): If you are using LVM and have taken snapshots, they can consume significant space. Check your LVM configuration if you suspect this might be the case.
Temporary Files:
```
sudo rm -rf /tmp/*
```
Use rm -rf with extreme caution. Ensure you are within the /tmp directory before executing this.

After performing cleanup, run df -h again. If you have freed up enough space (even a few hundred MB or a few GB can be enough to get the system booting again), you can attempt to restart the GDM service or reboot the system.

Restarting Services and Rebooting

Once you believe you’ve cleared sufficient space, try the following:

Restart GDM:
```
sudo systemctl restart gdm.service
```
If this brings up the graphical login, great!
Attempt a Reboot: If restarting GDM doesn’t immediately show the login screen, reboot the system cleanly.
```
sudo systemctl reboot
```

If the system now boots into the GNOME desktop, the disk space issue was the primary cause.

Investigating `systemd-update-utmp.service` Failure

While disk space was the most immediate cause, let’s briefly touch upon why systemd-update-utmp.service might fail even when space is available, or as a consequence of the space issue.

The systemd-update-utmp.service is responsible for updating the /var/run/utmp and /var/log/wtmp files, which track user logins and system boot/shutdown events. When it fails with “No space left on device”, it means it couldn’t write to these files.

/var/run: This directory is often a tmpfs (a temporary file system residing in RAM), but it can also be linked to a location on disk depending on the system’s configuration. If /var itself is on the root partition and that partition is full, it impacts /var/run.
/var/log: This is a standard directory on the disk. If the root partition is full, /var/log will also be full, preventing writes.

The fact that you saw systemd-update-utmp.service fail, and then gdm.service fail with issues related to configuration generation, indicates a cascade effect. System services often depend on each other. A failure in a low-level service like updating UTMP records can prevent higher-level services like the display manager from starting.

Addressing GNOME Display Manager (GDM) Specific Issues

If, after clearing disk space, you still face issues with GDM, or if disk space was not the root cause, we need to investigate GDM more directly.

Checking GDM Configuration and Status

Even when GDM fails to start, you can often glean more information from its service status.

Detailed GDM Status:
```
systemctl status gdm.service
```
You’ve already provided this output, showing ExecStartPre=/usr/share/gdm/generate-config failing. This pre-start script is designed to ensure GDM has the necessary up-to-date configuration. Its failure suggests that either the script itself is corrupted, or more likely, the underlying system constraints (like disk space or permissions) prevent it from executing successfully.
GDM Logs: GDM also generates its own logs, which can be found in /var/log/gdm3/. You can examine these using journalctl or cat.
```
sudo journalctl -u gdm.service -xe
```
This command will display the systemd journal entries specifically for the gdm.service, with extended information (-xe) that can be very helpful.

Reconfiguring GDM

In some cases, GDM’s configuration might have become corrupted. You can attempt to reconfigure it.

Reconfigure GDM Package:
```
sudo dpkg-reconfigure gdm3
```
This command will prompt you to choose your default display manager if you have multiple installed (e.g., GDM, LightDM, SDDM). Even if GDM is already selected, reconfiguring it can sometimes fix configuration file issues.

Checking GDM Configuration Files

The primary configuration file for GDM is typically located at /etc/gdm3/custom.conf.

Examine custom.conf:
```
cat /etc/gdm3/custom.conf
```
Look for any unusual settings or comments that might be causing problems.

Reinstalling GDM

If reconfiguration doesn’t help, a clean reinstallation of GDM might be necessary.

Remove and Reinstall GDM:
```
sudo apt remove gdm3
sudo apt autoremove
sudo apt install gdm3
```
After installation, it might prompt you to select the default display manager again.

Investigating Graphics Driver Issues (Nouveau)

Your edit mentions trying nouveau.modeset=0. This indicates you suspect graphics driver issues. While the disk space problem is more prominent in your output, graphics drivers can indeed cause display manager failures.

The nouveau driver is the open-source driver for NVIDIA hardware. If this driver is failing to initialize correctly, it can prevent GDM from starting. Adding nouveau.modeset=0 to the GRUB command line attempts to disable the kernel’s modesetting for Nouveau, forcing it to use an older, potentially more stable, method.

If you have NVIDIA hardware and have installed proprietary NVIDIA drivers, or if you are using the Nouveau driver and it’s causing issues, here’s how to proceed:

Ensuring Correct Graphics Driver Installation

Identify Your Graphics Card:
```
lspci -k | grep -EA3 'VGA|3D|Display'
```
This will show your graphics card and the kernel driver in use.
If using Nouveau and experiencing issues:
1. Blacklist Nouveau: To prevent Nouveau from loading, you can create a blacklist file:
```
echo "blacklist nouveau" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
echo "options nouveau modeset=0" | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf
```
2. Update Initramfs: After modifying modprobe configurations, you must update the initramfs:
```
sudo update-initramfs -u
```
3. Reboot:
```
sudo reboot
```
  If you have proprietary NVIDIA drivers installed, this step should automatically load them. If you don’t have proprietary drivers and want to use them, you’ll need to install them.
If using proprietary NVIDIA drivers:
1. Check Driver Status: Ensure the NVIDIA kernel module is loaded:
```
lsmod | grep nvidia
```
2. Reinstall NVIDIA Drivers: Sometimes, kernel updates can break proprietary driver compatibility. Reinstalling the drivers is often the solution.
  - Using ubuntu-drivers (if available or for similar systems): While Debian doesn’t have ubuntu-drivers, the principle is similar. You might find specific Debian packages for NVIDIA drivers.
  - Using apt: Identify the recommended driver package for your card. For example, it might be nvidia-driver or a specific version.
```
sudo apt update
sudo apt install nvidia-driver  # Or a specific version like nvidia-driver-510
```
    Follow any on-screen instructions. After installation, update initramfs and reboot as described above.

GRUB Configuration Update

If you made changes to the GRUB configuration (like adding nouveau.modeset=0), you must update GRUB to apply these changes.

Update GRUB:
```
sudo update-grub
```
Then reboot.

Systemd Boot Target and Troubleshooting

The fact that your system progresses through boot messages before failing suggests that systemd is attempting to start services, but is hitting roadblocks.

Checking the Default Target: By default, Debian 11 should boot into the graphical target. You can verify this:
```
systemctl get-default
```
It should output graphical.target. If it’s multi-user.target, that explains why you’re not getting a graphical login.

Switching to Graphical Target (if needed):

sudo systemctl set-default graphical.target
sudo systemctl reboot

Revisiting the `systemd-update-utmp.service` Error Details

Let’s assume for a moment that disk space wasn’t the only issue, or that the systemd-update-utmp.service failed for a different reason. The output stated: . systemd-update-utmp.service - UPDATE UTMP about System Boot/Shutdown Loaded: loaded (/lib/systemd/system/systemd-update-utmp.service; static) Active: failed (Result: exit-code) since Tue 2022-02-08 14:30:01 EET; 8min ago Docs: man:systemd-update-utmp.service man:utmp(5) Process: 818 ExecStart=/lib/systemd/systemd-update-utmp reboot (code=exited, status=1/FAILURE) Main PID: 818 (code=exited, status=1/FAILURE)

The line Failed to write utmp record: No space left on device is clear. However, if that were fixed, and it still failed, you might look at:

Permissions: Ensure the /var/run/utmp file has the correct permissions.
```
ls -l /var/run/utmp
```
It should typically be owned by root and have read/write permissions for root, and read for others.
File Integrity: If the file was corrupted, it might cause issues. However, systemd usually handles creating this file.

Plymouth and Boot Process

The mention of “plymouth terminate” indicates that the graphical boot splash screen (Plymouth) has finished its sequence, but the actual display manager (GDM) failed to take over. This is consistent with GDM failing to start.

If you wish to disable Plymouth temporarily to get a cleaner boot log:

Edit GRUB:
```
sudo nano /etc/default/grub
```
Find the line starting with GRUB_CMDLINE_LINUX_DEFAULT and add nomodeset plymouth.enable=0 inside the quotes. For example: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset plymouth.enable=0"
Update GRUB:
```
sudo update-grub
```
Reboot:
```
sudo reboot
```
This will show you the textual boot messages directly, making it easier to spot where the process halts.

Conclusion: A Multi-faceted Approach

The issue of Debian 11 failing to start the GNOME Display Manager after a reboot, especially when accompanied by the “Failed to start Update UTMP about System Boot/Shutdown” error and the “No space left on device” message, overwhelmingly points to a critical disk space exhaustion on the root partition. Our detailed diagnostic steps focus on freeing up this space by identifying and removing unnecessary files from /var/log, /var/cache, and other potential locations.

Once disk space is remediated, the system should be able to successfully execute the systemd-update-utmp.service and subsequently allow GDM to initialize. If graphical issues persist, further investigation into GDM configuration, graphics driver compatibility (particularly with Nouveau or NVIDIA proprietary drivers), and systemd targets is warranted. By systematically working through these potential causes, you can effectively restore your Debian 11 system to its intended graphical state. We at revWhiteShadow are dedicated to providing the clarity and detailed guidance needed to overcome such technical hurdles, empowering you to maintain a robust and functional Linux environment.

Debian 11 Failed to start GNOME display manager

Debian 11: Resolving the Failed to Start GNOME Display Manager Error #

Diagnosing and Resolving Disk Space Exhaustion #

Accessing a TTY for Disk Cleanup #

Identifying Space-Consuming Files and Directories #

Cleaning Up Disk Space #

Restarting Services and Rebooting #

Investigating systemd-update-utmp.service Failure #

Addressing GNOME Display Manager (GDM) Specific Issues #

Checking GDM Configuration and Status #

Reconfiguring GDM #

Checking GDM Configuration Files #

Reinstalling GDM #

Investigating Graphics Driver Issues (Nouveau) #

Ensuring Correct Graphics Driver Installation #

GRUB Configuration Update #

Systemd Boot Target and Troubleshooting #

Revisiting the systemd-update-utmp.service Error Details #

Plymouth and Boot Process #

Conclusion: A Multi-faceted Approach #