Nie, ale w takim razie jest prawdopodobne jeszcze gorzej, bo to np. może być problem z kompatybilnością obudowy dysku, a właściwie mostka USB do sata (czy nvme?) z pre-bootloaderem RPi3, ale póki jestem w trasie to nie pomogę - przede wszystkim trzeba sprawdzić kompatybilność lub inną przyczynę która nie pozwala na “czyste” zabootowanie systemu z dysku
PS Potem to zedytuję, bo nie mam teraz warunków do pisania.
edit2: dopiero teraz zwróciłem uwagę na
Procedura którą opisałeś dalej sugeruje, że masz ustawicznie “brudny” system plików i nigdy nie doczekałeś ukończenia jego naprawy przez HAOS.
Co właściwie masz na myśli jako reset zasilania?
Przecież systemu się nie restartuje przez odcięcie zasilania - to jest dość normalny system operacyjny - np. windowsa nie wyłączasz chyba przez wyciągnięcie wtyczki z gniazdka elektrycznego (w przypadku laptopa by zaemulować taką sytuację musiałbyś najpierw pozbyć się akumulatora), tylko zamykasz system w “elegancki” sposób, natomiast “brudne” zamknięcie np. wskutek zaniku zasilania podczas pracy uruchamia procedury auto-naprawcze przy następnym starcie systemu (możesz to sprawdzić w zasadzie na każdym typowym systemie, jakkolwiek nie biorę odpowiedzialności za ewentualną utratę plików czy poważniejszą awarię).
W przypadku HAOS jest podobnie - jeśli chcesz zamknąć system (de facto chodzi o “eleganckie” zamknięcie systemu hosta) to robisz to z menu supervisora
w przypadku RPi4 zamknięcie systemu HAOS w ten sposób wyłącza zasilanie portów USB więc zwykle widać kiedy można odłączyć zasilanie już po LED w obudowie dysku (jeśli masz obudowę, gdzie LED świeci zawsze gdy jest zasilanie i mruga w trakcie dostępu do hdd/ssd, a takie zachowanie jest najpopularniejsze).
Jedna istotna UWAGA - GUI w trakcie procesu zamykania systemu przestaje być dostępne praktycznie natychmiast, ale to nie jest wyznacznik zamknięcia systemu, bo samo zamykanie systemu jeszcze potem trwa i trwa (i jeszcze trochę trwa i trwa) i wcale nie jest to coś co się dzieje szybko (nie są to sekundy, tylko minuty).
Oprócz tego kontrolki LED w samym RPi pokazują kiedy można wyłączyć zasilanie, to działa z pewnością w RPI4, ale w RPi3 chyba jest identycznie (no na jakieś 99%) - obejrzyj od początku do końca
generalnie to jest RPi4 i filmik trwa ponad 1,5 minuty! bo tyle trwa u mnie prawidłowe zamknięcie systemu (mimo tego, że dysk jest nvme, w obudowie na USB3 z obsługą UASP, a to wszystko jest wpięte do portu USB3 w RPi4, więc to totalnie najszybsze z możliwych rozwiązań), i zaczyna się on w momencie kliknięcia w potwierdzenie zamykania systemu, a kończy w momencie gdy system się prawidłowo zamknął - świadczy o tym 8- luib 10-krotne (policzyć błyski jest trudno) szybkie regularne mignięcie zielonej LED - to końcowe miganie zielonej LED jest tak bardzo charakterystyczne, że nie sposób tego przegapić jeśli się obserwuje kontrolki LED, jest też poprzedzone krótkim mignięciem (zgaśnięciem) kontrolki czerwonej i równoczesnym z wyłączeniem zasilania na portach USB - zielona kontrolka RPi jest słabo widoczna poniżej czerwonej w prawym dolnym rogu kadru).
Nie pamiętam czy w RPI3 też są wyłączane porty USB (mogą nie być) - więc jeśli RPi nie wyłącza portów, to zakryj sobie górną połowę kadru by widzieć tylko kontrolki RPi - te w prawym dolnym rogu, to być może będziesz miał jakieś odniesienie do rzeczywistości.
W każdym razie zasilanie od RPi można odłączyć dopiero, gdy system jest w 100% zamknięty i jest to czynność potrzebna by wystartować system ponownie (bo RPi bootuje natychmiast po ponownym podpięciu zasilania).
Jeśli potrzebujesz zrestartować hosta (czyli zrobić restart systemu HAOS), to do tego służy pozycja po lewej
Natomiast jeśli chcesz zrestartować tylko sam serwer HA (czyli w/g obecnej terminologii “HA core”) to jest do tego taki przycisk
który w zasadzie dubluje ten przycisk z kontroli serwera
I teraz do clou - jeśli odetniesz zasilanie to myślę, że w 9 na 10 przypadków następuje uszkodzenie bazy danych (bo jest to najczęściej zapisywany plik)
HAOS traktuje taki zanik zasilania na nie zamkniętym “czysto” systemie jako awarię systemu i wdraża przy następnym starcie procedury ratunkowe, które możesz odbierać jako brak startu, bo trwają przynajmniej kilka minut dłużej od czystego startu (ponieważ RPi3 ma tylko USB2 to może to nawet być kilkanaście minut) - HAOS po pierwsze startuje z drugiego “slotu” z systemem (w każdej instalacji są po 2 kopie systemu, być może różne, to zapewne zależy od historii uruchomień, ale nie wnikałem jak aktualizacja systemu hosta wygląda technicznie od środka), ponadto podejmuje wtedy próbę naprawy systemu plików na partycji hassio-data co właśnie trwa dosyć długo szczególnie jeśli są błędy (u mnie zawsze się ona udawała w przypadku wielokrotnych zaników zasilania moich maszyn na bazie x86-64) oraz ostatnie ale może najważniejsze - nawet naprawa systemu plików może nie być wystarczająco skuteczna aby baza danych pozostała w dobrej kondycji (co może choć nie musi być przyczyną utraty historii).
Nie , bo w RPi3 nie da się zaktualizować firmware, a właściwy bootloader znajduje się na dysku (w firmware jest zaszyty tylko pre-bootloader), dlatego RPi3 jest bardziej wybredne jeśli chodzi o dobór obudowy na dysk (mimo, to teraz po przemyśleniu, że być może nieprawidłowo zamykasz system sądzę, że nie masz żadnych problemów ze sprzętem tylko jesteś zbyt niecierpliwy jeśli chodzi o możliwości używanego sprzętu).
Właściwie najprostszą sugestią może być podłączenie monitora do RPi (mimo, że pewnie nie będzie w tym momencie bardzo użyteczny, to zobaczysz jak wygląda proces uruchamiania się systemu oraz później zamykania systemu) i przede wszystkim ile to faktycznie trwa w Twojej konfiguracji sprzętowej.
RPi 3 zawsze najpierw próbuje startować z karty TF, dopiero później z nośnika USB (nie pamiętam czy kolejność można zmienić w nieodwracalny sposób - ale pewne ustawienia pre-bootloadera można w RPi 3 zmienić w nieodwracalny sposób tylko jeden jedyny raz, jakkolwiek RPi3B+ kolejność bootowania jest już ustawiona OK fabrycznie i nie polecam grzebać - jeśli mnie pamięć nie myli to tylko “trójka beż plusa” wymagała takiej modyfikacji).
No i na koniec powrócę do tego od czego zacząłem - na tym dysku powinieneś zainstalować przede wszystkim najpierw RPiOS by się przekonać czy sprzęt pracuje w pełni stabilnie (oraz jak się zachowuje po czystym zamknięciu systemu i przy czystym restarcie, możesz też na tak spreparowanym systemie sprawdzić czy udaje się “brudny” restart - jakkolwiek RPiOS jest skonstruowany inaczej, więc nie oczekuj w pełni identycznego zachowania z HAOS), do tego przyda się też monitor klawiatura i mysz.
Zakładam, że może (choć nie musi) występować problem z zasilaniem - w HA stan zasilania można monitorować za pomocą tej integracji
jest ona standardowym składnikiem HAOS w wersji dla RPi (od jakiegoś dłuższego czasu - chyba już rok albo dwa).
Wskaźnik zasilania na filmiku ma uszkodzony jeden z segmentów, co utrudnia odczyt, ale w praktyce gdy jestem w stanie nim zmierzyć napięcie większe od 4,7V na portach USB, to RPi nie raportuje jeszcze problemów z zasilaniem (a przez większość czasu jest ono bliższe 4,8V)
Ja pisałem, ale tutaj nie szukaj problemu (a w szczególności jego rozwiązania) jeśli masz jakikolwiek problem ze stabilnością lub kompatybilnością to takie rozwiązanie na 99% nie pomoże (zostawiam sobie ten 1% jeśli przypadek okaże się beznadziejny - przecież nie ma musu by bootować z dysku, można go traktować tylko jako nośnik danych ale nie zwalnia nas to z obowiązku prawidłowej obsługi systemu).
Kluczowa informacja jest tutaj: