Hi Samuel, Yeag tune2fs -j must be run while the volume is unmounted.
When tune2fs is run against a live mounted instance, it modifies the superblock directly on the raw block device (/dev/wd0). However, the actively running ext2fs translator is unaware of this change and still holds the original superblock features in memory. There are code paths inside the running ext2 translator that saves the cached super block to disk which overwrites the HAS_JOURNAL flag that tune2fs just set. This results in the mismatch and the forced fsck you observed on the next boot. Because we don't currently have an RPC/ioctl mechanism for tune2fs to tell the live ext2fs translator to dynamically reload its superblock feature flags, modifying the filesystem offline (or from another boot instance) is the correct and supported approach for enabling the journal. Best, Milos On Tue, Jun 23, 2026, 6:00 PM Samuel Thibault <[email protected]> wrote: > Samuel Thibault, le mer. 24 juin 2026 02:52:23 +0200, a ecrit: > > I tried to activate the journal on the fly with > > > > tune2fs -j /dev/wd0 > > > > from the hurd VM itself, but it seems this approach fails: at reboot, we > > get: > > > > Checking root file system.../dev/wd0s2 primary superblock features > different from backup, check forced. > > > > and at reboot, journaling does not get enabled, even if /.journal > > exists. > > > > We'd need to fix that for people to be able to try journaling. > > (running tune2fs -j with the volume unmounted works, though) > > Samuel >
