FreeWilly 1.0.15

An engine whose filesystem was damaged badly enough to stop it booting could not be checked,
because the check began by asking that engine a question. The Engine page's filesystem check now
works on that machine, and it repaired the one this was measured on.

The check refused on the disk it exists for

When the engine exited with
Wsl/Service/CreateInstance/E_UNEXPECTED. The kernel log said why: as the distribution mounted,
ext4 found a bad checksum on one block bitmap, aborted the journal and remounted read-only, and
WSL's init could not start on that root.

EXT4-fs error (device sdd): ext4_validate_block_bitmap:421: comm LaunchDistro: bg 410: bad block bitmap checksum
Aborting journal on device sdd-8.
EXT4-fs (sdd): Remounting filesystem read-only
WSL (1) ERROR: I/O error @main.cpp:2396 (MountInit)

That is the damage the filesystem check exists to find, and in 1.0.14 it stopped at its first step:

[ok  ]  stop the engine         no host was running, so nothing will put the engine back
[FAIL]  note the disk           freewilly could not say which filesystem is its root, so nothing here can tell its disk from the others attached. Run the sequence by hand

The check runs e2fsck from a temporary rescue distribution against the engine's disk, and it
picks that disk out by the UUID of its filesystem, because device names move between boots: the
same disk was /dev/sdd in one run and /dev/sde in the next. It learned the UUID by asking the
engine's distribution, and a distribution that cannot boot cannot answer.

The UUID is read out of the virtual disk

When the distribution does not answer, the check reads the UUID from ext4.vhdx on the Windows
side, following the VHDX block allocation table to the ext4 superblock. The read works while WSL
has the file open.

How the disk is picked does not change. The UUID is still matched against blkid inside the
rescue, so a bad read ends in "no attached disk carries" and never in e2fsck running against some
other distribution's disk.

The disk is attached by a launch that fails

A UUID is no use until the disk is attached, and WSL attaches a distribution's disk only when
something launches that distribution. Measured with another distribution holding the virtual
machine up: terminating the engine's stopped distribution exits 0 and attaches nothing, while a
launch that fails with E_UNEXPECTED leaves the disk attached and unmounted, and it stays attached
through the terminate.

So the check now launches the distribution once, after the rescue is holding the machine and
before the terminate. A launch that boots after all is taken down by that same terminate, so
e2fsck never meets a mounted root. The step appears in the transcript as attach the disk.

A refusal quotes WSL

Where neither the distribution nor its disk can name the filesystem, the refusal now carries what
wsl.exe said, rather than stopping at "could not say".

What it did on the machine it was measured on

The read-only check found errors confined to block group 410: 192 blocks the bitmap marked as used
that nothing used, free-block counts that no longer added up, and a bitmap whose checksum did not
match. Passes 1 to 4, which cover inodes, directories and link counts, came through clean. The
repair corrected all three:

[ok  ]  attach the disk         freewilly would not start, which still attaches its disk: ...
[ok  ]  take the engine down    freewilly terminated, so its root is unmounted
[ok  ]  find the disk           9cb04147-49e5-4515-8e3c-0ecdca70eb3f is attached as /dev/sdd
[ok  ]  repair                  errors were found and corrected

The distribution booted afterwards with its root mounted read-write and ext4 recording no errors.

Install

Download FreeWilly-Setup-1.0.15.exe and check it against SHA256SUMS.txt. Upgrading keeps the
distribution and everything in it.

An engine that will not start can be checked from the Engine page, or with FreeWilly.exe --fsck
at a prompt. The repair writes to the disk holding every image and volume, so it is offered only
after a check has shown what it found, and at a prompt it is FreeWilly.exe --fsck --repair.