If you feel so strongly about it, stop investing more of your time in it and get something else.
You’re new here so you may not know that this is not a Help Desk and is a community forum where volunteers help others at their discretion. No one is obligated to help you and the manner in which you reply determines their willingness to help you.
It’s clear you’re frustrated but please try to keep that in check otherwise it will only alienate people trying to help you.
If it’s the same error then it suggests there may be a common problem. Tell us more about your network and how the VM and Green was/is connected to it. For example, is there a VLAN present? Hard-wired or WiFi? Host machine’s IP address is reserved in DHCP or not?
Mark! Thank you very much. I should have figured that out on my own. Yes, I have an HDMI and USB keyboard. Later today I’ll hook all that up and report back what I find.
To the others who find me frustrated. Yes, I realize this entire thing is Voluntary for Everybody. But having to wait to post something and THEN only one thing at a time is extremely counterproductive. Yes, I realize you are all trying to help. I promise to calm down and accept the limitations of the forum. Please don’t give up on me, and in return I will not give up on the HA Green.
I am going to hook up an HDMI and keyboard to this thing later today (06132024) at the suggestion of MaxK Mark.
To Taras: I have no VLAN. It’s Hard wired. I attached another screenshot of my network. I have DHCP reserved from 201 on up to 250. 139 and 140 reserved for my Cloud Devices. 199 reserved for Printer. HA is (Currently) 227. I really do not know what else to tell you…but don’t give up on me! Yes, you are appreciated.
John
Thanks for fixing your keyboard’s CAPS LOCK key. 
Network-wise it all sounds good so we’ll have to wait until you can login via the console and perform some tests to see how it behaves.
BTW, I can empathize with your frustration; it normally should be fairly frictionless. As for the forum’s hurdles, those are meant to thwart potential spammers and bots.
OK! FIXED! Taras, forgive my CAPS.
Here is what it took to fix. Nothing in any documentation I could find points to this as conceivably being a problem.
From the “ha network info”, nothing in that was any help whatsoever. So, I decided I would read the log file line by line and enter every URL until I found (1 or more) that was stuck. Nope. Not there, either. They all worked in a PC or Phone.
So I got to thinking, what is the difference between this Home Assistant and a PC/Phone. As you remember, when I had HA running on a virtual machine, linux, debian, or anything for that matter, I had the same Glitch. So, what is it…
AHA! As a standalone “Internet of Thing”, or running in a VM, it is completely dependant on a separate DNS setting. My DNS of the ‘Internet of Things’ was 64.250.224.2 And that DNS server does not like github, or something there. I changed the DNS to 8.8.8.8 and 8.8.4.4 for the ‘IOT’ stuff, lo and behold, success!
Who gave me 64.250.224.2? My Microwave Relay Internet Provider.
Of course, I will now go back and check all my other IOT stuff, like the Autel EVSE (car charger), the Garage Door Opener, the Goodman HVAC unit, the Sol-Ark Inverter, the Laser Printer, and a few other gadgets.
Yep, the Inverter sent me a text saying it was offline. Had to reboot it (3 minute power failure…) oh well, small price to pay, eh?
I also just tried my VM based HA, it works also.
So, thanks to all of you for trying.
If it were me, I would add to the instructions a list of URL’s that must be alive for Home Assistant to work. In my 72 years of life, I have never had a PC, phone, gadget, software, vacuum cleaner, or anything that Self-Updated through github. I also have sent an email to Las Vegas.net telling them to set up their DNS for github, for those IOT devices that need github.
I had never really though about it. Browsers almost always have their own DNS settings. Which is why you can download something from github and update your IOT. But if an IOT is directly trying to github, your ‘overall’ DNS settings have to jive.
Any final thoughts by the interested parties will be looked at! And yes, I will keep the Green Box, even though I could run HA on my media server, no issue (now)
Thanks again, all.
John
alas, this install issue is not uncommon. see this:
might be worth adding this to community guides.
So, lv.net redirects to isp.net and claim:
They are missing the sentence about ‘unless you need a real DNS Server.’
Sorry, Jeffcrum, but that statement you made about a real DNS server is misleading.
https://www.quora.com/Does-the-DNS-server-Im-connected-to-contain-all-the-names-in-the-internet#:~:text=No%2C%20a%20purely%20authoritative%20DNS,not%20authoritatively)%20about%20other%20domains.
A DNS that knows EVERY IP address does NOT EXIST. But they know ‘of a guy’ who ‘knows a guy’
This home assistant is the first and only IOT gadget I have ever seen that needs a Github connection. Yes, I have heard today from other sources that HA has been using Github. But that does that mean that every human knows that HA Must Have Github? So there are guaranteed to exist DNS that can’t resolve the HA IOT. I see that I’m not the only person who had to change their DNS server to get HA to work. Armedad had the same thing, exactly.
I just hope that the powers to be writing documentation for HA will include this information. Also note, GitHub suffers from over 100K infected repositories. This has to affect a DNS decision to include them. I am not by any means a ‘security expert’, but in 1981 I was hired to attempt a hack on Kinney Shoe Stores point of sale systems. They allegedly had the highest security available at the time. I was able to ‘get in’ in 15 minutes. Yes, a lot has changed since then, like a new severe breach reported every week. I see that the HA section at Github does indeed have ‘security’. So did Goodman HVAC systems, but they got hacked anyway. Needless to say, they don’t store anything there anymore.
By the way, I would be interested in knowing if ANY other device out there that is ONLINE is dependent on GitHub. Not one that you download from Github and update ‘offline’ Most everybody’s browser already has DNS settings that allow Github. But I can also guarantee you that NOT EVERYBODY’s DNS settings are setup for an IOT to get to Github. OR: The device is not depending on DNS, but an actual IP address, where DNS is not necessary.
John
There is another fix for this HA to Github issue. Edit your ‘HOSTS’ file to include the mapping to the Github repository. That way, the DNS would not matter in the least.
I would be really grateful if someone tells me that info, I’ll edit my hosts file
Copyright (c) 1993-2009 Microsoft Corp.
This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
This file contains the mappings of IP addresses to host names. Each
entry should be kept on an individual line. The IP address should
be placed in the first column followed by the corresponding host name.
The IP address and the host name should be separated by at least one
space.
Additionally, comments (such as these) may be inserted on individual
lines or following the machine name denoted by a ‘#’ symbol.
For example:
102.54.94.97 rhino.acme.com # source server
38.25.63.10 x.acme.com # x client host
localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
::1 localhost
John,
Thanks for replying to my comment. Because this is interesting to me.
I do not believe my statement was misleading.
Yes, the design of DNS servers (both authoritative and recursive) is what you have described. Authoritative servers own the IP address. Recursive dig into other servers (both authoritative and recursive) to get an address they do not own.
But DNS servers can be set with filters to ignore DNS names.
The fact that your next post about HOSTS files working proves this out. Your ISP is not blocking IPs. Your ISP’s DNS server is ignoring calls for Github. This is your ISP trying to prevent development type of functions from their clients.
You keep saying IOT gadgets have never needed Github is an assumption. If you have had IOT devices on other ISPs, they may have certainly made calls to Github that were not blocked by that ISP and just ‘worked’.
I doubt that most IOT devices are coded with IP addresses and generally need DNS.
So, again, I believe your ISP is blocking IOT devices that take updates by blocking Gibhub.
Of course, this is my opinion. That is kind of proved out by your DNS change.
Also, please select a post above as a solution. My opinion is that one of @123 's posts qualify.
Jeff
ISP breaks internet.
User blames Home Assistant.
This is news?
In point of fact @mobile.andrew.jones found the problem in post 4 of the thread when he said
Anyway good to know another thing to add to the troubleshooting toolbox, broken ISP DNS. Hope the rest of your ha journey goes smoother.
Just post this here: https://isitdns.com/
Thanks for taking the time to note down what it ended up being. It is on my todo list to improve the out-of-the-box experience in face of, let’s say, “not ideal” DNS environments 
Agners, there are posts all over the forum like this. It seems a common-ish problem. Some are admittedly to do with supervised installs, but not all.
Good to see O’Reilly is still about.
Maybe if ISPs are suggesting broken DNS servers, we need to go back to hosts files LOL.
Possibly a malware filter that is too agressive.
I know, but few have a good analyzes why the ISP provided DNS really failed.
To me it is a bit surprising that ISP DNS are really that messy, especially in the western world. But well, it is a wild wild west out there in the Internet 
I wonder if it’s worth the supervisor using a hardcoded known working DNS like 8.8.8.8 until it’s passed the landing page, and then using whatever the router provided once the system is up and running? @agners
It’s really not that uncommon, especially in rural areas with limited internet access. My parents internet provider is some random ass company and they have a really weird setup. I had to jump through hoops to get HA working with an out of the box configuration.
On Supervisor level we have CoreDNS as resolver which is used by Home Assistant Core, add-ons etc. CoreDNS has a fallback to Cloudflare.
On OS level, and that is what Docker uses and what failed in this case, we do have the fallback to Cloudflare too. However, the fallback mechanics in systemd-resolved are a bit different: From what I understand, if the DNS Server gives a response, it does not fallback. In a way this is the correct behavior, as it is privacy preserving. Unfortunately, I think that is exactly what many people run into.
One option would be to introduce a more forgiving fallback, but it comes at a cost privacy wise.
Ideally, I’d also have the same policy on OS and Supervisor level. But its all non-trivial, and I am worried that changing things too much around breaks setups which work today 
I was disheartened when /etc/resolv.conf became something that other processes took charge of.
Right, but operating on the principle that
a) we know the site must exist, so any response from the DNS server suggesting it doesn’t - should trigger a fallback DNS.
b) if the image is getting a 404, then we should fallback to a known working DNS.
It’s not really a problem with privacy, because it’s just to get us a working core. Once the supervisor says the system is healthy - it has the ability to reset the DNS of the actual host right?
if I was a betting man - I’d gamble on this being a very long running linux problem about sites that have IPv4 and IPv6 records. If the IPv6 address can’t be reached for some reason, it often fails to fallback to the IPv4 address.