Debian 13 Install Done Right: UEFI, Wi‑Fi, Non‑Free Firmware, No Drama

The non-negotiable principles

1) Decide up front: UEFI + GPT, or don’t bother. On modern systems, UEFI is the default reality. Treating it as optional is how you end up with a machine that boots “only when the moon is right” after the next firmware update.

2) Treat firmware like a dependency, not a moral debate. If your Wi‑Fi or GPU needs firmware blobs, that’s not a character flaw. It’s an input to your build. Handle it explicitly and you’ll stop losing hours to mysteriously absent devices.

3) Make the install reproducible. “I clicked whatever the installer suggested” is not a runbook. You want a partition scheme you can explain, a package selection you can audit, and post-install steps you can re-run.

4) Don’t optimize during install. You’re laying track, not racing. Use defaults that are easy to debug, then tune later with measurements.

5) Every choice should reduce your future downtime. Boot reliability, Wi‑Fi reliability, and clean upgrades are the real KPI. Cosmetics can wait.

Joke #1: Secure Boot is like a bouncer: great when it knows the guest list, awkward when it doesn’t recognize you.

A few interesting facts (history that still bites)

• UEFI replaced BIOS as the mainstream boot firmware over the last decade, but many boards still ship with “CSM/Legacy” toggles that confuse installs by mixing modes.
• GPT (GUID Partition Table) is part of the UEFI-era storage stack; it avoids MBR’s old limits and makes multi-disk setups less error-prone.
• Secure Boot was introduced to reduce boot-time malware by enforcing signature checks; it also made “boot something custom” a more deliberate act.
• Linux Wi‑Fi drivers often require separate firmware files; the kernel driver can be present while the radio stays unusable without the firmware payload.
• Debian historically separated “free” and “non-free” components; that policy shaped install media availability and why some people had “no Wi‑Fi” by default for years.
• systemd’s journal changed how boot issues are diagnosed: you now have structured logs early in boot, not just whatever scrollback you caught on a screen.
• NVMe became the default laptop storage and it’s fast enough that sloppy filesystem and swap choices show up as power/latency issues rather than obvious throughput limits.
• Initramfs exists to load modules early; missing firmware frequently surfaces here as “device not found” even though the driver is technically installed later.

Preflight checks before you boot the installer

Know what you’re installing onto

Before you touch Debian, confirm the platform mode and storage layout. If you’re on a laptop, you also want to know whether Wi‑Fi is Intel (usually painless) or Realtek/Broadcom (often firmware-dependent and occasionally spiteful).

Decisions to make now:

• UEFI mode only (recommended) vs legacy/CSM (avoid unless you have a hard requirement).
• Keep Secure Boot enabled and enroll keys vs disable Secure Boot (both valid; pick one deliberately).
• Install with Ethernet or phone tethering vs rely on Wi‑Fi during the installer.
• Disk encryption (LUKS) or not; if yes, decide whether to also encrypt swap and how you’ll handle remote recovery.

What to avoid like a production outage

• Mixing legacy boot and UEFI boot across OS installs. Dual-boot is fine; dual-boot-in-two-modes is chaos.
• Random partitioning that creates multiple ESPs “just in case.” One ESP per machine is typically enough unless you have a very specific multi-disk boot design.
• Assuming Wi‑Fi will “just work.” Plan for firmware. Plan for no network. Plan for having to add packages after first boot.

Non-free firmware: what it is, why you need it, and how to do it cleanly

Firmware is not a driver. It’s the blob the device needs to wake up and behave. The kernel module can be present and loaded, and still the device is dead because it can’t fetch the right firmware file. That’s why you see messages like “failed to load iwlwifi-*.ucode” and then a silent radio.

On Debian, the practical reality is this: plenty of modern hardware needs firmware that isn’t in the purely “free software” subset. Debian’s packaging has evolved, and Debian 13-era installs are far less dramatic than they used to be—but you still need to make sure your installer environment can access the firmware packages when it matters.

The sane approach

• Use installation media that includes firmware support when you’re installing on Wi‑Fi-only hardware.
• After install, explicitly enable the right APT components so upgrades don’t regress your hardware enablement.
• Install only the firmware you need unless you’re building a general-purpose image for multiple device models.

The two common failure modes

• Installer can’t see Wi‑Fi: driver loads, firmware missing; or device needs a newer firmware than what’s on the media.
• Post-upgrade Wi‑Fi dies: you installed firmware from a local .deb once, but didn’t configure APT to keep receiving firmware updates.

UEFI/GPT done right (and how to not brick your boot)

UEFI in one paragraph

In UEFI mode, your system firmware reads boot entries from NVRAM and loads an EFI binary from the EFI System Partition (ESP), usually mounted at /boot/efi. GRUB (or systemd-boot) lives there, and it points to your kernel/initramfs on your Linux filesystem. If your ESP is missing, unmounted, or formatted wrong, you’ll “install successfully” and then reboot into nothingness.

Secure Boot: pick a lane

You have two operationally valid options:

• Disable Secure Boot in firmware settings. Simple. Fewer moving parts. Slightly weaker boot-chain assurances.
• Keep Secure Boot enabled and ensure your bootloader/kernel path is signed appropriately. More secure. More complexity when you add out-of-tree modules (think Wi‑Fi oddities, NVIDIA drivers, ZFS DKMS).

If this is a laptop you travel with, I lean toward keeping Secure Boot enabled only if you’re willing to treat signing as part of your system lifecycle. If you’re building a dev workstation and you routinely load third-party kernel modules, disable Secure Boot and move on with your life.

ESP sizing and placement

Make the ESP 512 MiB (or 1 GiB if you dual-boot and keep multiple kernels). FAT32. Set the correct partition type. Mount it at /boot/efi. Keep it boring. Boring boots.

Wi‑Fi during install: the realistic options

The Debian installer is good, but it can’t conjure firmware out of thin air. Here’s what actually works in the field:

1. Ethernet. The gold standard. If you can plug in for 20 minutes, do it.
2. USB phone tethering. Surprisingly reliable. Most Android devices present an Ethernet-over-USB gadget interface that Debian can use without Wi‑Fi firmware.
3. Installer media with firmware. Good for laptops without Ethernet, and for sites where “internet during install” is not allowed.
4. Bring firmware on a second USB. Works when the installer prompts for firmware; you provide the files. Less convenient, but sometimes the only option in restricted environments.

Joke #2: Wi‑Fi firmware is the only “download to get internet” problem that keeps shipping in new and exciting forms.

My advice: don’t gamble on Wi‑Fi during install if you can avoid it. Use Ethernet or tethering, finish the base install, then harden and tune Wi‑Fi once you’re booted into your real kernel with your real logs.

Partitioning: boring, correct, and fast to recover

A partition layout that won’t surprise you later

For a typical single-disk Debian 13 laptop/workstation with UEFI:

• ESP: 512 MiB, FAT32, mounted at /boot/efi.
• / (root): ext4, sized for OS + apps (30–80 GiB is usually fine; more if you’re doing containers or heavy tooling).
• swap: optional; if you want hibernation, size it appropriately. Otherwise, a small swap (or none) can be fine depending on RAM and workload.
• /home: optional separate partition; useful if you reinstall often, less useful if you use good backups and don’t cargo-cult old habits.

Encryption

If the machine leaves your desk, use full-disk encryption. LUKS with an encrypted root volume is the “I can sleep at night” baseline. If you enable Secure Boot and disk encryption, remember you’re stacking complexity: manageable, but only if you document your recovery steps.

Filesystem choice

ext4 remains the operationally calm choice. Yes, btrfs and ZFS have features; they also have operational profiles. If you’re not prepared to monitor scrub status, handle snapshot policies, and reason about boot-time initramfs modules, pick ext4. Your future self will be less creative during outages.

Practical tasks (commands, outputs, decisions)

These are “do the thing, read the output, decide” tasks. Run them during install (where possible from a shell) or immediately after first boot.

Task 1: Confirm you booted the installer in UEFI mode

cr0x@server:~$ ls /sys/firmware/efi
config_table  efivars  fw_platform_size  runtime  runtime-map  systab  vars

What it means: If /sys/firmware/efi exists, you’re in UEFI mode.

Decision: If it’s missing, reboot and select the UEFI entry for your USB in the firmware boot menu. Don’t proceed in legacy mode unless you have a specific reason.

