Tag: debian

Opublikowane w

Polecenie su – zmiany

Jakiś czas temu zauważyłem, że polecenie su w moim Debianie unstable na domowym desktopie zmieniło zachowanie. Na koncie root przestał działać skrypt do aktualizacji systemu i usypianie.

Szybko sprawdziłem i oczywiście chodziło o PATH. Dopisałem pełne ścieżki do poleceń i prawie zapomniałem o sprawie, przypuszczając, że chodzi o jakiś chwilowy błąd w którymś z pakietów.

Jednak problem nie zniknął, więc postanowiłem sprawdzić dokładnie, co się wydarzyło. Na pierwszy ogień poszło sprawdzenie /etc/profile, w którym znalazłem spodziewane:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

Również w /etc/login.defs wszystko wyglądało poprawnie:

# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Skończyły mi się pomysły, więc udałem się na kanał #debian-next z pytaniem, czy to błąd, czy może były ostatnio jakieś zmiany. I okazuje się, że zmiany były, grubsze, dotyczące polecenia su.

Uprzednio, wydanie „gołego” polecenia su zmieniało użytkownika na root oraz ustawiało należną mu ścieżkę. Obecnie należy podawać su – (forma niezalecana) lub, lepiej, su -l, aby osiągnąć ten efekt.

I jeszcze co ciekawsze fragmenty dokumentacji (man su). Było:

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.
[...]
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

Aktualnie jest:

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME
if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing envi-
ronments.
[...]
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make the shell a login shell

Więc gdyby komuś w jakiejś debianopodobnej dystrybucji niebawem polecenie su przestało ustawiać PATH, to najprawdopodobniej chodzi o tę zmianę.

Opublikowane w

Debian SID jest czasem zepsuty

Niezbyt krótki wpis o urokach Linuksa na desktopie, o tym, że człowiek uczy się całe życie i o tym, czemu warto jednak korzystać z Debiana w wersji unstable AKA SID.

I przekornie zacznę od końca. Dawno temu przeczytałem świetny wpis o tym, dlaczego Debian unstable nie zasługuje na tę nazwę. Jak lubię Debiana i od dawna jest to mój podstawowy system na desktop, jeśli tylko mogę go używać (z polityką firmy się nie dyskutuje; nie każdy soft działa na Linuksie), tak używanie wersji stabilnej było nieco męczące, choćby ze względu na nieco stary soft. Przypominam, że było to w czasach, gdy backports nie były oficjalną częścią dystrybucji.

Radziłem sobie na różne sposoby – a to używając pakietów z wersji testing lub unstable, a to robiąc backporty. Jakoś to działało, ale wpis mi się spodobał i stwierdziłem, że dam szansę wersji unstable. Ku mojemu zaskoczeniu, zrobiło się dużo prościej i wcale nie mniej stabilnie. Rzekłbym nawet, że problemów z aktualizacją pakietów jest znacznie mniej, niż przy mieszaniu wersji. Nie to, że zawsze wszystko działa, ale konieczność downgrade pakietu, bo jakaś kluczowa funkcjonalność nie działa, zdarzyła mi się małe parę razy. W ciągu kilku lat.

No i właśnie, wróciłem z konfy, odpalam rano do kawy komputer, by sprawdzić pocztę i… nie wstał. Czarny ekran z kursorem, nawet nie migającym. Przejście do trybu tekstowego nie działa. I ciężko stwierdzić, która aktualizacja namieszała, bo zwykle usypiam laptopa, zamiast wyłączać. Smuteczek i zły moment.

W jakieś pół godziny nie udało mi się do niczego sensownego dojść, poszedłem do pracy. Po powrocie nie było wiele lepiej. Uruchomienie w single mode i aktualizacja pakietów nie pomogła, choć bardzo liczyłem na to.

Po krótkiej walce udało mi się za to ustalić, że wina leży w okolicy xorg. Tu słowo wyjaśnienia i ważna uwaga. Laptop to Dell Vostro 1440 i ma dwie karty graficzne. I zawsze były z nimi przygody, głównie za sprawą niedziałającego przełączania między nimi. Nie żeby mi jakoś specjalnie zależało na konkretnej – jak były działające sterowniki, to korzystałem z ATI, jeśli nie – z Intela, a przełączałem je przy pomocy zmiany konfiguracji w xorg.conf, dlatego w ogóle ten plik posiadam. Pamiętam, że kiedyś przestała działać mysz i klawiatura i musiałem dopisać stosowne sekcje w xorg.conf. I w ogóle przez lata zebrało się kilka wersji tych konfiguracji, chociaż gdzieś tak od dwóch korzytałem z tej samej.

