Ciąg dalszy wieczorem, bo muszę sobie uruchomić lokalną konsolę (CLI), by zobaczyć co możesz zrobić stamtąd
OK.
Sprawdziłem logi na serwerze HA.
2026-07-12 15:11:40.324 WARNING (MainThread) [supervisor.docker.manifest] Failed to connect to registry docker.io: Cannot connect to host registry-1.docker.io:443 ssl:default [Timeout while contacting DNS servers]
2026-07-12 15:11:43.055 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest: Cannot connect to host registry-1.docker.io:443 ssl:default [Timeout while contacting DNS servers]
2026-07-12 15:11:43.057 INFO (MainThread) [supervisor.docker.interface] Downloading docker image homeassistant/amd64-addon-ssh with tag 10.3.0.
2026-07-12 15:11:59.034 ERROR (MainThread) [supervisor.docker.interface] Can't install homeassistant/amd64-addon-ssh:10.3.0: [500] failed to resolve reference "docker.io/homeassistant/amd64-addon-ssh:10.3.0": failed to do request: Head "https://registry-1.docker.io/v2/homeassistant/amd64-addon-ssh/manifests/10.3.0": net/http: TLS handshake timeout
2026-07-12 15:11:59.035 ERROR (MainThread) [supervisor.apps.app] Could not pull image to update app core_ssh: Can't install homeassistant/amd64-addon-ssh:10.3.0: [500] failed to resolve reference "docker.io/homeassistant/amd64-addon-ssh:10.3.0": failed to do request: Head "https://registry-1.docker.io/v2/homeassistant/amd64-addon-ssh/manifests/10.3.0": net/http: TLS handshake timeout
2026-07-12 15:17:41.930 INFO (MainThread) [supervisor.docker.interface] Downloading docker image homeassistant/amd64-addon-ssh with tag 10.3.0.
2026-07-12 15:18:41.948 ERROR (MainThread) [supervisor.docker.interface] Can't install homeassistant/amd64-addon-ssh:10.3.0: [0] failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://registry-1.docker.io/v2/homeassistant/amd64-addon-ssh/blobs/sha256:ee5421ff829260577bad760f7e54d7f07dc6be7d6cbb2857817a005d4525e5a1": net/http: TLS handshake timeout
2026-07-12 15:18:41.949 ERROR (MainThread) [supervisor.apps.app] Could not pull image to update app core_ssh: Can't install homeassistant/amd64-addon-ssh:10.3.0: [0] failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://registry-1.docker.io/v2/homeassistant/amd64-addon-ssh/blobs/sha256:ee5421ff829260577bad760f7e54d7f07dc6be7d6cbb2857817a005d4525e5a1": net/http: TLS handshake timeout
Live
Wygląda ze dodatków tez nie moge zainstlowac. Probowałem terminal/SSH zainstalować i mam błedy j.w
Masz odpowiedź w pierwszych 2 linjkach :
2026-07-12 15:11:40.324 WARNING (MainThread) [supervisor.docker.manifest] Failed to connect to registry docker.io: Cannot connect to host registry-1.docker.io:443 ssl:default [Timeout while contacting DNS servers]
2026-07-12 15:11:43.055 WARNING (MainThread) [supervisor.docker.manifest] Failed to fetch manifest: Cannot connect to host registry-1.docker.io:443 ssl:default [Timeout while contacting DNS servers]
dobra można z konsoili (CLI) okazało się że mam podpięte już wszystko.
tam masz zrobić to
-
krok
login
znak zachęty na się zmienić z>haw płotek#
jeśli już się wcześniej zalogowałeś w CLI to pomijasz ten krok -
krok
nslookup ghcr.io
i dawaj fotkę z monitora (albo przepisz znak w znak co widzisz) -
krok jak z posta @Krzyszof_K reszta wieczorem bo i tak nie mam czasu teraz (ale podejrzewam, że curl nie działa w CLI)
w każdym razie na testowej instalacji zrobiłem rollback do takiego samego zestawu core + OS z jakiego startujesz
Do tej pory wszystko mi działało. Ostatnio jedyne co to zainstalowałem tailscale .. czy to mogło coś popsuć z DNS ?
literówka!
uzupełnienie do 20 znaków
curl -Iv https://ghcr.io/v2/
i
ip route get 140.82.121.34
oraz
nslookup ghcr.io 192.168.18.1
nslookup ghcr.io 1.1.1.1
@Krzyszof_K na obrazku widać, że nazwa się rozwiązuje na IP, ale też podejrzewam DNS
(odpowiedź jest z cache, nie widzę w tym nic złego)
BTW tym rollbackiem narobiłem sobie bigosu w testowej instalacji (nie startują mi Dodatki/Aplikacje), czyli zestaw core 2026.6.2 + OS 17.3 + najprawdopodobniej aktualny na dziś Supervisor robi jakiś rozpierdziel w instalacji, więc czym prędzej wracam na wersje aktualne…
Ponieważ mi się nie chciało tyle pisać zarzuciłem pytanie do AI i podpowiedzi brzmią sensownie (ja do tego jeszcze bym dorzucił paranoiczne ustawienia firewalla, niektóre routery mają jakieś debilne wynalazki filtrujące więcej niż powinny, bądź wycięty ruch NTP i się czas rozjechał - nieudane handshake TLS, ewentualnie jakieś wynalazki filtrujące ruch DNS jak Pihole/Adguard itd.) tego co jest w punkcie 2. sam doświadczyłem parę razy, to z punktów 1. i 3. często spotykane u mało doświadczonych użytkowników (BTW dawno nie optymalizowałem sobie DNSa), w 4. uwierzyć nie mogę, ale nie wiemy co to za sprzęt tego laptopa.
niżej wklejka AI
Oto najczęstsze przyczyny oraz sposoby na rozwiązanie tego problemu:
- Awaria lub blokada serwerów DNS
Bardzo często domyślny serwer DNS przypisany przez router (np. od dostawcy internetu) nie radzi sobie z szybkim rozwiązaniem adresu serwerów kontenerów GitHub. [1, 2]
- Rozwiązanie: Zmień serwer DNS w Home Assistant na stabilny publiczny serwer (np. Cloudflare
1.1.1.1lub Google8.8.8.8). Możesz to zrobić wchodząc w: Ustawienia → System → Sieć → kliknij na IPv4 → zmień z DHCP na Statyczny i wpisz DNS ręcznie. [1, 2]
- Chwilowe przeciążenie łącza lub problem z serwerem GitHub
Serwery GitHub Container Registry (ghcr.io) mogą w danym momencie przechodzić drobne okno serwisowe lub Twoje łącze doznało chwilowego skoku opóźnień (lagów). [1, 2, 3]
- Rozwiązanie: Poczekaj 15-30 minut i spróbuj ponownie wywołać aktualizację. Bardzo często problem ustępuje samoczynnie. [1, 2]
- Problemy z IPv6
Jeśli Twój router ma częściowo lub błędnie skonfigurowany protokół IPv6, system może próbować pobierać dane przez ten protokół, co wywołuje błędy timeout. [1]
- Rozwiązanie: Wyłącz tymczasowo protokół IPv6 w Home Assistant w sekcji Ustawienia → System → Sieć. [1, 2, 3]
- Przeciążenie sprzętowe (CPU / RAM / Dysk)
Jeżeli Twój komputer (x86-64) wykonuje akurat ciężkie zadanie (np. generuje kopię zapasową lub baza danych jest przeciążona), procesor może nie nadążyć z obsługą szyfrowania pakietów sieciowych w wyznaczonym czasie. [1, 2, 3]
- Rozwiązanie: Przed kliknięciem “Aktualizuj”, zrestartuj cały system Home Assistant (Ustawienia → System → Uruchom ponownie), aby oczyścić pamięć RAM, a dopiero po uruchomieniu włącz aktualizację.
Moje polecenia nie są z czapy bo @MarWo napisał Tailscale. Ja miałem z nim jazdy u siebie w defaultowej konfiguracji a mam go na wszystkich urządzeniach. Dopiero AI pokazał mi gdzie tkwił błąd w konfiguracji.
Dlatego chce zobaczyć tu którędy idzie ruch i co z DNS.
Nie są z czapy, ale on nie ma Terminala, a w CLI dostępne polecenia są inne (Dodatek Terminala ma w swoim kontenerze binarki, które używasz, w gołym Buildroot’cie są inne).
BTW Skoro podejrzewasz Tailscale to szkoda, że o tym wcześniej nie wspomniałeś (jednak akurat u mnie wszystkie instalacje w tym testowa używają Tailscale jako drugi backup zdalnego połączenia, pierwszy backup to Zerotier, a łącze podstawowe to tunel Cloudflared i jakoś wszystko działa…)
A ta rozpierducha na tej kombinacji wydań najprawdopodobniej rozwalała u mnie DNS w Dockerze (ale szkoda mi było czasu na walkę - mimo wszystko aktualizacja core zadziałała, potem podniosłem wersję systemu).
Bo tam było wtrącenie. U mnie cały ruch szedł najpierw do Tailscale a potem wracał i dlatego miałem problemy. Ale to jest jak ustawiasz Exit Node jak dobrze pamiętam.
No i dzięki AI mam że adresacja LAN jest dostępna w Tailscale ( a defaultowo nie była ).
1 polubienie
Tak, jest tak jak piszesz, exit node może powodować taki przypał.
Wykonałem tą komendę curl na terminalu mojego Hhaos:
https://ghcr.io/v2/
Mam już terminal. Zainstalował mi się ze sklepu.
To teraz zrób aktualizację HA core (możesz ręcznie pominąć backup, bo masz świeżutki sprzed paru godzin)
a po udanej aktualizacji core zaktualizuj OSa
Jeśli sklep (Dodatki/Aplikacje) działa to aktualizacje core i OS też powinny się udać…
A komenda miała być taka
curl -Iv https://ghcr.io/v2/
a poprawna odpowiedź wygląda mniej więcej tak
~ $ curl -Iv https://ghcr.io/v2/
* Host ghcr.io:443 was resolved.
* IPv6: (none)
* IPv4: 140.82.121.34
* Trying 140.82.121.34:443...
* Connected to ghcr.io (140.82.121.34) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
* subject: CN=*.ghcr.io
* start date: Jun 12 00:00:00 2026 GMT
* expire date: Sep 9 23:59:59 2026 GMT
* subjectAltName: host "ghcr.io" matched cert's "ghcr.io"
* issuer: C=GB; O=Sectigo Limited; CN=Sectigo Public Server Authentication CA DV R36
* SSL certificate verify ok.
* Certificate level 0: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (3072/128 Bits/secBits), signed using sha384WithRSAEncryption
* Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
* Certificate level 3: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://ghcr.io/v2/
* [HTTP/2] [1] [:method: HEAD]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: ghcr.io]
* [HTTP/2] [1] [:path: /v2/]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> HEAD /v2/ HTTP/2
> Host: ghcr.io
> User-Agent: curl/8.5.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 405
HTTP/2 405
< content-type: application/json
content-type: application/json
< docker-distribution-api-version: registry/2.0
docker-distribution-api-version: registry/2.0
< strict-transport-security: max-age=63072000; includeSubDomains; preload
strict-transport-security: max-age=63072000; includeSubDomains; preload
< date: Sun, 12 Jul 2026 18:51:26 GMT
date: Sun, 12 Jul 2026 18:51:26 GMT
< content-length: 78
content-length: 78
< x-github-request-id: 3AF7:2F6246:5141AB1:533FFB4:6A53E22E
x-github-request-id: 3AF7:2F6246:5141AB1:533FFB4:6A53E22E
<
* Connection #0 to host ghcr.io left intact
1 polubienie
ip route get 140.82.121.34
To pokaże jaką masz drogę do Githuba
Nie widać całej odpowiedzi, ale jeśli ostatnia linijka wygląda tak
* Connection #0 to host ghcr.io left intact
to jest OK
teraz to już musztarda po obiedzie, ale mając taką sytuację, to jeśli działa to bym nic nie dotykał tylko robił tą aktualizację core bez zachowywania backupu (gdybym miał świeżutki), kto powiedział, że po restarcie połączenia się podniosą tak samo?
I jeszcze coś na przyszłość (choć nie na temat)
Aktualizacje Supervisora są wydawane po cichu i odbywają się w tle, jeśli Supervisor wykryje, że jest inny niż oznaczony w danym momencie jak aktualny, to zabrania wszelkich innych aktualizacji kontenerów, póki sam się nie zaktualizuje.