Task 2: Check Secure Boot state

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

What it means: Secure Boot is enabled. If it says disabled, you’re free of signature enforcement.

Decision: If you plan on DKMS modules (NVIDIA, ZFS, special Wi‑Fi), either set up signing properly or disable Secure Boot now to avoid late-night surprises.

Task 3: Identify the disk and confirm GPT

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MODEL
NAME         SIZE TYPE MODEL
nvme0n1    953.9G disk Samsung SSD 990
nvme0n1p1   512M part 
nvme0n1p2    80G part 
nvme0n1p3   873G part

What it means: You have an NVMe disk with three partitions; likely ESP, root, and home/data.

Decision: If you see unexpected disks (USB stick, old SATA drive), stop and re-check. Installing to the wrong disk is the classic unforced error.

Task 4: Verify the ESP is correct (FAT32, mounted)

cr0x@server:~$ findmnt /boot/efi
TARGET    SOURCE     FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

What it means: ESP is mounted and is VFAT. Good.

Decision: If findmnt shows nothing, mount it and fix /etc/fstab before you troubleshoot bootloader issues.

Task 5: Confirm the system created UEFI boot entries

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI OS	HD(1,GPT,0f2a1c2f-7b0d-4d53-9a1e-6e2c4c7c2b11,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)
Boot0002* debian	HD(1,GPT,0f2a1c2f-7b0d-4d53-9a1e-6e2c4c7c2b11,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0003* debian (fallback)	HD(1,GPT,0f2a1c2f-7b0d-4d53-9a1e-6e2c4c7c2b11,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)

What it means: NVRAM has entries. You’re not relying on “whatever the firmware guesses.”

Decision: If efibootmgr shows nothing Debian-related, you likely installed in legacy mode or your ESP wasn’t mounted during GRUB install.

Task 6: Find your Wi‑Fi device and driver pairing

cr0x@server:~$ lspci -nnk | sed -n '/Network controller/,+4p'
03:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E(802.11ax) [8086:51f0]
	Subsystem: Intel Corporation Device [8086:0094]
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

What it means: Driver is bound (iwlwifi), which is a good start.

Decision: If “Kernel driver in use” is empty, you may need a newer kernel, missing module, or BIOS setting (rare). If the driver is present but Wi‑Fi still doesn’t work, suspect firmware.

Task 7: See firmware load failures in the kernel log

cr0x@server:~$ dmesg -T | grep -iE 'firmware|iwlwifi|rtl|brcm' | tail -n 8
[Mon Feb  5 10:11:07 2026] iwlwifi 0000:03:00.0: loaded firmware version 77.2df8986f.0 ty-a0-gf-a0-77.ucode op_mode iwlmvm
[Mon Feb  5 10:11:07 2026] iwlwifi 0000:03:00.0: Detected Intel(R) Wi-Fi 6E AX211 160MHz
[Mon Feb  5 10:11:07 2026] iwlwifi 0000:03:00.0: base HW address: 70:1a:xx:xx:xx:xx

What it means: Firmware loaded successfully. If you saw “failed to load firmware,” that’s your smoking gun.

Decision: Successful firmware load means you pivot to RF-kill, NetworkManager config, or regulatory domain issues—not firmware packages.

Task 8: Check RF-kill (yes, it still happens)

cr0x@server:~$ rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no

What it means: Wi‑Fi isn’t blocked by software or hardware switch.

Decision: If hard blocked is “yes,” look for a laptop key combo or BIOS toggle. If soft blocked is “yes,” rfkill unblock all is your next move.

Task 9: Validate APT components include firmware

cr0x@server:~$ grep -R "^[[:space:]]*deb " /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null
/etc/apt/sources.list:deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
/etc/apt/sources.list:deb http://deb.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
/etc/apt/sources.list:deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware

What it means: You’ll receive firmware updates via normal upgrades.

Decision: If non-free-firmware is missing, add it and run apt update before you chase phantom driver issues.

Task 10: Install the firmware package you actually need

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://deb.debian.org/debian-security trixie-security InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

cr0x@server:~$ sudo apt install -y firmware-iwlwifi
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  firmware-iwlwifi
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 7,248 kB of archives.
After this operation, 26.1 MB of additional disk space will be used.
Fetched 7,248 kB in 1s (7,102 kB/s)
Selecting previously unselected package firmware-iwlwifi.
(Reading database ... 214532 files and directories currently installed.)
Preparing to unpack .../firmware-iwlwifi_20250115-1_all.deb ...
Unpacking firmware-iwlwifi (20250115-1) ...
Setting up firmware-iwlwifi (20250115-1) ...
update-initramfs: Generating /boot/initrd.img-6.12.0-1-amd64

What it means: Firmware installed and initramfs updated, which matters for early device init.

Decision: Reboot if Wi‑Fi didn’t appear immediately. If still missing, go back to dmesg and confirm the firmware file name matches what’s installed.

Task 11: Confirm NetworkManager sees Wi‑Fi and can scan

cr0x@server:~$ nmcli dev status
DEVICE  TYPE      STATE      CONNECTION
wlan0   wifi      disconnected --
lo      loopback  unmanaged  --
enp0s31f6 ethernet unavailable --

cr0x@server:~$ nmcli dev wifi list | head
IN-USE  BSSID              SSID          MODE   CHAN  RATE        SIGNAL  BARS  SECURITY
        50:aa:bb:cc:dd:ee  corp-guest    Infra  36    540 Mbit/s  72      ▂▄▆_  WPA2
        d4:11:22:33:44:55  corp-secure   Infra  11    195 Mbit/s  60      ▂▄▆_  WPA2 802.1X

What it means: Radio is working and scanning.

Decision: If scans return nothing, you’re looking at RF-kill, regulatory domain, or a broken driver/firmware pairing.

Task 12: Check DNS vs routing (the “I have Wi‑Fi but no internet” split-brain)

cr0x@server:~$ ip route
default via 192.168.1.1 dev wlan0 proto dhcp metric 600
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.50 metric 600

cr0x@server:~$ resolvectl status | sed -n '1,18p'
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

What it means: You have a default route and a DNS server. That’s the minimum for connectivity.

Decision: If routing exists but DNS is empty or wrong, fix DNS. If DNS exists but no default route, fix DHCP or static config.

Task 13: Check boot errors quickly with journalctl

cr0x@server:~$ journalctl -b -p err..alert --no-pager | tail -n 12
Feb 05 10:11:10 server kernel: iwlwifi 0000:03:00.0: Failed to load firmware chunk!
Feb 05 10:11:10 server kernel: iwlwifi 0000:03:00.0: firmware: failed to load iwlwifi-ty-a0-gf-a0-77.ucode (-2)
Feb 05 10:11:10 server kernel: iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-77.ucode failed with error -2

What it means: Error -2 is “file not found.” That’s a package/config issue, not “Wi‑Fi is cursed.”

Decision: Install the matching firmware package and ensure APT has non-free-firmware enabled; rebuild initramfs if needed.

Task 14: Verify GRUB is installed for UEFI

cr0x@server:~$ dpkg -l | grep -E '^ii\s+grub-efi-amd64'
ii  grub-efi-amd64  2.12-3  amd64  GRand Unified Bootloader, version 2 (EFI-AMD64 version)

What it means: Correct GRUB package for UEFI is installed.

Decision: If you only see grub-pc, you’re in legacy territory. Decide whether to reinstall properly in UEFI mode rather than trying to duct-tape boot.

Task 15: Verify fstab won’t sabotage boot

cr0x@server:~$ sudo findmnt --verify
Success, no errors or warnings detected

What it means: Your mounts are consistent; no missing UUIDs that will drop you into emergency mode.

Decision: If verification fails, fix /etc/fstab now. A broken fstab is a time-delayed outage.

Task 16: Confirm initramfs contains needed modules (when debugging early boot)

cr0x@server:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'iwlwifi|firmware|nvme' | head
usr/lib/firmware
usr/lib/firmware/iwlwifi-ty-a0-gf-a0-77.ucode
usr/lib/modules/6.12.0-1-amd64/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko

What it means: The firmware and module are inside initramfs; early boot should be able to bring the device up.

Decision: If missing, run update-initramfs -u after installing firmware; then reboot.

Fast diagnosis playbook

This is the “you have 10 minutes before the meeting” workflow. It’s ordered to find the bottleneck quickly, not to be philosophically complete.

1) Boot mode and boot chain (UEFI problems masquerade as “Debian is broken”)

