Autor: pakos

raspberry swap

RPI z defaultu za dużo pamięci ani swap nie ma, ramu nie dodamy więc możemy jedynie powiększyć swap.

pi@raspberrypi:~ $ free -h
total used free shared buff/cache available
Mem: 926M 118M 758M 10M 49M 754M
Swap: 99M 99M 0B

sudo vi /etc/dphys-swapfile

zmieniamy wedle potrzeb: CONF_SWAPSIZE

CONF_SWAPSIZE=1024

i restartujemy

sudo dphys-swapfile swapoff
sudo dphys-swapfile setup
sudo dphys-swapfile swapon

pi@raspberrypi:~ $ free -h
total used free shared buff/cache available
Mem: 926M 197M 649M 30M 79M 650M
Swap: 1.0G 0B 1.0G

debian python2

Trochę zapomniałem o pythonie, szczególnie wersji 2 aczkolwiek wypadało by się go w końcu pozbyć z systemu (o ile oczywiście jakiś tool nadal go nie potrzebuje).

Warto sobie sprawdzić co mamy zainstalowane:

dpkg -l|grep python

I wywalić co nie trzeba, w moim przypadki na starym sidzie:

apt-get autoremove --purge python
apt-get autoremove --purge python2
apt-get autoremove --purge python2-minimal
apt-get autoremove --purge python2.7
apt-get autoremove --purge python2.7-minimal

Oczywiście warto zweryfikować co ma zostać usunięte, u mnie tylko cherrytree łapał się do wywalenia na co koniec końców się zdecydowałem. Cherrytree zainstalowałem z flatpaka co by się już definitywnie pozbyć pythona 2*

Debian libsqlite3-0 3.31.0-1 + firefox = crash

Prosty objaw po aktualizacji sqlite do nowej wersji:

libsqlite3-0:amd64 (3.30.1+fossil191229-1, 3.31.0-1)

Przy starcie firefoxa wywala się:

ExceptionHandler::GenerateDump cloned child 11171
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Bugi pozgłaszane:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949644 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949646 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949647

Więc na ten moment można jedynie zrobić downgrade do wersji 3.30.1+fossil191229-1 i czekać na patch.

lightdm greeter i czarny ekran

Od dłuższego czasu lightdm płata mi figla, otóż na dwóch rożnych konfiguracjach sprzętowych wygaszenie/zablokowanie ekranu nie radzi sobie z powrotem na dobre tty gdzie działa lightdm.

Przez pewnie czas olewałem, przyzwyczaiłem się do przełączania na szybko konsoli aby wrócić na odpowiednią, przez pewnie czas korzystałem z xscreensavera, przez pewnie czas ustawiałem presentation mode i w ogóle nie blokowałem ekranu, zmieniałem greeter’a.

W miedzy czasie oczywiście bugi, fora i inne zakamarki internetu, i nic. Minęło dobrych kilka miesięcy i nadal nic, już zdążyłem się przyzwyczaić do slick-greetera zamiast defaultowego lightdm-gtk-greetera ale na prawdę nie daje mi to spokoju. Może się kiedyś doczekam odpowiedzi.

Ku pamięci, gdybym kiedyś miał ten sam problem:

# grep slick /etc/lightdm/lightdm.conf 
greeter-session=slick-greeter
# dpkg -l|grep greeter
ii  slick-greeter 1.2.4-2 amd64 Slick-looking LightDM greeter

raspberrypi chroot

Ostatnia aktualizacja rpi, dokładnie pakietu raspi-copies-and-fills całkowicie poskładała mi malinę. Boot kończył się kernel panic, pomieszane biblioteki w systemie a dokładniej: 

ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

Rescue (ku pamięci /boot/cmdline.txt -> init=/bin/bash) oczywiście też nie wstawało więc pozostał tylko chroot, montujemy kartę sd w czytniku i lecim:

mkdir /mnt/rpi                                    
mount -o rw /dev/sdb2 /mnt/rpi/
mount -o rw /dev/sdb1 /mnt/rpi/boot/
mount --bind /dev /mnt/rpi/dev
mount --bind /sys /mnt/rpi/sys               
mount --bind /proc /mnt/rpi/proc                                          
mount --bind /dev/pts /mnt/rpi/dev/pts/
sed -i 's/^/#CHROOT /g' /mnt/rpi/etc/ld.so.preload
cp /usr/bin/qemu-arm-static /mnt/rpi/usr/bin/
chroot /mnt/rpi/ /bin/bash  

