Debian on Morfitronik

Jak zmusić jeden proces do korzystania z VPN na linux (Wireguard)

Mikhail Morfikov — Fri, 07 Aug 2026 02:42:00 +0200

Jakiś już dłuższy czas temu opisywałem mechanizm przekierowania ruchu sieciowego jednego lub wybranych procesów do VPN na przykładzie OpenVPN pod moim Debianem. Zawarta w tamtym artykule konfiguracja jak najbardziej działa do tej pory, choć minęło już prawie 6 lat od jej wdrożenia w życie. Od tamtego momentu jednak, sporo się zmieniło w świecie linux'a, a konkretnie pojawił się wireguard, który jest nieco bardziej dostosowany do otaczającej nas rzeczywistości i kładzie na łopatki wysłużonego już OpenVPN. Nie mam nic do OpenVPN ale przydałoby się zrobić podobne rozwiązanie opisane w powyżej podlinkowanym artykule ale na przykładzie właśnie wireguard. Samo skonfigurowanie do pracy VPN na bazie wireguard jest w zasadzie dość proste i nie trzeba pisać kolejnego artykułu na ten temat. Niemniej jednak, stawiając VPN w opisany na stronie wireguard sposób będziemy przesyłać przez to połączenie cały ruch sieciowy, czego raczej nie chcemy. To tutaj właśnie zaczynają się problemy z wireguard, których w OpenVPN nie szło zaobserwować, a które uniemożliwiają poprawne działanie (zapętlanie się) połączenia VPN. Postaramy się zatem przyjrzeć nieco bliżej samej konfiguracji wireguard i spróbować sprawić, by ruch sieciowy tylko wybranych przez nas procesów był kierowany w tunel VPN.

Jak Video DownloadHelper (VDH) zabija dyski SSD (Firefox/Chrome)

Mikhail Morfikov — Thu, 22 Jan 2026 14:55:00 +0100

Jakiś już czas temu naskrobałem kawałek artykułu na temat mechanizmu Trim/discard w kontekście LUKS/LVM na dysku SSD pod Debian linux, przy okazji poruszając tam kwestie nieco daleko idącej optymalizacji systemu pod kątem przedłużenia żywotności tego typu dyskom opartym o technologię flash. Opisane w tym powyższym artykule zabiegi sprawiły, że zapis danych na tym dysku systemowym waha się w okolicy 3 GiB na dzień (średnia za rok 2024 i 2025). Gdyby ten stan rzeczy utrzymać, to ten dysk SSD posłużyłby jeszcze przez około 160 lat i taka żywotność nośnika SSD mnie jak najbardziej zadowala... Przez te dwa ostatnie lata tylko kilka aplikacji chciało zapisywać ogromne ilości danych na dysku systemowym bez wyraźnej przyczyny, np QuiteRSS, a tak poza tym, to ten dysk SSD nie wykazywał większych odchyłów od normy w kwestii zapisu danych. Niestety ten stan rzeczy uległ zmianie kilka dni temu. Szukając przyczyny udało się zawęzić krąg podejrzanych do przeglądarki Firefox (ewentualnie też Google Chrome i Chromium). Okazało się, że jeden z jej dodatków, a konkretnie Video DownloadHelper (VDH), z jakiegoś powodu zapisuje ogromne ilości danych w katalogu profilu tej przeglądarki (tj. w ~/.mozilla/firefox/ ). Pobierając dużo materiałów audio/video, np. z YouTube czy CDA, bardzo szybko nam taki dysk SSD padnie i to bez znaczenia czy docelowy katalog zapisu pobranych danych z internetu mamy ustawiony, np. na osobnym dysku HDD. Czy istnieje zatem jakiś sposób, który by powstrzymał dodatek Video DownloadHelper od zniszczenia nam dysku SSD?

Aktualizacja firmware odbiornika Logitech Unifying na Debian Linux

Mikhail Morfikov — Fri, 16 May 2025 18:20:00 +0200

Od wielu lat próbowałem rozstać się z moją leciwą już klawiaturą Logitech Media Keyboard Elite, która działała u mnie od początków przesiadki na linux'a, czyli ponad 15 lat. Nic tej klawiaturze nie dolega i dalej sprawnie działa ale ma jedną cechę, której nie da się wyeliminować. Mianowicie jest ona przewodowa. Przez te wszystkie lata próbowałem znaleźć klawiaturę bezprzewodową ale nie dało się. Takie klawiatury kosztowały blisko 500-1000zł, a te tańsze były pod względem jakości typowo chińskie. Do tego doszła nowa technologia komplikująca niesamowicie budowę klawiszy, przez co te klawiatury praktycznie są nierozbieralne, np. na potrzeby czyszczenia. Nie wiem ile razy przez te prawie 20 lat czyściłem mojego Logitech'a (kompletne rozkręcenie i powyciąganie klawiszy) ale obstawiam, że co najmniej kilkanaście razy (średnio raz do roku). Z przycisków nawet jedno oznaczenie się nie starło. Dlatego też miałem ogromne problemy znaleźć coś bezprzewodowego, w miarę taniego, co by mi posłużyło kolejne dwie dekady. Gdy straciłem już wiarę w producentów klawiatur, udało mi się za 50zł dorwać klawiaturę (używaną) od Logitech. Jest to model Logitech K350, który jest bardzo podobny do tej mojej starej klawiatury, z tą różnicą że jest on bezprzewodowy. Do tej klawiatury jest dostarczony odbiornik Logitech Unifying i całość w zasadzie działa bezproblemowo na moim Debianie, choć trzeba było parę rzeczy skonfigurować. Nie obyło się także bez aktualizacji firmware w tym odbiorniku, bo czynił on to urządzenie podatne na atak typu MouseJack.

Segfault i debug procesu z GDB/coredumpctl w Debian Linux

Mikhail Morfikov — Sun, 02 Feb 2025 23:25:00 +0100

Każdy z nas korzysta z całej masy aplikacji na swoich linux'ach. Na ogół te appki działają w sposób oczekiwany i nie ma z nimi większych problemów. Czasem jednak zdarza się tak, że z jakiegoś powodu taki program niespodziewanie kończy swoje działanie i w konsoli (czy logu systemowym) zostaje wydrukowany komunikat zawierający frazę segfault (segmentation fault, naruszenie ochrony pamięci). Ostatnio taki problem dotknął jedną z moich ulubionych aplikacji, z których korzystam na co dzień, tj. strawberry . Gdyby ta sytuacja wystąpiła raz, to pewnie nawet bym się nią bardziej nie zainteresował ale w tym przypadku ten cały segfault potrafił wyskoczyć kilka-kilkanaście razy w ciągu godziny, co trochę zaczęło mnie irytować. Postanowiłem poszukać przyczyny i nawet znalazłem stosowny bug na git projektu strawberry, no ale sytuacja niby nowa, a mi ta appka crash'owała od dobrych kilku tygodni, jeśli nie miesięcy. Dlatego też zacząłem udzielać się w tamtym wątku i przy okazji nauczyłem się jak przy pomocy gdb (GNU Debugger) pozyskać nieco bardziej użyteczne informacje i podesłać je deweloperowi aplikacji, tak by był on w stanie namierzyć przyczynę i wyeliminować zaistniały problem. W tym artykule została zebrana garść użytecznych informacji, które mogą przydać się użytkownikowi Debiana, na wypadek gdyby i jego aplikacje cierpiały na podobne problemy.

TRIM/UNMAP w dyskach SSD podłączonych via adapter USB-SATA na linux

Mikhail Morfikov — Sun, 16 Jun 2024 16:30:00 +0200

