this error now suggests something in /config/.storage/core.config_entries which is a json file isn’t correctly json formatted.
Quite weird if anything given this should be a fresh install so how is it non valid in the first place lol
It can be a long file but given what should be a fresh installation it should hardly have anything inside. Try cat /mnt/data/supervisor/homeassistant/.storage/core.config_entries in case it’s readable and not too long (need to login first)
File definitely exists . I can see the file in the .storage folder
Just tried using vi command. It appears to be blank
Let’s assume since it’s a JSON file that it should at least have {} so add literally those two in there. No space nothing else and save it
I’m not sure why this is even happening in the first place 
Seems like everything in .storage is corrupted. Not sure whether rebuild will fix that.
Can potentially take it to the extreme, remove every single file and folder within /homeassistant which should theoretically get supervisor to make a fresh HA configuration. It could be that it doesn’t but it’s not like it can get worse anyway I guess.
This is the message I have been getting from day 1 when the system boots up. Look at the 3rd line from bottom regarding the FAT and corrupted files. Usually in DOS I would do a fdsk to check and repair. I’m not sure about Linx. Do u think the files might have been stored in those potentially faulty sectors???
fsck should exist in the host shell to check actually
I’m up for it. If we don’t win, I am planning to send the system back to odroid to re-flash. Worst case scenario, they will re-flash anyways.
I’ll do it now
And then if also doesn’t do aynything deleting everything in config would take
rm /mnt/data/supervisor/homeassistant/* and
rm -r /mnt/data/supervisor/homeassistant/*
which should then leave that directory compltely empty if you do ls /mnt/data/supervisor/homeassistant
Thou i also have this in my HOST logs, im really not sure what it implies, but i’ve never had any issues indicating hardware/file-corruptions
PS: Maybe it’s just trying to umount with FAT, to check whether it’s FAT, then it goes on the EXT4 which should be the right filesystem
EDIT: thou i just checked, mine is on SDA1, which is actually FAT16(it seems)
ID_FS_LABEL: hassos-boot
ID_FS_LABEL_ENC: hassos-boot
ID_FS_TYPE: vfat
ID_FS_USAGE: filesystem
ID_FS_UUID: E252-3569
ID_FS_UUID_ENC: E252-3569
ID_FS_VERSION: FAT16
ID_MODEL: VMware_Virtual_S
ID_MODEL_ENC: VMware\x20Virtual\x20S
ID_PART_ENTRY_DISK: '8:0'
ID_PART_ENTRY_NAME: hassos-boot
I see, I may leave it alone then. I noticed fsck is not as straight forward as I’d hoped lol
I’m going to go ahead with this.
I’ll report back here.
Would definitely need to force a ha host reboot after because it won’t let you restart since everything will be missing 
When it’s back if go get back to # with login you can do docker logs hassio_supervisor --follow and you can live monitor the Supervisor logs
I have followed the Instructions. Here is the result of the last command
Here is HA core log. Two pages of red
I guess I need to wait for abit
Supervisor log says wait until Home Assistant is ready.
This should have triggered a new onboarding though
this is good. That’s the file where integration configuration lives. It’s saying the sun integration is set up which is correct as it is installed automatically in fresh installations. And also looks like a json file too. But not sure why every other dependency fails
Does still going at the IP of homeassistant on port 8123 not show onboarding?
