Recover from a GRUB shell prompt by booting an Arch Linux live USB, mounting your root partition to /mnt, and entering the chroot environment. Reinstall GRUB with grub-install and generate a new configuration using grub-mkconfig -o /boot/grub/grub.cfg to restore normal boot functionality.
Accessing the Recovery Environment
When your laptop drops into thegrub> shell after a reboot, it means the bootloader cannot find its configuration files or the necessary modules to load the kernel. This is a common issue during or immediately after an Arch Linux installation, often caused by incorrect partition mounting paths or missing EFI variables. The most reliable way to fix this is not to try typing commands in the limited GRUB shell, but to use a live environment to repair the system from the outside.
Start by creating a bootable Arch Linux USB drive if you do not already have one. Insert the USB into your laptop and power on the machine. You will need to access the BIOS or UEFI settings, usually by pressing F2, F12, Del, or Esc during the POST screen. Change the boot order to prioritize the USB drive. Once the system boots from the USB, you will be presented with the Arch Linux live environment menu. Select the option to boot into the live system. If you encounter issues where the keyboard does not work in the live environment but works in GRUB, check for legacy vs. UEFI mode mismatches, as discussed in related troubleshooting guides for input devices.
Mounting the Filesystem Correctly
Before you can repair GRUB, you must mount your installed Arch Linux partitions so that the live system can see them. This step is critical because GRUB needs to write to the correct EFI System Partition (ESP) and update the config file in the boot directory of your root partition. First, identify your partitions using thelsblk command. Look for your main disk, typically named sda, nvme0n1, or similar, and note the identifiers for your root partition (often labeled as arch or ext4) and your EFI partition (usually FAT32, around 512MB).
Assuming your root partition is /dev/sda2 and your EFI partition is /dev/sda1, mount the root partition first:
mount /dev/sda2 /mnt
Next, create the necessary mount points for the virtual filesystems. These are required for the chroot environment to function correctly, providing access to processes, devices, and network resources.
mkdir /mnt/boot/efi
mount /dev/sda1 /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
If you have a separate swap partition, activate it now using swapon /dev/sdaX. It is also advisable to ensure your DNS resolution works inside the chroot later, so copy the resolv.conf file:
cp /etc/resolv.conf /mnt/etc/resolv.conf
This setup ensures that when you enter the chroot, the system behaves exactly as if you had booted into your installed Arch Linux directly. For more details on handling disk images and mounting structures, refer to resources on mounting Arch disk images.
Entering Chroot and Reinstalling GRUB
Now that the filesystems are mounted, change your root directory to the mounted partition using thearch-chroot tool. This command sets up the environment variables and mounts the bind points automatically, allowing you to run commands as if you were logged into your broken system.
arch-chroot /mnt
Once inside the chroot, verify that you can see your partitions by running lsblk again. You should see the same layout as before. Now, reinstall GRUB. The exact command depends on whether you are using BIOS or UEFI. Most modern laptops use UEFI. To install GRUB for UEFI, specify the target platform as x86_64-efi and the directory where the EFI partition is mounted (/boot/efi).
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
If you are using legacy BIOS, the command would be grub-install /dev/sda. After the installation completes without errors, you must generate a new GRUB configuration file. The previous installation likely failed to create grub.cfg or created it with incorrect paths. Use grub-mkconfig to scan your system for kernels and initramfs images and write a fresh configuration.
grub-mkconfig -o /boot/grub/grub.cfg
This process scans the /etc/default/grub settings and the contents of /usr/lib/grub to build a valid boot menu. If you are unsure about how the boot menu presents itself with GPT and EFI partitions, understanding the interaction between the ESP and GRUB is helpful.
Exiting and Verifying the Fix
After generating the config file, exit the chroot environment by typingexit or pressing Ctrl+D. Then, unmount all the partitions in reverse order to ensure no data is lost or corrupted.
umount -R /mnt
Remove the USB drive and reboot the computer. Your laptop should now display the GRUB menu instead of dropping into the shell. If the system still fails to boot, check the BIOS settings to ensure Secure Boot is disabled, as some custom GRUB installations may not be signed keys compatible with strict Secure Boot policies. Also, verify that the EFI entry for GRUB exists in the NVRAM by checking efibootmgr output if you have access to another live environment.
For users installing newer drivers on Manjaro or Arch variants, ensuring that the kernel modules match the installed kernel version is also crucial for successful booting after such repairs.
Frequently Asked Questions
Why did my GRUB shell appear instead of the boot menu?
This happens when GRUB cannot locate its grub.cfg file or the necessary modules in the expected path. It is often caused by incorrect EFI partition mounting during installation or a failed update that overwrote the bootloader configuration incorrectly.
Can I fix this without a live USB?
While possible, it is highly risky and difficult. You would need to manually type complex GRUB commands like set root, linux, and initrd to load the kernel, which requires precise knowledge of your partition UUIDs. Using a live USB is the standard and safer recovery method.
What if grub-install says "device not found"?
This usually means the EFI partition is not mounted at /boot/efi inside the chroot. Verify that you have mounted your ESP to that specific directory before running the installation command. Ensure the partition is formatted as FAT32.
Does Secure Boot affect GRUB installation?
Yes, Secure Boot can prevent unsigned bootloaders from loading. If you enabled Secure Boot in BIOS, you may need to disable it or sign the GRUB binary with a key enrolled in your motherboard's MOK list. Standard Arch installations often require Secure Boot to be off unless specifically configured otherwise.
How do I know if I used UEFI or BIOS?
If your motherboard has a "UEFI" option in the boot menu and your EFI partition is formatted as FAT32, you are using UEFI. Legacy BIOS systems do not have an EFI partition and use the Master Boot Record (MBR) instead. Most laptops manufactured after 2012 use UEFI.