Ubuntu 24.04 LTS Install Guide: Dual-Boot, Secure Boot, and Zero Data Loss

Ground rules for zero data loss

“Zero data loss” is not a feeling. It’s a sequence of verifiable states:

• You know which disk you’re touching, by stable identifiers, not vibes.
• You have at least one offline copy of the data you care about.
• You have a boot-recovery path for both operating systems.
• You change one thing at a time, then validate.

Here’s the posture I want you in: cautious, methodical, slightly annoyed. That’s the correct energy for anything that edits partitions.

Decide your target architecture before you begin

Most modern machines should be: UEFI firmware + GPT partition table + Secure Boot enabled. If your system is legacy BIOS/MBR, you can still dual-boot, but the failure modes multiply. The guide assumes UEFI/GPT because that’s what you should be running in 2026 unless you’re resurrecting a museum exhibit.

Two things you should not do

• Do not “wipe and reinstall” when the installer offers it “helpfully.” It’s doing its job. Your job is to refuse.
• Do not shrink partitions from Linux first if Windows is involved. Shrink Windows from inside Windows. Let each OS manage its own filesystem metadata.

One short joke #1: Partitioning a disk without a verified backup is like doing surgery because you once watched a medical drama—bold, brief, and surprisingly expensive.

Interesting facts and historical context (because this mess has a history)

1. UEFI replaced BIOS as the mainstream firmware model in the 2010s, bringing standardized boot entries and a real filesystem (FAT) for bootloaders in the EFI System Partition (ESP).
2. GPT became the default because MBR caps usable space and has fragile partition table limits; GPT stores redundant headers and supports many partitions cleanly.
3. Secure Boot arrived to reduce bootkit malware. It verifies signatures in the boot chain, which is great until you need third-party drivers and forget what “signing” means.
4. Ubuntu adopted shim as a practical bridge: Microsoft-signed shim can boot on Secure Boot systems and then validate GRUB and kernels with Ubuntu’s keys.
5. GRUB2 replaced legacy GRUB with more features and more ways to confuse yourself. It’s flexible, not psychic.
6. Windows Fast Startup (a hybrid hibernation feature) has been a recurring dual-boot hazard because it leaves filesystems “not quite closed,” which Linux correctly treats as unsafe.
7. BitLocker became mainstream on consumer devices, especially on “Modern Standby” laptops, and it changes how you should approach resizing and boot changes.
8. NVMe changed the naming game: disks show up as /dev/nvme0n1 with partitions like /dev/nvme0n1p3, which is easy to misread during a tense install.
9. Ubuntu LTS releases are designed for long operational lifetimes; 24.04 LTS is a “sit on it for years” release, which is why installation correctness matters more than novelty.

Operationally, the theme is simple: the boot chain and the disk layout are shared infrastructure. Treat them like production, not like a weekend craft project.

Pre-flight checks: hardware, firmware, and disk truth

Before you boot any installer, you inventory. Not because it’s fun, but because it prevents the two classic disasters: (1) writing to the wrong disk and (2) installing in the wrong boot mode.

Task 1: Confirm you booted the installer in UEFI mode

Boot the Ubuntu live USB (“Try Ubuntu”). Then:

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"
UEFI mode

What it means: “UEFI mode” is what you want for modern dual-boot. If you see “Legacy BIOS mode,” stop and reboot the USB selecting the UEFI entry in your firmware boot menu.

Decision: Proceed only in UEFI mode unless you are intentionally supporting legacy BIOS.

Task 2: Identify all disks and their sizes (so you don’t nuke the wrong one)

cr0x@server:~$ lsblk -e7 -o NAME,PATH,SIZE,TYPE,MODEL,SERIAL
NAME        PATH             SIZE TYPE MODEL                 SERIAL
nvme0n1     /dev/nvme0n1   953.9G disk Samsung SSD 990 PRO   S6Z2...
nvme0n1p1   /dev/nvme0n1p1   100M part
nvme0n1p2   /dev/nvme0n1p2    16M part
nvme0n1p3   /dev/nvme0n1p3   450G part
nvme0n1p4   /dev/nvme0n1p4   900M part
nvme0n1p5   /dev/nvme0n1p5   503G part

What it means: You’re looking for the internal disk (often NVMe) and existing partitions. On many Windows installs, you’ll see an ESP (~100–300MB), an MSR (16MB), the Windows partition (large), and a recovery partition.

