cloud-init: stop persisting zram swap into /etc/fstab (slow cloud boot) - #10324
Open
igorpecovnik wants to merge 1 commit into
Open
cloud-init: stop persisting zram swap into /etc/fstab (slow cloud boot)#10324igorpecovnik wants to merge 1 commit into
igorpecovnik wants to merge 1 commit into
Conversation
cloud-init's `mounts` module sees the running zram swap that armbian-zram-config sets up and writes a "/dev/zram0 ... swap ... cloudconfig" line into /etc/fstab. On the next boot systemd turns that into a dev-zram0.swap unit that blocks ~90s waiting for /dev/zram0 (created later by armbian-zram-config) before swap.target recovers — a very slow boot every time, seen on the arm64 cloud images. Ship a cloud.cfg.d drop-in that sets the `swap` mount to null, removing cloud-init's default swap mount so it leaves zram/swap to Armbian. Verified against cc_mounts (config is sanitized before de-dup, so the default swap entry is suppressed too). Signed-off-by: Igor Pecovnik <igor@armbian.com>
Contributor
📝 WalkthroughWalkthroughThe PR adds a cloud-init configuration that prevents Armbian zram swap from being persisted in ChangesCloud-init swap handling
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On the arm64 cloud images, boot takes ~90 s longer than it should. Root cause:
armbian-zram-config.servicesets up zram swap at boot.mountsmodule sees that active swap and persists it to/etc/fstab:/dev/zram0 none swap sw,comment=cloudconfig 0 0.dev-zram0.swapunit that blocks ~90 s on the device timeout waiting for/dev/zram0(which only appears oncearmbian-zram-configruns), failingswap.targetuntil it recovers.Confirmed on two production cloud hosts (
armbian-aarch64-1/2), both with the identical fstab line and a 90 sdev-zram0.devicetimeout indmesg.Fix
A
cloud.cfg.ddrop-in (99-armbian-no-zram-swap.cfg) that sets cloud-init'sswapmount tonull:This removes cloud-init's default swap mount so it leaves zram/swap management to Armbian, while keeping the rest of the
mountsmodule. Verified againstcc_mounts.py(26.1):handle()runssanitize_mounts_configurationbeforeadd_default_mounts_to_cfg, so the sanitizedswap→/dev/zram0entry suppresses the auto-added default swap entry, and the null mountpoint keeps it out of fstab.Deployed cloud hosts were already fixed by removing the stale fstab line (armbian-zram-config still provides the swap); this stops new images from shipping the bug.
Summary by CodeRabbit
/etc/fstab.