— and Why “Preparing in Advance” Solves It Once and for All
When running Ubuntu on Hyper-V, some users encounter a very confusing issue:
- On a cold boot, the system occasionally drops into emergency mode
- Errors indicate failure to load kernel modules or mount the root filesystem
- Repeatedly clicking “Stop → Start” eventually allows Ubuntu to boot normally
- The system disk and files are not corrupted
This problem is hard to reproduce reliably and difficult to search for online.
After a complete investigation, the conclusion is clear:
This is not accidental, nor mysterious behavior —
it is a classic engineering problem caused by insufficient boot-time preparation.
1. The Key Conclusion (Important)
The root cause is not a broken system.
The real issue is:
Linux boots faster than the virtual disk is ready.
And the solution can be summarized in one sentence:
Move work that is normally done during boot
to a point before the system starts booting.
2. Where Exactly Does the Failure Occur?
A simplified Linux boot sequence looks like this:
GRUB
→ Linux kernel
→ initramfs (minimal early boot environment)
→ Mount root filesystem (/)
→ systemd startup
The failure happens precisely at this transition:
initramfs → mounting the root filesystem
In a Hyper-V cold-boot scenario:
- The kernel has already started mounting
/ - But the virtual disk controller / I/O path is still initializing
- The device “will exist very soon”, but does not yet exist at that moment
Linux does not wait indefinitely by default, so the mount fails and the system
drops into emergency mode.
3. Why Rebooting Sometimes “Fixes” It
This is where many people are misled.
What actually happens:
First cold boot
- Virtual device initialization is slow
- Disk readiness lags behind kernel startup
Subsequent boots
- Controllers, caches, and resources are already warm
- The disk becomes ready much faster
This creates the illusion:
“If I restart a few times, it works.”
But this only changes the probability, not the underlying problem.
4. The Real Solution: Prepare in Advance
The effective fix consists of four steps:
sudo update-initramfs -u -k all
sudo nano /etc/default/grub
Change:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash rootdelay=10"
Then run:
sudo update-grub
sudo reboot
What This Achieves
update-initramfs
Ensures all required kernel modules are already available at boot time,
instead of being loaded on demand.rootdelay=10
Explicitly tells the kernel to wait (up to 10 seconds) for the virtual disk
before attempting to mount/.update-grub
Applies the new boot configuration.reboot
Activates the changes, which only take effect during startup.
Together, these steps eliminate the boot-time race condition entirely.
Final Summary
This issue is not caused by system size, corruption, or misconfiguration.
It happens because:
The system was trying to boot before all required components were ready.
The fix works because it does exactly one thing:
Everything that must be ready at boot time is prepared before boot begins.
KAGAYA's Blog 