Repository navigation
compact: fstrim fails on WSL 3.0 (execvpe does not find /sbin tools) #560
Description
skrog compact fails at its first step on WSL 3.0.3:
skrog: compact: fstrim in skrog-engine: wsl -d skrog-engine -u root --exec fstrim -v /: exit status 1:
<3>WSL (8 - Relay) ERROR: CreateProcessCommon:875: execvpe(fstrim) failed: No such file or directory
Verified on WSL 3.0.3.0 / Windows 10 19045, against the real engine and against a throwaway distro imported from skrog-rootfs-29.8.2-1-amd64.tar.gz:
/sbin/fstrimexists in the rootfs, andenvunderwsl --execshows/sbinonPATH.wsl --exec fstrim,wsl --exec sysctlandwsl --exec ipall fail withexecvpe(...) failed;wsl --exec lsworks. The relay's lookup apparently does not search/sbin.wsl --exec /sbin/fstrim -v /works.
So every skrog compact without --no-trim fails on this WSL. Inferred, not checked: this is a WSL change, since docs/housekeeping.md measured compact against WSL 2.7.8.
internal/compact/compact.go:198 is the only bare-name exec of a /sbin tool in skrog that I found; the others are sh -c or /bin//usr/bin tools.
Fix
Call /sbin/fstrim by its path. The rootfs is ours, so the path is fixed.
Activity
zcsizmadia commentedon Oct 25, 2026
Calling
/sbin/fstrimby path fixes the first step: verified live on a throwaway distro, and the unit tests fail without it. It is on the branchfix/560-fstrim-path, not yet pushed.It is not enough to make
skrog compactwork on WSL 3.0.3. The next step fails too:Verified on this machine:
vmmem) started at 10:43 was still running at 10:52 with no distro running, so it is not idling out aftervmIdleTimeout, as the docs measured on WSL 2.7.8 (~66 s).wsl --shutdown, a newvmmemwas up within a second, and compaction failed the same way. I did not identify what starts it; the skrog supervisor (0.8.0) was running throughout.vhdx.Freereturns true while the disk is held, so the 90 s wait ends at once and the error comes fromCompactVirtualDiskitself. The comment onopen(), that this access mode fails at the open, does not hold here.wsl --manage <distro> --compactcompacts the same disk right after a terminate (#552), because WSL detaches it inside the VM it owns.compact: run fstrim by its path; WSL 3.0's --exec does not find /sbin…
zcsizmadia commentedon Oct 25, 2026
Correction to my previous comment: the utility VM does idle out on WSL 3.0.3. It is
skrog compactthat keeps restarting it. Verified on this machine:vmmem) exited 60–65 s after the last distro stopped, matching what the docs measured on 2.7.8.wsl -l -v,wsl --list --runningandwsl --terminateon a stopped distro do not start it.wsl --manage --compactdoes.skrog compactstarted it:vmmemcame back the moment it ran. Its stop step callsStopEngine, which runsRemoveEmulationinside the distro before terminating it (Emulation: run foreign-architecture containers via binfmt_misc + qemu-user (opt-in) #462), and that boots a stopped distro.vhdx.Freereturned true while the VM held the disk, andvhdx.Compactfailed with the sharing violation. Once the VM exited,Freereturned true again andCompactsucceeded. SoFreecannot see this hold, and the wait loop ends at once.Together these explain the failure: the stop boots the VM, and the wait does not notice it holding the disk. Inferred, not checked: before #462, a stopped engine was not booted, so the disk was usually already free.
The fstrim part is fixed in #562. This stays open for the wait.
compact: wait for the disk by retrying the compaction; do not boot a …