Hello All,
I’m a long user of Dietpi and I’m really happy with it. However, this is the third time I face a severe issue and this time I noticed thats related with the Diet pi image.
Over the past 2 or 3 year, since I use this image, I got 2 SD cards damaged. They are locked as READ-ONLY and there is no way to unlock that. I thought that was a corrupted SD card and I replaced them without thinking too much about it.
Last month, I decided to start a fresh image but this time on a USB, this would make it more reliable. I was using a 16GB brand new USB pendrive and everything was working fine. At some point I needed to shutdown and when I turn it on again it wasn’t booting. Just the red light was on. I inserted the USB on my main PC and it was working, however, once again, as read-only. This time I was sure that was something with the image and not a SD issue. The image was running for around 1 month and the pen drive was new.
It raised me some questions:
1- I’m the only one with this issue or there are more reports about it?
2- Anything I can do to solve it? The pen and the SD are useless as it is.
3- Anything I can do to prevent it in the future?
4- Any clue about what can be happening?
I was using the following SWs:
The issue happened in a RPi2 and RPi3.
Please let me know if you need any additional details.
Thanks for your support.
Best Regards.
Hi,
many thanks for your message. Honestly I doubt there is a general issue with the RPi image. Because according DietPi statistics, RPi is the most used device type (50% and more). By design, DietPi is tuned in a way to reduce disk writes as much as possible to enlarge SD card life time.
Yes we had some reports in the past about r/o file systems. Usually they are related to faulty SD cards, data corruption or other hardware related issues. I would recommend to run a file system check on the affected device. For this, plug SD card or pend drive into another Linux box and run following
fsck -a /dev/<device_name>
How to avoid data corruption? Quite hard to say but usually following could be taken into account
- if you stop a system, never simply remove power. Always switch it of correctly using poweroff command
- use high quality SD cards
- you could think off using r/o file system and simulate r/w using an overlay FS
If you use transmission 24/7, use a real HDD (NAS HDD for 24/7 usage like WD Red) or durable SSD via docking station on USB. Neither SD cards nor USB sticks are usually made to stand long the amount of writes that e.g. video downloads produce. USB stick is better than SD card usually, but nothing beats a real drive.
Move DietPi userdata there as a whole at best do Home Assistant data and plugins are stored there as well.
When fscking the stick on an external system, you could add or do e2fsck-c /dev/sdX2 to check for bad blocks, to get more evidence that it’s really the hardware and not an issue of the image.
Ah indeed, forgot about the usage of a HDD for applications like Transmission
Hello All,
thanks for your replies.
Regarding the transmission I’m using an external HDD (WD Red) to store the contents.
About moving the ‘user data’ and ‘Home Assistant data’, are you referring to move if for the external HDD? Usually I only use the external HDD to store media contents / documents.
Is anyway to unlock the pen partition?
Thanks.
Cheers.
first check the pen drive for file system corruptions. There is a reason why the drive was set to r/o by the operating system.
Hello all,
here I share some informations. Please let me know if it’s useful or if you need anything more from my side.
The pen have 2 partitions: SDA1 and SDA2
root@DietPi:~# e2fsck -c /dev/sda1
e2fsck 1.44.5 (15-Dec-2018)
e2fsck: Read-only file system while trying to open /dev/sda1
Disk write-protected; use the -n option to do a read-only
check of the device.
root@DietPi:~# e2fsck -n /dev/sda1
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sda1
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
/dev/sda1 contains a vfat file system labelled 'boot'
root@DietPi:~# e2fsck -c /dev/sda2
e2fsck 1.44.5 (15-Dec-2018)
e2fsck: Read-only file system while trying to open /dev/sda2
Disk write-protected; use the -n option to do a read-only
check of the device.
root@DietPi:~# e2fsck -n /dev/sda2
e2fsck 1.44.5 (15-Dec-2018)
Warning: skipping journal recovery because doing a read-only filesystem check.
rootfs: clean, 202757/917472 files, 1644380/3722240 blocks
If this was the first time I would say the pen is damaged, but this its not the first time I’m not really sure.
Thanks for your support.
Best Regards,
looks like some damage on the bootFS
Take care that e2fsck is for ext4 file system only while the boot partition is FAT32. The latter needs to be checked with dosfsck (dosfstools package) or simply with fsck (which tries to select the correct tool automatically based on found file system).
In case of the second partition, please try: e2fsck -fn /dev/sda2 (force flag to check even if the fs is marked as clean)