MichaIng
TVBOX_DietPi_OdroidC4-ARMv8-Bookworm
Creating a bug report/issue
- [x] I have searched the existing open and closed issues
Required Information
- DietPi version |
cat /boot/dietpi/.version - Distro version |
echo $G_DISTRO_NAME $G_RASPBIAN - Kernel version |
Linux DietPi 6.12.34-current-meson64 #1 SMP PREEMPT Thu Jun 19 13:32:38 UTC 2025 aarch64 GNU/Linux - SBC model |
x96q S905x - Power supply used | 5V 1A
- SD card used | SanDisk ultra
Additional Information (if applicable)
- Software title | (EG: Nextcloud)
- Was the software title installed freshly or updated/migrated?
- Can this issue be replicated on a fresh installation of DietPi?
- Bug report ID |
echo $G_HW_UUID
Steps to reproduce
- ...Rootfs ext4 without journal after power loss / AdGuardHome fails to start
| [FAILED] ext3 or ext4 rootfs without journal detected │
│ │
│ ext3 and ext4 root filesystems are expected to contain a filesystem journal to protect against │
│ data loss. That it is missing is most likely the result of a failed resize script. Please │
│ collect the output of the following commands and open an issue on our GitHub repository or │
│ forum: │
│ │
│ journalctl -u dietpi-fs_partition_resize │
│ cat /var/tmp/dietpi/logs/fs_partition_resize.log │
│ │
│ GitHub: https://github.com/MichaIng/DietPi/issues │
│ Forum: https://dietpi.com/forum/c/troubleshooting/10 │
│ │
│ If you aim to solve this yourself, the resize script is located at │
│ /var/lib/dietpi/services/fs_partition_resize.sh. Alternatively, a journal can be added with │
│ "tune2fs -j $G_ROOTFS_DEV".
Last login: Sun Sep 21 17:33:12 2025 from xx.xx.xx.xx
/boot/dietpi/func/dietpi-banner: line 68: ((: == 20 : syntax error: operand expected (error token is "== 20 ")
sed: can't read /boot/dietpi.txt: No such file or directory
─────────────────────────────────────────────────────
DietPi v9.17.2 : 17:33 - Sun 09/21/25
─────────────────────────────────────────────────────
- LAN IP : xx.xx.xx.xx (eth0)
grep: /boot/dietpi.txt: No such file or directory
tune2fs: No such file or directory while trying to open
Couldn't find valid filesystem superblock.
root@DietPi:~# journalctl -u dietpi-fs_partition_resize
-- No entries --
root@DietPi:~# cat /var/tmp/dietpi/logs/fs_partition_resize.log
Removed "/etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service".
The partition table has been altered.
Disk /dev/mmcblk0: 115.63 GiB, 124151398400 bytes, 242483200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x13257074
Old situation:
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 192511 184320 90M c W95 FAT32 (LBA)
/dev/mmcblk0p2 194560 2189311 1994752 974M 83 Linux
/dev/mmcblk0p2:
New situation:
Disklabel type: dos
Disk identifier: 0x13257074
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 192511 184320 90M c W95 FAT32 (LBA)
/dev/mmcblk0p2 194560 242483199 242288640 115.5G 83 Linux
The partition table has been altered.
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 15
The filesystem on /dev/mmcblk0p2 is now 30286080 (4k) blocks long
root@DietPi:~# cat /boot/dietpi/.version
cat: /boot/dietpi/.version: No such file or directory
grep: /boot/dietpi.txt: No such file or directory tune2fs: No such file or directory while trying to open Couldn't find valid filesystem superblock.
Looks like the filesystem got corrupted so that certain files, and the tune2fs tool are not available anymore.
This is not the first boot of the system, right? I guess first run steps are done because /boot/dietpi/.install_stage is missing. And the ext4 journal is present, but the tune2fs tool to detect it is missing.
Interesting that you have a dedicated boot partition, I thought our Odroid C4 images used a single partition already in 2023 🤔. But it was downloaded from our website?
Let's check a few things:
ls -l /boot /boot/dietpi /lost+found
dmesg -l 0,1,2,3
It's not the first boot, and downloaded from your website, The problem occurred after a sudden power cut,
root@DietPi:~# ls -l /boot /boot/dietpi /lost+found
ls: cannot access '/boot/dietpi': No such file or directory
/boot:
total 2010
drwxr-xr-x 3 root root 2048 Dec 29 2024 'System Volume Information'
-rwxr-xr-x 1 root root 466 Oct 2 2023 TVBOX_SETUP.txt
-rwxr-xr-x 1 root root 2015 Oct 2 2023 aml_autoscript
-rwxr-xr-x 1 root root 1902 Oct 2 2023 aml_autoscript.txt
-rwxr-xr-x 1 root root 3967 Oct 2 2023 boot.scr
-rwxr-xr-x 1 root root 3611 Oct 2 2023 boot.scr.txt
-rwxr-xr-x 1 root root 649 Oct 2 2023 s905_autoscript
-rwxr-xr-x 1 root root 650183 Oct 2 2023 u-boot-s905x-s912
-rwxr-xr-x 1 root root 735459 Oct 2 2023 u-boot-s905x2-s922.mnj
-rwxr-xr-x 1 root root 650183 Oct 2 2023 u-boot.ext
/lost+found:
total 0
No /boot/dietpi directory at all. Also where are the kernel and the initramfs? Also theses boot configs are all not ours, are you sure our actual /boot directory is not just below this mount?
umount /boot
ls -l /boot
mount /boot
And regarding tune2fs:
which tune2fs
dpkg -l | grep e2fsprogs
ls -l /usr/sbin/tune2fs
And what do these scripts do?
cat aml_autoscript
cat boot.scr
cat s905_autoscript
cat TVBOX_SETUP.txt
root@DietPi:~# umount /boot
root@DietPi:~# ls -l /boot
total 68868
drwxr-xr-x 2 root root 4096 Oct 2 2023
BOOT_EMMC
-rw-r--r-- 1 root root 7709 Jun 20 13:29
DietPi_OpenVPN_Client.ovpn
lrwxrwxrwx 1 root root 31 Jun 24 21:29
Image -> vmlinuz-6.12.34-current-meson64
-rw-r--r-- 1 root root 5036925 Jun 22 15:46
System.map-6.12.34-current-meson64
drwxr-xr-x 2 root root 12288 Oct 2 2023
arm9xxx_dtb
-rw-r--r-- 1 root root 2923 Jun 24 21:29
boot.cmd
-rw-r--r-- 1 root root 2995 Jun 24 21:29
boot.scr
-rw-r--r-- 1 root root 270369 Jun 22 15:46
config-6.12.34-current-meson64
drwxr-xr-x 4 root root 4096 Jul 28 23:13
dietpi
-rw-r--r-- 1 root root 18092 Sep 23 2023
dietpi-LICENSE.txt
-rw-r--r-- 1 root root 16059 Sep 23 2023
dietpi-README.md
-rw------- 1 root root 3950 Sep 24 2023
dietpi-wifi.txt
-rw-r--r-- 1 root root 17477 Sep 18 13:08
dietpi.txt
-rw-r--r-- 1 root root 965 Dec 29 2024
dietpiEnv.txt
lrwxrwxrwx 1 root root 27 Jun 24 21:29
dtb -> dtb-6.12.34-current-meson64
drwxr-xr-x 3 root root 4096 Jun 24 21:26
dtb-6.12.34-current-meson64
-rw-r--r-- 1 root root 14561500 Sep 15 13:43
initrd.img-6.12.34-current-meson64
lrwxrwxrwx 1 root root 31 Sep 15 13:43
uInitrd -> uInitrd-6.12.34-current-meson64
-rw-r--r-- 1 root root 14561564 Sep 15 13:43
uInitrd-6.12.34-current-meson64
-rw-r--r-- 1 root root 35967488 Jun 22 15:46
vmlinuz-6.12.34-current-meson64
root@DietPi:~# mount /boot
root@DietPi:~# which tune2fs
/usr/sbin/tune2fs
root@DietPi:~# dpkg -l | grep e2fsprogs
ii e2fsprogs 1.47.0-2
arm64 ext2/ext3/ext4 file system utilities
root@DietPi:~# ls -l /usr/sbin/tune2fs
-rwxr-xr-x 1 root root 133456 Mar 5 2023 /usr/sbin/tune2fs
root@DietPi:~# cat aml_autoscript
cat: aml_autoscript: No such file or directory
root@DietPi:~# cat boot.scr
cat: boot.scr: No such file or directory
root@DietPi:~# cat s905_autoscript
cat: s905_autoscript: No such file or directory
root@DietPi:~# cat TVBOX_SETUP.txt
cat: TVBOX_SETUP.txt: No such file or directory
Ah sorry, regarding the scripts:
cat /boot/aml_autoscript
cat /boot/boot.scr
cat /boot/s905_autoscript
cat /boot/TVBOX_SETUP.txt
So everything is there, only that /boot mount is causing the issues, since it mounts above our scripts, configs, the kernel etc. Since it is the first partition, I guess however its boot.scr is used, which might be a dedicated issue. I guess you followed some 3rd party guide about how to make the Odroid C4 image work on that TV box, which includes some problematic steps, and surely is also responsible for that boot partition in the first place, since our images do not contain it.
Maybe that TV box does not boot with regular Odroid C4 bootloader, and maybe the 3rd party U-Boot images u-boot-s905x-s912 do not support ext4 natively, hence a FAT partition is required. But mounting that permanently to /boot breaks things. If you show me the website/source of these instruction, I can suggest a cleaner solution.
And regarding tune2fs, I was misinterpreting it: The tool is there, so no filesystem corruption or so. But due to missing /boot/dietpi, the $G_ROOTFS_DEV variable is not defined, respectively the file it would be sourced from /boot/dietpi/.hw_model was not present when that check ran, so tune2fs was called with empty device path, leading to the No such file or directory while trying to open (the block device) error.
From what I see so far, all it needs is keeping /boot unmounted. It does not contain anything needed for the final system, only the bootloader (most likely) needs it in early boot stage:
umount /boot
sed -i '/[[:blank:]]\/boot[[:blank:]]/d' /etc/fstab # so it won't get mounted from next boot on
exec bash # to reload the bash session
Okay that is great. I just wonder why that was not an issue before 🤔.
Feel free to tell me where the instructions or scripts for the TV box were from, and the content of those related scripts/configs. We might be able to enhance this for future users.
Hehe, that mobile screen output reminds me of this pull requests which aims to better handle line breaks for small screens: #5820 It there wasn't just so many other higher priority tasks.
I have never used scripts or instructions anywhere, but before the power cut I tried to make my dietpi a samba client for my dga4132, except that samba server on dga4132 is very old, and did not accept the dietpi client, and certainly I made a false maneuver, the consequences of which appeared after reboot (after the power cut), here is the whole story
I think you are using a custom version made by me. https://dietpi.com/forum/t/dietpi-img-for-amlogic-s905x-s905x3-tvbox/15976
This version is not officially supported. The first FAT partition is used to start the boot process. It should not be mounted after you log in.
First, check if /boot is mounted. umount /boot
You will get "umount: /boot: not mounted"
If boot is mounted, check /etc/fstab Add # in front of the /boot line in /etc/fstab
Add this to the startup file so that the system checks the disk every time you start the system.
echo "extraargs='fsck.mode=force fsck.repair=yes'" >> /boot/dietpiEnv.txt
Find root df / # /dev/mmcblk2p1 << ROOT DEV
Chech if root has journal dumpe2fs /dev/mmcblk2p1 | grep 'Filesystem features:' has_journal ext_attr resize_inode .....................
Reboot TVBOX
Ah right, I remember. So I understand the boot procedure of this board correctly?
- That box does not load U-Boot from SD card or eMMC, but from some onboard SPI storage?
- That U-Boot loads
aml_autoscripton FAT partitions only? -
aml_autoscriptscans the SD card, USB, and eMMC, fors905_autoscriptresp.emmc_autoscriptand loads it. But it usesfatload, which supports FAT partitions only. -
s905_autoscriptdoes the same foru-boot.ext, also usingfatload -
u-boot.extloadsboot.scrfrom the same partition?
One issue is that while /boot/boot.scr is present on the rootfs, it is not used. That might cause at least confusion, but might cause issues at some point. Maybe remove the unused boot.scr and boot.cmd to rule out that someone or even dietpi-update alters them and expects this to be effective. Btw, is that u-boot.ext so old that it does not support loading initrd.img, but only uInitrd? The only change in the boot script would be to load initrd.img last, and add the :${filesize} (load generates that variable) to the initramfs load address of the booti command.
s905_autoscript is sort of unnecessary. aml_autoscript could load u-boot.ext directly. And did you test whether u-boot.ext scans through partition and loads /boot/boot.scr from the ext4 partition, if that is the first it finds? In case there are no other issues, like that it does not support initrd.img, that would fix the potential issue above.
echo "extraargs='fsck.mode=force fsck.repair=yes'" >> /boot/dietpiEnv.txt
Uhh, do not do that, for several reasons:
- It overrides the
extraargs=that is already in the file, includingnet.ifnames=0, that way enabling "predictable" network interface names, breaking network that way. If any kernel command-line argument shall be added, append it to the exitingextraargs=line. - Quotation of values in this env file is invalid:
'here is taken literally, which makes the first arg, and the value of the 2nd arg invalid. -
fsck.repair=yesis present already in DietPi images, since last release. -
fsck.mode=forceforces a fullfsckof all drives on every boot, which can take a very long time. Can make sense for a single boot, but then I'd just create/forcefsckon the rootfs, which is removed automatically afterfsck. By default,fsckruns on rootfs and bootfs (if it exists), but skips a full scan if no dirty bit is set. This is a reasonable default, since on filesystem errors, the kernel sets the dirty bit automatically, that way triggering fullfsckon next boot on (only) the affected filesystems. - However, in this case, filesystem errors were not the issue anyway, and also the journal is present. Only the
/bootovermount broke access to scripts needed to perform the ext4 journal check correctly 😉.