Oczywiście, trudno się nie zgodzić, ale nie w postaci 2 dysków po 120GB…
chyba nie zrozumiałeś idei - instalacja generic umożliwia użycie 2 nośników, ale standardowo jedynie w konfiguracji:
- dysk systemowy (wystarcza na luzie 16GB) - na nim jest pierwsze 7 partycji HAOS + kopia “starej” partycji danych - ten dysk pracuje w trybie tylko do odczytu (poza aktualizacjami samego HAOS)
- i dysk danych (im więcej tym lepiej, oczywiście w granicach rozsądku) - zawiera po migracji danych na drugi nośnik tylko partycję danych (a na niej w stosownych katalogach wszystko co instalujemy dodatkowo, konfiguracje i dane, które generujemy).
Tak swoją drogą ta konfiguracja jest wspierana też na wszystkich platformach RPi - można wtedy użyć karty TF w charakterze dysku systemowego i ssd/hdd@usb na dane (prawdopodobnie to samo dotyczy też wszystkich wspieranych platform więc i wszystkich odrdoid-arm oraz tinkerboard, włącznie z modelami wyposażonymi w eMMC tylko nie było mi dane przetestować, a na forum nikt się nie chwalił takimi konfiguracjami), natomiast pod względem ilości dostępnej pamięci RAM dla modeli nie mających minimum 2GB RAM zalecane jest użycie 32-bitowej wersji HAOS tam gdzie to możliwe.
Absolutnie nie ma sensu używanie 2 dysków o dużej pojemności - wtedy systemowy się po prostu będzie marnował - lepiej wtedy użyć jeden, ale większy.
Poniżej instalacja, która ma za sobą już parę lat - kiedyś to była instalacja “generic-RPi-armv7” na RPi3B bez plusa, ale w tym właśnie RPi zjarał się stabilizator napięcia, tymczasowo się przesiadłem na RPi3B+, ale wcześniejsza awaria stabilizatora jednak mnie zmotywowała do poszukiwań czegoś diametralnie innego i w końcu do zmiany platformy i zrobiłem to już na przełomie 2019/2020 - wtedy dzisiejszy generic-x86-64 to była jeszcze platforma pod nazwą “nuc” (w dokumentacji do systemu HAOS dodałem 2 modele dogłębnie przetestowanych i wspieranych NUCów)
~ $ df -h
Filesystem Size Used Available Use% Mounted on
overlay 220.0G 30.2G 180.9G 14% /
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/sda1 220.0G 30.2G 180.9G 14% /share
/dev/sda1 220.0G 30.2G 180.9G 14% /backup
/dev/sda1 220.0G 30.2G 180.9G 14% /media
/dev/sda1 220.0G 30.2G 180.9G 14% /config
w ramach ciekawostek - jak widać powyżej dane są na sda1 (a nie sda8, jak w instalacji na jednym dysku sata, gdyby nie to, że mam systemowy eMMC, to byłby to oczywiście sdb1 gdyby system byłby też na sata, czyli na sda1-7) - po ostatniej zmianie sprzętu system mam na eMMC 32GB (wlutowanym w płytę główną), a ssd 240GB jest tylko na dane.
Przy okazji zeszłomiesięcznej migracji na sprzęt posiadający eMMC wymieniłem też dysk na dane - ostatni screenschot z danych SMART wyglądał w tym ssd który przepracował nieco ponad 2 lata tak:
(obrazek z kwietnia, bezpośrednio przed wymianą nie zrobiłem SS, a nie mam już dostępu do tego dysku, ale widać że już wtedy szacowane zużycie wynosiło 15%, a przebieg trochę ponad 10TBW wygenerowany w całości przez HA)
W zamian za niego wrzuciłem tam używkę eksploatowaną w dość chyba dziwnych warunkach (setki milionów błędów - czyżby uszkodzony kabel sata?), ale z przebiegiem jedynie 1,4TBW i estymowanym zużyciem poniżej koło 0%?? (ciekawe na ile to prawda, “producent” gwarantuje 220TBW w przypadku tego modelu, czyli biorąc pod uwagę jakieś 0,6% limitu powinien pokazywać stan pozostałej żywotności 99% a nie 100% edit: skreślenie - IRDM PRO v1 - ten na S10 miał gwarę 5 lat bez limitu TBW! i nawet taki parametr się nie pojawiał w dokumentacji, którą wywiało ze strony Wilk Elektronik po wprowadzeniu v2 na S12, ale pliki są w archiwum internetu 
)
Dla porównania - inna instalacja (mniej rozbudowana), ta była w swoim czasie migrowana z RPi4B na karcie TF na peceta dyskiem 120GB
[core-ssh ~]$ df -h
Filesystem Size Used Available Use% Mounted on
overlay 109.3G 24.6G 79.2G 24% /
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/sda8 109.3G 24.6G 79.2G 24% /config
/dev/sda8 109.3G 24.6G 79.2G 24% /ssl
/dev/sda8 109.3G 24.6G 79.2G 24% /addons
/dev/sda8 109.3G 24.6G 79.2G 24% /backup
/dev/sda8 109.3G 24.6G 79.2G 24% /share
/dev/sda8 109.3G 24.6G 79.2G 24% /media
w planie jest wprawdzie migracja na sprzęt wyposażony w 32GB eMMC (“bo mam”, przy okazji wyjmę nadmiar RAM) - standardowo to będzie na system i nie planuję wymiany ssd ani na większy. ani na inny w najbliższym czasie, bo tu danych generuje się znacznie mniej, więc i ssd znacznie mniej dostaje “po tyłku” - obrazek świeżutki - przepracowane 2 lata i 4 m-ce i zaledwie raportowane 10% zużycia, tzn. w/g producenta pozostało jeszcze “90% życia”
No cóż - optymalnie jest ustawić recorder na nie więcej niż 7-14dni wstecz (u siebie mam 10), zanim dojrzałem do zbieranie długoterminowej historii w inny sposób (w planie był LTSS) wiedziałem już o planowanych ulepszeniach recordera i standardowej bazy sqlite i jak się okazało już pozostałem na rozwiązaniu standardowym - bardzo sobie cenię każde rozwiązania, które ułatwiają utrzymanie instalacji w sposób możliwie bezobsługowy, a to jedno z nich
(więc obecnie z tymi 10 dniami wstecz danych bieżących, najstarsze statystyki mam dostępne do około roku wstecz - gdy wydano te funkcje w kanale stabilnym, teraz je rozszerzono praktycznie na wszystko, ale baza ma nadal rozmiar poniżej 2GB).
Chyba zrozumiałem co zrobiłeś - “wypaliłeś” HAOS-generic na pendrive i z tego pendrive odpaliłeś sprzęt? (to by tłumaczyło pierwsze uruchomienie znacznie dłuższe niż normalnie) niestety instalacja by potwierdzić lub zaprzeczyć zgodność sprzętu wymaga normalnej instalacji (“wypalenia” systemu na dysku) - tutorialek instalacji różnymi metodami HAOS-generic jest tam (jak dotąd nikt nie przygotował wygodnego dedykowanego instalatora):
PS - Usuwasz stare backupy? (nie są szczególnie potrzebne po dłuższym czasie, a zajmują cenne miejsce).
W tym wypadku raczej (jeśli to nie stare backupy zapychają dysk) nie zmieścisz się na systemowym dysku 16GB przy migracji w standardowy sposób (czyli przez przywrócenie backupu na etapie onboardingu, chyba, że faktycznie wcale nie potrzebujesz tyle miejsca - to właściwie głównie zależy od tego jak dużą masz bazę danych, bo kontenery z addonami i tak się będą musiały zbudować od nowa z okazji zmiany platformy z arm na x86), ale nawet jeśli się nie uda (byłaby to w sumie tylko strata czasu, bo migracja trwa parę godzin, ale można zostawić na noc i ramo sprawdzić czy jest OK), to i tak można zmigrować na już zainstalowany i wstępnie skonfigurowany HAOS (by mieć już przeniesioną pustą partycję danych na drugi dysk) i usunąć z niego wszystkie tymczasowe dane przywracając całościowo świeży backup z RPi.
A czemu o tym wspominam - bo w Thin Client’ach często są fabrycznie montowane ssd w takich maławych rozmiarach, a można je wykorzystać przy instalacji HAOS-generic właśnie na dysk systemowy).