A previous attempt at building this system from scratch failed at wifi — a real driver problem that killed that attempt outright. This time, the kernel config started from the one place guaranteed to already have that driver working: this exact machine's own currently-running Ubuntu kernel. That choice fixed the wifi problem completely. It also quietly carried two settings across that don't make sense on the system actually being built, and both had to be caught before they became a second boot failure.
Starting from a config that's already proven, not a default
The book's own process for kernel configuration is interactive — make menuconfig, page by page, deciding every option by hand. This build skipped that in favor of seeding .config directly from /boot/config-6.17.0-1012-oem, the config file behind the Ubuntu kernel this machine boots into every day, then running make olddefconfig to migrate it non-interactively to the newer kernel source being built. The specific motivation was concrete, not general caution: this machine's wifi chip needs the ath12k driver, and a prior from-scratch attempt on this same hardware never got that driver working correctly by picking through kernel options by hand. Copying the host's config sidesteps that entirely — CONFIG_ATH12K=m was confirmed present in the final built config, and lspci -k/lsmod on the host had already confirmed that exact driver bound to the exact hardware, successfully, under that exact config.
What "it already works" doesn't mean
A config that boots one system correctly encodes real assumptions about that system that don't automatically transfer. Two showed up here. First: CONFIG_BLK_DEV_NVME and CONFIG_NVME_CORE were both set as loadable modules (=m) in the host config — completely reasonable for Ubuntu, which boots through an initramfs that loads whatever modules the root filesystem needs before the real root ever gets mounted. This build has no initramfs. A kernel with no initramfs and NVMe support as a module can't find its own root filesystem at boot, because the module that would let it read an NVMe device doesn't exist yet at the exact moment it's needed. Second: CONFIG_SYSTEM_TRUSTED_KEYS and CONFIG_SYSTEM_REVOCATION_KEYS pointed at certificate file paths that only exist inside Ubuntu's own kernel packaging tree — paths a vanilla kernel.org source tree, which is what this build actually compiles, has no reason to contain at all.
Catching it before the boot, not because of one
Neither of these was found by booting a broken kernel and working backward from a panic. Both were found by reading the built .config directly and checking it against what this specific build actually has available, before ever attempting a real boot with it. That's a meaningfully different kind of check than the debugging most kernel configuration war stories describe — not "the boot failed, here's why," but "here's what a boot with this config would fail on, found by reading the config instead of watching it fail."
Why "proven working" and "correct for this build" aren't the same claim
The host's config earns its trust from a real, specific track record — it drives the exact hardware this machine has, today, successfully. That track record says nothing about two structural differences between the system it was proven on and the system it was being reused for: one boots through an initramfs, the other doesn't; one is Ubuntu's own kernel packaging, complete with Ubuntu's own certificate files, the other is a plain upstream source tree with none of that infrastructure. A config carries forward every assumption baked into the system it came from, not just the hardware-specific ones you're actually trying to borrow. Getting the wifi driver right by copying a known-good starting point was the correct call. It didn't make the starting point correct everywhere else, and the parts where it wasn't were invisible until someone went looking for them specifically, rather than trusting that "this already boots somewhere" meant "this will boot here."