Thanks @abbbbbottttt good to know it’s not the power supply. Looks like an issue there with the /var/opt/emoncms partition that holds the emoncms data. I haven’t seen that before at this point with the new image so I think it’s probably best that we either send you a new SD card or if you want to get it up and running faster, I’d suggest uploading the emonSD-10Nov22 image from here: https://docs.openenergymonitor.org/emonsd/download.html.
It might be possible to fix it by running via command line:
sudo fsck.ext2 /dev/sda3
but I might be inclined to just write a new image as Id be worried about other issues that we are not seeing yet.
I’ve had some degree of success now in that I was able to write an image to the SD card. However Etcher complained that the emonSD-10Nov22 image was too big for the supplied card and wouldn’t let me use it.
I grabbed the previous image from the list and it was fine.
Is there any drawback to this alongside a Full Update, or is it worth trying to get that latest image sorted?
Why is the image tailored to a specific size of SD Card? A while ago, I succeeded in shrinking the emonSD-210721 image so that it wrote to an 8 GB SD, then expanded it to fill the card. But shrinking the image in the first place was extremely tedious, compared to a couple of keystrokes in GParted once the shrunk image was on the SD card.
The second article mentions: However, in 90% of cases, the error relates to fstab or Linux file system damage
That being said, if it’s file system damage, recovery may or may not be possible.
If it’s a problem with fstab, that’s easily fixed.
Given that others who’ve started using the Tx4 haven’t had any problems like this one,
it sounds as if the file system has been corrupted.
Because of SD Card failures due to repeated writes to the card, Trystan & Glyn determined that changing the partition format (type) made a significant difference to the life of the cards. To do this, a specific data partition was introduced. I modified the init process of the default RPi image so that the expanding of the partitions still happened on the back of the in-built process to do that.
RPiOS has changed that mechanism and Trystan has been modifying the sizes manually (I think).
This latest iteration, the OS takes up more of the root partition than before. I asked if the boot partition could be enlarged slightly to accommodate a future install of esphome. I think this may have caused the issue.
Ideally, we will try and piggyback onto the resize process that the PiOS image normally does on first boot.