Podsumowując doświadczenia z własnych instalacji oraz kilku dyskusji (również na PW, choć po to jest forum by z niego korzystać - poszukiwanie wiedzy nie jest powodem do wstydu!) ujmę to tak - jest to banalne rozwiązanie i dobrze się sprawdza na słabym sprzęcie (o czym pisałem m. in. tam i tam ).
Można w ten sposób zagospodarować np. starego laptopa (nawet z uszkodzoną matrycą, bo ekran nie jest w sumie najważniejszy, a nawet jest w systemie workaround umożliwiający pracę z zamkniętą klapą matrycy).
Niestety istnieje prawdopodobieństwo, że nie na każdym sprzęcie x64 się da to zrobić.
Kluczowa jest obsługa UEFI w BIOSie (możliwe jest uruchomienie sprzętu mimo uruchomionego trybu CSM, byleby wtedy tryb UEFI był włączony - wtedy sprzęt zwykle i tak wystartuje w trybie UEFI, czasem trzeba jednak włączyć preferowanie UEFI, niektóre biosy po uruchomieniu CSM mogą wyłączyć tryb UEFI!, niektóre nie mają CSM tylko oddzielne pozycje dla Legacy Boot i UEFI Boot, w takim wypadku Legacy nie przeszkadza, ale nie jest potrzebny), dodatkowo tryb UEFI musi umożliwić wyłączenie Secure Boot, oprócz tego procesor musi być 64-bitowy i spełniać minimum wymagań dla wirtualizacji (większość procków w górę od dziś mocno archaicznego Core2 spełnia te wymagania), oraz potrzebna karta sieciowa Ethernet (przewodowa) dla której HAOS ma wbudowane sterowniki, (edit: połowa 2023 - w HAOS10.0 już mało która popularna karta onboard jest nieobsługiwana) nie wiem jak bardzo jest nieaktualna dokumentacja systemu
(sam dodawałem do niej model przetestowanego NUCa parę lat temu - kiedyś ta platforma nazywała się Intel NUC, a umożliwiała pracę na niejednym sprzęcie x64 już na długo przed przemianowaniem na Generic x86-64 - i nie widzę zbyt wielu uzupełnień - rzeczywiste możliwości nieco wyprzedzają dokumentację), ale z tego co wiem lista wspieranych sterowników kart sieciowych jest nadal dość uboga - obsługiwane są typowe chipsety sieciowe intel’a, Marvell Yukon 2 i jakieś Reatek’i no i oczywiście każda z nimi zgodna karta (jakkolwiek jak dotąd w każdym przypadku moich eksperymentów ta lista była wystarczająca - nawet karta 2,5Gbps RTL8125B znaleziona na płycie głównej dla graczy działa bezproblemowo na sterowniku r8169
). Edit: od HAOS 7.0 doszła obsługa kart Ethernet na chipsetach Atheros i Broadcomm.
Poniższy fragment wymaga weryfikacji, póki co skreślam (czekam na raporty tych którym się udało).
Być może wystarczy do instalacji i uruchomienia sama karta WiFi z listy obsługiwanych (zawsze wykorzystywałem kablowe karty Ethernet, więc na taką konstrukcję jeszcze nie trafiłem, by myśleć jak obejść problem jej konfiguracji WiFi, o ile w przypadku RPi robił to odpowiedni skrypt wczytujący ustawienia z pendrive lub podkatalogu na partycji boot, to w przypadku x64 nie wiem czy to tak samo działa). Z tego co wiem obsługiwane są wyłącznie karty WiFi intel’a (moduły iwlwifi i iwlmvm).
Nie należy się nastawiać na wykorzystanie karty WiFi, na obecnym etapie moim zdaniem instalacja z wykorzystaniem wyłącznie WiFi jest możliwa tylko na platformie RPi.
Jako nośnik systemowy może być zarówno hdd jak i ssd (obsługiwane są zarówno konstrukcje sata jak i nvme, może być nawet w zewnętrznej obudowie USB, byleby się do tego nadawała - wsparcie UASP jest bardzo wskazane, no i o ile pajęczarstwo nam nie przeszkadza ), może być eMMC (zdarza się w budżetowych AIO czy laptopach) a wśród NUC’o-podobnych wynalazków konstrukcję, która używa modułu eMMC znam tylko jedną i jest to obecnie z powodu kryzysu dostępu do komponentów nieprodukowany Odroid H2+, ale w biednych konstrukcjach można wykorzystać nawet kartę SD/TF czy pendrive w charakterze nośnika systemowego - jeśli nie będzie tam partycji z danymi, to taka konstrukcja przetrwa lata).
Jednym z kluczowych elementów jest też podpięcie kabla Ethernet (dzięki temu interfejs sieciowy zostanie auto-magicznie skonfigurowany z DHCP naszego routera) i dostęp do internetu (podczas pierwszego startu systemu jest synchronizowany czas oraz są sprawdzane aktualizacje oraz w ogóle odbywa się pobieranie i instalacja niezbędnych kontenerów - obecnie - co najmniej od 2022 roku obraz systemu nie umożliwia dokończenia instalacji offline, czyli internet jest koniecznością podczas pierwszego uruchomienia).
Ogólny sposób instalacji jest zasadniczo jeden - nie ma do tego instalatora - po prostu obraz dysku trzeba przepisać na nośnik fizyczny
Przepisanie obrazu można zrobić trzema (wykluczającymi się) metodami:
- Używając do tego innego komputera pod niemal dowolnym systemem, przekładając nośnik (dysk) i przepisując obraz za pomocą Balena Ether
- Używając do tego docelowego komputera, jakiejś dystrybucji linuxa live i przepisując obraz za pomocą Balena Ether
- Używając do tego docelowego komputera, jakiejś dystrybucji linuxa live i przepisując obraz za pomocą
dd
pierwszy sposób jest zdecydowanie najprostszy, za to te 2 ostatnie są idealne na wypadek gdy nośnik (dysk) jest trudno dostępny/obudowa nierozbieralna (to mi się zdarzyło jakieś pół roku temu w TC AIO Samsunga), albo występuje problem ze skorzystaniem z Balena Ether w systemie którego używamy codziennie (to raczej ekstremalnie rzadki przypadek, ale doświadczyłem kiedyś takiego, że inny kontroler dysku nieco inaczej widział geometrię dysku i system po przełożeniu dysku między komputerami nie chciał działać z tego powodu), edit - jak się okazuje problemy z Balena Ether nie są rzadkością pod windowsem (ale i na to są obejścia).
Metoda pierwsza
1. Używając do tego innego komputera , do którego podpinamy nasz docelowy nośnik systemowy, czyli ssd (sata lub nvme) / hdd / eMMC itd., + Balena Ether, a następnie przepisujemy obraz, ostatnim krokiem jest przełożenie nośnika do docelowego komputera i zabootowanie właśnie z niego.
Oficjalny opis jak to zrobić jest tam:
ostatnim słowem jedynego nas interesującego paragrafu jest “onboarding” za którym mamy link do tej czynności
(paragraf zatytułowany “Install Home Assistant Container” to już całkowicie inna metoda instalacji i tego można już nie czytać).
Jeśli wybrałeś metodę 1. to nigdy nie stosuj metod opisanych w tym poście w metodzie 2. - taka próba skończy się skasowaniem dysku systemowego Twojego komputera (jeśli nie wiesz co robisz - nie rób).
Metoda druga - na tej się skupię, bo dla niektórych wydaje się być przerażająco trudna, a nie jest.
2. Używamy linuxa live + Balena Ether
a) jako systemu linux w postaci live-USB użyłem Ubuntu Desktop 20.04.4 LTS - obecnie niedostępny wersja z patchem to obecnie Ubuntu Desktop 20.04.5 LTS - to też link do jego pobrania edit: w 2 połowie 2022 wypadałoby oczywiście użyć wersji 22.04 LTS aktualny system do pobrania edit2: zgłoszono problem z wersją 22.04 więc dorzuciłem link do 20.04, a jeśli się pojawi kolejne poprawione wydanie Balena Ether które zadziała w Ubuntu 22.04.x i znowu będzie działać tutorial jak po staremu, to poproszę o info. Obejście problemu z Balena Ether w Ubuntu 22.04.
Obejście tego problemu w/g oficjalnego tutoriala (Ubuntu dependency for Ether):
sudo add-apt-repository universe
sudo apt update
sudo apt install libfuse2
Instrukcja przygotowania startowego pendrive spod kilku popularnych systemów jest tu pod linkiem Create a Bootable USB stick
b) Może się zdarzyć, że z powodu karty graficznej system live Ubuntu nie wystartuje prawidłowo z użyciem typowych ustawień (np. mogą być anomalie w wyświetlaniu pulpitu lub czarny ekran) i będzie trzeba wybrać z boot-menu pozycję “(safe graphics)”.
Opcja dla niecierpliwych (tylko dla Ubuntu 20.04) - jeśli nasz pendrive nie jest z gatunku śmieciowych gadżetów reklamowych (podczas pisania tego tutorialka zniszczeniu uległ mi właśnie taki “darmowy chinol” który nie przetrwał zapisania na nim kilku obrazów różnych systemów - padł przy trzecim, którym był wspomniany Ubuntu… co opóźniło mi robotę, bo nie mogłem znaleźć czegoś zastępczego) - można wcisnąć ctrl+C by przerwać weryfikację nośnika z Ubuntu (przecież nie będziemy instalować Ubuntu więc nawet jeśli byłoby coś lekko nie tak, to i tak nam to raczej nie przeszkodzi).
c) Po udanym zabootowaniu wybieramy opcję “Try Ubuntu” (bądź “Wypróbuj Ubuntu” - zależnie od wybranego języka)
d) Na tym etapie możemy sprawdzić czy karta sieciowa pracuje z jednym ze standardowych sterowników, które są na pokładzie HAOS, w tym celu odpalamy Terminal i w nim wydajemy komendę dmesg
i przewijamy wyniki - szukając jakiegoś ciągu typu e100, e1000, igb, sky2
lub r8169
(na dziś to chyba wszystkie dostępne sterowniki kart Ethernet w HAOS)
można to nieco zautomatyzować np. tak:
dmesg | grep "r8169"
oczywiście po ręcznym przeszukaniu wiedziałem, że chcę szukać ciągu r8169 ale można parę razy wydać podobne polecenie zmieniając szukany ciąg na nazwy dostępnych sterowników
jak widać w tym laptopie jest wspierana karta (i widać, że nie podpiąłem do niej kabla, a jest to jeden z kluczowych elementów udanej instalacji!), więc mógłby służyć jako sprzęt pod natywną instalację HAOS
e) Balena Ether nie jest elementem systemu, ale wszystkie konieczne kroki to otwarcie Firefoxa (jest pre-instalowany) i przejście w nim pod link
https://www.balena.io/etcher/
skąd pobieramy wersję “Ether for Linux x64 (64-bit) (appimage)”, ona (ta wersja) w tym linuxie będzie wybrana domyślnie, w dowolne miejsce wewnątrz
/home
ale nie na pulpit! (system w trybie live pracuje z RAMdysku), to jest plik archiwum *.zip (i on i tak zniknie po restarcie) doskonałym miejscem jest katalog Download (Pobrane)więc trzeba go jeszcze rozpakować, bo Balena Ether jest w środku, też w dowolne miejsce byle nie na pulpit
rozpakowujemy (prawie) byle gdzie (ja to wrzuciłem też do Download)
odpalamy wypakowany plik i postępujemy zgodnie z instrukcją
(tak jak w metodzie 1. przegapiłem zrobienie screenshota, ale to chyba oczywiste)
po załadowaniu linka z obrazem HAOS robi się dziwnie - Balena Ether proponuje sflaszowanie pendrive, z którego mamy właśnie odpalony system
ale to nic, bo po prostu to jest tryb ochrony dysków systemowych (miałem tam zainstalowanego windowsa, który celowo “poszedł do dymu” - ten komputer jest w trakcie składania, a to i tak był tylko tymczasowy system dla aktualizacji firmware), więc przechodzimy do opcji wyboru (ten dysk, który przedstawia się na obrazku jako Goodram Baseus, to dysk na który zrzucałem screenshoty, które właśnie oglądacie, więc to jeszcze nie to)
właściwy dysk, na którym w tej metodzie ma się znaleźć HAOS jest ukryty poniżej
aby go wybrać musimy potwierdzić, że wiemy co robimy (czytelniku, jeśli nie wiesz co robisz, nie kontynuuj, szczególnie jeśli próbujesz instalacji inną metodą niż 2. bo to jest ostatni krok przed nieodwracalnym skasowaniem dysku!), czyli naduszamy “Yes I’m sure”
Wciskamy “Flash” i…
Tym razem obraz zostaje ostatecznie przepisany na dysk
i po wszystkim - trzeba jeszcze zamknąć system (prawy górny róg) po odpowiednim monicie o wyjęcie pendrive z systemem live wciskamy Enter (w przypadku gdy mamy trefną konfigurację karty graficznej może nie być tego widać, dlatego sugeruję wybranie właściwej opcji w boot-menu Ubuntu przed rozpoczęciem roboty).
Ale, ale - zanim to zrobimy, to jest jeszcze jedno fajne narzędzie - Gparted
To jest krok tylko dla ciekawskich (nie jest w żadnym razie potrzebny do niczego, poza wizualną kontrolą układu partycji)
i tu UWAGA - jeśli chcemy podejrzeć partycje zaraz po przepisaniu obrazu (czyli naszej niby-instalacji), to Gparted wykrywa uszkodzoną partycję - ale niech nas ręka nie świerzbi!
NIE naprawiamy, jeśli nie chcemy zepsuć! (tak ma być, to jest wstępny etap instalacji) po prostu ignorujemy błąd.
Jak widać system HAOS dałby się zainstalować na nośniku o pojemności zaledwie 2GB (ale nie da się go używać w ten sposób, realne minimum rozsądku na testową malutką instalację to jakieś 16GB, ale jeśli mamy szczególnie biedny sprzęt z malutkim wbudowanym ssd czy eMMC to naprawdę wystarczy i kilka GB byleby w jednym z pierwszych kroków konfiguracji skorzystać z opcji przeniesienia partycji danych i wskazać Home Assistantowi inny odpowiednio większy dysk roboczy - uwaga ta opcja może nadal nie działać poprawnie - u mnie nie zadziałała dla dysków nvme, obejście problemu jest niżej).
Teraz już naprawdę można zamknąć Ubuntu i skonfigurować BIOSa.
Dla ciekawskich - po wstępnym etapie instalacji, układ partycji się nieco zmienia - partycja hassos-data
rozrośnie się tak, by zająć całe dostępne miejsce (co w przypadku wolnego sprzętu i np. instalacji na zwykłym talerzowym hdd może zając sporo czasu)
Tu jest naprawdę nadal co nieco do napisania… ale to już zależy od feedbacku użytkowników, którzy skorzystają z poradnika - nie jestem w stanie przewidzieć wszelkich możliwych problemów (zazwyczaj nie występują), a najbardziej typowe już chyba opisałem.
Metoda trzecia dd
(tak naprawdę to nie tylko dd
, ale i xz
i w zasadzie można użyć jeszcze parę innych programów odpalanych z linii komend, ale samo dd
jest tym kluczowym elementem).
3. Miałem jej nie opisywać - nie jestem linuxowym guru (więc nie planuję jej wspierać), ale czasy nastały takie, że na sprzęcie z 2GB RAM nie da się odpalić nawet przeglądarki Firefox w Ubuntu 22.04 w trybie live (edit: - wcześniej pisałem m.in. tak: “wiem, że metoda działa, bo robiłem tak na “nierozbieralnym” Samsungu TC241, ale sporo wody w Odrze upłynęło i po prostu “z głowy” nie podam teraz jednej sprytnej komendy, która zrobi wszystko”, teraz poświęcając sporo czasu na test na realnym sprzęcie potwierdziłem, że po odpowiednich modyfikacjach można to zrobić “w jednym poleceniu”), nieaktualna wersja tej metody jest w wideo z linka w tamtym wątku
Nadszedł czas by się zabrać i za to, więc póki co doskonała instrukcja, potraktujmy ją jako lekturę obowiązkową (zakłada, że mamy pobrany obraz lokalnie) jest tu:
a oto ta “magiczna jednolinijkowa komenda” (ale traktowanie tego jako magię skończy się katastrofą - polecam chociaż spróbować zrozumieć co ona robi i dlaczego tak a nie inaczej), która pobiera, rozpakowuje i przepisuje obraz systemu na dysk (przygotowana dla Ubuntu live, sprawdzona też w Mint 20.3; jeśli w waszej dystrybucji live ma wyglądać inaczej to proszę się chwalić), więc odplamy terminal i wpisujemy z grubsza to (wielkość liter MA znaczenie, spacje też mają być we właściwych miejscach, wymagany dostęp do internetu):
wget -q -O - "https://github.com/home-assistant/operating-system/releases/download/9.3/haos_generic-x86-64-9.3.img.xz" | xz -dc | sudo dd of=/dev/sdc bs=4M conv=fsync
i 3 słowa komentarza - zamiast fragmentu /9.3/haos_generic-x86-64-9.3.img.xz
należy użyć aktualnej wersji (ta jest dla HAOS 9.3 - generalnie całość tego linku można znaleźć w oficjalnym tutorialu dla naszej platformy (na http://hass.io)
a zamiast
/dev/sdc
należy użyć ścieżki do dysku na którym chcemy zainstalować system, najprawdopodobniej będzie to/dev/sda
dla pierwszego dysku sata lub USB/dev/sdb
dla drugiego dysku j/w/dev/mmcblk0
dla wbudowanego dysku eMMC (zazwyczaj jest tylko jeden)/dev/nvme0
dla pierwszego dysku nvme (nietestowane klepnąłem “z pamięci”)no i gdy już mamy wyedytowaną i sprawdzoną komendę klepiemy w Enter
teraz można iść do parku na spacer - nie zobaczymy nic nowego przez długi czas (chyba, że sypnie błędami na początku), akcja jest w zasadzie nie nieodwołalna - wszystko dzieje się równocześnie nie dając żadnych “pasków postępu”, ani innych oznak działania (za wyjątkiem transferu z internetu i migania kontrolki hdd jeśli taką mamy), a jedynym znakiem, że jest już po robocie będzie pojawienie się tzw. znaku zachęty - czyli terminal wróci do swych normalnych funkcji, brak znaku zachęty oznacza, że wciąż się to dzieje i gwarantuję nawet na szybkim sprzęcie i szybkich łączach to trochę trwa.
I jeszcze jedna uwaga - nie przewidziałem opcji retry dla wgeta (więc można ją dodać jeśli ktoś ma niezbyt stabilne łącze).
Od biedy gdy w terminalu powróci znak zachęty można zweryfikować istnienie nowych partycji w GParted (ignorujemy komunikat o konieczności naprawy).
Można zamknąć system (wyjąć nośnik z Ubuntu live i wcisnąć Enter ) i ewentualnie następnie ustawić w BIOSie bootowanie już z właściwego urządzenia (o ile nie korzystaliśmy z biosowego bootmanagera - zwykle to F12 lub F10, by tylko tymczasowo zmienić urządzenie, którego bootujemy) i iść na kolejny spacer (wciąż przypominam o dostępie do internetu), chociaż tym razem zamiast spaceru proponuję pozostawienie podłączonego monitora (to uzmysławia ile czasu potrzebuje system na samo bootowanie, ale potem jeszcze startują usługi, a później właściwa instalacja więc nawet mając na ekranie banner Home Assistanta instalacja nie jest ukończona - tu się trzeba sugerować tym co widzimy w naszej przeglądarce w web GUI pod adresem naszej maszyny na porcie 8123).
Nietestowana wersja dla odważnego (użyłem skracacza url’i) - jeśli ktoś wypróbuje niech się pochwali
mały updatewget -q -O - "tinyurl.com/haos-8-2" | xz -dc | sudo dd of=/dev/sdc bs=4M conv=fsync
wget -q -O - "tinyurl.com/haos-9-3" | xz -dc | sudo dd of=/dev/sdc bs=4M conv=fsync
wget -q -O - "tinyurl.com/haos-11-1" | xz -dc | sudo dd of=/dev/sdc bs=4M conv=fsync
Kończenie instalacji:
- odpowiednie ustawienia bootowania w BIOSie (aby system startował bezpośrednio ze świeżo utworzonej partycji EFI w trybie “EFI - no security” - to nie ma związku z bezpieczeństwem - chodzi o to, że nasz linux nie ma certyfikatów Microsoftu, odpalając tryb “bezpiecznego UEFI” potrzebowalibyśmy też zainstalować odpowiednie certyfikaty w EFI).
- ewentualne przenosiny partycji danych już po świeżej instalacji i po wstępnej konfiguracji (być może daje się to zrobić nawet na etapie przed wstępną konfiguracją, ale tego akurat nie próbowałem z braku odpowiedniego sprzętu w dniu, a raczej nocy eksperymentalnej instalacji, a konkretniej - drugiego pustego i większego od systemowego dysku ssd) -
będzie to uzupełnione- obecnie ta operacja jest już możliwa nie tylko z CLI, ale też po prostu z GUISupervisora (jeśli działa), obecnie zostało to przeniesione do Ustawienia → System → Pamięć masowa → hamburger menu.
Możliwe pułapki
- konfiguracja BIOSa
Fotki z BIOSu Fujitsu Q910 (dzięki @Krzyszof_K ) oraz innych modeli sprzętu (mam nadzieję, że się jeszcze rozrośnie dzięki innym użytkownikom)
https://forum.arturhome.pl/t/ustawienia-bios-dla-natywnej-pracy-systemu-haos/3791
- Potencjalnie niekompatybilna karta sieciowa
Używając wspomnianego linuxa live można spróbować ustalić jakiego sterownika potrzebuje nasz sprzęt (opisałem w metodzie 2.)
poniższy kawałek loga akurat pochodzi już z… HA w eksperymentalnej instalacji wykonywanej metodą 2. widać tu też listę sterowników kart sieciowych ładowanych na starcie - jak widać tu karta “poleciała” na sterowniku r8169
[ 0.403865] e100: Intel(R) PRO/100 Network Driver
[ 0.405134] e100: Copyright(c) 1999-2006 Intel Corporation
[ 0.406412] e1000: Intel(R) PRO/1000 Network Driver
[ 0.407684] e1000: Copyright (c) 1999-2006 Intel Corporation.
[ 0.408961] igb: Intel(R) Gigabit Ethernet Network Driver
[ 0.410227] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 0.411474] sky2: driver version 1.30
[ 0.412701] r8169 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 0.419955] libphy: r8169: probed
[ 0.421252] r8169 0000:02:00.0 eth0: RTL8125B, d8:bb:c1:00:11:22, XID 641, IRQ 133
[ 0.422471] r8169 0000:02:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
-
Brak prawidłowej obsługi UEFI przez BIOS - istnieje obejście z użyciem rEFInd (jest to ostateczność, ale dla komputerów z “czarnej listty” nie znam sensowniejszego rozwiązania), dzięki @grzegorzbb
Instalacja natywna (bare-metal, "golas") Home Assistant OS (HAOS-generic) końcówka 2022 - #51 przez grzegorzbb -
Skrypt przenoszenia partycji danych nie działa w konfiguracji na której go wstępnie testowałem (nvme 250GB jako podstawowy i nvme 1000GB jako dodatkowy, ani w HAOS 6.6 ani HAOS 7.0.rc1), jego obejściem jest… skopiowanie partycji
hassio-data
przy użyciu GParted na drugi dysk, a następnie zmiana etykiety (label) oryginalnej partycji zhassio-data
nahassio-data-old
(update: wbudowany w system skrypt zmienia nazwę przeniesionej partycji na hassio-data-external`, więc robiąc to “z palca” sugeruję taką zmianę - to może się przyda w przyszłości, a zachowamy kompatybilność z tym co przygotowali twórcy systemu).
Taki mikrodowodzik, że się to udało, choć wbudowane skrypty do przenoszenia i tak nie widzą dysku danych
~ $ dmesg | grep "nvm"
[ 0.370754] nvme nvme0: pci function 0000:02:00.0
[ 0.372280] nvme nvme1: pci function 0000:04:00.0
[ 0.384767] nvme nvme0: Shutdown timeout set to 10 seconds
[ 0.387770] nvme nvme0: 8/0/0 default/read/poll queues
[ 0.388969] nvme nvme1: 8/0/0 default/read/poll queues
[ 0.391394] nvme0n1: p1
[ 0.392596] nvme1n1: p1 p2 p3 p4 p5 p6 p7 p8
[ 1.411094] EXT4-fs (nvme1n1p7): mounted filesystem with ordered data mode. Opts: (null)
[ 1.547274] nvme0n1: p1
[ 1.979206] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Opts: (null)
[ 2.001166] EXT4-fs (nvme0n1p1): resizing filesystem from 62336512 to 244190390 blocks
[ 2.375497] EXT4-fs (nvme0n1p1): resized filesystem to 244190390
~ $ ha os datadisk list
devices: []
~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
overlay 961396456 2868548 919434908 0% /
tmpfs 24622512 0 24622512 0% /sys/fs/cgroup
/dev/root 185472 185472 0 100% /sbin/docker-init
/dev/nvme0n1p1 961396456 2868548 919434908 0% /config
/dev/nvme0n1p1 961396456 2868548 919434908 0% /backup
devtmpfs 24620536 0 24620536 0% /dev
tmpfs 24622512 0 24622512 0% /dev/shm
/dev/nvme0n1p1 961396456 2868548 919434908 0% /ssl
/dev/nvme0n1p1 961396456 2868548 919434908 0% /addons
/dev/nvme0n1p1 961396456 2868548 919434908 0% /share
/dev/nvme0n1p1 961396456 2868548 919434908 0% /media
/dev/nvme0n1p1 961396456 2868548 919434908 0% /data
/dev/nvme0n1p1 961396456 2868548 919434908 0% /run/audio
/dev/nvme0n1p1 961396456 2868548 919434908 0% /etc/asound.conf
tmpfs 9849008 1180 9847828 0% /run/dbus
/dev/nvme0n1p1 961396456 2868548 919434908 0% /etc/hosts
/dev/nvme0n1p1 961396456 2868548 919434908 0% /etc/hostname
/dev/nvme0n1p1 961396456 2868548 919434908 0% /etc/resolv.conf
tmpfs 24622512 0 24622512 0% /dev/shm
/dev/nvme0n1p1 961396456 2868548 919434908 0% /var/log/journal
/dev/nvme0n1p1 961396456 2868548 919434908 0% /etc/pulse/client.conf
tmpfs 9849008 1180 9847828 0% /run/log/journal
tmpfs 24622512 0 24622512 0% /proc/asound
tmpfs 24622512 0 24622512 0% /proc/acpi
devtmpfs 24620536 0 24620536 0% /proc/kcore
devtmpfs 24620536 0 24620536 0% /proc/keys
devtmpfs 24620536 0 24620536 0% /proc/timer_list
tmpfs 24622512 0 24622512 0% /proc/scsi
tmpfs 24622512 0 24622512 0% /sys/firmware
teraz ten system idzie na przemiał, bo mam już wszystkie potrzebne podzespoły by złożyć kompletny sprzęt (nie jako bazę pod HA).
Dalsze testy wskazują, że w bardziej typowych konfiguracjach (dyski sata) skrypt działa, oczywiście docelowy musi być większy od źródłowego (to jest podstawowa motywacja do przenoszenia).
Update - wątek z obrazkami dotyczącymi przenoszenia partycji danych w GUI (jak i CLI):
Zasoby
Wydania HAOS - jeśli potrzebujemy jakiejś niestandardowej wersji systemu (bo. np. najświeższa “beta”, czy raczej “release candidate” zawiera jakieś łatki których potrzebujemy, albo wręcz odwrotnie - chcemy spróbować instalacji na już niewspieranym sprzęcie)
Parę postów gdzie już wcześniej wspominałem o metodzie instalacji bare-metal: NUC i migracja
W początkowym etapie konfiguracji oprócz hasła czy loginu wybieramy też lokalizację naszej instalacji, a jednym z jej parametrów jest wysokość n.p.m. - łatwo ją ustalić używając tego serwisu: