- Shipped
- September 23, 2026 at 1:54 PM UTC
- Author
- Kamo
- Commit
- dbad178
virt-resize renumbers partitions. Canonical's image is laid out p14 (BIOS boot), p15 (ESP), p16 (/boot) and then p1 (root) physically last, and virt-resize rewrites the table in PHYSICAL order — its own output says so and I read past it: virt-resize: /dev/sda1: This partition will be resized from 2.5G to 19.0G. [ 47.8] Expanding /dev/sda1 (now /dev/sda4) GRUB's core image embeds the partition its /boot/grub lives on. After the move it cannot find it, and the guest stops at: SeaBIOS (version 1.16.3-4.el9) Booting from Hard Disk... error: no such partition. Entering rescue mode... grub rescue> WHY THIS TOOK SO LONG TO SEE Every signal above the disk said "still booting", and three of them actively misled: - one vCPU pinned at 100% for fifteen minutes, which reads like work. It is the rescue prompt polling the keyboard. - ZERO bytes of serial output, which reads like a disk that never executed. GRUB writes to VGA, and this image has no serial console at all, so the serial log was never going to contain anything either way — before or after the bootloader. - a valid MBR with a 55 aa signature, which reads like a healthy disk. It is: the boot SECTOR loads correctly. What is stale is the reference inside core.img. Downstream, the readiness probe on 3389 never passed, the Service got no endpoints, and the computer sat in WAKING. Nothing in that chain mentions a bootloader. What settled it in ten seconds, after an hour of inference, was a screenshot: virsh qemu-monitor-command "$DOMAIN" --hmp "screendump /tmp/screen.ppm" then read the framebuffer. A 720x400 dump is VGA text mode, which already says the guest never reached graphics; the text says the rest. Worth reaching for FIRST on any KubeVirt guest that is running and unreachable. grub-install runs after the customize and before the machine-id truncate, so the identity scrub still happens last.