- 已装运
- 2026年9月24日 02:15 UTC
- 作者
- Kamo
- 提交
- a7f4925
A computer provisioned, came up, and panicked on its next boot: Run /init as init process Failed to execute /init (error -2) Kernel panic - not syncing: No working init found. The initrd was full size, 37.8 MB, with the same 429-entry early segment as the golden image's and a main segment of its own. The only difference from the image that boots: no /init inside it. Two code paths regenerate the initrd, and they ran 36 MILLISECONDS APART from different threads: 01:37:26.658 POST /branding 200 the boot-splash handler's update-initramfs 01:37:26.694 hibernation readiness the boot thread's, inside configure() 01:37:28.963 restarting so the kernel picks up resume= Two concurrent rebuilds of one target, then a reboot into the result. Proven by elimination rather than inference: a single clean update-initramfs run against that same disk produces a valid initrd with main/init present, and /boot had 749 MB free, so neither the tool nor space was at fault. Three changes, because one is not enough: BOOT_WORK_LOCK is now taken by everything that rewrites how the computer boots, and restart_for_resume refuses while it is held. Rebooting during that work is what turns a bad initrd into a destroyed machine. The hibernation wiring no longer runs update-initramfs at all. It never needed to: resume= and resume_offset= on the kernel command line are what make a computer resumable, update-grub writes them, and resume_configured() verifies them against /proc/cmdline. The conf.d/resume file is still written so the NEXT distribution-driven rebuild keeps the resume device — with apt's error handling around it rather than ours. And the two commands that decide whether a machine can boot are no longer run with check=False. Their status is kept and their output logged, and a restart is refused while either has failed. That one matters less than it looks: by the time update-initramfs fails, the damage is already on disk, which is exactly why the first two changes exist.