Tag: Debian

W połowie poprzedniego roku chodził mi po głowie pomysł, żeby w prywatnym desktopie wymienić pamięć z 32 GiB na 64 GiB albo nawet 128 GiB, nie dlatego żebym tego potrzebował, raczej na zapas. Przy obecnych cenach RAM-u taki zakup mocno odbił by się na kieszeni, więc mam nadzieję, że nie będę do niego zmuszony.

Być może ratunkiem na drogi RAM jest zram czyli moduł jądra Linux, który pozwala tworzyć urządzenia blokowe w RAM-ie, których zawartość jest kompresowana w locie. Jednym z zastosowań takiego rozwiązania jest utworzenie skompresowanej przestrzeni wymiany w RAM-ie. Sens tego jest taki, że w momencie gdy system zaczyna swapować to używa do tego szybkiego RAM-u, ale dzięki kompresji potrzebuje go wyraźnie mniej.

Od początku grudnia testuję zram na trzech komputerach (dwa razy Debian, jedno Ubuntu). Póki co jestem pod wrażeniem tego rozwiązania, bo odczuwalnie przesuwa granicę wykorzystania pamięci RAM, przy którym używanie komputera jest komfortowe. Jednocześnie jak dotąd nie zauważyłem żadnych problemów wynikających z używania zram.

Przykładowo, na służbowym laptopie z 32 GiB RAM -u po przekroczeniu 26 GiB system zaczynał zrzucać pamięć na dysk, ale bez odczuwalnego spowolnienia, a powyżej 30 GiB cały system stawał się mniej responsywny. Po włączeniu zram nawet przy wykorzystaniu 35 GiB pamięci system wciąż działa płynnie.

Stopień kompresji przy użyciu algorytmu lz4 oscyluje w okolicach 3:1, zazwyczaj nieco powyżej, a czasami trochę mniej. Poniżej przykładowy wynik polecenia zramctl, które pokazuje aktualne statystyki:

NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4          12,4G   6G  1,8G    2G      12 [SWAP]

Jak widać, aktualnie w przestrzeni wymiany jest 6 GiB danych, ale zajmują one tylko 1,8 GiB.

Póki co nie włączyłem zram na serwerach z Proxmoxem, bo doszukałem się informacji o potencjalnych problemach, a na szczęście do serwerów kupiłem RAM ze sporym zapasem kiedy był tani.

Oczywiście, że działa i to bez żadnych kombinacji. Poniżej opiszę dlaczego u mnie nie zadziałało i jak to naprawić.

Tytułem wprowadzenia, robię przymiarki do przyspieszenia sieci domowej do 10 Gb/s. Do komputera stacjonarnego kupiłem kartę Mellanox ConnectX-3 (MCX311A-XCAT) na PCI Express. Jakież było moje zdziwienie, kiedy po zainstalowaniu karty w komputerze i uruchomieniu Debiana po karcie nie było ani śladu. Nie to, że nie została rozpoznana czy nie został załadowany moduł jądra. Po prostu pustka, ani lspci ani dmesg nie pokazały żadnej informacji związanej z kartą. Oczywiście przeszedłem standardową procedurę od wyjęcia i ponownego włożenia karty do grzebanie w opcjach UEFI — na próżno.

Przełomem okazał się ten wątek na forum STH, a konkretnie informacja o zależności pomiędzy gniazdami M2 i slotami PCI Express. Sprawdziłem instrukcję do mojej płyty głównej MSI MAG B550 Tomahawk, a tam jak byk stoi, że w wypadku obsadzenia obu gniazd M2 trzeci slot PCI Express jest nieaktywny.

Po wyjęciu dysku z drugiego gniazda M2 i uruchomieniu Debiana wszystko było na swoim miejscu. Polecenie lspci -k pokazało:

04:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3]
	Subsystem: Mellanox Technologies ConnectX-3 10 GbE Single Port SFP+ Adapter
	Kernel driver in use: mlx4_core
	Kernel modules: mlx4_core

W ustawieniach systemu w zakładce Sieć pojawiło się nowe połączenie 10 000 Mb/s.

Podsumowując, karta sieciowa Mellanox ConnectX-3 działa z Debianem 12 bez żadnych kombinacji.

Swego czasu Skype na Linuksie (w tym na Debianie) był bardzo ułomny, dostępna była wyłącznie wersja 32-bitowa, a instalacja była upierdliwa. Między innymi dlatego starałem się unikać Skype’a.

Niedawno zostałem zmuszony do przeproszenia się ze Skype’em i ku memu zaskoczeniu okazało się, że Skype for Linux dojrzał. Ze strony można pobrać pakiet DEB, a instalacja sprowadza się do zwyczajowego:

dpkg -i /home/joe/Pobrane/skypeforlinux-64.deb

Instalator dodaje repozytorium do listy źródeł apta, ale nie pobiera klucza, więc po wykonaniu aptitude update pojawi się błąd:

