After power outage I can only boot to black screen with mouse cursor.
SOLVED: Booting to Black Screen with Mouse Cursor After Power Outage
A sudden power outage can leave any computer user in a state of anxiety, especially when the familiar graphical login screen fails to appear, replaced instead by an unsettling black screen with a persistent, albeit responsive, mouse cursor. This situation, often encountered after unexpected system shutdowns, can be particularly perplexing for users of Linux distributions, such as Ubuntu, especially those with advanced configurations like LUKS encryption and custom GRUB boot entries. At revWhiteShadow, we understand the frustration this anomaly can cause. This comprehensive guide is meticulously crafted to help you diagnose and resolve this specific issue, aiming to provide a clearer path to recovery than other existing resources. We will delve deep into the potential causes and offer detailed, actionable steps to restore your system’s graphical interface, drawing upon extensive troubleshooting experience.
Understanding the Black Screen with Mouse Cursor Phenomenon
The perplexing display of a black screen accompanied by a functional mouse cursor, while frustrating, is often a symptom of a deeper underlying issue within the operating system’s boot process. Unlike a complete system freeze where no input is registered, the presence of the cursor indicates that a certain level of the system has initialized and is responding to hardware input. However, the failure to launch the graphical display manager, desktop environment, or related services points towards a disruption in the sequence of operations that typically bring your visual interface to life.
When a power outage occurs abruptly, it can interrupt critical file write operations, corrupt data in memory that was destined for disk, or even damage the filesystem itself. For users employing advanced disk encryption like LUKS, the decryption process and subsequent mounting of partitions are crucial steps. Any corruption or interruption during these stages can cascade into broader system instability, preventing the display manager from loading correctly. The black screen is often the result of the graphical subsystem failing to start, leaving the user in a text-mode-like environment, but with the graphical cursor indicating that the graphics drivers themselves might be partially initialized.
The specific scenario described, where a user can successfully boot into an emergency mode or a multi-user target via the command line, is a significant clue. It confirms that the core operating system is functioning and that the storage devices, including the LUKS-encrypted partitions, are accessible. The problem, therefore, lies in the transition from the command-line-based boot environment to the graphical user interface (GUI). This transition involves numerous services, daemons, and configuration files, any of which could be compromised or misconfigured due to the power interruption.
Initial Assessment: Confirming System Integrity After the Outage
Before diving into more complex solutions, it is crucial to perform a basic assessment to confirm that the core components of your system remain functional. The ability to access a command-line interface (CLI) through GRUB commands or an emergency mode is paramount.
Accessing the Command Line Interface (CLI)
As indicated in the user’s experience, booting with specific GRUB parameters like systemd.unit=multi-user.target allows for access to the CLI. This is a vital step that bypasses the graphical login manager. Once in the CLI, you can begin to inspect system logs and test critical services.
Verifying Disk Space and Filesystem Integrity
Low disk space, particularly in critical areas like /tmp, /var, or /home, can prevent services from starting correctly, including the display manager. Similarly, filesystem corruption resulting from the power outage can lead to unreadable or missing critical files.
Checking Disk Space
We will use the df -h command to display disk space usage in a human-readable format. Pay close attention to the mounted partitions, especially /, /home, and any temporary directories that might be mounted on separate partitions.
df -h
Ensure that partitions are not 100% full. If a critical partition is full, you will need to free up space. Common culprits for filling up / or /var include log files or package cache.
Checking Filesystem Integrity
To check and repair filesystem errors, we will use fsck. It’s important to run fsck on unmounted partitions. If your root partition is LUKS-encrypted, you will first need to decrypt it. Assuming you have already decrypted the LUKS volume and mounted your root partition (e.g., as /mnt/root), you can check its filesystem.
Important: Running fsck on mounted filesystems can lead to further corruption. Always ensure the partition is unmounted or, if