Skip to content

[Ubuntu] Cap Azure resource disk mount timeout to avoid boot delay - #14753

Open
v-davit-ioramashvili wants to merge 2 commits into
actions:mainfrom
v-davit-ioramashvili:azure-resource-disk-mount-timeout
Open

v-davit-ioramashvili wants to merge 2 commits into
actions:mainfrom
v-davit-ioramashvili:azure-resource-disk-mount-timeout

Conversation

@v-davit-ioramashvili

Copy link
Copy Markdown
Contributor

Description

Improvement.

Ubuntu VMs booted from an ephemeral OS disk have no Azure resource disk, but the image still ships cloud-init's default /mnt mount for it. At boot, systemd waits ~90s for the missing device before giving up (nofail), delaying the transition to "running".

Fix: a cloud-init drop-in (/etc/cloud/cloud.cfg.d/99-azure-resource-disk-timeout.cfg, written by configure-environment.sh) caps the wait with x-systemd.device-timeout=1s. It is set through cloud-init rather than editing /etc/fstab directly, because cloud-init (cc_mounts) rewrites fstab on every boot and would drop a direct edit. When the resource disk is present it is detected early and mounts as before; the 1s cap only takes effect when the disk is absent.

Validated on fork CI for ubuntu-22.04 / 24.04 / 26.04: systemd abandons a missing device at the configured timeout (~1s, vs ~5s with a 5s control), and cloud-init regenerates the /mnt line carrying device-timeout=1s. https://github.com/v-davit-ioramashvili/runner-images/actions/runs/35228383511

Related issue:

github/hosted-runners-images#967

Check list

  • Related issue / work item is attached
  • Tests are written (if applicable)
  • Documentation is updated (if applicable)
  • Changes are tested and related VM images are successfully generated

VMs booted from an ephemeral OS disk have no Azure resource disk, but the
image still ships cloud-init's default /mnt mount for it. At boot, systemd
waits ~90s for the missing device before giving up (nofail), delaying the
transition to "running".

Add a cloud-init drop-in that caps the wait with x-systemd.device-timeout=1s.
It is set through cloud-init rather than editing /etc/fstab directly because
cloud-init (cc_mounts) rewrites fstab on every boot and would drop a direct
edit. When the resource disk is present it is detected early and mounts as
before; the 1s cap only takes effect when the disk is absent.
Copilot AI lite review requested due to automatic review settings September 18, 2026 10:23

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Tests should verify that cloud-init generates the /mnt fstab entry with the 1-second timeout.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds a cloud-init override to cap missing Azure resource disk mount waits at one second.

Changes:

  • Writes the resource disk timeout configuration.
  • Adds tests for the configuration and timeout value.
File summaries
File Description
images/ubuntu/scripts/build/configure-environment.sh Creates the cloud-init resource disk timeout configuration.
images/ubuntu/scripts/tests/System.Tests.ps1 Tests the configuration file and timeout setting.
Review details
  • Files reviewed: 2/2 changed files
  • Comments generated: 1
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +20 to +22
It "caps the resource-disk mount wait so boot is not delayed when the disk is absent" {
$content = Get-Content $configFile -Raw
$content | Should -Match 'x-systemd\.device-timeout=1s'
Inline the config path inside each It block. In Pester v5 a variable set in
the Describe body is only available during discovery, not inside It at run
time, so both assertions ran against a null path and failed on the image
build. Matches the adjacent ReadAhead test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants