GRUB recovery in Kali needs a known boot mode and disk layout before a write operation. Record existing-entry behavior, missing prerequisites and accessible recovery material.
Sources, review date and section shortcuts
Key claims reviewed: October 19, 2026. A changed boot order, a missing firmware entry and damaged bootloader files need different evidence.
Primary documentation · Related practical guide
Go straight to: Decision check · Main workflow · Further detail
Open the GRUB: Boot-recovery decision gate for this guide’s task-specific fields and next action.
Keep disk identity ahead of a repair command
Record boot mode, disk and partition identifiers, mount layout and the exact error before choosing a write operation. An existing entry that boots successfully can change the diagnosis without reinstalling a loader. Keep recovery material accessible through the approved channel. This is a conditional x86-64 UEFI guide, not a universal repair for every architecture, layout or encrypted installation. Source and scope.
If a Windows/Kali dual-boot computer starts directly in Windows, first check whether its existing Kali boot entry still works from the firmware’s one-time boot menu. A changed default entry is one possible cause; the timing after an update does not prove that Windows deleted GRUB or that your data is intact.
This guide separates boot-entry checks from a conditional x86-64 UEFI GRUB repair. It cannot guarantee recovery without data loss. Back up important data and arrange access to recovery material before making changes. Technical references were checked on October 16, 2026; no disk or firmware repair was performed for this article.
Record the symptom before selecting a repair
Distinguish direct Windows startup, a GRUB menu followed by a Kali error, a grub rescue prompt, a firmware “no bootable device” message and a blank screen. They do not have one universal cause. Photograph the exact message without exposing recovery keys.
If the disk is missing, produces I/O errors or contains irreplaceable unbacked-up data, stop before bootloader writes. A boot repair is not a disk-health test or a data-recovery procedure. Seek appropriate recovery help when preserving the data is the first priority.
Inspect the disk layout and boot mode
From a trusted compatible Live environment, the commands below list filesystem information, report whether an EFI interface is present and display boot entries. They do not install GRUB or change boot order. An unavailable EFI interface can indicate the Live environment was booted in Legacy mode; do not force a UEFI repair from that assumption.
Identify the installed root filesystem, any separate /boot and the intended EFI System Partition (ESP) using the actual layout and installed /etc/fstab. Encryption, LVM, RAID and Btrfs subvolumes require additional handling. A partition’s size, FAT filesystem or visibility alone does not prove it is the correct ESP or that its contents are healthy.
lsblk -f
if [ -d /sys/firmware/efi ]; then
printf "EFI interface present\n"
else
printf "EFI interface unavailable\n"
fi
sudo efibootmgr -vSeparate firmware entries from bootloader files
UEFI firmware entries identify loaders, while the ESP contains the corresponding files. A missing entry does not necessarily mean the loader files were erased. An existing label also does not prove its device and path are correct. Compare both before choosing a write operation.
The efibootmgr manual distinguishes BootCurrent, BootOrder and BootNext. BootNext overrides the normal order for one boot; it is not a persistent reorder. Use the manual for your installed version and preserve the original entries before changing them.
Try the existing entry before reinstalling
Use the firmware’s one-time menu to select the known existing Kali entry when available. If Kali starts, back up files and record its mounted filesystems and boot configuration. A persistent order adjustment may be sufficient; it does not require reinstalling Kali.
If the loader is rejected, check the actual policy and error. Kali’s installation baseline says its kernel is unsigned and calls for Secure Boot to be disabled. A signed loader alone is not a universal workaround. Do not erase keys or weaken an organizational boot policy as a troubleshooting shortcut.
Conditional GRUB repair: verify mounts before writes
This outline applies only to an identified x86-64 UEFI Kali installation with an understood filesystem layout and compatible recovery environment. It preserves the useful mount/chroot approach from the original guide. It is not a script to paste into an unidentified disk. Stop at any error.
First mount the installed root at a deliberate recovery location such as /mnt. Mount a separate /boot in its correct place before mounting the intended ESP at /mnt/boot/efi. Follow the installed fstab; use the correct unlocked/activated volumes or root subvolume where required. Verify the mount tree and installed files. Do not create or format partitions to make the example fit.
Before entering the installed system, provide its required runtime interfaces. The mount manual explains recursive bind mounts and propagation. The original approach recursively binds /dev, /proc, /sys and /run under the recovery root and makes those bind trees recursively slave. Review each destination and success before chrooting; confirm EFI variables are available if an NVRAM update is intended.
Inside the correctly prepared installed system, the following original repair commands are relevant only when the matching GRUB EFI tools are installed and /boot/efi is the verified ESP. The grub-install manual documents the target, ESP directory and bootloader ID options. These commands write boot files/configuration and may update NVRAM; they are not inspection commands.
# Inside the verified installed-system chroot only
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Kali
# Continue only after successful installation and reviewed output
update-grubThe update-grub manual describes generating /boot/grub/grub.cfg; it is separate from installing the EFI loader. Review the generated entries. Exit the chroot, unmount the recovery tree in an orderly way and resolve busy mounts before rebooting. Do not use force flags or overwrite another loader merely to bypass an unexplained failure.
Change boot order only with verified identifiers
Record efibootmgr -v output first. If you choose an order change, use the actual entry identifiers from that machine and retain the required Windows and recovery entries. Numbers from an example are not portable between computers.
A missing entry with healthy loader files may need entry restoration rather than loader reinstallation. Creating one requires the actual disk, ESP partition and loader path. Inspect those values and preserve the previous state; do not guess a disk default or copy a universal creation command.
Treat the rescue prompt as evidence, not a recipe
A grub rescue prompt indicates a GRUB loading problem; a blank display by itself does not. The GNU GRUB rescue-shell guidance describes failures loading normal mode. Recovery paths depend on the real partition and module locations.
Do not assume a copied (hd0,gptN) path maps to your Linux device naming. A successful one-time boot is an opportunity to back up and inspect the installed configuration, not proof that the underlying problem is permanently fixed.
Prepare BitLocker recovery before platform changes
Use Microsoft’s BitLocker recovery guidance to prepare for relevant platform and boot changes. Store recovery information through an approved secure method and verify you can retrieve it. Do not disable encryption as a routine GRUB repair step.
Avoid writing Windows volumes from Linux when Windows was hibernated or left in an unsafe shutdown state. Recovering the Linux boot path does not require casually modifying Windows user data. Keep any Windows repair procedure separate and specific to its documented failure.
Stop at uncertainty rather than making destructive guesses
Do not format the ESP, delete partitions, reinstall the whole operating system or overwrite Windows loader files simply because a menu entry is missing. Preserve a backup and the existing partition map. The Kali dual-boot guide emphasizes external backups before disk changes.
Also stop when the installed system cannot be identified, encryption credentials are unavailable, a filesystem reports damage or the expected mounts do not match fstab. A general article cannot resolve those conditions by assuming a standard layout.
Verify both systems and keep a recovery record
After an appropriate repair, test Kali and Windows through their intended boot paths. Check that required data and the expected root filesystem are present, then repeat a normal reboot. Record the specific configuration tested and any remaining recovery prompts or errors.
Keep the partition identifiers, boot-entry output, a verified recovery medium and separate file backups. A copy of ESP files can help with boot recovery but is not a backup of operating systems or user data. Retest the recovery plan after material configuration changes.
Common questions
Does booting Windows prove Kali was erased? No. It establishes which path booted. Inspect entries and files before drawing a conclusion.
Does update-grub reinstall the EFI loader? No. It generates the configuration. Installing the loader, restoring an entry and changing its order are distinct operations.
Next step: identify before writing
Start with the exact symptom, a one-time boot-entry check and an inventory of the actual layout. Choose the smallest repair supported by that evidence. No repair time or loss-free result can be promised for an unexamined computer.
GRUB: Boot-recovery decision gate
Use these fields for your own task. Keep the actual conditions, evidence and unresolved questions beside the next decision.
Use the editable record below to retain the task context and unresolved questions.
Edit here, then select and copy the text to your own notes before leaving. This field has no submission or storage function; reloading resets it. Do not enter passwords, tokens or private client information. The 12,000-character limit applies to this working note.
Next action: Resolve disk and boot-mode identity before choosing a repair command.
Related task: Use Kali Encrypted USB Persistence: Secure Boot Limits for that separate part of the workflow.
Worksheet change record — October 20, 2026
Added four task-specific fields, a next action and a related guide. This is a blank editorial working aid, not a completed test or validated assessment. Existing source-review dates retain their own scope; this addition is not a new verification of every statement.
GRUB recovery: visible partition does not establish mount identity
Illustrative example — not a performed lab test.
- Observation
- Recovery media can see several partitions, but the intended root and EFI mounts have not been identified.
- Supported interpretation
- Disk visibility passed; repair prerequisites remain incomplete.
- Still unresolved
- Which installation and boot mode a write operation would affect.
- Next authorized check
- Stop before reinstalling a bootloader. Record device identifiers, filesystem roles, encryption and current mounts against the intended installation. Keep independent backups and recovery material available; a copied device name from another machine is not a verified repair target.
Practice-aid update: October 20, 2026. Added the illustrative decision case and editable note. No new VM execution or full-article revalidation is claimed.