#w moim przypadku usunąłem wszystkie wpisy w /etc/ld.so.preload dzięki czemu system wstał i mogłem dokonać update z nowszą wersją w/w paczki.
#gdy nie majstrujemy w ld.so.preload po wyjściu z chroota dajemy:

sed -i 's/^#CHROOT //g' /mnt/raspbian/etc/ld.so.preload

I to tyle, odmontować i można probować wystartować rpi 🙂

qnap nfs export one ip

Każdemu zdarza się wpadka, tak było z firmware qnapa do kilku modeli. Wszystkie udziały exportowane dla więcej niż jednego ip niestety nie działały. W /etc/exports pojawiał się tylko pierwszy z nich mimo poprawnych ustawień.

Sprawa oczywiście prosta do rozwiązania, ręczna edycja /etc/exports, downgrade lub czekać na nowy firmware. I tutaj niespodzianka, już jest, po aktualizacji wszystko działa cacy 🙂

Realtek RTL8192CU powersaving

Pomimo iż iwconfig pokazuje power management jako off okazuje się, że z defaultu jest jednak włączone co skutkuje wyłączaniem adaptera po nieaktywności.

pi@raspberrypi:~ $ sudo iwconfig wlan0 
wlan0     IEEE 802.11bgn  ESSID:"pakosowo_2G"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 18:31:BF:36:E5:68   
          Bit Rate:144.4 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=100/100  Signal level=69/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

pi@raspberrypi:~ $ cat /sys/module/8192cu/parameters/rtw_power_mgnt
1

Power saving należy ręcznie wyłączyć w:

pi@raspberrypi:~ $ cat /etc/modprobe.d/8192cu.conf
# Disable power saving
options 8192cu rtw_power_mgnt=0

QNAP TS-231P

Prawdę mówiąc od dłuższego czasu zbierałem się na zakup nas’a z prawdziwego zdarzenia aniżeli budowanie czegoś od zera. Przez pewien czas szczątkowe funkcjonalności pełniła malina z podpiętym dyskiem na usb i pewnie jeszcze by to długo działało ale w końcu dorosłem do zakupu. Podstawowym założeniem była jak najmniejsza cena bo bądźmy szczerzy, aż takich wymagań do domu nie mam aby wydać kilka tysięcy pln.

Po przestudiowaniu ofert, opinii z dosyć wąskiej oferty w dolnej granicy cenowej wybór padł właśnie na Qnap’a, model TS-231P + dwa dyski w moim przypadku to 2x Seagate w 2TB.

Zestawu używam już prawie miesiąc i jak za taką cenę oceniłbym go bardzo dobrze, niestety trochę nie doceniłem siebie i teraz pewnie wybrałbym coś innego, a chodzi mi głownie o procesor. Tutaj jest „Annapurna Labs Alpine AL-212 (2 rdzenie, 1.7 GHz) ” czyli ARM no i 1 GB ramu. Do podstawowych funkcji jakie są przewidziane pewnie wystarcza, zużycie pewnie jest też w miarę sensowne (jeżeli kogoś interesują dokładne dane to jest tego masa na różnych stronach).

Mnie właśnie zaczęła doskwierać architektura procesora no i niewielka ilość pamięci gdy tylko zabrałem się za zabawę z lxc i dockerem, o tym przed zakupem kompletnie nie pomyślałem a co dopiero o prawdziwej wirtualizacji której tutaj brak 🙂

Druga sprawa to dyski które zakupiłem, o ile sam Qnap jest bardzo cichy w codziennej pracy to dyski strasznie głośno się zachowują, szczególnie przy dużym i ciągłym zapisie/odczycie i to jeszcze muszę dokładniej zbadać 😐

Reasumując jeśli kogoś interesuje głownie storage na backupy/filmy/muzykę i usługi typu samba/cifs/nfs/ftp/dlna itp w niskiej cenie to polecam, jeżeli coś więcej to szukałbym czegoś z procesorem z prawdziwego zdarzenia i większą ilością pamięci. Zapewne też tak zrobię jak  tylko znajdę kupca na ten model 🙂