1. Check UEFI mode: ls /sys/firmware/efi
2. Check ESP mount: findmnt /boot/efi
3. Check NVRAM entries: efibootmgr -v
4. Check what failed at boot: journalctl -b -p err..alert

Likely bottleneck: ESP not mounted during GRUB install, wrong boot mode, or firmware settings reset.

2) “No Wi‑Fi” is usually firmware, block state, or wrong APT components

1. Identify device/driver: lspci -nnk | sed -n '/Network controller/,+4p' (or lsusb for USB dongles)
2. Check RF-kill: rfkill list
3. Check firmware logs: dmesg -T | grep -i firmware
4. Confirm APT has non-free-firmware: grep sources, then apt update

Likely bottleneck: missing firmware package, installer used offline repo only, or a hardware kill switch.

3) “Wi‑Fi connects but internet is dead” is DNS or routing

1. Route: ip route
2. DNS: resolvectl status
3. Ping gateway: ping -c 2 192.168.1.1
4. Ping IP: ping -c 2 1.1.1.1 (tests routing)
5. Ping name: ping -c 2 debian.org (tests DNS)

Likely bottleneck: captive portal, broken DNS, or corporate network requiring 802.1X configuration.

4) Slow boot or hangs: find the unit that’s waiting

1. systemd-analyze time
2. systemd-analyze blame | head
3. systemd-analyze critical-chain