Jakiś czas temu opisywałem jak na Debianie włączyć obsługę mechanizmu TRIM (realizowanego przez polecenie fstrim ) na podpiętych do komputera dyskach SSD. Problem w tym, że dyski SSD, z którymi będziemy wchodzić w interakcję, nie zawsze będą podłączane do dedykowanych portów SATA/mSATA. Jak zachowa się zatem nasz linux, gdy będziemy chcieli podłączyć po portu USB zewnętrzny dysk SSD? Przez zewnętrzny dysk USB nie mam na myśli dedykowanych zewnętrznych dysków USB, bo te raczej nie powinny sprawiać kłopotów. Chodzi mi bardziej o wewnętrzne dyski SSD (np. ze starego laptopa), które zamkniemy w dedykowanej obudowie USB, lub też będziemy taki dysk podłączać na krótko za pomocą adaptera USB-SATA. W takich przypadkach zwykle kernel linux'a nie odważy się włączyć wsparcia dla TRIM dla nośników SSD i tak właśnie się stało w przypadku mojego nowo zakupionego dysku od Goodram, a konkretnie jest to model SSDPR-CX400-02T-G2 , który to został podłączony do portu USB3 mojego Raspberry PI (i Debiana) przy pomocy kabelka USB-SATA (Unitek USB3.1 USB-A to 2.5" SATA6G). Przez kilka miesięcy dysk sprawował się bez zarzutu ale ostatnio przy próbie wgrania na niego danych (przez sieć), transfer spadł do dosłownie pojedynczych MiB/s. Poszukałem trochę informacji i okazało się, że dla tego typu nośników trzeba ręcznie włączyć TRIM, o ile będzie to w ogóle możliwe.

Przestrzeń wymiany SWAP tylko na potrzebny hibernacji w Debian linux

Mikhail Morfikov — Wed, 10 Jan 2024 20:05:00 +0100

W obecnych czasach, rola przestrzeni wymiany w zasadzie ograniczyła się z grubsza do umożliwienia nam przeprowadzenia procesu hibernacji. Inne aspekty pracy systemu, w których SWAP brał udział zostały albo zepchnięte na margines (bardzo stare maszyny z niewielką ilością RAM), albo zupełnie wyeliminowane za sprawą nowszych technologi lub/i posiadania większej ilości pamięci operacyjnej w takich systemach. Obecnie domowy komputer z 32 GiB pamięci RAM to nic niezwykłego i przestrzeń wymiany na takich maszynach nie jest już nam w zasadzie do niczego potrzebna, bo raczej jest mało prawdopodobne, że nam tej pamięci zabraknie przy codziennym użytkowaniu naszego linux'a. Niemniej jednak, hibernacja systemu jest czymś pozytywnym z perspektywy użytkownika, bo umożliwia mu zapisanie stanu pracy przed wyłączeniem komputera i odtworzenie tego stanu po ponownym uruchomieniu systemu. Jeśli chcielibyśmy się cieszyć urokami hibernacji, to bez konfiguracji SWAP'a się nie obejdzie. Problem jednak zaczyna się, gdy mamy dysk SSD i taka przestrzeń wymiany zostanie na nim skonfigurowana. Chodzi generalnie o pewne aplikacje, które są w stanie generować bardzo dużo cache w pamięci operacyjnej, czego efektem będzie przenoszenie danych z RAM do SWAP, a to może bardzo szybko wykończyć taki nośnik flash. Dlatego też przydałoby się nieco zabezpieczyć przestrzeń wymiany przed tego typu sytuacjami, tak by można było jej używać jedynie w przypadku hibernacji.

Trim/discard przy LUKS/LVM na dysku SSD pod Debian linux

Mikhail Morfikov — Fri, 15 Dec 2023 17:00:00 +0100

Z okazji zbliżającego się końca roku, postanowiłem nieco ogarnąć swojego Debiana, tj. postawić go na nowo. Jakby nie patrzeć 4 lata korzystania z tego linux'a z włączonymi gałęziami unstable i experimental sprawiło, że trochę syfu się nazbierało. Nie chciałem też czyścić całego kontenera LUKS czy samej struktury LVM z systemowymi voluminami logicznymi na starym dysku HDD, bo zainstalowany tam system zawsze może się do czegoś przydać, np. do odratowania tego nowego linux'a. Dlatego też postanowiłem zakupić niedrogi dysk SSD (MLC, używany) i to na nim postawić świeżego Debiana z wykorzystaniem narzędzia debootstrap. Sama instalacja linux'a na dysku SSD nie różni się zbytnio od instalacji na dysku HDD, za wyjątkiem skonfigurowania w takim systemie mechanizmu trim/discard. Standardowi użytkownicy linux'a nie muszą zbytnio nic robić, aby ten mechanizm został poprawnie skonfigurowany. Sprawa się nieco komplikuje, gdy wykorzystywany jest device-mapper, który mapuje fizyczne bloki urządzenia na te wirtualne, np. przy szyfrowaniu dysku z wykorzystaniem LUKS/dm-crypt, czy korzystaniu z voluminów logicznych LVM. Dlatego też postanowiłem przyjrzeć się nieco bliżej zagadnieniu konfiguracji mechanizmu trim/discard na dysku SSD w przypadku zaszyfrowanego systemu na bazie LUKS+LVM.