Decision: Write down the disk path (example: /dev/nvme0n1). If there’s more than one internal disk, decide which one will host Ubuntu.

Task 3: Confirm the partition table type (GPT vs MBR)

cr0x@server:~$ sudo parted -l
Model: Samsung SSD 990 PRO (nvme)
Disk /dev/nvme0n1: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  106MB   105MB   fat32        EFI system partition          boot, esp
 2      106MB   123MB   16.8MB               Microsoft reserved partition  msftres
 3      123MB   483GB   483GB   ntfs         Basic data partition          msftdata
 4      483GB   484GB   944MB   ntfs         Basic data partition          hidden, diag
 5      484GB   1024GB  540GB

What it means: “Partition Table: gpt” confirms you’re in the right era. If you see “msdos,” you’re on MBR/legacy, and the plan changes.

Decision: For dual-boot with Secure Boot, GPT is the smoothest path. If MBR appears, consider converting (advanced) or accept legacy complexity.

Task 4: Confirm the EFI System Partition (ESP) exists and is FAT32

cr0x@server:~$ sudo blkid /dev/nvme0n1p1
/dev/nvme0n1p1: UUID="3A1B-2C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="..."

What it means: TYPE=vfat and “EFI system partition” is your ESP. Ubuntu will reuse it; you should not format it during installation.

Decision: Keep the ESP. Don’t create a second ESP unless you have a specific reason (multi-disk segregation or a very weird vendor firmware).

Task 5: Check if Windows is hibernated / Fast Startup risk (from Linux)

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
Mounting volume... FAILED
Attempting to correct errors... FAILED
FAILED
NTFS volume is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting).

What it means: The -n flag is a dry-run. If it says unsafe/hibernated, do not mount the Windows partition read-write from Linux, and do not resize it from Linux tools.

Decision: Boot Windows, disable Fast Startup, and do a full shutdown.

Task 6: Check Secure Boot state from the live environment

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

What it means: Secure Boot is on. Good. We’ll keep it on and work with it.

Decision: Proceed with Secure Boot enabled unless you have a specific driver situation that forces it off (rare, but it happens).

Backups that actually count (and how to prove them)

Backups are not “I copied some folders once.” Backups are “I can restore under pressure.” You’re about to edit the most critical metadata on the machine. So you need:

• File backup of your personal data (Documents, projects, keys, photos, etc.).
• Recovery keys for Windows BitLocker if enabled.
• Boot recovery media (Windows recovery USB, and your Ubuntu installer USB).

Windows-side backup checklist (do this in Windows)

From an operational perspective: the best Windows backup is the one you already tested. If you didn’t, do a quick restore test of at least one file. Also, save your BitLocker recovery key somewhere not on the same device.

Task 7: Verify you can see the external backup disk and its filesystem (from Ubuntu live)

cr0x@server:~$ lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME      SIZE TYPE FSTYPE MOUNTPOINT
nvme0n1 953.9G disk
nvme0n1p1 100M part vfat
nvme0n1p3 450G part ntfs
sda     931.5G disk exfat
sda1    931.5G part exfat  /media/ubuntu/BackupDrive

What it means: Your external disk is present (sda1) and mounted. Great. If it isn’t mounted, mount it via the file manager or udisksctl mount.

Decision: Do not proceed until the backup destination is accessible.

Task 8: Create a quick integrity check of your most important files

cr0x@server:~$ cd /media/ubuntu/BackupDrive
cr0x@server:~$ sha256sum my-keys.tar my-photos.zip > SHA256SUMS.txt
cr0x@server:~$ cat SHA256SUMS.txt
b1f2...  my-keys.tar
9a8c...  my-photos.zip

What it means: You’ve created hashes that you can later verify after copying or restoring. This is how you catch “copy succeeded” but “file corrupted” scenarios.

Decision: Keep the checksum file with the backup.

Task 9: Snapshot the current partition table (cheap, useful evidence)

cr0x@server:~$ sudo sgdisk --backup=/media/ubuntu/BackupDrive/nvme0n1-gpt.bin /dev/nvme0n1
cr0x@server:~$ ls -lh /media/ubuntu/BackupDrive/nvme0n1-gpt.bin
-rw-r--r-- 1 root root 17K Feb  5 12:18 /media/ubuntu/BackupDrive/nvme0n1-gpt.bin

What it means: You now have a binary backup of the GPT partition table. If someone (including you) makes a mess, you have a fighting chance to restore structure.

Decision: Store this off-machine. It’s small and invaluable.

Partitioning strategy for UEFI/GPT dual-boot

Here’s the core rule: Windows owns its partitions; Ubuntu gets new ones carved from free space. Your job is to create that free space safely, then assign it cleanly.

Recommended layout (practical, not theoretical)

• ESP (existing): 100–512MB FAT32, mounted at /boot/efi. Do not format.
• Ubuntu root: 40–100GB ext4 mounted at /. Bigger if you install games or huge toolchains.
• Swap: optional as a partition; Ubuntu can use a swapfile. If you hibernate Linux, plan swap appropriately (usually ≥ RAM).
• Home: optional separate partition. Good for clean reinstalls, but not magic.

For most laptops: one root partition + swapfile is fine. For workstations where you reinstall often: separate /home is sane.

About encryption: choose your blast radius

Ubuntu offers full-disk encryption (LUKS). It’s a good default if your threat model includes “lost laptop” or “curious person with a screwdriver.” It also changes your recovery procedures and can complicate some dual-boot repair flows if you don’t understand what’s inside the encrypted container.

If you want “zero surprises,” choose:

• Keep Windows as-is (BitLocker stays on if it already is).
• Encrypt Ubuntu if you can tolerate typing a passphrase at boot and you’re comfortable with recovery steps.

Task 10: Measure real free space and current usage

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
tmpfs          tmpfs  3.1G  2.1M  3.1G   1% /run
/dev/sr0       iso9660 3.7G 3.7G     0 100% /cdrom
/dev/loop0     squashfs 2.4G 2.4G     0 100% /rofs

What it means: In the live environment, df doesn’t show your internal disk usage unless you mount it. This is a reminder: do not guess. If you need Windows usage, check in Windows Disk Management.

Decision: Shrink Windows from Windows. Use Linux tools mainly for identification and validation.

How much space should you allocate?

My opinionated baseline: 60GB for Ubuntu root if you do development, containers, or keep a few kernels around. If you’re a light user, 40GB works. If you do serious container work, 100–200GB is not excessive; container images multiply like rabbits in spring.

One short joke #2: Disk space is the only resource that gets smaller the moment you stop watching it.

Secure Boot: keep it on, understand what changes

Secure Boot is not your enemy. It’s just strict. Ubuntu’s default boot chain on Secure Boot typically looks like:

• Firmware verifies shim (signed).
• shim verifies GRUB (signed).
• GRUB loads the kernel (signed).
• Kernel enforces module signature rules depending on policy and configuration.

When you’ll get prompted for MOK (Machine Owner Key)

If you install third-party drivers (common with NVIDIA), Ubuntu may ask to enroll a key via MOK. This is normal. You’ll set a one-time password during installation, then on the next reboot you’ll get a blue-ish MOK manager screen to enroll the key.

Task 11: Check Secure Boot verification tools availability and state

cr0x@server:~$ sbverify --version
sbverify version 0.9.4
cr0x@server:~$ mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: ...

What it means: You can inspect enrolled keys and verify EFI binaries if needed. You usually won’t need to, but when something fails at 2 a.m., you’ll be glad the tools exist.

Decision: If Secure Boot is enabled and Ubuntu boots, don’t “fix” anything. Stability beats curiosity.

A reliability paraphrased idea worth keeping

Paraphrased idea (attributed to Gene Kranz): “Be tough and competent.” In ops terms: stay calm, verify, and don’t improvise on critical paths.

Installation: the safe path through the Ubuntu installer

The Ubuntu 24.04 installer is generally friendly, which is exactly why it’s dangerous: it will happily do big irreversible things quickly. Your job is to choose the options that keep control in your hands.

Step 1: Shrink Windows (do this before you install Ubuntu)

In Windows:

• Disable Fast Startup.
• If BitLocker is enabled, ensure you have the recovery key saved off the machine. Consider suspending BitLocker before resizing, depending on your environment policy.
• Use Disk Management to shrink the Windows partition and leave unallocated space.
• Reboot Windows once, then do a full shutdown (not “restart”).

Yes, this is annoying. It’s still the correct way.

Step 2: Boot Ubuntu live USB in UEFI mode

You already validated UEFI mode earlier. Do it again if you’re unsure. Humans are fallible; firmware menus are worse.

Task 12: Confirm unallocated space exists (from Ubuntu live)