Likely bottleneck: network-online waits, missing mounts in fstab, or a device timing out.

Quote (paraphrased idea): “Hope is not a strategy,” commonly attributed in operations culture; treat it as a reminder to instrument and verify.

Common mistakes: symptoms → root cause → fix

1) Symptom: Installer finishes, reboot goes straight back to firmware menu

Root cause: Installed in legacy mode or ESP wasn’t mounted, so no UEFI boot entry/EFI binary was installed correctly.

Fix: Reboot installer in UEFI mode; ensure ESP exists and is mounted at /boot/efi before installing GRUB. Validate with efibootmgr -v.

2) Symptom: “No Wi‑Fi adapter found” in GNOME/KDE

Root cause: Firmware missing; driver loads but device can’t initialize. Alternatively, device is hard-blocked.

Fix: Check rfkill list and dmesg for firmware errors. Enable non-free-firmware in APT and install the matching firmware package (e.g., firmware-iwlwifi).

3) Symptom: Wi‑Fi works until a kernel upgrade, then disappears

Root cause: Firmware was installed once from removable media or local files; APT sources don’t include non-free-firmware, so updates don’t track your kernel/driver needs.

Fix: Correct /etc/apt/sources.list to include non-free-firmware, then apt update and reinstall the firmware package; rebuild initramfs.

4) Symptom: Boot drops into emergency mode after install

Root cause: Bad /etc/fstab entry: wrong UUID, missing partition, or a mount that cannot succeed (common with external drives).

Fix: Use findmnt --verify and blkid to correct UUIDs. Add nofail,x-systemd.device-timeout= for non-critical mounts.

5) Symptom: Secure Boot enabled; DKMS module won’t load

Root cause: Module is unsigned; Secure Boot blocks it.

Fix: Either disable Secure Boot, or enroll a Machine Owner Key and sign modules consistently. Don’t half-configure this—half is worse than none.

6) Symptom: Wi‑Fi connects but websites don’t load

Root cause: DNS misconfigured or captive portal; sometimes IPv6-only oddities on corporate guest networks.

Fix: Compare ping 1.1.1.1 vs ping debian.org. If IP works but name doesn’t, fix DNS (resolvectl status). If neither works, check routing and captive portal requirements.

7) Symptom: You have an ESP, but updates occasionally “forget” your boot entry

Root cause: Firmware updates reset NVRAM entries; your system relies on a fragile entry order.

Fix: Keep a fallback EFI binary at \EFI\BOOT\BOOTX64.EFI (often provided by GRUB install tooling) and verify with efibootmgr -v. Also consider updating firmware settings to keep the Debian entry first.

