nie no, mam oczywiście świeżynkę, jeszcze nie odpalaną. mogę ją uruchomić ale będe potrzebwoał pomocy z przeniesieniem tych danych na duzy dysk. A aż mi głupio - cały wieczór ci zabrałem
Czyli jeszcze nic nie masz.
GParted czasem nie zaproponował napraw przy pierwszym jego uruchomieniu?
Mam nadzieję, że zignorowałeś tą propozycję…
Jakich kurna danych? przecież nie masz żadnych danych.
Partycję danych (ale nie faktyczne dane, tylko jakieś śmieci) przeniesiesz jednym klikiem w HA
tak, to zapamiętałem aby nie próbować naprawiać
no tak. ale HA musi wiedzieć, że do danych ma używać drugiego dysku tak? Jakoś trzeba chyba to ustawic??
Tak zrozumiałem że ha bedzie sobie na eMMC ale będzie korzystał przestrzeni SSD
Będzie wiedział
To jest w zasadzie mega-proste rozwiązanie - skrypty przenoszą dane (by być ścisłym nie przenoszą, bo stare dane nie znikają, a przekopiowują ten mikro śmietnik bez istotnych danych) oraz co najważniejsze zmieniają nazwy partycji - genialne, bo proste, umożliwia to też ręczne cofnięcie takiego przeniesienia - to kwestia zmiany etykiet partycji.
Jeśli z ciekawości obejrzałeś sobie układ partycji na eMMC w GParted, to wiesz że jest ich całe stado (konkretniej 8; w fazie przedinstalacyjnej, czyli sprzed pierwszego uruchomienia nie zajmują całego dysku, dlatego GParted się burzy, że tablica partycji nie pasuje do nośnika, pierwsze uruchomienie HA jest tak naprawdę instalacją - wtedy są robione m.in. takie modyfikacje by układ partycji pasował do nośnika).
Po przenosinach 7 pierwszych zostaje nietkniętych, a ósma na dane ma zmienioną etykietę (po której HA/HAOS wiedzą, że jej nie używać) i pierwotną zawartość.
Natomiast na dodatkowym dysku powstaje kopia tylko tej ósmej i oczywiście dostaje odpowiednią etykietę + jest powiększany jej rozmiar tak, by zajęła całą pojemność dysku.
uffff,
wygląda na to, że chociaż z tym fobijamy do końce.
HA wstał, nawet widział dysk 256GB. Wskazałem go jako dysk do przeniesienia danych. wyłączył się ha i coś tam sobie miesza teraz
wstał. chyba jest ok 
Zrobiłeś screenshoty? (sprzed przeniesienia)
To jest ten rzadki moment, kiedy cywilizacja potrzebuje Twego wsparcia.
Takie rzeczy zwykle robi się raz w życiu danej instalacji, okazja na następny będzie za wiele lat (o ile projekt Home Assistant pozostanie wiodącym i będzie jeszcze istniał).
tylko ten jeden niestety. wczesniej działałem na drugim kompie to nie było jak nawet.
dziękuję ci za przede wszystkim cierpliwość ogromną do mnie. I w drugiej dopiero kolejności za mieocenioną pomoc. Nie pordziłbym sobie pewnie tu sam.
Teraz czeka mnie dłuuuuga przeprawa z conbee z2m, noderedami i całą resztą automatyki bo straciłem wszystko
Nie no bez jaj, myślałem że sobie przywrócisz backup (i dlatego tak dbasz o te dane).
generalnie mam backup nawet działającą bramke tą AIS dev3 ale nie wiem czy idzie to jakoś przerzucić. Poza tym kopii nedereda nie mam a to było najważniejsze dla mnie. Co do z2m to używałem znienawidzonego przez wszystkoch cc2531 (choć nigdy mnie nie zawiódł) ale przy zmianie na porządniejszy sprzęt chcę od razu przejść na conbee
Hmm akurat konfiguracja Z2M powinna się przenieść od strzała (nie sądzę aby w AIS mogło coś być zmienione, bo to jest w ogóle zewnętrzny serwer).
No cóż moim skromnym zdaniem Conbee jest niemal równie technicznie przestarzale jak CC2531, ale to moje zdanie i jest najmojsze.
Ja bym wszedł w sprzęt pracujący w Zigbee3 (skoro i tak nie przeniesiesz backupu).
Też długo wierzyłem, że CC2531 może działać niezawodnie, póki mój własny się nie posypał.
W specyficznych warunkach (prawdopodobnie gdy jest dużo urządzeń, lub przy losowych zanikach zasilania) on potrafi częściowo nadpisać sobie fragment flasha (porównywałem wsady), przyczyny nie znalazłem, pomaga oczywiście ponowne flashowanie.
A teraz chciałbym się odnieść do kilku poruszonych wcześniej kwestii, które może nie są najistotniejsze, ale chciałbym aby nie wygenerowały mitów.
(nie jestem wprawdzie linuxowym guru, ale pewne rzeczy wiem i będę się odnosił tylko do kwestii, co do których mam zupełną pewność)
-
w Balena Ether “flash from url” nie robi niczego szczególnie innego niż “flash from file”, jakkolwiek pierwszym etapem jest pobranie pliku (w przypadku live do RAMu), więc mamy potencjalne źródło błędów
-
idę o zakład, że dysk sąsiada nie zawierał starej instalacji proxmoxa, tylko co najwyżej Windows, a zatem nie było tam partycji trudnych do usunięcia (w szczególności lvm)
-
archiwum z obrazem oczywiście musi być właściwe (systemu na inną architekturę procesora po prostu nie uruchomimy na x86-64, a w ogóle to każdy obraz ma jakieś konkretne zastosowanie), ale w kontekście wcześniej opisywanych problemów (problem z przepisaniem obrazu) nie ma to żadnego znaczenia - Balena Ether przepisuje na nośnik obraz “tak jak jest” bez zwracania uwagi jaka ma być platforma docelowa (dlatego robiąc to pod Windows, zdarza się że Windows zaczyna się burzyć i chce formatować świeżo przygotowany nośnik, bo nie rozpoznaje m.in. partycji linuxowych i uważa nośnik za niesformatowany), więc nawet jeśli wybierzemy niewłaściwy obraz, to on i tak się znakomicie przepisze na dysk, tylko to nie zadziała na późniejszym etapie.
Swoją drogą gdyby dla Balena Ether miało znaczenie, że docelowa platforma sprzętowa czy programowa ma być inna od tej na której aktualnie pracuje, to w ogóle używanie BE nie miałoby sensu, bo to by uniemożliwiało przygotowanie choćby karty z obrazu dla RPi.
No i kwestia ostatnia
- Balena Ether ma nieco zwaloną obsługę błędów i nie był to pierwszy przypadek, gdy błąd był zupełnie od czapy.
oraz ostatniejsza i chyba kończąca temat
- Podczas wizyty w BIOSie trzeba jeszcze dokonać paru ustawień o których nie wspomnieliśmy, ale najbardziej kluczowe jest ustawienie, by sprzęt się włączał wraz z pojawieniem się zasilania (musi sobie jakoś radzić z awariami zasilania) oraz jakaś sensowna czystka w kolejności bootowania (sugeruję pozostawienie tylko eMMC jako urządzenia z którego wstaje system), zdecydowanie odradzam natomiast uruchomienie opcji fast boot (można w ten sposób sobie odciąć możliwość następnej wizyty w BIOSie).
Przyznam, że tego nie sprawdzałem, ale będę miał okazję już w weekend i z czystej ciekawości zainstaluję na nowym dysku Proxmoxa zanim zacznę instalację HAOS na tym dysku.
@skalarro fajnie, że się udało, co prawda z dużą pomocą kolegi @szopen , ale chyba masz to co chciałeś. Piszę chyba bo rodzi się kilka pytań, na które musisz sobie sam odpowiedzieć.
Czy w przypadku awarii jednego z nośników, dasz sobie radę?
Czy masz świadomość, że system na eMMC będzie się uruchamiał znacznie wolniej? Dotyczy to zaróno zaników zasilania, jak comiesięcznych aktualizacji.
Tu masz dość stare porównanie bo z 2018 roku, czyli okresu w którym wyprodukowano Twojego DELL
I na koniec, czy w przypadku kolejnej migracji, a tego wykluczyć nie można, poradzisz sobie z takim procesem, mając swiadomość, że twoje dane są na innym nośniku niż system.
1 polubienie
Dużo? ogromną. Kolega poprowadził mnie za rączkę przezcały proces. Poświęcił mi cały wieczór.
Aż tak bardzo wolniej nie jest. Jak nie będzie się odpalał ze 3 razy dziennie to nie ma większego znaczenia czy wstanie w minute czy pół.
pewnie nie ;/
Przypuszczam, że nie masz porównania, ale jak nie przeszkadza to gitara.
Trochę mnie rozczarowałeś odpowiedzą na ostatnie, przecież jak zrobisz pełny backup , to odtworzysz po instalacji na nowym nośniku. Będzie trochę trwało, ale da radę.
W moim mniemaniu trochę gorzej będzie jak coś się stanie z jednym z dysków, ale nie chcę krakać 
Kwestię utraty wydajności (czyli konkretnie wolniejszego startu systemu) poruszyłem dawno temu, u siebie mam bezpośrednie porównanie, bo zrobiłem sobie “downgrade”, czyli przeniosłem się z systemu na ssd na system na eMMC wydajnościowo raczej porównywalny z tym z twojego obrazka, bo to ta sama epoka sprzętu.
De facto to była migracja z NUC6CAYH na NUC6CAYS, ale oprócz braku/obecności eMMC są to dokładnie identyczne konstrukcje i po zwykłym przełożeniu ssd obie konstrukcje mają identyczną wydajność, aby było weselej to taką zmianę zrobiłem na najbardziej rozbudowanej instalacji i mi to nie przeszkadza, więc chyba nie jest aż tak tragicznie jak się wydaje (po obejrzeniu syntetycznych benchmarków), a dodam, że prędzej spodziewam się awarii marnego ssd niż tego, że padnie wlutowane eMMC.
tak się prezentują dyski i partycje po migracji
Może ujmę to innymi słowami - gdyby wydajność eMMC miała faktycznie realny wpływ na komfort pracy, to po pierwsze wróciłbym z konfiguracją “tylko ssd”, a po drugie bym przed tym ostrzegał wielkimi literami.
Co do padu jednego z nośników w takiej konfiguracji 2-dyskowej, to
- w przypadku awarii eMMC - zakładam że to się nie stanie w ciągu 10 lat (po prostu wiem jak to wygląda technologicznie), ale procedura naprawcza polega na wyłączeniu tego nośnika w BIOSie i instalacji na ssd całości, z wykorzystaniem ostatniego dobrego pełnego backupu (jest możliwa też bardziej skomplikowana procedura nawet jeśli nie było świeżego backupu umożliwiająca przeniesienie 100% danych, ale może nie będę jej opisywał)
- w przypadku padu ssd najprostsza procedura naprawcza wymaga kilku prostych ruchów - utworzenia pod linuxem pustej partycji ext4 na nowym ssd i ustawienia etykiety partycji (na
hassos-data-external) i oczyścicie przywrócenia backupu, ale można też dokonać ponownej instalacji w sposób opisany wyżej (moim zdaniem to więcej roboty) i na samym końcu przywrócenia backupu. W przypadku awarii nośnika danych oczywiście nie mamy alternatywnej procedury i odzyskujemy tylko to, co jest w backupie.
Oczywiście podstawa to regularne cykliczne backupy (pełne lub z wykluczaniem potencjalnych multimediów) na zewnętrznym nośniku lub w chmurze (polecam nieoficjalny Dodatek do backupów w gdrive, ale istnieją też inne podobne rozwiązania również jako nieoficjalne Dodatki umożliwiające np. backup na nośniku USB).
Bo jeśli nie było backupów, to znaczy, że dane nie były ważne.
@skalarro
Będę jeszcze miał prośbę o screenshoty (lub skopiowanie tekstu), bo w ostatnich wydaniach HAOS zmieniono nazewnictwo partycji, więc warto by było to uaktualnić.
Chodzi o zawartość tych zakładek, które u mnie się nazywają mmcblk0p8 i sda1) celowo na obrazkach ich nie rozwijałem, bo mam przeniesione partycję inną metodą jeszcze sprzed istnienia tego skryptu, który się uruchamia jednym klikiem w GUI)
Instalacja od samego początku - tylko jeden dysk.
"SDA1" /dev/disk/by-partlabel/hassos-boot
"SDA2" /dev/disk/by-partlabel/hassos-kernel0
"SDA3" /dev/disk/by-partlabel/hassos-system0
"SDA4" /dev/disk/by-partlabel/hassos-kernel1
"SDA5" /dev/disk/by-partlabel/hassos-system1
"SDA6" /dev/disk/by-partlabel/hassos-bootstate
"SDA7" /dev/disk/by-partlabel/hassos-overlay
"SDA8" /dev/disk/by-partlabel/hassos-data
No i rozwiń sda8 (bo to typowa instalacja)
to co interesujące jest tu
a tak naprawdę trzeba przesunąć trochę w prawo
Tylko to było pytanie przede wszystkim skierowane do @skalarro
bo w typowej instalacji z nieprzeniesioną partycją, to wiem co tam ma być (dwa razy końcówka […]/hassos-data)
oto przykład dla nvme (instalacja typowa)
natomiast zmieniły się skrypty przerzucające partycję danych w inne miejsce
/dev/disk/by-id/wwn-0x50025385500da20a-part8 /dev/disk/by-label/hassos-data
Dziwnie, ale OK nie wnikam, zrób screenshota - ważne jest co jest w jednej linii tam gdzie by-label edit: de facto chodzi mi o by-partitionlabel ale obie ścieżki są ważne
popatrz na to
DEVLINKS: >-
/dev/disk/by-id/ata-Samsung_SSD_840_Series_S14ENEACC06128A-part8
/dev/disk/by-id/wwn-0x50025385500da20a-part8 /dev/disk/by-label/hassos-data
/dev/disk/by-partlabel/hassos-data
/dev/disk/by-partuuid/a52a4597-fa3a-4851-aefd-2fbe9f849079
/dev/disk/by-path/pci-0000:00:1f.2-ata-2-part8
/dev/disk/by-path/pci-0000:00:1f.2-ata-2.0-part8
/dev/disk/by-uuid/4862efdc-bb3f-4b74-9a56-6fbfe50f09c5
DEVNAME: /dev/sda8
DEVPATH: /devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/sda8