W: Błąd GPG: https://repo.skype.com/deb stable InRelease: Następujące podpisy nie mogły zostać zweryfikowane z powodu braku klucza publicznego: NO_PUBKEY 1F3045A5DF7587C3
E: The repository 'https://repo.skype.com/deb stable InRelease' is not signed.
E: Failed to download some files
W: Nie udało się pobrać https://repo.skype.com/deb/dists/stable/InRelease: Następujące podpisy nie mogły zostać zweryfikowane z powodu braku klucza publicznego: NO_PUBKEY 1F3045A5DF7587C3
E: Nie udało się pobrać niektórych plików indeksu, zostały one zignorowane lub użyto ich starszej wersji.

Żeby go naprawić wystarczy pobrać klucz GPG:

curl https://repo.skype.com/data/SKYPE-GPG-KEY | apt-key add -

Sama aplikacja (w wersji 5.3.0.1) zdaje się działać poprawnie i stabilnie, niestety wciąż brakuje w niej niektórych funkcji, np. Udostępniania ekranu podczas rozmowy konferencyjnej.

Przy próbie wykonania aktualizacji listy pakietów aptitude zakomunikował mi rzecz następującą:

E: The repository 'https://deb.opera.com/opera-stable stable Release' does no longer have a Release file.

Najwyraźniej w repozytorium Opery zaszły jakieś zmiany. Zajrzałem na adres repozytorium i faktycznie we wskazanym katalogu pliku Release nie było, ale za to w podkatalogu opera znajdowały się wszystkie niezbędne pliki. Wobec tego otworzyłem plik /etc/apt/sources.list.d/opera-stable.list i poniższą linijkę:

deb https://deb.opera.com/opera-stable/ stable non-free #Opera Browser (final releases)

zamieniłem na taką:

deb https://deb.opera.com/opera-stable/opera testing non-free

Po tym zabiegu aktualizacja przebiegła bez problemów.

Dodam, że korzystam z Debiana w wersji testing (obecnie stretch) i dlatego podałem taką dystrybucję.

Da się? Da się! Tak w skrócie można podsumować moje podejście do połączenia laptopa z Linuksem do głośników bez użycia kabli. Poszło łatwiej niż sądziłem, prawie plug & play.

W sumie wszystko co musiałem jest elegancko opisanie w debianowej wiki. Na początek należy się upewnić, że wymagane pakiety są zainstalowane:

aptitude install pulseaudio pulseaudio-module-bluetooth pavucontrol bluez-firmware

U mnie ich brakowało, ale mój system instalowałem z wersji minimalnej, nie lubię mieć w systemie rzeczy, których nie używam. Potem warto zrestartować usługę bluetooth i dźwięku:

service bluetooth restart
killall pulseaudio

Ostatnim krokiem jest sparowanie głośników z komputerem podobnie jak każdego innego urządzenia.

Gdy urządzenie jest sparowane wystarczy przełączyć wyjście na głośniki bluetooth.

Dzięki przenośnym głośnikom mogę cieszyć się dźwiękiem z laptopa nie tylko przez słuchawki (te wbudowane pierdziawki nie nadają się prawie do niczego). Wiem też, że mój następny amplituner powinien być wyposażony w bluetooth. Gdy go kupię dźwiękiem z mojego laptopa będą się również mogli cieszyć sąsiedzi. ;-)

Kiedy po aktualizacji pakietów system nie wstaje to wiedz, że coś się dzieje. W moim przypadku uruchamianie zdychało przy uruchamianiu powłoki graficznej. W tym wpisie pokażę jak można zdiagnozować przyczynę i skutecznie naprawić system w jednym z takich wypadków.

Pierwszym krokiem przy diagnozowaniu problemów z X-ami jest sprawdzenie logów.

# grep '(EE)' /var/log/Xorg.0.log

[    13.384] (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: libGL.so.1: cannot open shared object file: No such file or directory
[    13.384] (EE) Failed to load module "glx" (loader failed, 7)

Ewidentnie w systemie brakowało biblioteki libglx.so. Należy więc sprawdzić jej zależności.

# ldd /usr/lib/xorg/modules/extensions/libglx.so 
	linux-vdso.so.1 (0x00007fffad3fd000)
	libGL.so.1 => not found
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb41bf2f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb41bd2b000)
	libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fb41bb05000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb41b804000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb41b45b000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fb41b232000)
	libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007fb41b007000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fb41adf5000)
	libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fb41abf2000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fb41a9ec000)
	libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007fb41a7ea000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fb41a4a7000)
	libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007fb41a28e000)
	libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007fb41a089000)
	libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007fb419e86000)
	libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007fb419c83000)
	libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007fb419a7c000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fb41985a000)
	libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007fb419657000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fb419451000)
	libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007fb419243000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb41c62f000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fb41903f000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fb418e39000)

Dzięki ldd wiedziałem że brakuje pliku libGL.so.1. Sprawdziłem, że powinien znajdować się w pakiecie libgl1-mesa-glx, więc sensownym posunięciem wydaje się ponowna instalacja tego pakietu.

# aptitude reinstall libgl1-mesa-glx

Niestety, to nie pomogło. Archiwum z pakietem zawierało potrzebny plik, ale instalator z nieznanych mi względów go nie kopiował. Zrobiłem to za niego, skopiowałem z:

/var/cache/apt/archives/libgl1-mesa-glx_10.5.9-2_amd64.deb

do:

/usr/lib/x86_64-linux-gnu/libGL.so.1
/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0