Zablokowanie możliwości ładowania modułów kernela na Debian linux

Mikhail Morfikov — Tue, 13 Dec 2022 13:03:00 +0100

Kernele oferowane przez różne dystrybucje linux'a, np. Debian czy Ubuntu, są tak budowane by możliwie jak największa ilość sprzętu na takim jądrze operacyjnym nam zadziałała bez zbędnego przerabiania systemu. Takie podejście sprawia, że nowo nabyty przez nas sprzęt możemy od razu podłączyć do komputera, a stosowne moduły po rozpoznaniu urządzenia zostaną załadowane do pamięci operacyjnej, przez co my będziemy mogli wejść w interakcję z takim kawałkiem elektroniki. Problem w tym, że kernel ma bardzo dużo tych modłów. Dużo modułów, to więcej kodu, a więcej kodu to więcej błędów, które na poziomie jądra mogą być bardzo opłakane w skutkach. Z zagrożeniem, jakie niosą moduły zewnętrzne (te spoza drzewa kernela linux), można sobie poradzić podpisując kernel kluczami od firmware EFI/UEFI. W takim przypadku załadowanie niepodpisanego modułu już się nie powiedzie. Niemniej jednak, dystrybucyjne kernele mają całą masę modułów do różnorakiego sprzętu, które na etapie budowania kernela są podpisywane, co otwiera im drogę do bycia załadowanymi w naszym systemie nawet jeśli nie posiadamy urządzeń, które by użytek z tych modułów robiły. Przydałoby się zatem zabezpieczyć możliwość ładowania modułów kernela w taki sposób, by jedynie administrator systemu miał możliwość określenia jakie moduły i na którym etapie pracy systemu mogą one zostać załadowane.

Oblivious DoH (ODoH) z dnscrypt-proxy na Debian Linux

Mikhail Morfikov — Mon, 21 Nov 2022 17:42:00 +0100

Parę miesięcy temu natrafiłem na taki oto artykuł na blogu Cloudflare, który poświęcony jest poprawie prywatności wykonywanych przez klientów zapytań DNS za sprawą wykorzystania mechanizmu zwanego Oblivious DoH (ODoH). Oczywiście postanowiłem już wtedy zbadać czym ten ODoH jest ale standardowe narzędzia dostępne w linux'ie (Debian/Ubuntu) jeszcze (przynajmniej wtedy) nie dojrzały do obsługi ODoH. Obecnie już jest trochę lepiej ale Oblivious DoH wciąż jest w fazie eksperymentów (RFC9230). Póki co, jedynym znanym mi narzędziem, które posiada wsparcie dla ODoH jest dnscrypt-proxy, którego instalację i konfigurację do współpracy z dnsmasq już jakiś czas temu opisywałem. Mając wsparcie dla ODoH w dnscrypt-proxy możemy pokusić się o wdrożenie Oblivious DoH w swoim systemie i sprawdzić czy faktycznie taki zabieg przyczyni się do poprawy prywatności wykonywanych przez nas zapytań DNS i właśnie temu zagadnieniu będzie poświęcony niniejszy wpis.

Rekalibracja baterii w laptopach Lenovo ThinkPad pod linux

Mikhail Morfikov — Tue, 01 Feb 2022 18:09:00 +0100