cr0x@server:~$ sudo parted /dev/nvme0n1 unit GiB print free
Model: Samsung SSD 990 PRO (nvme)
Disk /dev/nvme0n1: 953GiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number  Start  End    Size   File system  Name  Flags
        0.00GiB 0.00GiB 0.00GiB Free Space
 1      0.00GiB 0.10GiB 0.10GiB fat32            boot, esp
 2      0.10GiB 0.12GiB 0.02GiB                  msftres
 3      0.12GiB 450.00GiB 449.88GiB ntfs
 4      450.00GiB 451.00GiB 1.00GiB  ntfs        hidden, diag
        451.00GiB 953.00GiB 502.00GiB Free Space

What it means: The “Free Space” block at the end is where Ubuntu will go. If you don’t see free space, you didn’t shrink Windows or you’re looking at the wrong disk.

Decision: If free space is missing, stop. Don’t try to “make it work” with random resizing from Linux.

Step 3: Choose “Manual partitioning” (or equivalent) in the installer

If the installer offers “Install alongside Windows,” it can work. It can also guess wrong, especially on systems with multiple disks, vendor recovery partitions, RAID modes, or BitLocker. If you want “zero data loss,” take manual control.

Manual partitioning: what to create

• Do not format the ESP. Set it to mount at /boot/efi.
• Create an ext4 partition in the free space for /.
• Optional: create an ext4 partition for /home.
• Swap: use swapfile (default) unless you hibernate.

Task 13: Double-check you’re not formatting the wrong partition (sanity check)

cr0x@server:~$ sudo lsblk -f /dev/nvme0n1
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32       3A1B-2C4D
├─nvme0n1p2
├─nvme0n1p3 ntfs               1C2D3E4F5A6B7C8D
├─nvme0n1p4 ntfs               9E8D7C6B5A4F3E2D
└─nvme0n1p5

What it means: You can see which partitions already have filesystems. The free space won’t show as a partition yet. If you see an ext4 partition you didn’t expect, stop and investigate.

Decision: Only format the new partitions you create for Ubuntu. Never format an NTFS partition you care about. Never format the ESP.

Bootloader installation target

On UEFI systems, the “bootloader target disk” should be the disk that contains the ESP (usually the same disk as Windows). If you put Ubuntu on a second disk, be deliberate: some firmware only boots from the first disk reliably.

Install updates and third-party drivers (carefully)

If you have NVIDIA graphics, the installer may offer third-party drivers. Taking them is fine, but expect MOK enrollment if Secure Boot is enabled.

Post-install verification: boot paths, drivers, updates

You’re not “done” when the desktop appears. You’re done when:

• Ubuntu boots reliably with Secure Boot on.
• Windows still boots.
• You can explain (briefly) how the system is booting.

Task 14: Confirm Secure Boot status in installed Ubuntu

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

What it means: You stayed in Secure Boot mode end-to-end.

Decision: If Secure Boot is unexpectedly disabled, check firmware settings. Don’t assume Ubuntu “turned it off.” Firmware toggles can reset after updates or CMOS events.

Task 15: Confirm EFI boot entries (Ubuntu and Windows)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0000* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0003* ubuntu                HD(1,GPT,...)File(\EFI\ubuntu\shimx64.efi)

What it means: Firmware knows about both bootloaders. Ubuntu is using shim (shimx64.efi) which is expected under Secure Boot.

Decision: If “Windows Boot Manager” is missing, don’t panic. It can be recreated, but first check the ESP content.

Task 16: Inspect ESP contents (confirm nothing got overwritten)

cr0x@server:~$ sudo mkdir -p /mnt/esp
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/esp
cr0x@server:~$ sudo ls -R /mnt/esp/EFI | head -n 50
/mnt/esp/EFI:
Boot
Microsoft
ubuntu

/mnt/esp/EFI/Microsoft:
Boot

/mnt/esp/EFI/ubuntu:
grubx64.efi
mmx64.efi
shimx64.efi

What it means: The ESP contains both vendors’ directories. This is what “alongside Windows” should look like.

Decision: If the Microsoft directory is missing, you likely formatted the ESP or wrote to the wrong disk. Recovery is possible but now you’re doing incident response.

Task 17: Confirm GRUB sees Windows (and fix it if needed)

cr0x@server:~$ sudo grep -R "menuentry 'Windows" -n /boot/grub/grub.cfg | head
1234:menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-1C2D3E4F5A6B7C8D' {

What it means: Windows is present in GRUB’s config. If it’s not there, os-prober might be disabled or Windows might be hidden due to hibernation state.

