Boot folder is empty after power failure

You could still try to fix it, but we’d need to find out why systemd-fsck is not running on reboot as it should, by checking the whole boot log:

journalctl

But if setting up the system freshly is not an issue, that could be cleaner indeed. If you have a space USB drive you can attach, you could move the rootfs to this drive (via dietpi-drive_manager) to have data on a more durable drive than a SD card.

It’s too long to post in the forum, it gives an error.

This is what it looks like in parts.

log.txt (45.1 KB)

@devifast
I collected all your logs and put them together into a log.txt, which I attached to your last post. I hope that’s fine.

Puhh quite a lot of services are failing during startup due to corrupted file system. Not sure if there is still a chance to get thinks back.

If you have another linux box…boot into that, use gparted to scan the sd card and fix errors

I find that you need it completely isolated from the OS…thus booting into another linux distro then scan the sd card for errors, this way the partitions are not mounted at all

2 Likes

Hello, I reinstalled the whole system again. I connected a battery in parallel with the power supply to avoid crashes. My next question is. How do we back up the system so that it doesn’t require a person to go onsite to restore it?

Theoretical you could connect an external USB device and do backups on it. But if you are able to restore from remote, depends on the issue you have and how worse it is. If you have significant corruption, you might even have issues to start programs to do the backup. Or file system blocks are corrupted in a way that you are not able to write them anymore. It’s not that black and white answer. Best would be your system is not power off unexpanded and you try to boot from a USB device. Something that should be possible on a Zero 2 W Raspberry Pi Documentation - Raspberry Pi Hardware

My Pi is mounted on a PCB I developed and enclosed in a DIN rail mounting box, it’s a fully developed device. I can’t turn on an additional device.
What do you think about the following line in config.txt

#dtoverlay=sdhost,overclock_50=84 #Outdated, but may still be functional
#dtparam=sd_overclock=100

If there is no need for persistent data, you could think of using r/o file system.

Out of worry, I forgot to mention that I may have forgotten to comment out these lines during system installation.

This is something new for me. Please for more detailed information.
I quickly read, this is how it should happen.
Did you mean read only?

As a starting point, have a look at this post Samba Fails on RO filesystem - #2 by Joulinar

And yes, it’s read only file system.

The idea is different. Nothing superfluous. That’s why I started using your operating system because everything was being written to RAM. There are no redundant files in the SD card. But over time the operating system grew in volume which I think for super small SBCs is not necessary. Maybe there should be a category just for such systems that are super small.
Only the essentials.
This is your motto. Greetings.

I’m not able to follow your post

This is not correct. The entire operating system is located on the SD card. Yes we aim to readuce r/w operation down to a minimum by keeping logs and temp files in tempfs but at the end, still files are written down to SD card. And on an unexpsected power loss, this could lead to corruption.

Not sure what you mean by this. There might be software updates that will increase file system usage or some user data. Where do you see the OS growing?

DietPi is already a very small and lean system, just running software that is needed to get basic functions. You could install DietPi on nearly every OS, even on RPi1

At the end it depends what user will do with it.

I’m worried about the fact that with each update the volume grows.

This one still works to overclock the SD card, but it doesn’t increase stability but might decrease it.

Which volume you are referring to? Because DietPi bash scripts are located with /boot/dietpi only and it has a size of around 2MB. Rest of the file system is used by the underlying operating system base image. And in case of your Raspberry Zero2, we use Raspberry OS.

As already stated above, we tried to remove as much as possible package from RPi OS, to reduce storage + memory consumption as much as we can. Just have a look to our comparison page. We compared plain RPi OS with the DietPi flavoured one. As you can see, we reduced number of installed packages by nearly 50%.

If there are areas growing, it might be caused by Debian package updates. Something you could easily check yourself by running apt update && apt upgrade. This will update your packages independently from dietpi-update.

Just to be precise: We do not use RPi OS and remove packages, but instead we debootstrap a new Debian image from scratch and install, along with the RPi kernel and bootloader, only a small set (compared with other distro’s common images) of packages in the first place.

apt upgrade indeed shows you how much additional or less disk space will be used after the upgrade. Apart of that there is nothing which should grow over time and is not actively triggered by yourself (software installs, dietpi-backups and such), aside of over the first month some individual dpkg backups in /var/backups.

Thanks guys, you are awesome.

1 Like

Hello again. Two days ago I got an empty /boot folder on another machine. I was able to restore with the command - fsck /dev/mmcblk0p1. Everything started, but please explain where this problem is coming from. Greetings.