Checklists / step-by-step plan

Plan A: The clean UEFI install (recommended default)

1. In firmware settings: set boot mode to UEFI only; disable CSM/Legacy if present.
2. Decide Secure Boot: either disable it, or commit to module signing later.
3. Boot Debian installer via the UEFI entry.
4. In installer shell (if needed): confirm UEFI mode with ls /sys/firmware/efi.
5. Partition with GPT:
   • ESP: 512 MiB, FAT32, mount /boot/efi
   • Root: ext4
   • Optional: swap
   • Optional: separate /home
6. Select only what you need in tasksel. You can install desktop/server roles later.
7. First boot: confirm findmnt /boot/efi and efibootmgr -v.
8. Enable APT components including non-free-firmware.
9. Install firmware packages for your hardware, regenerate initramfs, reboot.
10. Run updates, then snapshot your “known good” state (even if it’s just a list of packages and config diffs).

Plan B: Wi‑Fi-only laptop, no Ethernet port

1. Prefer phone USB tethering for install-time network access.
2. If tethering isn’t possible, use install media that supports firmware and be ready to install firmware packages post-boot.
3. Post-install: verify firmware load in dmesg, then confirm scanning via nmcli dev wifi list.
4. Only after Wi‑Fi is stable: add printers, Bluetooth, and everything that creates more state to debug.

Plan C: Corporate environment (proxy, 802.1X, policies)

1. During install, avoid relying on enterprise Wi‑Fi auth. Use Ethernet or tethering.
2. After install, configure certificates and 802.1X profiles using NetworkManager tooling.
3. Verify NTP/time early; TLS failures often look like “repo down” when it’s actually “clock wrong.”
4. Confirm DNS suffixes and split DNS rules before blaming Debian.

Three corporate-world mini-stories

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

A team rolled out Debian-based laptops to a group that traveled constantly. The build was “standardized” and tested on a handful of developer machines that all happened to have Intel Wi‑Fi. The assumption—never written down—was that “Linux Wi‑Fi works out of the box now.”

Week one looked fine. Then Procurement sourced a second vendor for the same laptop model due to supply constraints. Same chassis, different Wi‑Fi chipset revision. The image still installed, but half the fleet came up without a network interface. People blamed DHCP, then blamed the VPN, then blamed “the new kernel.” The real issue was simpler: the driver loaded, but the specific firmware blob for that revision wasn’t present, and the APT sources on the image didn’t include non-free-firmware.

Because these were laptops, “just plug in Ethernet” wasn’t a universal workaround. The result was a perfect storm: a production change (new hardware revision), a missing dependency (firmware), and no reliable path to remediation (no network to fetch packages). People started doing what people do under stress: copying random firmware files from the internet onto USB sticks and hoping for the best.

The fix wasn’t heroic. They updated the base image to include the right APT components, added a minimal set of firmware packages for the known chipsets, and wrote a two-page runbook: how to identify the chipset, how to confirm firmware load, and how to recover using phone tethering. The incident didn’t repeat—not because the universe became kinder, but because the assumptions were replaced with checks.

Mini-story 2: An optimization that backfired

Another org wanted “fast boots” and “clean disks,” so they got clever during install. They shrank the ESP to something tiny because “it only holds boot files,” kept only one kernel, and aggressively cleaned packages. They also enabled Secure Boot but didn’t want the operational overhead of signing anything beyond the default.

For a while it was fine. Then a routine kernel update pulled in a new GRUB build and an updated initramfs. The ESP filled up. GRUB updates partly succeeded, leaving the system in a state where the firmware could still find an EFI binary, but the bootloader couldn’t reliably find the right kernel bits. Some machines booted; others didn’t. The failures looked random, which is the worst kind: it invites superstition.

The response initially focused on “why is Debian writing so much to the ESP?” and “can we compress initramfs more?” That’s the wrong direction. The correct direction is to accept that storage is cheap and outages are expensive. They resized the ESP to a sensible value, stopped deleting fallback boot files, and adopted a policy: keep at least two kernels installed, and never do “space optimization” without a measured capacity budget.

The backfire wasn’t the optimization itself; it was optimizing the wrong constraint. Boot partitions fail at the worst times, and you don’t want a clever design when you’re debugging blind at a remote site.

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

