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.

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.

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.

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ć.

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.

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.

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.

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.

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

Przeglądając ostatnio log systemowy, zauważyłem, że pojawia się w nim komunikat kernel: ENERGY_PERF_BIAS: Set to 'normal', was 'performance' . Co prawda korzystam z laptopa i cokolwiek związane z energią ustawione w trybie wydajności nie zawsze zdaje się być optymalnym rozwiązaniem ale też moja maszyna zwykle jest podpięta do źródła zasilania i przydałoby się, by była ona skonfigurowana właśnie bardziej w stronę profilu wydajności niż oszczędności energii. Ten powyższy komunikat informuje nas zaś, że system zmienił ustawienia z performance (tryb wydajności) na normal (jakiś bliżej nieokreślony tryb normalny). Chodzi naturalnie o ustawienia trybu pracy procesora Intel. Postanowiłem zatem poszukać informacji na temat tego czym jest ten cały Energy Performance Bias (EPB) i jak go skonfigurować w odpowiedni sposób pod linux.