Jakiś już czas temu opisywałem temat konfiguracji progów ładowania baterii w laptopie Lenovo ThinkPad T430, tak by przedłużyć parokrotnie jej żywotność. Niemniej jednak, ustawienie na dłuższy czas progów 30-40% nie pozostaje bez wpływu na pracę maszyny. Może i same baterie litowo-jonowe nie posiadają efektu pamięci ale elektronika, która tymi bateriami zarządza, już tę pamięć może posiadać. Chodzi generalnie o to, że brak pełnych cyklów baterii (rozładowanie do 0% i ładowanie do 100%) może powodować różne błędy w ocenie ile faktycznie tego ładunku w takim akumulatorze pozostało. Efektem tych błędów są wskazania sugerujące, że nasz laptop może jeszcze popracować, np. 20-30 minut dłużej, gdy stan faktyczny na to nie pozwala, co skończyć może się utratą niezapisanych danych w skutek nagłego odcięcia zasilania. Dlatego też jeśli wykorzystujemy jedynie pewien zakres pojemności baterii w laptopie, to co pewien czas (co 30-50 takich niepełnych cykli albo raz na 2 miesiące) przydałoby się przeprowadzić w laptopie proces rekalibracji baterii (a raczej rekalibrację jej kontrolera/elektroniki), tak by ewentualne straty pojemności zostały uwzględnione w szacunkach systemu. Zabieg rekalibracji baterii można bez większego problemu przeprowadzić z poziomu dowolnej dystrybucji linux'a, np. Debian/Ubuntu, i tym zagadnieniem się zajmiemy w niniejszym artykule.

Chroot do 32-bit systemu ARM z poziomu 64-bit linux'owego hosta

Mikhail Morfikov — Sun, 07 Nov 2021 10:20:00 +0100

Eksperymentując ostatnio z moją maszynką Raspberry Pi 4B, zaszła potrzeba, by zejść do systemu RasPiOS/Raspbian przy pomocy mechanizmu chroot. Problem w tym, że system wyrzuca komunikat: chroot: failed to run command ‘/bin/bash’: Exec format error . Niby wszystko jest na swoim miejscu ale ta widoczna wyżej wiadomość nie chce zniknąć uniemożliwiając tym samym dalszą zabawę z RPI. Okazało się, że winna jest tutaj architektura CPU. Mój laptop działa pod kontrolą 64-bitowego Intel'owskiego procesora (x64, x86-64, AMD64), na którym uruchomiony jest również 64-bitowy Debian linux. Z kolei Raspberry Pi ma 64-bitowy procesor ARM (ARMv8-A) działający pod kontrolą 32-bitowego systemu operacyjnego. Te dość spore rozbieżności sprawiają, że nie damy rady skorzystać z chroot, przynajmniej nie bez zaprzęgnięcia do tego celu emulatora QEMU.

Drukowanie zeskanowanych dokumentów tekstowych na drukarce laserowej

Mikhail Morfikov — Tue, 26 Oct 2021 19:57:00 +0200

Posiadacze monochromatycznych (czarnobiałych) drukarek laserowych zapewne spotkali się z problemem drukowania kolorowych dokumentów na tego typu urządzeniach. Nie chodzi tutaj o drukowanie obrazków czy innych elementów graficznych ale o wydrukowanie, np. zeskanowanej książki. Ostatnio przyszło mi wydrukować dokumentację techniczną dość starego urządzenia. Problem w tym, że nie był to zwykły kawałek książki, a jedynie jej skany, z których ktoś postanowił zrobić plik PDF . Takiego dokumentu "tekstowego" za bardzo nie da się wydrukować na drukarce laserowej, przynajmniej nie bez pchania się w ogromne koszty. Dla przykładu, w miejsce pożółkniętej kartki ze skanu, taka drukarka wstawi jakiś odcień szarości i w ten sposób zadrukuje tą szarością całą stronę marnując przy tym niesamowite ilości toneru, za który my będziemy musieli później zapłacić, co czyni cały proces drukowania zeskanowanych dokumentów bardzo kosztownym. Postanowiłem jednak znaleźć jakiś sposób, by tę dokumentację wydrukować, choć trzeba było pierw zająć się samymi skanami, tj. doprowadzić je do stanu, w którym można by mówić o ewentualnym ich wydrukowaniu. Okazało się, że nie jest to jakoś specjalnie trudne zadanie, zwłaszcza, gdy na linux zaprzęgnie się do tego celu ImageMagick.

Jak wyłączyć mapowanie adresów IPv4 na IPv6 w Debian linux

Mikhail Morfikov — Thu, 14 Oct 2021 23:52:00 +0200

