Correct, however, the project is driven by mainly open source contributors (developers mainly) that do this in their spare time. Which makes the part of documentation harder.
The project has grown at a rate in which some things could not be anticipated on, like the thing we are discussing now.
Everybody can edit the documentation, even if you are not a developer.
PS: I’m getting really off topic here 
tried updating my HassOS 2.12 , running esxi server
when i click update button i receive this error : Error: 500 Internal Server Error Server got itself in trouble
how to troubleshoot?
this 
19-12-18 08:22:37 INFO (MainThread) [hassio.utils.gdbus] Start dbus monitor on de.pengutronix.rauc
19-12-18 08:22:37 INFO (MainThread) [hassio.utils.gdbus] Stop dbus monitor on de.pengutronix.rauc
19-12-18 08:22:37 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 418, in start
resp = await task
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_app.py", line 458, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.7/site-packages/aiohttp/web_middlewares.py", line 119, in impl
return await handler(request)
File "/usr/src/hassio/hassio/api/security.py", line 147, in token_validation
return await handler(request)
File "/usr/src/hassio/hassio/api/utils.py", line 39, in wrap_api
answer = await method(api, *args, **kwargs)
File "/usr/src/hassio/hassio/api/hassos.py", line 44, in update
await asyncio.shield(self.sys_hassos.update(version))
File "/usr/src/hassio/hassio/hassos.py", line 177, in update
rauc_status = await self.sys_dbus.get_properties()
AttributeError: 'DBusManager' object has no attribute 'get_properties'
seems my timezone is not correct, i always have that when doing a cold boot, they its on ETA zone, instead of ETA +1, gonna do a restart HA (service), then time is correct, maybe thats the trick
HassOS runs on UTC, it seems correct to me.
About your issue, that is being tracked here:
Perhaps split these out.
This is not a critisism of the project or of you, I just think that it would be of benefit to push it to the top of the ToDo pile and I’m happy to help review, but it would be wrong of me to be the source of the content (I don’t fully understand it)!
its updated now , when i do restart after a cold boot, timezone is correct for me
now tried updating again and succeeded, running 3.7 now
I know! I hope I didn’t come across that way. I recognize the problem and agree.
The top of the todo pile is syncing integration documentation with the source code & revisiting website structure. Both of those are thing I am assigned to work soon.
Great, if you get there and want some review or thoughts from the outside let me know.
Uh no?
I don’t get where the fuzz is from. You can install Hass.io on any system. I’m running Hass.io. I run Hass.io on Ubuntu. Some run Hass.io on HassOS, others prefer running Hass.io on Arch Linux.
You don’t say: I run Google Chrome on a generic Linux install as well, right? In my case, I’m running Google Chrome on MacOS.
I do believe that the name HassOS, even though there’s a big “OS” in the name implying that it’s the operating system, confuses people. No one ever questioned what ResinOS was when it was the base for Hassio installations on RPis.
Referring to Hassio as the “whole environment” seems to help, but it’s a daily struggle. People think Hassio is one docker container. People think Hassio has the UI editors and that a traditional Home Assistant install does not. People think that following a video tutorial on “how to install Hassio in docker” makes them docker users who now need to use compose and portainer because that’s what all the users in the docker channel in discord talk about.
I think using the correct terminology goes a long way and I’ll keep battling the phrase “Hassio in docker” because from what I’ve seen it’s always going to cause more conflict and confusion than letting it go.
I’ve also tried a dozen variations of diagrams to help users understand. I don’t know if it actually helps, but here’s another:
When people say hassio in docker they usually say it that way to differentiate from running HassOS. It does actually matter sometimes differentiating because a debian/docker/hassio install is different to HassOS when you are talking access to the host for example. Particularly when you have to install the base OS then docker then hassio… why wouldn’t a user refer to that as Hassio in docker? Of course all hassio implies docker but it’s a semantic differentiation to using HassOS where the docker is hidden.
The volunteer work to bring this update to life is just considerable.
The announcement of this topic is just great news, it should mainly generate enthusiasm!
A huge thank you to all contributors who got involved this update !
I am kind of disappointed / sad to see this topic drowned by complaints about an insufficiently clear sentence or insufficiently explicit documentation on the different types of installation.
Main contributors deserve congratulations, it is one of the engines of the motivation to continue to invest and share their personal time and skills for community.
Even if the subject may deserve to be discussed, it is the HassOS 3 released! Raspberry Pi 4 support announcement, isn’t that annoying debate off topic here ?
If this point tickles some of you, could you please create a new topic for it.
Sorry in advance for this noob question.
What are the steps to make to switch from sd-card to a SSD hard disk.
Right now I have a Rpi 3+ running the latest versions:
Many thanks in advance for any help to take the right steps to make.
nice diagram indeed, and clarifies a lot.
If I were allowed 1 suggestion:
In the top bar you state at the end: ‘This can be a pi, a pc, or VM.’
Which might lead to the conclusion ‘Your Operating System’ is (because of the phrase ‘This can be’) a device.
If you’d change that line in: This (operating system) is device (in)dependent, and can even run on a VM.
The device-layer has been left out of your diagram, and does deserve its own place, it’s what confuses many…
Seeing as Supervisor, Home Assistant and DNS are mandatory always present containers maybe I would list them on a seperate row as all others are optional?
It’s the same process but you flash the SSD instead of an SD. On a 3b+ you don’t have to change anything other than use the right hardware. This table has some known working combinations of usb sata adapters and ssd drives. It doesn’t mean others won’t work. I grabbed some random drive and adapter which were not on the list and they worked fine, but there is a chance some hardware won’t.
Thanks!!
I just ordered this:
Kingston A400 120GB SSD (SA400S37)–|--Startech USB3-SATA3 adapter (USB312SAT3CB).
What about this?:
" USB Boot
USB mass storage boot is available on Raspberry Pi 3B, 3B+, 3A+, and 2B v1.2. To enable USB boot, add program_usb_boot_mode=1 into config.txt . Note that this permanently alters the one-time programmable memory of the device."
Do I still have to do this, when?
On a 3b+, you do not. You can physically switch from SD to USB + SSD whenever you want, one or the other.