W każdym razie, po nieco dłuższej walce z downgrade podejrzanych pakietów i zasięgnięciu języka na IRCu udało mi się uruchomić Xy, ale… znowu bez klawiatury i myszy. Dopisywanie stosownych sekcji w xorg.conf powodowało albo powrót do niedziałania grafiki, albo nie przynosiło efektów. Stwierdziłem, że pomysły mi się skończyły i pora na bardziej radykalne rozwiąznia, czyli sprawdzenie, jak też wygląda konfiguracja Xów i działanie pod Debianem live. I o dziwo nie miał najmniejszych problemów, mimo braku xorg.conf. Jednak Debian live jest oparty o wersję stabilną, nie unstable.

Wygenerowałem xorg.conf na live, potem jeszcze trochę poszukałem i znalazłem rozwiązanie. Okazało się, że wszystkie pakiety były w porządku, za to brakowało mi w systemie pakietu xserver-xorg-input-evdev – pewnie został usunięty przy ostatniej aktualizacji, a ja tego nie zauważyłem. Po jego doinstalowaniu zarówno klawiatura jak i mysz działają.

Pochwaliłem się na IRC (kanał debian-next na OFTC) i wywołałem spore zdziwienie. Po pierwsze, wszystko powinno działać bez xorg.conf. Za to warto mieć zainstalowane xserver-xorg-input-libinput oraz xserver-xorg-input-all, które to pakiety instalują się domyśnie przy instalacji xserver-xorg. Zapewne kiedyś były zainstalowane lecz usunąłem je przy jakichś problemach z aktualizacją pakietów – uroki SIDa. I stąd całe zamieszanie.

Piszę o tym, bo mimo wszystko polecam Debiana unstable na dekstop, a tego typu problemy to wyjątek. Nie zmienia faktu, że łącznie zeszły mi ze trzy godziny na przywrócenie pełnej funkcjonalności systemu. Pozostało mi doinstalowanie brakujących pakietów i wypróbowanie działania bez xorg.conf, ale chwilowo nie mam weny. Pewnie wkrótce zaktualizuję wpis.

UPDATE: Po doinstalowaniu obu brakujących pakietów i skasowaniu xorg.conf wszystko działa. Czyli całe zamieszanie z powodu przekombinowania było.

Opublikowane w

Update

Na blogu cisza i pozornie nie dzieje się nic. Pozory jednak mylą, choć łapię się na tym, że nie chce mi się pisać osobnych wpisów o drobiazgach. Jest w tym zasługa Blox, który działa… tak jak działa. Statystki pokazują dostępność 99,9% dla obu blogów i… nie jest to przypadek. 502 Bad Gateway lata często. Zgłaszałem i mi się znudziło. Nie jest na tyle źle, żebym się spakował z miejsca, ale drażni i zniechęca.

W zasadzie wszystkie ważniejsze systemy podniosłem do Stretch. Większych problemów nie było. Jedyne co, to po upgrade przestała działać planeta Joggera. Paczka wyleciała ze Stretch, wersja z Jessie nie chciała działać. Postawiłem kontener z unstable i… też nie działało. Skończyło się kontenerem z Jessie, wszystko póki co działa, ale pewnie przy końcu aktualizacji Jessie będzie trzeba coś z tym zrobić. Być może zmienię silnik.

Z racji nowych zabawek (Orange Pi Zero) i średniego wsparcia nowych wersji Debiana dla różnych SoC zacząłem się bawić builderem Armbiana. Fajna zabawka, pewnie pobawię się nieco więcej w najbliższym czasie. Marzy mi się budowanie obrazów dla Stretch, zmiana powinna być prosta, choć toolchainy i ilość miejsc gdzie coś może pójść nie tak trochę przeraża – nie znam rozwiązania.

Bardzo spodobał mi się ESP8622 i MicroPython. Będę się bawił, już kupiłem – leży i czeka. Pewnie będą jakieś wpisy z tych zabaw, chociaż tak naprawdę wszystko jest do znalezienia w sieci. Imponujące jest niskie zapotrzebowanie na prąd, zwł. w deep sleep. Chociaż przy używaniu WiFi podobno znacznie rośnie. Niemniej, ma to szansę być autonomiczne jeśli chodzi o zasilanie przy użyciu jedynie niewielkiego panelu solarnego, czego o SoC pokroju RPi nie da się powiedzieć. Ogólnie są świetne projekty oparte o solary, ceny rozwiązań bardzo spadły. Sensu ekonomicznego czy ekologicznego z tego co widziałem w wyliczeniach jeszcze nie ma (i to dla San Francisco) ale niezależność energetyczna (światło, komputer, smartfon, dogrzewanie kawalerki) z jednego panela w cenie $200 za kompletne rozwiązanie robi wrażenie.

Trochę czasu schodzi na ogarnianie przemeblowań w domu. Trochę koniec prowizorek – połączyłem biurka i mam teraz narożne, co przekłada się na dobrą miejscówkę do psucia różnych zabawek. Po pierwsze sporo miejsca, po drugie w końcu jest dostępny prąd. Jeszcze muszę dopracować, ale kierunek mi się podoba. 😉