Przeglądając ostatnio połączenia w swoim telefonie z Androidem, natknąłem się na wpisy mające w swoich adresach źródłowych ustawione IP takie, jak ::ffff:192.168.1.188 . Podobnie sprawa wygląda w przypadku adresów docelowych tego samego połączenia, tj. widnieje tam np. ::ffff:216.58.215.1 . Na pierwszy rzut oka taka konstrukcja adresu IP przypomina IPv6, przynajmniej jej pierwsza część, tj. ::ffff: , natomiast drugi kawałek już bardzo przypomina adres IPv4. Okazuje się, że za taki format adresów IP odpowiada mechanizm mapowania adresów IPv4 na adresy IPv6. Nie jest to jednak tożsame z 6to4 czy 6in4, gdzie host ze stałym publicznym adresem IPv4 jest w stanie komunikować się z hostami nadającymi po IPv6. W przypadku mapowania adresów IPv4 na IPv6, połączenia ze zdalnymi hostami mogą odbywać się zarówno po IPv4 jak i IPv6, a to z którego z tych protokołów nasz linux skorzysta zależy od tego czy taka maszyna dysponuje przydzielonym adresem IPv6. Jeśli ISP nie zapewnia nam adresu IPv6, to wtedy pakiety sieciowe będą przesyłane z wykorzystaniem protokołu IPv4. Wciąż jednak te mieszane konstrukcje adresów IP będą widoczne na wykazie połączeń w netstat/ss . Okazuje się jednak, że ten mechanizm mapowania adresów może powodować szereg problemów związanych z bezpieczeństwem systemu. Dlatego też tam gdzie to możliwe przydałoby się go wyłączyć.

Jak zaktualizować firmware custom ROM'ów w smartfonach Xiaomi

Mikhail Morfikov — Thu, 30 Sep 2021 02:43:00 +0200

Te bardziej szanujące się marki produkujące smartfony zwykle zapewniają wsparcie dla swoich urządzeń przez co najmniej dwa lata (a czasem nawet i dłużej) od momentu ich wypuszczenia na rynek. Po wgraniu sobie alternatywnego ROM'u na nasz telefon, oprogramowanie w nim może być aktualizowane przez opiekuna czy dewelopera takiego ROM'u znacznie dłużej niż producent przewidział. W ten sposób nie musimy wydawać pieniążków na nowy sprzęt, oczywiście zakładając, że mu nic nie dolega, np. pod względem wydajności, czy też ewentualnie nie zużył on się nam jakoś bardziej podczas eksploatacji. Jedną rzeczą, o której posiadacze smartfonów z Androidem zapominają po wgraniu custom ROM'ów na bazie AOSP/LineageOS, to fakt, że o ile ROM faktycznie dostaje aktualizacje czy to bezpieczeństwa, czy też upgrade do nowszej wersji Androida, o tyle sam firmware zwykle pozostaje nietknięty. W przypadku mojego modelu smartfona Redmi 9, Xiaomi od czasu do czasu wypuszcza aktualizacje firmware do tego urządzenia i przydałoby się ten firmware co jakiś czas zaktualizować. Na szczęście nie trzeba w tym celu powracać do stock'owego oprogramowania, a cały proces możemy przeprowadzić z poziomu dowolnej dystrybucji linux'a.

Kopia zapasowa danych smartfona z Androidem (OAndBackupX, Syncthing)

Mikhail Morfikov — Sun, 26 Sep 2021 16:44:00 +0200