Decision: If Windows isn’t detected, first ensure Windows is fully shut down and not hibernated; then run update-grub.

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

What it means: GRUB can chainload Windows. That’s the simplest dual-boot arrangement.

Decision: If Windows still doesn’t appear, use firmware boot menu to boot Windows directly and fix hibernation/Fast Startup.

Task 18: Check kernel and driver state (especially on laptops)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ ubuntu-drivers devices | sed -n '1,120p'
== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
modalias : pci:v000010DEd000025A2sv00001028sd00000B42bc03sc00i00
vendor   : NVIDIA Corporation
model    : AD104M [GeForce RTX ...]
driver   : nvidia-driver-550 - distro non-free recommended
driver   : xserver-xorg-video-nouveau - distro free builtin

What it means: You can see recommended drivers. On Secure Boot systems, proprietary driver installation may trigger MOK enrollment.

Decision: If you need NVIDIA for your workload, install the recommended driver, and be ready to enroll MOK on reboot. If you just need a working desktop and stability, you can defer.

Task 19: Check for RAID/RST mode that can break Linux disk visibility

cr0x@server:~$ sudo lspci -nn | grep -i -E "sata|raid|nvme"
00:17.0 SATA controller [0106]: Intel Corporation Device [8086:7ae2]
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]

What it means: This doesn’t definitively tell you firmware mode, but it helps you spot systems where Intel RST/RAID mode might be involved. If Linux can’t see your Windows disk, firmware storage mode is a prime suspect.

Decision: If the internal disk disappears under Linux, check firmware for RST/RAID vs AHCI settings and handle with care (especially with Windows installed).

Task 20: Validate filesystem mounts and fstab (avoid future boot surprises)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS / /boot/efi
/dev/nvme0n1p6 / ext4 rw,relatime,errors=remount-ro
/dev/nvme0n1p1 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
cr0x@server:~$ sudo cat /etc/fstab
UUID=... / ext4 errors=remount-ro 0 1
UUID=3A1B-2C4D /boot/efi vfat umask=0077 0 1

What it means: Ubuntu mounts the ESP by UUID. That’s good. Device names can change; UUIDs are stable.

Decision: If /boot/efi isn’t mounted, GRUB updates may write to nowhere and future kernel updates can produce a fun surprise. Fix it now.

Three corporate-world mini-stories (so you don’t repeat them)

Mini-story 1: An incident caused by a wrong assumption

A mid-sized company rolled out Ubuntu dual-boot laptops for developers: Windows for corporate apps, Ubuntu for build tooling. The imaging team assumed that “the disk is always /dev/nvme0n1” because it was true on the first dozen models. Then procurement did what procurement does and shipped a batch with two internal drives: a small NVMe for the OS and a larger SATA SSD for data.

The automation script partitioned the first disk it saw, installed Ubuntu, and updated the EFI boot entries. On the dual-drive models, “first disk” wasn’t consistent. Some machines ended up with GRUB on one disk, the ESP on another, and Windows’ boot manager entry pointing into the void.

Symptoms were chaotic: a subset of laptops booted straight to firmware, some booted Ubuntu but not Windows, some booted Windows only if you mashed F12 at the right time. It looked like “Secure Boot weirdness” because that’s what people say when they don’t know where the bootloader lives.

The fix was boring and slightly humiliating: stop relying on enumerations, identify disks by model/serial, and explicitly target the disk containing the ESP. They also added a preflight step: dump lsblk and efibootmgr to logs before any changes. The next rollout had a failure rate close to zero, which is the only acceptable number for “we touched boot.”

Lesson: Disk names are not identities. Treat them like transient interface names and use stable identifiers.

Mini-story 2: An optimization that backfired

A different org tried to “optimize” install time by turning off Secure Boot in firmware during provisioning. The idea was to avoid MOK prompts, speed up driver installation, and then re-enable Secure Boot at the end. In a lab, it worked. In production, it produced a quiet disaster.

On some firmware versions, toggling Secure Boot reset parts of the boot order or triggered “fallback” boot behavior. Some devices would re-enable Secure Boot but refuse to boot the previously installed unsigned or differently-signed components without a clean enrollment. Others would reorder boot entries so Windows dominated again, and the helpdesk would get tickets like “Ubuntu disappeared.”

Worse, the team’s automation assumed re-enabling Secure Boot was a reversible toggle. It wasn’t. It was a state transition with side effects. The installed system wasn’t broken; the assumptions were.

