Przechodzimy na Malinie z karty SD na dysk HDD/SSD…

Nadeszła pora…

Pora na zmianę głównego miejsca systemu Raspberry Pi. Wiele dobrego mogę powiedzieć o Raspberry Pi, ale na pewno nie to, że używanie kart pamięci (szczególnie przy wielu zapisach do loga, bazy danych, itp.) pozwala na bezstresową pracę. Ostatnio odzyskiwałem backup karty praktycznie co tydzień.

Jakoś tak się stało, że leżał mi mały dysk talerzowy 80GB ze starej PS3. Gdzieś, kiedyś w promocji kupiłem również aktywny hub USB. Niestety, napięcie na portach USB z Raspberry (nie chciałem modyfikować zmiennej max_usb_current) niby zasilało dysk, ale bardzo niestabilnie. Podłączyłem dysk do huba, hub do USB, podpiąłem zasilanie, ruszyło. Pierwszy sukces.

Na początku warto sprawdzić jak nasz dysk przestawia się w systemie, żeby przez przypadek nie sformatować czego, czego zdecydowanie nie chcemy 😉

sudo fdisk -l

Ok, jak widać mój dysk 80GB znalazł się pod /dev/sdb/. Pod /sda/ jest pendrive na którego zapisywane są backupy i leży część danych, na przykład z bajkami dla dzieci. Tak w sumie to warto będzie to niedługo przenieść na dysk, a backupy wypchnąć albo na FTP, albo w chmurę. Może kiedyś…

Skoro wiemy jaki dysk mamy sformatować, bierzemy się do pracy.

sudo fdisk /dev/sdb

I teraz po kolei komendy (po każdej literze Enter):

d – wyczyść dysk

n – new

 p – utwórz domyślną partycję

 1 – podaj numer partycji

w – zapisz zmiany

Po kolei (dinozaury może jeszcze pamiętają to wszystko ze starych komputerów, kiedy jeszcze nie było Windows i dyski trzeba było formatować z linii poleceń 😀 ):
1. Wymazaliśmy partycje z dysku, jeżeli jakieś były
2. Utworzyliśmy partycję domyślną
3. Podaliśmy dane domyślne – dla uproszczenia, oczywiście partycji można zrobić więcej, zmienić ich rozmiar…
4. Zapisaliśmy zmiany

Pora sformatować dysk.

sudo mkfs.ext4 /dev/sdb

Póżniej musimy dysk sparować z Raspberry Pi:

sudo mount /dev/sdb /mnt

I teraz sedno, synchronizacja naszej karty SD z dyskiem. rsync zachowuje wszystkie uprawnienia, restrykcje, itp.

sudo rsync -axv / /mnt

Kilka minut i mamy kopię karty na dysku.

Wypadałoby również powiadomić Raspberry Pi, że karta SD jest potrzebna tylko i wyłącznie do 'bootowania’, cały system jest już na dysku twardym.

To ważna różnica! Raspberry Pi 3 ma opcję jednorazowego przeprogramowania bitu OTP, aby bootowanie odbywało się bez użycia karty SD, ale osobiście się na to jeszcze nie zdecydowałem – po kilku tygodniach testów możliwe, że tak zrobię. Obciążenie karty SD jest jednak teraz minimalne i znacznie zwiększa bezawaryjność systemu.

Najpierw kopia

sudo cp /boot/cmdline.txt /boot/cmdline.txt.bak

I zmieniamy plik cmdline.txt

sudo nano /boot/cmdline.txt

Zmieniamy wartość przy root i dodajemy na końcu rootdelay

root=/dev/sdb i na końcu rootdelay=5

Efekt:

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sdb rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait rootdelay=5

Brawo! Teraz pora wyedytować fstab, aby nasz dysk zawsze się mapował i system wiedział, że 'rootfs’ jest na HDD. Czyli używamy karty tylko na moment startu Raspberry Pi, później już wszystko odbywa się na HDD.

sudo nano /mnt/etc/fstab

Zamieniamy wpis przy karcie SD na nasz HDD, stary komentujemy:

/dev/sdb       /               ext4    defaults,noatime  0       1

U mnie wygląda to tak:
proc            /proc           proc    defaults          0       0
/dev/sdb       /               ext4    defaults,noatime  0       1
PARTUUID=376f54aa-01  /boot           vfat    defaults          0       2
#PARTUUID=376f54aa-02  /               ext4    defaults,noatime  0       1
Cudnie! Teraz 
sudo reboot
Chwila stresu i powinniśmy wystartować z dysku. Jak to informatycy piszą: 'U mnie działa’.
Mam nadzieję, że teraz żadnych rozjazdów w systemie nie będę już miał.
W przyszłości przejdę na dysk SSD, gdy uda mi się kupić coś fajnego, małego w dobrej cenie.

Aaaaaa. Rozsypała mi się baza Domoticz! Co robić, co robić?

A 'rozsypać’ się może z różnych powodów. Błąd zapisu na kartę, zanik napięcia, przejście w Domoticz z wersji stable na beta i z powrotem na stable.

Jaki jest objaw? W logach Domoticz widzimy informację

’…Database is malformed…’.

U mnie konkretnie był problem z LightingLog – odpowiada on za przetrzymywanie danych archiwalnych o czujnikach – błąd był przy nocnym czyszczeniu tej tabeli. A to skutkowało zwiększoną wielkością bazy danych. U Was może być różnie. Jest to w końcu baza plikowa, bez serwisu który dba o integralność danych, itp.

Najpierw
sudo apt-get install sqlite3

Trzeba też zatrzymać serwis Domoticz

sudo service domoticz stop

Następnie

cd domoticz
sqlite3 domoticz.db
pragma integrity_check;

Nie jest dobrze! Błędy, jak widać, są i to dość dużo. Spróbujemy poradzić sobie z nimi na razie najprostszą metodą – zrzucenie struktury bazy i danych do pliku ponowne załadowanie. W 99% przypadków powinno pomóc.

Skoro jest źle – trzeba działać!

Startujemy:

sqlite3 domoticz.db

.mode insert

.output dump.sql
.dump
.exit

Co zrobiliśmy? Poleciliśmy SQLite, aby wyeksportował całą naszą bazę (wraz ze strukturą) do pliku dump.sql

Teraz załadujemy ten plik już do nowej bazy. Jak to może nam pomóc? Ano wyeksportowana została poprawna struktura tabel oraz danych z bazy, także teraz tą dobrą wrzucimy do nowej. Wszystkie dane powinny zostać poprawne. W moim konkretnym przypadku tak było – mam nadzieję, że i u Was nie będzie to nic poważniejszego.

sqlite3 domoticz1.db < dump.sql

Załadowaliśmy nasze dane do bazy domoticz1.db.

Sprawdźmy, dla pewności, czy faktycznie nam to pomogło.

Wygląda dobrze, wystarczy zastąpić domoticz.db plikiem domoticz1.db i uruchomić domoticz.


sudo service domoticz start
Gotowe!