Jak to zwykło się mawiać w świecie IT: ludzie dzielą się na te osobniki, które robią backup i te, co backup robić będą. Jakiś czas temu pochyliłem się nad zagadnieniem czy smartfon z Androidem bez Google Play Services ma sens. Poruszyłem tam problem tworzenia kopi zapasowej danych użytkownika zgromadzonych w telefonie. W tym podlinkowanym artykule zostało przestawione jak przy pomocy TWRP dokonać pełnego backupu całego systemu urządzenia i o ile pod względem technicznym takie podejście było jak najbardziej w pełni do zaakceptowania, to jednak to rozwiązanie miało dość istotną wadę, tj. na czas backup'u trzeba było wyłączyć smartfon. Parę dni temu natrafiłem na narzędzia OAndBackupX, które jest w stanie zrobić kopię zapasową wszystkich zainstalowanych w Androidzie aplikacji (oraz ich ustawień), wliczając w to nawet appki systemowe. OAndBackupX jest o tyle lepszym rozwiązaniem w stosunku do TWRP, że można przy jego pomocy robić kopię danych pojedynczych aplikacji, a nie od razu całego ROM'u, co nie tylko jest czasochłonne ale również zjada sporo miejsca na dysku komputera, czy gdzie ten backup zamierzamy przechowywać. Niestety OAndBackupX wymaga uprawnień root, zatem na stock'owym ROM'ie producenta naszego telefonu nie damy rady z tego narzędzia skorzystać. Jeśli jednak mamy alternatywny ROM na bazie AOSP/LineageOS, to przydałoby się rzucić okiem na ten kawałek oprogramowania, bo zdaje się ono być wielce użyteczne, zwłaszcza w przypadku osób mojego pokroju, czyli linux'iarzy, którzy o backup swoich danych chcą zatroszczyć się tylko i wyłącznie we własnym zakresie, zaprzęgając do pracy choćby Syncthing.

Kontrola podświetlenia klawiatury via UDEV (backlight)

Mikhail Morfikov — Sat, 04 Sep 2021 12:36:00 +0200

Ostatnio na polskim forum linux mint pojawił się wątek, w którym jeden z użytkowników miał problem z ogarnięciem podświetlania klawiatury. Chodzi generalnie o start komputera z włączonym backlight'em klawiatury, przez co trzeba to podświetlenie manualnie wyłączać za każdym razem po uruchomieniu się systemu. W przypadku mojego laptopa Lenovo ThinkPad T430, taka sytuacja co prawda nie występuje i system uruchamia się naturalnie ze zgaszoną klawiaturą. Niemniej jednak, zainteresował mnie ten problem tyle, że w drugą stronę -- chodzi o możliwość startu systemu z włączonym podświetleniem klawiatury, bo ustawienia BIOS/EFI/UEFI mojego laptopa tego aspektu pracy komputera nie są w stanie w żaden sposób skonfigurować. Okazało się, że zaimplementowanie tego typu funkcjonalności nie jest jakoś specjalnie trudne i można bez większego trudu ogarnąć backlight klawiatury przy pomocy prostej reguły dla UDEV'a.

Jak odblokować bootloader w Xiaomi Redmi 9 (galahad/lancelot)

Mikhail Morfikov — Fri, 27 Aug 2021 22:26:00 +0200

Jakiś czas temu wpadł w moje łapki smartfon Xiaomi Redmi 9 (galahad albo lancelot, bo w różnych częściach systemu jest to inaczej określone), który miał preinstalowanego Androida 10 oraz MIUI 11. Przez parę miesięcy używania telefonu, dostał on dwa albo trzy większe update całego ROM'u, wliczając w to aktualizację MIUI do 12.0.1 ze stanem zabezpieczeń na dzień 2021-01-05. Zatem ostatnia aktualizacja zabezpieczeń tego telefonu miała miejsce zaraz na początku Stycznia. Od tego czasu cisza. Niby w przypadku tego modelu telefonu aktualizacje miały być wydawane co trzy miesiące do roku 2023 ale najwyraźniej coś jest nie tak i urządzenie od ponad pół roku nie dostało żadnych aktualizacji. Niby pod tym linkiem można wyczytać informację, że planowana jest aktualizacja do Androida 11 ale prawdę mówiąc jestem nieco zawiedziony opieszałością Xiaomi. Tak się złożyło, że przez przypadek trafiłem w to miejsce na forum XDA, gdzie z kolei znalazłem m.in. ten wątek. Zatem alternatywne ROM'y na mój smartfon istnieją i tego faktu nie byłem świadomy, bo w zeszłym roku jeszcze nic nie szło znaleźć. Postanowiłem zatem odblokować bootloader w swoim Xiaomi Redmi 9 i spróbować wgrać na niego TWRP i jeden (a może nawet kilka) przykładowy ROM na bazie AOSP/LineageOS. Proces odblokowania bootloader'a w urządzeniach Xiaomi nie wymaga zbytnio wysiłku i da się go przeprowadzić w całości pod linux korzystając czy to z XiaoMiTool, czy też przy pomocy maszyn wirtualnych na bazie QEMU/KVM. Ten proces nie do końca jest dla każdego taki oczywisty, dlatego postanowiłem go dokładnie opisać.

Migracja z apt-key w Debian linux

Mikhail Morfikov — Sat, 21 Aug 2021 14:35:00 +0200

Z okazji wypuszczenia parę dni temu nowego Debiana, przeglądałem sobie notki dla wydania stabilnego pod kątem aktualizacji z buster (10) -> bullseye (11). Niby ja i tak korzystam cały czas z unstable/experimental i zwykle jestem na bieżąco ze zmianami wprowadzanymi w tej dystrybucji linux'a ale też zawsze coś może umknąć uwadze z perspektywy wielu miesięcy czy nawet kilku lat (a dokładnie 25 miesięcy). Sporo z tych rzeczy, które w tych podlinkowanych notatkach wyczytałem, miałem już załatwione wcześniej ale zapomniałem rozprawić się z repozytoriami APT. Konkretnie chodzi tutaj o odejście od apt-key , czyli narzędzia, które w Debianie używane jest do dodawania kluczy GPG do systemowego keyring'a APT. Te klucze zwykle wykorzystywane są do weryfikacji sygnatur złożonych pod zewnętrznymi repozytoriami, a że ja mam ich sporo, to musiałem się nieco zagłębić w temat i ustalić w jaki sposób od następnego wydania Debiana (bookworm/12) będzie się te klucze GPG od takich repozytoriów ogarniać. No i właśnie o tym będzie ten poniższy kawałek artykułu.

Analiza systemu plików EXT4 pod kątem formatowania większych dysków pod linux

Mikhail Morfikov — Sun, 25 Jul 2021 18:40:00 +0200

Zapewne każdy użytkownik linux'a tworzył na dysku HDD/SSD partycje sformatowane systemem plików EXT4. Prawdopodobnie też zastanawiało nas pytanie odnośnie ilości zajmowanego miejsca przez strukturę samego systemu plików, zwłaszcza w przypadku dysków o sporych rozmiarach (setki GiB, czy nawet kilka TiB). Jako, że musiałem ostatnio zmigrować kolekcję filmów ze strych dysków na jeden większy, który miał zostać podłączony pod Raspberry Pi z działającym Kodi na bazie LibreELEC, to przy okazji postanowiłem ten dysk sformatować w taki sposób, w jaki powinno się do tego zadania podchodzić wiedząc, że ma się do czynienia z dużym dyskiem, na którym będą przechowywane głównie duże pliki. Celem tego artykułu jest pokazanie jakie błędy przy tworzeniu systemu plików EXT4 można popełnić przez posiadanie niezbyt wystarczającej wiedzy z jego zakresu, oraz jak te błędy wyeliminować przed rozpoczęciem korzystania z tak nie do końca poprawnie przygotowanego do pracy dysku twardego

Aktualizacja firmware drukarki HP LaserJet P2055dn pod linux

Mikhail Morfikov — Wed, 27 Jan 2021 19:10:00 +0100

Bawiąc się ostatnio drukarką laserową Hewlett Packard (HP) LaserJet P2055dn, zauważyłem, że ma ona wgrany dość stary firmware. Naturalnie sama drukarka do najmłodszych nie należy, bo została wyprodukowana w 2011 roku ale skoro na stronie producenta jest dostępna nowsza wersja oprogramowania dla tego urządzenia, to przydałoby się je do tej drukarki wgrać. Problem jednak pojawia się w przypadku takich osób jak ja, tj. tych, które korzystają w swoim środowisku pracy z maszyn mających na pokładzie system operacyjny z rodziny jakieś dystrybucji linux'a, np. Debian czy Ubuntu. Producent drukarki udostępnia stosowne narzędzia do aktualizacji firmware ale tylko i wyłącznie dla OS z gatunku Windows. Co mają zrobić osoby, które z Windows'a nie korzystają, a chciałyby przy tym mieć aktualny firmware w drukarkach HP? Możemy spróbować postawić maszynę wirtualną na bazie QEMU/KVM, tam zainstalować Windows'a i udostępnić w obrębie tej maszyny wirtualnej drukarkę, której firmware mamy zamiar aktualizować.