They rolled back the “optimization,” provisioned with Secure Boot on from the first boot, and accepted the extra minutes. It’s amazing how fast things go when you stop creating your own problems.

Lesson: Don’t optimize the critical path by changing security modes midstream. If you want Secure Boot on, keep it on from the start.

Mini-story 3: A boring but correct practice that saved the day

A financial firm had a policy: before any OS deployment, technicians must capture (1) a GPT backup, (2) a photo of the firmware boot menu showing boot mode, and (3) a copy of EFI directory listings from the ESP after install. Everyone complained it was bureaucratic. Everyone was wrong.

One day a laptop came back from a vendor repair with the mainboard replaced. The disk was intact, but the NVRAM boot entries were gone—no “ubuntu,” no “Windows Boot Manager.” The machine booted to firmware and stared at the user like it had never heard of operating systems.

The technician pulled the stored ESP listing from the ticket, confirmed that \EFI\Microsoft\Boot\bootmgfw.efi and \EFI\ubuntu\shimx64.efi should exist, then mounted the ESP from a live USB and verified the directories were still there. Good. The data wasn’t gone; the pointers were.

They recreated the boot entries with efibootmgr and used the firmware’s “UEFI file” boot option as a fallback. No repartitioning. No reinstall. No data loss. The ticket closed quickly, which is the finest compliment in operations.

Lesson: Capture state before and after changes. When firmware forgets, you don’t need heroics—you need evidence.

Fast diagnosis playbook

When dual-boot breaks, people thrash: reinstall GRUB, toggle BIOS settings, curse the moon. Don’t. Do this in order to find the bottleneck fast.

1) Is this a boot-mode problem (UEFI vs legacy)?

• From a live USB: check /sys/firmware/efi.
• If the installed OS was installed in UEFI but you boot the recovery USB in legacy mode, you’ll chase ghosts.

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Decision: Match the boot mode of your tools to the installed system.

2) Is firmware pointing at the right EFI binary?

• Use efibootmgr -v in Ubuntu.
• If Ubuntu won’t boot, use the firmware boot menu to choose Windows Boot Manager or a UEFI file path.

cr0x@server:~$ sudo efibootmgr -v | sed -n '1,20p'
BootCurrent: 0003
BootOrder: 0003,0000
Boot0000* Windows Boot Manager  HD(1,GPT,...)File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0003* ubuntu                HD(1,GPT,...)File(\EFI\ubuntu\shimx64.efi)

Decision: If entries are missing, recreate them. If entries exist but don’t work, inspect the ESP and signatures.

3) Is the ESP intact and mounted?

If the ESP was formatted, you’ll see missing directories. If it’s just not mounted, updates don’t land where they should.

cr0x@server:~$ sudo mount | grep -E "/boot/efi|/mnt/esp" || echo "ESP not mounted"
ESP not mounted

Decision: Mount it, validate directories, then repair boot entries.

4) Is Windows “dirty” (hibernated) and blocking detection?

Windows Fast Startup can make Linux refuse to mount NTFS, and can also interfere with os-prober detection. If Windows is dirty, fix that first.

5) Is Secure Boot blocking a driver/module?

When graphics or Wi‑Fi fails after install, Secure Boot may be enforcing module signature rules. That’s not a reason to disable Secure Boot; it’s a reason to install signed drivers or enroll MOK correctly.

cr0x@server:~$ dmesg | grep -i -E "secure boot|lockdown|module verification" | tail -n 20
[    0.000000] secureboot: Secure boot enabled
[   12.345678] Lockdown: Loading of unsigned module is restricted; see man kernel_lockdown.7

Decision: If you need that module, install via Ubuntu packages that support Secure Boot flow, and enroll MOK when prompted.

6) Only then: GRUB repair

GRUB is often blamed, and sometimes guilty. But fix the underlying boot mode/ESP/NVRAM issues first. Otherwise you just reinstall GRUB into the same broken context.

Common mistakes: symptoms → root cause → fix

1) Symptom: Windows partition mounts read-only or won’t mount

Root cause: Windows was hibernated or Fast Startup left NTFS “dirty.”

Fix: Boot Windows, disable Fast Startup, run a full shutdown. Then retry detection.

cr0x@server:~$ sudo ntfsfix -n /dev/nvme0n1p3
NTFS volume is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting).

2) Symptom: Installer doesn’t show “Install alongside Windows” option

