Stuck on "bootloop" after dietpi-drive_manager set to check filesystem

Troubleshooting
1

I had an issue with some data corruption in within a docker container with no apparent reason for it, deleting and creating it again allegedly fixed that. To be sure that the issue wasn’t something spreading in my ssd, I used dietpi-drive_manager to set to check the system partition on next boot, which now I guess I shouldn’t have… atm it boots, initializes everything, checks the drive and then reboots, again and again… and does it quite efficiently while using very little power to do so I may add.

It’s a RPi 4 4 GB, latest dietpi, booting from an ssd connected to a USB3 enclosure, updated just earlier today, sorry can’t be much more specific, “it doesn’t boot” any more.

Can someone help me get out of this loop?, I’m not a very skilled linux user, but I can follow instructions fairly well.

Thanks in advance.

2

Does the USB3 enclosure has it’s own power supply? I/O errors are often associated with power supply problems.

Refering to this post Check system disk for errors - #4 by MichaIng activating the fs check means, there is a fsck file created:

[…] the /forcefsck file […] is automatically removed by systemd on boot, to be a one time action.

So I’m not sure if the fs check is creating the loop. Do you have a monitor attached and can confirm that the check is done on every reboot?
The /forcefsck file should be located in /, I think.
Are you able to hook up the SSD to another linux system to check if this file is still there? You can also run fsck from this machine for this drive.

Edit: corrected false information

1 Like
3

nope, it should be located on the root level /.

If you don’t have another linux box, you could install DietPi on a TF card and boot your system. This way we could have a look to your SSD.

1 Like
4

Not it’s a 2.5’ powered from USB directly, but I’m not even sure it was data corruption, I assumed it was based on a stack exchange lookup for the error, but I’m not a 100% sure it was.

I do have a monitor attached and I see the booting and the file check, but it’s really fast, so can’t read everything going on. My guess is that it mounts the drive as read only in order to do the check or something and then reboots without removing this file…

I suppose I’ll have to do that, because the only linux pcs I have are “retired” in a self for this low power rpi4.

Thanks to both for your help!

5

So now I managed to finally boot by deleting the file, “journalctl -t systemd-fsck” or “cat /run/initramfs/fsck.log” shows nothing, how can I be sure the drive is doing fine?, how should I go about checking the filesystem in order to avoid this happening again?

Thanks again.

6

You are the first one I have seen with this issue on constant reboots and the file not being removed.

You could boot your system using TF card and perform some file system check on the connected (not mounted) SSD.

1 Like
7

Doh!, I should have thought of that option by myself thanks a lot again for the help.