howto check disk

Hi

battling with a new Odroid N2+, which is constantly rebooting in the middle of dietpi-backup/sync to an external usb-ssd I question myself if the filesystem is not in risk of being corrupted.

If it is, is there a warning somewhere? And how can I check/fix it. I mean the main OS drive.

Thx in advance

Welcome over here manilx :slight_smile:. So it’s still not stable? :frowning:

There is an option in dietpi-drive_manager to have the root file system scanned on next reboot. But you can do it manually:

> /forcefsck
reboot

Probably you can use the new max_freq_a73 and max_freq_a53 settings in /boot/boot.ini to downclock the CPUs by one step and see if that helps. Should not be required, but if it is, maybe you got bad hardware and have chance for a replacement by Hardkernel.

Yes, nothing but problems.

I will try your suggestion but I think this board has issues.
Problem is that sending it back for replacement is a hassle out of Portugal. I have paid high duty taxes for import. In the end the board has cost me almost double retail.
And to send it back I need to apply for export permit or I risk paying again…

P.S. On the Odroid they well try me to switch sides and leave dietpi… No bloody way!

Changing clock speed doesn’t seem to work or I’m doing something wrong:

I changed boot.ini to this:

# Max CPU frequency for big A73 cores in MHz
# - Valid values on Odroid N2: 500, 667, 1000, 1200, 1398, 1512, 1608, 1704, 1800 (default), 1908, 2004
# - Valid values on Odroid N2+: 500, 667, 1000, 1200, 1398, 1512, 1608, 1704, 1800, 1908, 2016, 2100, 2208 (default), 2304, 2400
setenv max_freq_a73 "2100"

# Max CPU frequency for small A53 cores in MHz
# - Valid values on Odroid N2: 100, 250, 500, 667, 1000, 1200, 1398, 1512, 1608, 1704, 1896 (default), 1992
# - Valid values on Odroid N2+: 500, 667, 1000, 1200, 1398, 1512, 1608, 1704, 1800, 1908 (default), 2016
setenv max_freq_a53 "1800"

But doesn’t seem to have any effect. Still the defaults:

DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     aarch64
 Temperature  |     31'C : 87'F (Cool runnings)
 Governor     |     schedutil

                 Current Freq    Min Freq   Max Freq
 CPU0         |      1800 MHz      500 MHz    1908 MHz
 CPU1         |      1800 MHz      500 MHz    1908 MHz
 CPU2         |      1000 MHz      500 MHz    2208 MHz
 CPU3         |      1000 MHz      500 MHz    2208 MHz
 CPU4         |      1000 MHz      500 MHz    2208 MHz
 CPU5         |      1000 MHz      500 MHz    2208 MHz

Board will be returned today for replacement.
Let’s see if a new one doesn’t have these abnormal issues, otherwise it would be a deeper issue related to SW.

I’ll let you know!

Tried to run this on the pie4 (also via dietpi-drive_manager):
I get this:

What do you mean with “tried to run on”?

I meant to attach the SD card as external drive to another system, if it’s an RPi then via USB SD card adapter/reader or so, ah or as internal SD card as well when you boot the RPi from USB. Best boot the Pi 4 first, then attach the SD card, to avoid any invalid boot attempts.

If on the Odroid N2 the CPU frequencies have no effect, that’s likely an issue with the /boot/boot.ini. I’ll review it. Note that I cannot test it :wink:.

Doing this on my running pie4:
I wanted to check the fs of the boot drive, i.e. the usb I’m running the pie from…
“There is an option in dietpi-drive_manager to have the root file system scanned on next reboot.”
This is what I understand of this description… If I only have one pie I have to check the fs on itself.

Ah yeah sorry for my confusion:

  • If you have no other Linux system, you need to scan the root filesystem on reboot via dietpi-drive_manager option or by simply running > /forcefsck from console, then reboot. Result can be checked via cat /run/initramfs/fsck.log.
  • If you have another Linux system where you can attach the SD card as external drive to, that’s the better option as you can fsck and in case repair it interactively there. But I’d do that effort only when you’re sure that the filesystem is corrupted, e.g. when scan on reboot found errors but you still face I/O issues/errors.

This is exactly what I have done. And the result is in the screenshot, which I don’t quite understand.

Okay. It fails to mount the /boot partition, which is strange indeed. However, pressing Ctrl+D should allow you to continue boot. Let’s see if you’re about to mount the boot partition then: mount /boot
And of course to check the result of the fsck.

^D continues to boot to the normal login prompt.

root@PlexServer:~# cat /run/initramfs/fsck.log
cat: /run/initramfs/fsck.log: No such file or directory
root@PlexServer:~# journalctl -t systemd-fsck
– Logs begin at Thu 2019-02-14 10:11:58 WET, end at Fri 2021-03-12 16:42:48 WET. –
Mar 12 16:39:02 PlexServer systemd-fsck[128]: Please pass ‘fsck.mode=force’ on the kernel command line rather than creating /forcefsck on the root file system
.
Mar 12 16:39:02 PlexServer systemd-fsck[128]: e2fsck 1.44.5 (15-Dec-2018)
Mar 12 16:39:02 PlexServer systemd-fsck[128]: Pass 1: Checking inodes, blocks, and sizes
Mar 12 16:39:52 PlexServer systemd-fsck[128]: Pass 2: Checking directory structure
Mar 12 16:40:41 PlexServer systemd-fsck[128]: fsck: Warning… fsck.ext4 for device /dev/sda2 exited with signal 13.
Mar 12 16:40:41 PlexServer systemd-fsck[128]: fsck failed with exit status 8.
Mar 12 16:40:41 PlexServer systemd-fsck[128]: Ignoring error.
Mar 12 16:40:43 PlexServer systemd-fsck[324]: Please pass ‘fsck.mode=force’ on the kernel command line rather than creating /forcefsck on the root file system
.
Mar 12 16:40:44 PlexServer systemd-fsck[324]: fsck.fat 4.1 (2017-01-24)
Mar 12 16:40:44 PlexServer systemd-fsck[324]: /dev/sda1: 412 files, 106001/516190 clusters