Root cause: Windows is on BitLocker and/or Fast Startup is enabled, or the disk layout is unusual (dynamic disks, RAID mode).

Fix: Use manual partitioning; ensure free space exists; confirm UEFI mode; avoid dynamic disk setups.

3) Symptom: After install, machine boots straight into Windows

Root cause: Firmware boot order still prefers Windows Boot Manager, or Ubuntu entry wasn’t created.

Fix: Set boot order in firmware, or from Ubuntu:

cr0x@server:~$ sudo efibootmgr
BootCurrent: 0000
BootOrder: 0000,0003
Boot0000* Windows Boot Manager
Boot0003* ubuntu
cr0x@server:~$ sudo efibootmgr -o 0003,0000

Decision: If firmware keeps reverting, check for vendor “Windows-first” policies or firmware updates.

4) Symptom: After install, machine boots to firmware with “No bootable device”

Root cause: Boot entries missing (NVRAM reset), ESP not found, or ESP corrupted.

Fix: From live USB, mount ESP and verify EFI binaries exist. Recreate entries with efibootmgr. If binaries are missing, you may need to reinstall GRUB/shim to ESP.

5) Symptom: Ubuntu boots, but no Wi‑Fi

Root cause: Missing firmware package, or Secure Boot blocked an out-of-tree module, or the device is unsupported.

Fix: Identify the device, install correct firmware, check dmesg.

cr0x@server:~$ lspci -nn | grep -i network
02:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax) [8086:2725]
cr0x@server:~$ dmesg | grep -i firmware | tail -n 20
[    8.123456] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-*.ucode failed with error -2

Decision: Install the missing firmware package via apt (requires networking; use Ethernet or USB tethering if needed).

6) Symptom: Black screen after NVIDIA driver install with Secure Boot enabled

Root cause: MOK enrollment not completed, or the module failed signature validation.

Fix: Reboot, enroll MOK when prompted. If you missed it, reinstall the driver package and repeat MOK flow, or temporarily boot with the open-source driver to recover.

7) Symptom: GRUB menu doesn’t show Windows

Root cause: os-prober not running, Windows hibernation, or Windows boot files not on the expected ESP.

Fix: Ensure Windows is fully shut down, then run update-grub. Verify ESP contains Microsoft bootloader directory.

8) Symptom: BitLocker recovery prompt after installing Ubuntu

Root cause: Boot configuration changed (expected) and BitLocker wants verification via recovery key.

Fix: Enter recovery key, then in Windows consider “suspend and resume BitLocker” so it re-seals to the new boot state. Don’t disable BitLocker permanently unless policy allows and you understand the risk.

Checklists / step-by-step plan

Plan A: Standard single-disk Windows + Ubuntu dual-boot (recommended)

1. In Windows: Back up critical files to an external disk. Save BitLocker recovery key off-device.
2. In Windows: Disable Fast Startup. Full shutdown.
3. In Windows: Shrink the Windows partition leaving unallocated space.
4. Boot Ubuntu USB (UEFI): Validate UEFI mode (/sys/firmware/efi exists).
5. From live Ubuntu: Record lsblk and parted -l output (screenshots or saved text).
6. From live Ubuntu: Backup GPT (sgdisk --backup) to external disk.
7. Installer: Use manual partitioning. Select ESP, mount at /boot/efi, do not format.
8. Installer: Create ext4 for / in the free space. Optional /home.
9. Installer: Keep Secure Boot enabled. If asked, set MOK password (write it down temporarily).
10. First reboot: Complete MOK enrollment if prompted.
11. In Ubuntu: Run efibootmgr -v, confirm entries for Windows and ubuntu.
12. In Ubuntu: Run update-grub and confirm Windows detection.
13. Boot test: Boot Windows from GRUB and from firmware boot menu. Confirm BitLocker behaves as expected.

Plan B: Ubuntu on second disk, Windows on first disk (works, but be deliberate)

1. Confirm which disk contains the ESP. Usually Windows disk.
2. Decide whether to place Ubuntu’s EFI files on the existing ESP or create a second ESP on the Ubuntu disk. Prefer a single ESP unless you have a reason.
3. Install Ubuntu using manual partitioning, explicitly selecting the right disk/ESP.
4. Verify firmware boot order and ensure both entries remain after reboots and updates.

Plan C: If something goes wrong, don’t “try things” blindly

