/.journal left visible after ext4 journal creation

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | v10.7.2
  • Distro version | trixie
  • Kernel version | Linux dietpi4 6.18.50+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.18.50-1+rpt1 (2026-09-11) aarch64 GNU/Linux
  • Architecture | arm64
  • SBC model | RPi4/RPi3
  • Power supply used | Original 5V/1A
  • SD card used | SanDisk ultra

Additional Information (if applicable)

  • Both of my Raspberry Pi systems were freshly installed with DietPi 10.6 (August 2026) using Raspberry Pi Imager, which downloaded the DietPi image directly.

Steps to reproduce

I noticed a /.journal file on my DietPi system and, not knowing that this can be an intermediate DietPi/ext4 journal file, assumed it was filesystem corruption. I also saw some other unexpected directories in / and manually deleted them.
I am ~90% sure the other directories were actually created by a command I had run, so they may be unrelated.
I then rebooted, after which the Pi kernel panicked.

Expected behaviour

DietPi documentation/release notes indicate that recent DietPi images intentionally create the ext4 journal as /.journal after filesystem expansion and that fsck should subsequently import it into hidden inode 8. This mechanism has previously caused first-reboot issues.
Could you confirm whether the /.journal still being present on the Pi 3 is expected, or whether it indicates that the journal import/recovery process did not complete?
Both systems were installed recently from DietPi 10.6 via Raspberry Pi Imager.

Actual behaviour

During recovery, e2fsck reported:
Superblock has an invalid journal (inode 6513).
e2fsck: The journal superblock is corrupt
I restored the deleted directory entry for inode 6513:
debugfs -w -R ‘link <6513> /.journal’ /dev/sdd2
Then e2fsck successfully recovered it:
recovering journal
Moving journal from /.journal to hidden inode.
The filesystem subsequently checked cleanly and booted normally.
Interestingly, the other freshly installed DietPi 10.6 Raspberry Pi 3 still has /.journal present. I have deliberately left it untouched.

Extra details

The original inode was 128 MiB and contained a valid JBD2 journal. After successful recovery, the filesystem uses the normal hidden journal inode 8.
No apparent user data was lost.

paste lines of logs or code into such code fences here
2

maybe something @MichaIng could have a look into

3

This is expected, since our Raspberry Pi images ship without initramfs, and the journal, freshly created on first boot, cannot be imported to the internal/hidden inode 8 once the filesystem is mounted. However, it is immutable. Did you remove its immutable flag via chattr?

It can be imported to inode 8 via fsck on external systems, as you did. But practically, it does not make any difference, as long as admins do not just remove immutable files without checking back what they might be :wink:.

Which ones in particular?

4

Thanks for the explanation. I was playing with rsyslogd and probably due to a bad config, it flooded / with files and folders having names extracted from syslog. I’ve thought it was a part of some sort of journal corruption. Yes, I’ve removed the i flag before deletion. Totally forgot that I had backups. Thanks for your time and quick response @Joulinar @MichaIng .