Boot folder is empty after power failure. I ran a system with dietpi on 05/05/2022. since then the power has gone out more than ten times, but the system was restored without a problem until yesterday. it is 100 kilometers from where I live and I will go to restore the system on site. I’m thinking of putting a battery for the alarm system in parallel with the 12V power supply. Share experience. Thanks.
in addition - the other directories are in place and nothing seems to be missing from them (like Node red ) the terminal works through Putty so I found the missing files in the boot directory .
Basic commands also don’t work (like dietpi -config, dietpi -software dietpi -backup) I haven’t tried others.
What SBC you are running? A raspberry pi or something else? Can you share following
df -h
cat /etc/fstab
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
1 Like
root@PoolPi:~# df -h
cat /etc/fstab
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 3.3G 25G 12% /
devtmpfs 207M 0 207M 0% /dev
tmpfs 239M 0 239M 0% /dev/shm
tmpfs 96M 1.6M 94M 2% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
cat: /etc/fstab: Structure needs cleaning
NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID
mmcblk0 29.2G 0 disk
|-mmcblk0p1
| vfat 128M 0 part aad71f1f-01 2565-1BA0
`-mmcblk0p2
ext4 29G 0 part / aad71f1f-02 14fcf30d-e3ea-40e7-be42-2304f593b40e
SBC is Raspberry Zero2
Looks like you have some file system corruption due to the unexpanded shutdown. This is preventing the system from mounting file systems correctly.
Try following
> /forcefsck
reboot
# then after reboot
journalctl -t systemd-fsck
1 Like
root@PoolPi:~# > /forcefsck
-bash: /forcefsck: Read-only file system
root@PoolPi:~# journalctl -t systemd-fsck
-- Journal begins at Sat 2022-08-06 18:17:03 EEST, ends at Sat 2022-08-06 18:23: 10 EEST. --
-- No entries --
root@PoolPi:~#
Ok your file system is read only. Definitely not healthy. Let’s try to mount it rw and create the check again
mount -o remount,rw /
> /forcefsck
reboot
# then after reboot
journalctl -t systemd-fsck
Perform the steps one by one to see if they are failing still
root@PoolPi:~# mount -o remount,rw /
> /forcefsck
root@PoolPi:~# reboot
root@PoolPi:~#
login as: root
root@'s password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@PoolPi:~# journalctl -t systemd-fsck
-- Journal begins at Sat 2022-08-06 18:30:31 EEST, ends at Sat 2022-08-06 18:31:32 EEST. --
-- No entries --
root@PoolPi:~#
boot part is emty
root@PoolPi:~# cd /boot
root@PoolPi:/boot# ls -la
total 8
drwxr-xr-x 2 root root 4096 Dec 15 2021 .
drwxr-xr-x 18 root root 4096 Aug 6 18:30 ..
root@PoolPi:/boot#
I guess there is still some corrections. Can you check for kernel error message
dmesg -l err,crit,alert,emerg
root@PoolPi:~# dmesg -l err,crit,alert,emerg
[ 5.124905] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #48: co mm systemd-fstab-g: iget: bad extra_isize 65535 (inode size 256)
[ 5.167070] systemd-fstab-generator[66]: Failed to open /etc/fstab: Structure needs cleaning
[ 5.204784] systemd[62]: /usr/lib/systemd/system-generators/systemd-fstab-gen erator failed with exit status 1.
[ 5.509857] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #45: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 5.511839] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #36: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 5.514291] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #47: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 5.547323] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #64: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 5.549499] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #71: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 5.549951] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #63: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 5.553528] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #65: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 5.560931] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #70: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 5.562766] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #66: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 7.409368] systemd[1]: Failed to start Remount Root and Kernel File Systems.
[ 8.044807] systemd[1]: Failed to start Apply Kernel Variables.
[ 10.864253] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #38: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 20.547054] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #72: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 20.645892] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #72: co mm systemd: iget: bad extra_isize 65535 (inode size 256)
[ 21.667202] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #62: co mm systemd-sysctl: iget: bad extra_isize 65535 (inode size 256)
[ 67.826189] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #44: co mm bash: iget: bad extra_isize 65535 (inode size 256)
[ 67.827297] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #44: co mm bash: iget: bad extra_isize 65535 (inode size 256)
[ 67.828234] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #44: co mm bash: iget: bad extra_isize 65535 (inode size 256)
[ 67.832197] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #44: co mm bash: iget: bad extra_isize 65535 (inode size 256)
[ 939.576747] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #74: co mm systemd-tmpfile: iget: bad extra_isize 65535 (inode size 256)
[ 939.620829] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #33: co mm systemd-tmpfile: iget: bad extra_isize 65535 (inode size 256)
[ 939.622001] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #33: co mm systemd-tmpfile: iget: bad extra_isize 65535 (inode size 256)
[ 939.632630] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #34: co mm systemd-tmpfile: iget: bad extra_isize 65535 (inode size 256)
[ 939.634173] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #34: co mm systemd-tmpfile: iget: bad extra_isize 65535 (inode size 256)
[ 939.634853] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #34: co mm systemd-tmpfile: iget: bad extra_isize 65535 (inode size 256)
[ 939.638416] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #35: co mm systemd-tmpfile: iget: bad extra_isize 65535 (inode size 256)
[ 939.643707] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #37: co mm systemd-tmpfile: iget: bad extra_isize 65535 (inode size 256)
[ 2455.734191] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #44: co mm bash: iget: bad extra_isize 65535 (inode size 256)
[ 2455.735358] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #44: co mm bash: iget: bad extra_isize 65535 (inode size 256)
[ 2455.745143] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #44: co mm bash: iget: bad extra_isize 65535 (inode size 256)
[ 2455.754275] EXT4-fs error (device mmcblk0p2): ext4_lookup:1785: inode #44: co mm bash: iget: bad extra_isize 65535 (inode size 256)
root@PoolPi:~#
Let’s check with @MichaIng . Usually he has good ideas for these kind of issues.
Ok, I’ve mentioned in a previous post that this OS is a favorite in my rankings and I don’t see it moving any time soon. The good thing is that everything is in the memory, I don’t know what happened, I had a system working for 182 days, but we had to turn off the power, which stopped my counting. I work in the energy industry and we have a six-month preventive maintenance, the electricity never stops here, that’s where these 182 days come from - straight laboratory conditions. The bad thing is that in practice it is not like that.
My mistake. The SBC is Zero1W.
I’m already confused, I have several working from different generations.
Please do a live fsck on the boot filesystem:
fsck /dev/mmcblk0p1
Repeat it until there are no errors reported. Then try to mount it and check the content:
mount /boot
ls -l /boot
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@PoolPi:~# fsck /dev/mmcblk0p1
fsck from util-linux 2.36.1
fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
[123?q]?
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@PoolPi:~# fsck /dev/mmcblk0p1
fsck from util-linux 2.36.1
fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
65:01/00
- Copy original to backup
- Copy backup to original
- No action
[123?q]? 2
*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
- Write changes
- Leave filesystem unchanged
[12?q]? 1
/dev/mmcblk0p1: 357 files, 103866/258077 clusters
root@PoolPi:~#
Select Copy original to backup and write changes. It doesn’t matter anyway since RPi doesn’t make use it the boot sector.
Is the boot partition then mounted successfully? And does the forcefsck file still exist?
ls -l /forcefsck
I’m wondering that there is no systemd-fsck output from the root filesystem check.
root@PoolPi:~# ls -l /forcefsck
-rw-r--r-- 1 root root 0 Aug 6 18:30 /forcefsck
root@PoolPi:~#
I don’t want to waste anyone’s time, I appreciate the quick response! Tomorrow I will reinstall it on a new SD card, I will keep the old one for analysis. Thanks for your responsiveness.