Updating to 110 and the Config Check add-on

I ran Config Check again and it went to the end (with no error found! - yay!) but the below comments about the version discrepancy and spelling mistakes are still valid.

It also doesn’t explain why it failed the first time although I notice that those two ‘missing’ files seem to appear and disappear ‘at random’ so maybe the add-on needs to account for this?

Anyway, I’m all good, I just thought this info might be interesting to someone?

(And yes, I could create an issue on GitHub, and will if these are genuine issues)

So, I decided today was the day.
v110 seems to have had more problems than normal but at some stage I have to bite the bullet.

I ran the Config Check but it seems to fail because I have two missing files…

Note two extra things:

  • The spelling mistakes in the log, or does ‘stat’ mean something in Linux-speak?
cp: can't stat '/config/home-assistant_v2.db-wal': No such file or directory
cp: can't stat '/config/home-assistant_v2.db-shm': No such file or directory
  • The discrepancy between the installed version, 3.3.0 and version reported in the log 3.2.9)

starting version 3.2.9

Any idea what I should do?
Upgrade to 110 or not?

Full log

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] udev.sh: executing... 
starting version 3.2.9
[12:20:59] INFO: Update udev information
[cont-init.d] udev.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[12:20:59] INFO: Setup udev devices

[12:20:59] INFO: Don't worry, this temporary installation is not overwriting your current one.
[12:20:59] INFO: Installing Home Assistant: latest...
[12:20:59] INFO: Please be patient, this might take a few minutes...
[12:21:21] INFO: Installed Home Assistant 0.110.3
[12:21:21] INFO: Making a copy of your configuration for checking...
cp: can't stat '/config/home-assistant_v2.db-wal': No such file or directory
cp: can't stat '/config/home-assistant_v2.db-shm': No such file or directory
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

I’m a little hesitant to reply since I only use “Home Assistant Core”, and I no longer use SQLite, but from when I did use the default database, I recall those are indeed temporary files that come and go as database maintenance takes place. So, yeah, it would seem, at a minimum, the “Home Assistant” or “Home Assistant Supervisor” or whatever-it’s-called-nowadays, should somehow take that into account.

But what it probably really means is, you should have changed to another database, such as MariaDB, long ago. :stuck_out_tongue_winking_eye:

EDIT: Or, at the very least, do what the recorder docs suggest (see the Note at the top) and move the database elsewhere (e.g., somewhere other than in the config folder, even if it’s on the same system.) See here where it shows how to specify the path to the database (the first line of which is for SQLite.)


Yeah I just did that finally myself.

History things do seem to be a bit faster.

If @klogg needs any help I can tell you how I did it but I’m not sure what install you run - I run Core in docker - so…“Container” ? :confused:

Ha! Ha!
You read my mind. I was going to ask exactly that but thought it would sound a little too much like I wanted my hand held so I read the docs (again) and… got a little worried that messing at that level could cause me more problems than I would solve.

Then by chance I found this and chickened out altogether. (EDIT: not entirely related but another annoyance caused by the DB)

All that despite the fact that I’ve been thinking independently about moving to MariaDB for many months :blush:

So, yes! Please tell me how as though I was 5.
I really should do this :wink:

You don’t mention which install you are running.

I know I’ve probably seen it elsewhere I just don’t remember.

Oh sorry, (it was probably sub-conscious desire to not have to think about it!)
I used kanga’s guide for Ubuntu so “Home Assistant Supervised” :thinking:

Yep, that’s it…

Not a problem.

i’m going to assume that you have the ability to add containers to your docker environment.

Here is the docker command I used:

$ sudo docker run -itd  --name=mariadb -e PUID=1000 -e PGID=1000 -e MYSQL_ROOT_PASSWORD=<CREATE_ROOT_PASSWORD> -e TZ=America/New York -e MYSQL_DATABASE=homeassistant -e MYSQL_USER=<CREATE_USER> -e MYSQL_PASSWORD=<CREATE_PASSWORD> -p 3306:3306 -v /home/finity/docker/mariadb/config:/config --restart unless-stopped linuxserver/mariadb

You will need to verify your PUID & PGID but most of the time it should as above for a single user machine.

Also you will need to change the path to the persistent volume binding for the config directory.

As far as the two passwords I made them the same for ease of use in the HA config. I’m not really sure what the differences are or exactly which one to use there. If they are both the same then it doesn’t matter.

Then in your HA config you need to change the recorder integration to use the mariadb database you created above (“homeassistant” - which you can change if you want).

Here is the only line you will need to add to the recorder config:

  db_url: mysql://<USER>:<PASSWORD>@<IP_OF_YOUR_HOST>/homeassistant?charset=utf8

once you restart HA then it should immediately start using the mariadb location.

You can verify this by noting that the file info for “changed” for the “home-assistant_V2.db” file stops changing after you restart HA and the mariadb is used.

You can also verify it’s working by opening up your history and you should see very little data in there since you just started writing data.

And that brings up another point to be aware of - you will lose access to you old data from within HA. It will be just like you deleted the old db from HA and restarted from scratch (because you kind of are). It wasn’t a big deal to me tho.

Once it’s all running then you should be able to just delete your old db from your HA config directory. I haven’t yet so I can’t say that for sure but I don’t see why it would cause issues since it’s not being used any more.

I’m pretty sure that’s it. It was fairly straight forward using docker for things.