One Laptop, Two Linuxes, and a Boot File That Ate Itself: Fixing a Self-Inflicted Initramfs Bug

A routine update day on my Omarchy/Debian dual-boot travel laptop turned into a lesson in boot internals. I installed Zoom from the AUR after auditing its PKGBUILD, then caught a Debian update quietly shrinking my boot file to a quarter of its size. The cause was a helper script tripping over its own files. Here’s how I diagnosed it, repaired it, and made sure it can’t happen again.

The goal

My HP Pavilion x360 is my travel laptop, and it dual-boots Omarchy (an Arch-based setup) and Debian 13 “Trixie.” Both share one boot partition, with the Limine bootloader presenting a menu at startup.

I depend on Zoom for daily meetings, so the plan was simple: install Zoom on the Omarchy side as a backup in case Debian ever fails, and make sure both systems are properly updated. Simple plans have a way of teaching you something. I covered hardening this laptop in Two Machines, Two Hidden Gaps.

Part 1: Omarchy update and a Zoom install I actually audited

On Omarchy, I updated with Omarchy’s own tool rather than plain pacman, because it also applies Omarchy’s configuration migrations:

omarchy-update

Before changing anything, the update took a Btrfs snapshot (via limine-snapper-sync), a restore point I can boot into if an update ever goes wrong.

One thing worth noting: mise bumped my default Python from 3.14 to 3.15. Virtual environments built on 3.14 may need rebuilding, which is good to know before a Black Hat Python script throws a confusing “module not found.”

Zoom isn’t in Arch’s official repos, so it came from the AUR, which is community-maintained. Anyone can upload an AUR package, so I read the PKGBUILD, the build recipe, before installing:

yay -S zoom

What I checked:

  • source= downloads directly from https://zoom.us/client/... over HTTPS.
  • sha512sums= gives a cryptographic fingerprint, so a tampered download fails the integrity check.
  • package() is a single cp command that copies files into place, with no extra downloads and no surprise scripts.

That’s what a trustworthy PKGBUILD looks like. Reading the install script is the cheapest supply-chain defense there is.

Part 2: The Debian update that broke the boot file

Back in Debian, sudo apt upgrade installed 12 security-relevant updates (curl, Firefox ESR, Ghostscript, ntfs-3g), then failed at the end:

update-initramfs: Generating /boot/initrd.img-debian-current
depmod: ERROR: Bad version passed debian-current
run-parts: /etc/initramfs/post-update.d//zz-limine-debian exited with return code 1

The initramfs is the small starter image the kernel loads at boot, carrying the drivers needed to unlock and mount the encrypted root drive. Something was trying to build one for a kernel called “debian-current,” which doesn’t exist.

Diagnosis: let the file sizes talk

/boot on this laptop is a root-only FAT partition, so sudo ls -la /boot was needed:

FileSize
initrd.img-6.12.111+deb13-amd64 (good)~135 MB
initrd.img-debian-current (just rebuilt)~33 MB

The boot file Limine uses for Debian had just been rebuilt with no drivers, at about a quarter of its normal size. A reboot into Debian at that moment would likely have failed.

The root cause was in a custom hook script. To give Limine a stable filename, it copied the newest kernel to /boot/vmlinuz-debian-current. But Debian’s linux-version list treats any vmlinuz-* file as a kernel. So the script’s own copy got counted as a kernel named “debian-current,” it sorted as “newest,” and every later rebuild targeted it. The script was tripping over its own output.

The fix

  1. Restored the good initrd over the broken one, then verified it byte for byte with cmp.
  2. Protected the fallback kernel (6.12.94), which a Limine fallback entry depends on, from apt autoremove:
   sudo apt-mark manual linux-image-6.12.94+deb13-amd64
  1. Backed up limine.conf.
  2. Renamed the fixed-name copies so they no longer look like kernels: debian-vmlinuz and debian-initrd.img.
  3. Updated the Limine entry and the hook script with sed to use the new names, and verified both edits.
  4. Test-booted the updated entry and confirmed with uname -r.
  5. Deleted the old debian-current files, confirmed sudo linux-version list showed only real kernels, and finished the interrupted setup:
   sudo dpkg --configure -a

The rebuild then targeted the real kernel, and within the same minute the hook copied it to debian-initrd.img, at full size and identical to the original. Self-healing, as intended.

Lessons

  • Read the error messages literally. “Version number does not start with digit” was the whole story in one line.
  • File sizes are evidence. A 75% drop in an initrd is a red flag you can spot without opening anything.
  • Don’t blindly accept apt autoremove. It wanted to delete a kernel my boot menu’s fallback entry relies on.
  • Verify every edit. sed is silent whether it changes something or not, so always check the result.
  • Audit what you install. Thirty seconds reading a PKGBUILD beats trusting a stranger’s script with root.
  • Watch for “permission denied” disguised as silence. linux-version list returned nothing as a regular user, not because nothing existed, but because /boot was root-only.

The travel laptop now boots both systems cleanly, survives future kernel updates without manual repair, and has Zoom on both sides.