Gdybyś coś chcący lub niechcący zmodyfikował, to się pojawi dodatkowy przycisk zapisu
Pliki otwierasz przez kliknięcie ich w browserze (lewy panel edytora), więc może coś otwarłeś nieświadomie, ale zawsze można zamknąć bez zapisywania.
Jednak jeśli to jakiś plik, którego broni system, to zachowanie może być istotnie dziwne.
Muszę mieć nadzieję, że tak było.
repack jest w twojej konfiguracji recordera
https://www.home-assistant.io/integrations/recorder/
Naprawa uszkodzonej Bazy: https://www.sqlite.org/recovery.html
Nie używam już od dawna FE, ale z tego co pamiętam nic się tam samo nie otwiera. Może przypadkowo w coś kliknąłeś? Obyś nie otwierał pliku twojej bazy danych, bo to tez może powodować uszkodzenia BD.
Ja już nie chciałem tego wczoraj poruszać, ale nie znalazłem konfiguracji history. Nie martwiło mnie to, bo dokumentacja mówi, że jeśli nie wprowadzałem zmian, to używana jest domyślna. Widzę w niektórych logach, że zapisane przez recorder, ale w integracjach go nie widzę, jak i history - powinienem?
Oczywiście, że wiem, iż nic się samo nie robi. Byłem już trochę przekonany, że zrobiła się jakaś kaszana na dysku i stąd ten niedający się zamknąć plik.
Muszę przyjąć, że jakiś otworzyłem kilkanaście tygodni temu (też tam dawno nie byłem) i zapomniałem, jednocześnie byłem przekonany, że to niemożliwe, aby wciąż oczekiwał na edycję po kilkunastu restartach i aktualizacjach.
Pomyślałem jeszcze o jednej sprawie - bo może tu jest błąd zasadniczy - jeśli, od razu po instalacji na wbudowanej MMC przeniosłem dane na dysk SSD - to miejsce na bazę danych też się przeniosło, prawda? Bo w konfiguracji mogę wybrać tylko system i zewnętrzne/sieciowe nośniki, więc…
Dzisiaj baza się zapisała, błędów nie było, wczorajsza historia jest. Czy naprawianie starej bazy i łączenie z nową ma jakieś ograniczenia czasowe? Nie wiem, czy będę mógł się tym zająć w najbliższy weekend, ale najwyżej zarwę którąś noc, jeśli to nie powinno czekać. Planowałem skorzystać z tego rozwiązania.
Tak jeśli niczego nie zmieniasz to stosowana jest konfiguracja domyślna.
Kluczowe składniki HA, które muszą pracować cały czas pod spodem nie wymagają dodatkowych integracji, jednak niektóre kwestie to zaszłości historyczne z bardzo starych wersji HA (więc jest pewna pula integracji, które są zawsze włączone, chyba, że je wyłączymy jawnie w konfiguracji YAML, ale nie polecam grzebać tak głęboko).
File Editor nie jest składnikiem HA, restart HA go nie zamyka, bo on jest osobnym serwerem pracującym we własnym kontenerze niezależnym od HA.
Dopiero restart całej maszyny (tu fizycznej, ale w wielu instalacjach wirtualnej) zamyka wszystkie kontenery.
Czyli system masz na eMMC, a tylko (aktualną) partycję danych na ssd?
Partycje mają odpowiednie etykiety (label’e), na ich podstawie system wybiera którą partycję danych ma używać do pracy. (ale jeśli nie znajdzie aktualnej to prawdopodobnie użyje starej z oryginalnej lokalizacji, nie testowałem, nie wiem, sam jedną instalację mam właśnie tak uruchomioną: eMMC na system + ssd sata na dane, działa niezawodnie od kilku lat, jeśli znajdę czas na migrację tego na nowszy sprzęt to pewnie z ciekawości zrobię eksperyment co się stanie po odłączeniu dysku z danymi, terminu nie obiecuję…).
Czy ten ssd jest podpięty przez USB?
Będą albo i nie będą, jakbyś rozwinął mmcblk0p8 oraz sda1 i przekopiował do posta zawartość każdego wielkiego szarego pola jako tekst (sformatowany jak kod), to byłby z tego większy użytek.
Jakkolwiek ja po prostu wiem jak to było projektowane (rozwiązanie pochodzi z projektu jednego z użytkowników HAOS i zostało wdrożone do standardowej instalacji), bo działo się to wtedy gdy byłem zainteresowany taką konfiguracją…
Więc nieaktywna partycja danych jest moim zdaniem na mmcblk0p8 i prawdopodobnie nazywa się hassos-data-old
a aktywna jest na sda1 i prawdopodobnie nazywa się hassos-data-external
Pytałem o USB, bo z wieloletnich doświadczeń z malinami wiem, że to jest to miejsce w którym traci się dane, z portu m.2 czy msata dysk się sam raczej nie wypnie (no chyba, że nie użyłeś stosownych śrub lub zaczepów).
A w kwestii skryptu nie będę się wypowiadał (męczyłem się kiedyś ręcznie, ale i tak nadal nie znam się na bazach danych), jeśli nie masz backupów musisz się liczyć z potencjonalną utratą całej historii.
Oczywiście:
Podsystem: block
Ścieżka urządzenia:
/dev/mmcblk0p8
Identyfikator:
/dev/disk/by-id/mmc-hA8aP__0x8fd12041-part8
Atrybuty:
DEVLINKS: >-
/dev/disk/by-diskseq/12-part8 /dev/disk/by-id/mmc-hA8aP__0x8fd12041-part8
/dev/disk/by-label/hassos-data-old /dev/disk/by-partlabel/hassos-data
/dev/disk/by-partuuid/a52a4597-fa3a-4851-aefd-2fbe9f849079
/dev/disk/by-uuid/5cb2cdc3-da4d-463a-97a2-d5fa9789cca5
DEVNAME: /dev/mmcblk0p8
DEVPATH: >-
/devices/pci0000:00/0000:00:1c.0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p8
DEVTYPE: partition
DISKSEQ: '12'
ID_DRIVE_FLASH_MMC: '1'
ID_DRIVE_MEDIA_FLASH_MMC: '1'
ID_FS_BLOCKSIZE: '4096'
ID_FS_LABEL: hassos-data-old
ID_FS_LABEL_ENC: hassos-data-old
ID_FS_LASTBLOCK: '3668731'
ID_FS_SIZE: '15027122176'
ID_FS_TYPE: ext4
ID_FS_USAGE: filesystem
ID_FS_UUID: 5cb2cdc3-da4d-463a-97a2-d5fa9789cca5
ID_FS_UUID_ENC: 5cb2cdc3-da4d-463a-97a2-d5fa9789cca5
ID_FS_VERSION: '1.0'
ID_NAME: hA8aP_
ID_PART_ENTRY_DISK: '179:0'
ID_PART_ENTRY_NAME: hassos-data
ID_PART_ENTRY_NUMBER: '8'
ID_PART_ENTRY_OFFSET: '1427456'
ID_PART_ENTRY_SCHEME: gpt
ID_PART_ENTRY_SIZE: '29349855'
ID_PART_ENTRY_TYPE: 0fc63daf-8483-4772-8e79-3d69d8477de4
ID_PART_ENTRY_UUID: a52a4597-fa3a-4851-aefd-2fbe9f849079
ID_PART_TABLE_TYPE: gpt
ID_PART_TABLE_UUID: c1d2b079-0db5-462d-81d9-634c27fa1052
ID_SERIAL: '0x8fd12041'
MAJOR: '259'
MINOR: '0'
PARTN: '8'
PARTNAME: hassos-data
SUBSYSTEM: block
TAGS: ':systemd:'
USEC_INITIALIZED: '2580356'
Podsystem: block
Ścieżka urządzenia:
/dev/sda1
Identyfikator:
/dev/disk/by-id/ata-Samsung_SSD_850_EVO_M.2_250GB_S33CNX0HC34637A-part1
Atrybuty:
DEVLINKS: >-
/dev/disk/by-diskseq/15-part1
/dev/disk/by-id/ata-Samsung_SSD_850_EVO_M.2_250GB_S33CNX0HC34637A-part1
/dev/disk/by-id/wwn-0x5002538d419c7bf7-part1 /dev/disk/by-label/hassos-data
/dev/disk/by-partlabel/hassos-data-external
/dev/disk/by-partuuid/bdcc0ad5-2b88-4944-9035-6cf3af9db4df
/dev/disk/by-path/pci-0000:00:12.0-ata-1-part1
/dev/disk/by-path/pci-0000:00:12.0-ata-1.0-part1
/dev/disk/by-uuid/5cb2cdc3-da4d-463a-97a2-d5fa9789cca5
DEVNAME: /dev/sda1
DEVPATH: /devices/pci0000:00/0000:00:12.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
DEVTYPE: partition
DISKSEQ: '15'
ID_ATA: '1'
ID_ATA_DOWNLOAD_MICROCODE: '1'
ID_ATA_FEATURE_SET_HPA: '1'
ID_ATA_FEATURE_SET_HPA_ENABLED: '1'
ID_ATA_FEATURE_SET_PM: '1'
ID_ATA_FEATURE_SET_PM_ENABLED: '1'
ID_ATA_FEATURE_SET_SECURITY: '1'
ID_ATA_FEATURE_SET_SECURITY_ENABLED: '0'
ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN: '8'
ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN: '2'
ID_ATA_FEATURE_SET_SECURITY_FROZEN: '1'
ID_ATA_FEATURE_SET_SMART: '1'
ID_ATA_FEATURE_SET_SMART_ENABLED: '1'
ID_ATA_PERIPHERAL_DEVICE_TYPE: '0'
ID_ATA_ROTATION_RATE_RPM: '0'
ID_ATA_SATA: '1'
ID_ATA_SATA_SIGNAL_RATE_GEN1: '1'
ID_ATA_SATA_SIGNAL_RATE_GEN2: '1'
ID_ATA_WRITE_CACHE: '1'
ID_ATA_WRITE_CACHE_ENABLED: '1'
ID_BUS: ata
ID_FS_BLOCKSIZE: '4096'
ID_FS_LABEL: hassos-data
ID_FS_LABEL_ENC: hassos-data
ID_FS_LASTBLOCK: '61049344'
ID_FS_SIZE: '250058113024'
ID_FS_TYPE: ext4
ID_FS_USAGE: filesystem
ID_FS_UUID: 5cb2cdc3-da4d-463a-97a2-d5fa9789cca5
ID_FS_UUID_ENC: 5cb2cdc3-da4d-463a-97a2-d5fa9789cca5
ID_FS_VERSION: '1.0'
ID_MODEL: Samsung_SSD_850_EVO_M.2_250GB
ID_MODEL_ENC: >-
Samsung\x20SSD\x20850\x20EVO\x20M.2\x20250GB\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_PART_ENTRY_DISK: '8:0'
ID_PART_ENTRY_NAME: hassos-data-external
ID_PART_ENTRY_NUMBER: '1'
ID_PART_ENTRY_OFFSET: '2048'
ID_PART_ENTRY_SCHEME: gpt
ID_PART_ENTRY_SIZE: '488394752'
ID_PART_ENTRY_TYPE: 0fc63daf-8483-4772-8e79-3d69d8477de4
ID_PART_ENTRY_UUID: bdcc0ad5-2b88-4944-9035-6cf3af9db4df
ID_PART_TABLE_TYPE: gpt
ID_PART_TABLE_UUID: 9661ddef-728f-4386-a48b-d215183ec0ef
ID_PATH: pci-0000:00:12.0-ata-1.0
ID_PATH_ATA_COMPAT: pci-0000:00:12.0-ata-1
ID_PATH_TAG: pci-0000_00_12_0-ata-1_0
ID_REVISION: EMT21B6Q
ID_SERIAL: Samsung_SSD_850_EVO_M.2_250GB_S33CNX0HC34637A
ID_SERIAL_SHORT: S33CNX0HC34637A
ID_TYPE: disk
ID_WWN: '0x5002538d419c7bf7'
ID_WWN_WITH_EXTENSION: '0x5002538d419c7bf7'
MAJOR: '8'
MINOR: '1'
PARTN: '1'
PARTNAME: hassos-data-external
SUBSYSTEM: block
TAGS: ':systemd:'
USEC_INITIALIZED: '2577371'
Wciąż mam backup, mam też tę bazę uszkodzoną, ale przywrócenie backupu działa do następnego poranka.
Odnośnie konfiguracji partycji - jest tak jak mówiłem (co mnie osobiście cieszy, bo to rozwiązanie miałem wprowadzone, zanim było dostępne w HAOS i nie byłem pewien czy ostatecznie nie wprowadzono jakichś zmian).
Czyli w backupie masz uszkodzoną bazę, musisz użyć “oczko wcześniejszego” backupu i problem powinien się rozwiązać (pomijając kwestię dziury w danych).
Chciałem to przemilczeć, bo osobiście przedwczoraj usunąłem wcześniejsze kopie backupów mając w głowie, że może jednak gdzieś się skończyło miejsce na dane. Zostałem z kopią z dnia awarii i z chwili po jej przywróceniu…
Bo, rozumiem, że przywrócić z backupu jedynie dane się nie da.
Temat braku miejsca umarł w tym poście
Sądziłem, że wklejając raport też go przeczytałeś…
Wstępny podgląd sytuacji z wolnym miejscem na dysku jest przecież też tutaj
ale jak rozumiem “balastu” pozbyłeś się wcześniej (więc może i wcześniej brakowało miejsca, ale musiałbyś tam mieć setki pełnych backupów by to było prawdopodobne, backupy cząstkowe tworzone przy aktualizacjach Dodatków to dosłownie kilobajty).
Używasz backupów na gdrive? to szybko sprawdź czy coś nie ocalało
Tak, wiedziałem że jest miejsce, może nie wybrzmiało odpowiednio mocno, ale ja już dawno wiem, że było to absurdalne działanie, raczej panika. Wtedy też, miałem w głowie, że skoro mam ostatni backup to poprzednich nie potrzebuję.
Nie korzystam z gdrive, niestety i też nie mam dobrego wytłumaczenia - odkładałem konfigurację dysku sieciowego, bo tyle miejsca lokalnie.
Podsumowując - pełna żenada.
Hmm to jest nieco sprzeczne z kluczowymi zasadami bezpiecznego backupu (słynne 3-2-1).
No cóż, ale skoro mleko się rozlało, to pozostaje tylko próba naprawy tej uszkodzonej bazy…
Na razie postanowiłem chwilę poobserwować, bo niestety weekend ułożył się trochę inaczej, niż myślałem. I mam kolejne pytanie, czy ten przyrost backup-u nie jest zbyt dynamiczny? Gdyby tak miało iść dalej, to w rok będzie ponad 20 GB. Gdzieś znajdę, co tak pluje logami?
Miałeś teraz pustą bazę o niemal zerowym rozmiarze jak rozumiem.
Szybki przyrost jej wielkości zostaje zahamowany dopiero po około miesiącu. (tzn. znacząco zwalnia, ale oczywiście nie do zera)
Aż mi wstyd, że tak szybko przychodzi tu wsparcie.
Bardzo dziękuję za odpowiedź.
Nie zdążyłem skończyć, ale logi nie są zachowywane w backupie.
A backup sobie możesz otworzyć narzędziami do otwierania archiwów (w rodzaju 7zip, tzn. wiem, że on sobie radzi).
Dzięki.
Zdaje się, że zaraz temat będzie nieaktualny, bo przyszła aktualizacja HA OS i po niej system wstaje już od pół godziny. To mi przypomniało, że taki problem miałem już przy poprzedniej aktualizacji, więc może jednak coś jest na rzeczy z eMMC.
Jeżeli twój plik home-assistant.log ma duży rozmiar to świadczy to o błędach, w ekstremalnych przypadkach plik ten potrafi urosnąć do rozmiaru Bazy danych w jedną noc.
No cóż nikt nigdy nie mówił żeby robić aktualizacje w dniu wydania czy nazajutrz.
Niektórzy twierdzą, że HAOS 15.0 jest spaprany (sam w ramach ostrożności jeszcze nie zrobiłem aktualizacji na zdalnym systemie, chociaż 2 inne instalacje przeżyły i jest OK), ale jeśli miałeś już wcześniej problemy z aktualizacją systemu… (tylko to NIE ma nic wspólnego z partycją danych, którą masz w innym miejscu niż system…).
Biorąc od uwagę wszystkie okoliczności które opisujesz (ale pomijając, że być może sam sobie coś nagrzebałeś…) to jak dla mnie podejrzany jest sam sprzęt na którym masz tę instalację.
To mi tak pachnie jakimś sprzętem polizingowym, być może z wieloletnim przebiegiem.
Więc tu jest podstawowe pytanie czy przeprowadziłeś dogłębne testy wszelkich komponentów przed instalacją HAOS ?
W szczególności mam na myśli RAM (którego dogłębny test sprawdza również częściowo procesor i wybrane komponenty płyty głównej) i ssd.
(o ile eMMC jest zazwyczaj niesprawdzalne, chociaż HAOS po świeżej instalacji raczej raportował stan nośnika eMMC, to stan S.M.A.R.T. jest do sprawdzenia narzędziami, które proponowałem wyżej lub wręcz z użyciem linuxa live czy nawet podpinając dysk do windowsowej maszyny nawet z użyciem przejściówki USB).
