Hello Chris, sorry to hear this. How is the emonBase powered? is it plugged into the emonVs or a separate power supply elsewhere? I wonder if there’s a power issue causing it to not startup properly?
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.
There is a high probability you did not wait long enough from first boot.
It does take quite a while, and you do start to think it has failed. Power it on, make a cuppa, do some other jobs and then come back. It will have probably finished all it’s bits by then!
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.
What colour is the SD card. As far as Im aware all of our SD cards are now 32GB and so if you have a 16GB card it means we’ve sent you one in error… and we will send you a replacement.