I used DietPi-Drive Manager to check and fix my boot disk, which I suspected had errors. After reboot, logging in via Putty I get
-bash: /boot/dietpi/func/dietpi-globals: No such file or directory
[FAILED] DietPi-Login | Failed to load DietPi-Globals. Skipping DietPi login scripts..
And then other dietpi commands are not found.
Did I kill my boot disk? Any other options besides digging up the backup, which I suspect still has the same errors?
Hi,
can you have a look to the folder
ls -la /boot/dietpi/func/
root@DietPi:~# ls -la /boot/dietpi/func/
ls: cannot access '/boot/dietpi/func/': No such file or directory
hmm that did not look healthy. what about DietPi script directory ls -la /boot/dietpi/
root@DietPi:~# ls -la /boot/dietpi/
ls: cannot access '/boot/dietpi/': No such file or directory
Ok last check ls -la /
root@DietPi:~# ls -la /
total 84
drwxr-xr-x 22 root root 4096 Mar 5 13:06 .
drwxr-xr-x 22 root root 4096 Mar 5 13:06 ..
lrwxrwxrwx 1 root root 5 Jun 2 2020 DietPi -> /boot
drwxr-xr-x 2 root root 4096 Feb 8 08:31 bin
drwxr-xr-x 2 root root 4096 Sep 25 2019 boot
drwxr-xr-x 17 root root 3680 Mar 5 13:13 dev
drwxr-xr-x 110 root root 4096 Mar 5 12:55 etc
-rw-r--r-- 1 root root 0 Mar 5 13:06 forcefsck
drwxr-xr-x 6 root root 4096 Feb 17 17:06 home
drwxr-xr-x 17 root root 4096 Jun 2 2020 lib
drwx------ 75 root root 16384 Sep 25 2019 lost+found
drwxr-xr-x 2 root root 4096 Aug 5 2020 media
drwxr-xr-x 10 root root 4096 Oct 19 08:36 mnt
drwxr-xr-x 4 root root 4096 Sep 19 08:44 noip-renew
drwxr-xr-x 8 root root 4096 Jan 12 08:11 opt
dr-xr-xr-x 151 root root 0 Dec 31 1969 proc
drwx------ 20 root root 4096 Mar 5 13:12 root
drwxr-xr-x 27 root root 720 Mar 5 13:13 run
drwxr-xr-x 2 root root 4096 Feb 8 08:31 sbin
drwxr-xr-x 2 root root 4096 Aug 9 2020 srv
dr-xr-xr-x 12 root root 0 Dec 31 1969 sys
drwxrwxrwt 2 root root 4096 Oct 19 10:00 tmp
drwxr-xr-x 10 root root 4096 Jan 7 2020 usr
drwxr-xr-x 12 root root 4096 Oct 19 10:04 var
ok you are missing the entire DietPi script folder. But this we already know. It would be possible to download all scripts but no guarantee that this is working. There might be more thinks missing. Do you know if you already updated to v7? Or what was your last version?
I believe it was at 6.33- I was encountering issues with checksum corruption when I was trying to update previously.
did you already run a fsck on reboot:
> /forcefsck
reboot
Check the results, either with cat /run/initramfs/fsck.log or journalctl -t systemd-fsck.
root@DietPi:~# > /forcefsck
-bash: /forcefsck: Read-only file system
I’m probably doing something dumb…
not really, this just indicates that there are issues on your file system as your device has mounted it r/o. usually this only happen to protect data on a corrupted fs. Can you do a reboot and check following afterwards
dmesg -l err,crit,alert,emerg
journalctl -t systemd-fsck
root@DietPi:~# dmesg -l err,crit,alert,emerg
[ 0.438102] bcm2708_fb soc:fb: Unable to determine number of FBs. Disabling driver.
[ 5.674352] sd 1:0:0:0: [sdb] No Caching mode page found
[ 5.674358] sd 1:0:0:0: [sdb] Assuming drive cache: write through
root@DietPi:~# journalctl -t systemd-fsck
-- Logs begin at Fri 2021-03-05 13:12:57 CST, end at Fri 2021-03-05 13:46:59 CST
. --
-- No entries --
strange that the check was not executed. at least there is a forcefsck file already on your rootFS
-rw-r--r-- 1 root root 0 Mar 5 13:06 forcefsck
can you share your mounts
cat /proc/mounts
/dev/root / ext4 ro,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1899144k,nr_inodes=147012,mode=755 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup2 /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegat e 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name= systemd 0 0
none /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpu acct 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_eve nt 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,ne t_cls,net_prio 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=38,pgrp=1,timeout=0,min proto=5,maxproto=5,direct 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
If it’s not an RPi, the file system check is done within the initramfs and the results can be seen via: cat /run/initramfs/fsck.log
Although that /dev/root does indicate an RPi, is it true?
root@DietPi:~# /dev/root
-bash: /dev/root: No such file or directory
root@DietPi:~# cat /run/initramfs/fsck.log
cat: /run/initramfs/fsck.log: No such file or directory
I’m not sure what’s going on.
chucklesmcgee
Questions is what SBC you are running?
A RPi4 4GB
Since the rootfs is mounted R/O, can you try to run fsck on it?
e2fsck -f /dev/mmcblk0p2
mount -o remount,rw / doesn’t work either, does it?
Else you need to attach the SD card to another Linux system and check it there.