GRUB_GFXMODE, ensuring proper nomodeset usage if hardware is incompatible, and rebuilding the initramfs to include necessary modules.
Understanding the Blinking Text Symptom
The blinking cursor or text during the initramfs phase occurs when the Linux kernel attempts to switch the display from the BIOS/UEFI provided graphics mode to a higher-resolution framebuffer provided by the DRM (Direct Rendering Manager) subsystem. If the kernel cannot establish a stable connection with the GPU via the specified video mode, it falls back to a basic text mode that may flicker or blink as it retries initialization. This is distinct from a black screen, which usually implies a complete failure to output any signal, whereas blinking text suggests the system is alive but struggling with the display handshake.
This issue is particularly common on systems using hybrid graphics (such as NVIDIA Optimus) or newer AMD Ryzen processors where the integrated graphics controller interacts complexly with discrete GPUs. It can also happen if the initramfs image lacks the specific firmware or kernel modules required for your display adapter. Unlike issues seen later in the boot process, such as the blank screen problems detailed in our guide on Resolving X/Plasma Blank Screen Issue on Kubuntu with Ryzen 2600x and Gtx 1070ti, this problem happens before the desktop environment loads, making standard GUI-based fixes impossible.
Adjusting GRUB Video Settings
The most effective fix involves configuring GRUB to use a compatible graphics mode that does not rely on aggressive kernel mode setting (KMS) during the early boot stages. You need to edit the GRUB configuration file, typically located at /etc/default/grub. Look for the line defining GRUB_GFXMODE. If this value is set to a high resolution like auto or a specific non-standard resolution, change it to a safe, low-resolution VESA mode such as 640x480 or 1024x768.
# Example modification in /etc/default/grub
GRUB_GFXMODE=640x480
GRUB_GFXPAYLOAD_LINUX=keepAdding GRUB_GFXPAYLOAD_LINUX=keep instructs the kernel to retain the graphics mode set by GRUB rather than attempting to reconfigure it immediately upon booting. This bypasses the problematic transition that causes the blinking. After saving the file, you must apply these changes by running sudo update-grub on Debian-based systems or sudo grub-mkconfig -o /boot/grub/grub.cfg on Arch-based distributions. If the issue persists, you may also need to explicitly disable kernel mode setting by adding nomodeset to the GRUB_CMDLINE_LINUX_DEFAULT variable.
Verifying Initramfs Module Inclusion
If GRUB settings are correct, the blinking may stem from missing drivers within the initial ramdisk. The initramfs must contain the appropriate kmod packages for your storage controllers and GPU. For example, if you are using an NVMe drive, ensure nvme is included; for SATA, check for ahci. On systems with proprietary NVIDIA drivers, the open-source nouveau driver might conflict with the expected behavior during early boot.
You can inspect the contents of your current initramfs image to verify module inclusion. Use the command lsinitramfs /boot/initrd.img-$(uname -r) to list all files and directories. Search for the relevant driver names. If critical modules are missing, you may need to reinstall the associated kernel headers or update the mkinitcpio.conf (on Arch) or MODULES array in /etc/mkinitcpio.conf (on other distros) to force their inclusion. Once modified, regenerate the image using sudo mkinitcpio -P or sudo update-initramfs -u.
Handling EFI and Partition Issues
In some cases, the blinking text is a symptom of GRUB failing to read the bootloader configuration due to partition layout issues, especially when using GPT partitions. If your system uses an EFI System Partition (ESP), ensure it is correctly mounted and formatted as FAT32. Misconfigurations here can cause GRUB to hang or behave erratically during the handoff to the kernel. For deeper insights into how GRUB presents the menu based on partition structures, refer to our analysis on How is the grub boot menu presented if the gpt looks for efi system partition.
Additionally, verify that the fstab entries are accurate. An incorrect UUID for the root partition can cause the initramfs to drop into an emergency shell, sometimes displaying erratic text output while waiting for user input. Check your /etc/fstab against blkid output to ensure consistency.
Frequently Asked Questions
Why does my screen blink only during boot and not after?
This happens because the blinking occurs in the early userspace (initramfs) before the full graphical interface or even the standard TTY console is established. Once the kernel successfully initializes the DRM drivers and switches to the final display mode, the flickering stops. It is strictly a pre-desktop initialization artifact.
Can I use nomodeset permanently to fix this?
While nomodeset often resolves the blinking, it disables hardware acceleration for graphics. This results in poor performance for desktop environments and gaming. It is recommended to use it only as a diagnostic step or temporary workaround until you can configure proper GRUB_GFXMODE values.
What if updating GRUB doesn't solve the blinking?
If GRUB updates fail to resolve the issue, the problem likely lies within the initramfs content itself. You should rebuild the initramfs image to ensure all necessary kernel modules, especially those for your GPU and storage controller, are properly bundled. Check dmesg logs for driver loading errors.
Does this issue affect Windows dual-boot systems?
No, this is specific to the Linux kernel's boot process. However, if you are experiencing keyboard issues in Linux that work in Windows, it might indicate a broader hardware compatibility layer problem. See our guide on Keyboard not working in Windows or Fedora 37 but works in Grub for related troubleshooting.
Is it safe to ignore the blinking text?
Ignoring it is generally safe if the system boots normally afterward and you can access your desktop. However, persistent blinking can sometimes hide error messages about disk failures or filesystem corruption. It is best practice to address it to ensure you don't miss critical boot warnings.