It looks like the fstab entries are wrong. Can you paste:

cat /etc/fstab
grep UUID /boot/boot.ini
lsblk -npo NAME,UUID,PARTUUID,MOUNTPOINT

root@PlexServer:~# cat /etc/fstab

You can use “dietpi-drive_manager” to setup mounts.

NB: It overwrites and re-creates physical drive mount entries on use.

#----------------------------------------------------------------

NETWORK

#----------------------------------------------------------------
//192.168.2.50/Video /mnt/qnap cifs username=,password=,iocharset=utf8,uid=dietpi,gid=dietpi,file_mode=0770,dir_mode=0770,vers=3.1.1,nofail,noauto,x-systemd.automount

#----------------------------------------------------------------

TMPFS

#----------------------------------------------------------------
tmpfs /tmp tmpfs size=1938M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid,mode=1777

#----------------------------------------------------------------

MISC: ecryptfs, vboxsf (VirtualBox shared folder), gluster, bind mounts

#----------------------------------------------------------------


#----------------------------------------------------------------

SWAPFILE

#----------------------------------------------------------------


#----------------------------------------------------------------

PHYSICAL DRIVES

#----------------------------------------------------------------
PARTUUID=e8af6eb2-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=e8af6eb2-01 /boot vfat noatime,lazytime,rw 0 2
root@PlexServer:~# grep UUID /boot/boot.ini
grep: /boot/boot.ini: No such file or directory
root@PlexServer:~# lsblk -npo NAME,UUID,PARTUUID,MOUNTPOINT
/dev/sda
├─/dev/sda1 DC3E-E470 e8af6eb2-01 /boot
└─/dev/sda2 a7adb26a-8b87-4729-99c8-9f5ac069d51e e8af6eb2-02 /
root@PlexServer:~#

I’m still confused. Is this now an Odroid N2 or a Raspberry Pi 4?

Odroids by default use UUIDs and not the PARTUUIDs (the shorter ones present in our fstab) and of course must have /boot/boot.ini to be able to boot. However, the PARTUUIDs are correct.

If I remember right, on RPi 4, this mount on boot errors happen in combination with UAS, which is enabled by default on RPi 4 but not well compatible with all drives. Can you try to blacklist it:

echo 'blacklist uas' > /etc/modprobe.d/disable-uas.conf

I’m on my Pie4 now! Odroid has gone back to factory… Sorry about the confusion! Has been a complicated few days…

I wanted to do a fs check on the pie…


Anyway run the command you provided. Initiated the fs again.
Same problem as before. ^D continues boot.

root@PlexServer:~# journalctl -t systemd-fsck
– Logs begin at Thu 2019-02-14 10:11:58 WET, end at Fri 2021-03-12 17:38:48 WET. –
Mar 12 17:36:40 PlexServer systemd-fsck[130]: Please pass ‘fsck.mode=force’ on the kernel command line rather than creating /forcefsck on the root file system
.
Mar 12 17:36:40 PlexServer systemd-fsck[130]: e2fsck 1.44.5 (15-Dec-2018)
Mar 12 17:36:40 PlexServer systemd-fsck[130]: Pass 1: Checking inodes, blocks, and sizes
Mar 12 17:37:30 PlexServer systemd-fsck[130]: Pass 2: Checking directory structure
Mar 12 17:38:19 PlexServer systemd-fsck[130]: fsck: Warning… fsck.ext4 for device /dev/sda2 exited with signal 13.
Mar 12 17:38:19 PlexServer systemd-fsck[130]: fsck failed with exit status 8.
Mar 12 17:38:19 PlexServer systemd-fsck[130]: Ignoring error.
Mar 12 17:38:22 PlexServer systemd-fsck[327]: Please pass ‘fsck.mode=force’ on the kernel command line rather than creating /forcefsck on the root file system
.
Mar 12 17:38:22 PlexServer systemd-fsck[327]: fsck.fat 4.1 (2017-01-24)
Mar 12 17:38:22 PlexServer systemd-fsck[327]: /dev/sda1: 412 files, 106001/516190 clusters

https://manpages.debian.org/buster/e2fsprogs/e2fsck.8.en.html#EXIT_CODE
Edit code 8 == Operational error
But I have no idea what the signal 13 means. Cannot find something about it. It could be exit codes 8 + 4 + 1, but that would be the exit code itself.

However, do you actually face any issues on that RPi, or does dmesg -l emerg,altert,crit,err report any file system errors? Otherwise I’d leave it as is an check that partition on an external Linux system, e.g. when the Odroid is back there, or when you find time to spin up a VM, which is quite easy with out images :wink:.

No critical error. I just wanted to check because I had a few powercycles withoit previous shutdown during the odroid mess…


I have a dietpi VM lying around…

So I connect that drive to it (has 2 partitions) mount it with dietpi-drive_manager, run a check on it and then unmount it. Is that it?

It does not need to be mounted, the “Check & Repair” option should be shown when it’s still unmounted. A dry run is done first, so you can see found errors before anything is touched.