1. Boot a live Ubuntu USB in UEFI mode.
2. Identify disks (lsblk), find ESP (blkid), mount it, list /EFI.
3. Check NVRAM entries (efibootmgr -v).
4. Only then attempt repair: recreate entries or reinstall GRUB to ESP.

Task 21: Recreate a missing Windows Boot Manager entry (if the file exists)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Windows Boot Manager" -l '\EFI\Microsoft\Boot\bootmgfw.efi'
BootCurrent: 0003
BootOrder: 0004,0003,0000
Boot0004* Windows Boot Manager

What it means: You created a new NVRAM entry pointing at the Microsoft EFI binary on partition 1 (the ESP).

Decision: If it fails, verify the ESP partition number and path; backslashes matter in EFI paths.

Task 22: Recreate a missing Ubuntu entry (shim path)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi'
Boot0005* ubuntu

What it means: You recreated the Ubuntu Secure Boot entry.

Decision: Put it first in boot order if desired.

Task 23: Set boot order explicitly (because firmware “helpfulness” is a menace)

cr0x@server:~$ sudo efibootmgr -o 0005,0004
BootOrder: 0005,0004

What it means: Firmware will try Ubuntu first, then Windows.

Decision: If the order doesn’t stick, check for vendor firmware settings that lock boot order, or BIOS updates that reset NVRAM.

FAQ

1) Should I disable Secure Boot for Ubuntu 24.04?

No, not by default. Ubuntu supports Secure Boot well. Disable it only if you have a specific blocker you understand (usually a niche kernel module situation).

2) Will Ubuntu overwrite Windows?

Only if you tell it to. The dangerous option is “Erase disk and install Ubuntu.” Use manual partitioning and never format Windows partitions or the ESP.

3) Do I need a separate /home partition?

Not required. It’s useful if you reinstall Ubuntu frequently and want user data isolated. If you’re not disciplined about backups, a separate /home won’t save you from yourself.

4) Is a swap partition required?

No. Ubuntu can use a swapfile. If you plan to hibernate Linux, you should plan swap capacity intentionally and test hibernation. Otherwise, swapfile is simpler and generally fine.

5) Why does BitLocker ask for a recovery key after I install Ubuntu?

Because boot configuration changed and BitLocker is doing its job: it detected a new boot environment. Enter the recovery key, then let Windows re-seal (often by suspending/resuming BitLocker once). Don’t lose that key.

6) My installer can’t see my internal drive. What now?

Common cause on some laptops: firmware storage mode set to Intel RST/RAID. Linux may not see the disk as expected. Switching to AHCI can help but must be done carefully to avoid breaking Windows boot. If you don’t already know the procedure, stop and plan the change.

7) GRUB doesn’t show Windows, but Windows boots from the firmware menu. Is that bad?

Not catastrophic. It means GRUB didn’t detect Windows or isn’t configured to show it. Fix Windows hibernation/Fast Startup, then run update-grub. You can also live with firmware selection, but it’s clunkier.

8) Can I share one data partition between Windows and Ubuntu?

Yes, usually via NTFS or exFAT. NTFS is fine for a shared data partition if you ensure Windows is fully shut down (no Fast Startup/hibernation). For reliability, avoid storing Linux-only permissions-sensitive data on NTFS.

9) Should I install Ubuntu “alongside Windows” or use manual partitioning?

If you want the highest success rate across weird OEM layouts, choose manual partitioning. The alongside option can work, but it’s an automation shortcut; you’re the one carrying the risk.

10) If I mess up the bootloader, is my data gone?

Usually not. Boot issues are often NVRAM entries or ESP contents. Your files are typically intact. The danger is panic-driven repartitioning. Stop, mount the ESP, inspect, then repair boot entries.

Conclusion: next steps after you’re booting cleanly

If you can boot Ubuntu and Windows reliably with Secure Boot enabled, you’ve already done the hard part: you made the boot chain boring again. Keep it that way.

Practical next steps:

• Update Ubuntu and reboot once to confirm kernel updates don’t break Secure Boot flow.
• Confirm backups: verify a checksum from your backup drive and restore one file as a test.
• Document your layout: save lsblk, parted -l, and efibootmgr -v output somewhere safe.
• Decide your default OS: set firmware boot order accordingly, and keep the other OS reachable via GRUB or firmware menu.
• Keep Windows Fast Startup off if you routinely access Windows partitions from Linux.

That’s it. No mysticism. Just disciplined changes, verified states, and the quiet satisfaction of a system that boots the same way twice.