One team had a habit that looked like paranoia: after every OS rollout, they ran a small verification script locally on the machine. It checked UEFI mode, ESP mount, Secure Boot state, firmware load errors, and whether APT sources included firmware components. Then it saved the output in a ticket.

Months later, a firmware update from the hardware vendor reset a subset of machines to boot from “UEFI OS” rather than the Debian entry. The machines still booted—but now they booted through the fallback path, and a few edge cases started failing after subsequent updates. Most organizations would have called this “random boot weirdness.”

This team didn’t have to guess. They compared the post-update efibootmgr -v outputs to the earlier ticket attachments. The delta was obvious: BootOrder changed, and the Debian entry wasn’t first. The fix was mechanical: restore BootOrder, ensure fallback EFI binary existed, and document “firmware update may reset NVRAM entries” as an operational risk.

It was boring. It was correct. It also meant the on-call person spent 20 minutes fixing systems instead of two nights developing a new religion about UEFI.

FAQ

1) Should I use the graphical installer or text installer?

Use whichever you’re faster with. The real differentiator is whether you can drop into a shell and validate UEFI mode, disks, and firmware needs. Both installers can get you there.

2) Do I need non-free firmware on every Debian 13 install?

No. But if you’re on modern laptops, the odds are high that Wi‑Fi (and sometimes Bluetooth) will need it. Treat it as “likely” unless you’ve confirmed your chipset works without extra firmware packages.

3) Is it safe to enable non-free-firmware in APT?

Operationally, yes. You’re not enabling a mystery repo; you’re enabling Debian’s packaged firmware component so upgrades keep your hardware working. The risk is mostly philosophical, not technical.

4) My Wi‑Fi device is Realtek. What should I expect?

Expect firmware dependency and occasional driver maturity gaps. First step is always dmesg for firmware load errors and lspci -nnk to confirm the driver binding. If you’re stuck, consider Ethernet/tethering for install and stabilize after boot.

5) Should I keep Secure Boot enabled?

If you want the security property and you’re willing to manage module signing, yes. If you want low-friction kernel module workflows, disable it. The worst outcome is leaving it enabled and repeatedly discovering that your modules don’t load during urgent work.

6) Do I need a separate /boot partition?

Usually no on UEFI systems. You need an ESP for EFI binaries, but your kernel/initramfs can live on your root filesystem. Separate /boot can help with certain encryption setups, but it’s another moving part.

7) ext4 vs btrfs for a laptop: what would you choose?

ext4 unless you’re explicitly committed to snapshot workflows and understand the recovery story. btrfs can be great, but “great” comes with policy: snapshot retention, scrub cadence, and boot integration.

8) How do I tell if “no internet” is DNS or routing?

Ping an IP (routing) and a hostname (DNS). If ping 1.1.1.1 works but ping debian.org fails, it’s DNS. If both fail, it’s routing, captive portal, or link-layer issues.

9) What’s the quickest way to see why the last boot failed?

journalctl -b -p err..alert. That gets you the high-severity errors without drowning in noise. Then widen the scope if needed.

10) Can I fix a broken UEFI boot without reinstalling?

Often yes: mount the ESP, reinstall GRUB for EFI, and recreate boot entries with efibootmgr. But if you installed in legacy mode and want UEFI long-term, reinstalling cleanly can be faster and safer than boot archaeology.

Next steps that keep it stable

Debian 13 can be a no-drama install if you treat boot mode, firmware, and networking as first-class concerns—not afterthoughts.

Do these next, in this order:

1. Record your boot facts: UEFI mode, Secure Boot state, ESP UUID/mount, and efibootmgr -v output.
2. Lock in firmware reliability: confirm non-free-firmware is in APT sources; install the correct firmware package; verify with dmesg.
3. Run a post-install sanity pass: findmnt --verify, journalctl -b -p err..alert, and a basic network check (ip route, resolvectl status).
4. Only then customize: desktop tweaks, extra repos, third-party drivers, and performance tuning. Stability first; style later.

If you do nothing else, remember this: the installer is not the finish line. The finish line is a machine that still boots and still has Wi‑Fi after the next kernel upgrade.