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