Niespełna tydzień temu pojawiła się możliwość aktualizacji Ubuntu 25.10 do wersji 26.04 LTS. To był pierwszy raz od X czasu, kiedy nie wymuszałem aktualizacji przez -d, grzecznie czekając, jak pojawi się możliwość płynnej/bezpiecznej aktualizacji z pomocą do-release-upgrade. I doczekałem się.
Słowem wstępu, a zarazem podsumowując same różnice względem starszej wersji: nie widzę żadnej różnicy :). Brzmi to może dość dziwnie, a samą obserwację opieram na różnicach wizualnych, których nie widać, samym działaniu, oraz aktualizacji względem wersji, do wersji.
Standardowo, jak to przy aktualizacji do wyższej wersji musiały pojawić się pewne problemy, choć z perspektywy lat, uważam, że była to najprzyjemniejsza aktualizacja, co może wynikać bezpośrednio z obycia się i nastawienia do pewnych problemów, a może i z samego doświadczenia.
A no i kolejny raz potwierdza się to, że się starzeję. Zmieniłem domyślny kanał aktualizacji z normal na LTS.

Aktualizacja na laptopie
Tutaj od razu mogę stwierdzić, że nie miałem żadnego problemu, poza usilną podmianką (znowu) Firefoxa z wersji z repozytoriów na wersję snap. Dokładnie ta sama historia, która miała miejsce przy poprzedniej aktualizacji miała miejsce przy poprzedniej aktualizacji. Klasycznie podmieniła się wersja, ale fix był szybszy, aniżeli aktualizacja ;).
Update na RaspberryPi 5
W przypadku RaspberryPi sytuacja wyglądała nieco inaczej. Wszystko na pierwszy rzut oka przebiegło całkowicie bezproblemowo, do momentu, gdy chciałem dostać się do zaplecza WordPressa i Nextclouda – pojawiły się problemy z dostępem do plików.
Z początku pomyślałem, że aktualizacja zepsuła mi uprawnienia, ale te były prawidłowe. Przyznam, że dość długo walczyłem nad różnymi scenariuszami i rozwiązaniem problemu z AI, bezskutecznie.
Problematyczny okazał się PHP-FPM i (co ciekawe) był on dokładnie tak samo skonfigurowany na Ubuntu 25.10 (oraz starszych), co po aktualizacji do 26.04 (zaktualizowany został PHP 8.4 > PHP 8.5). Po rozwiązaniu problemu odniosłem wrażenie, że nie rozumiem czemu tak się stało. Konfiguracja paczek 1:1, a PHP-FPM dopiero po aktualizacji skumało, że korzystał do tej pory z innego użytkownika. Domyślnie FPM używa praw użytkownika www-data, a ja mam skonfigurowanego usera www z własną ścieżką dostępu. Przy domyślnej konfiguracji komplikuje to działanie.
Po kilku nierównych godzinach walki, znalazłem przyczynę w pliku /etc/php/8.5/fpm/pool.d/www.conf. Dokładnie chodzi o linie:
28 user = www #wszędzie był www-data
29 group = www
...
53 listen.owner = www
54 listen.group = www
Po drodze poprawienie jeszcze kilka rzeczy w konfiguracji PHP (upload_max_filesize oraz post_max_size), restart:
systemctl restart php8.5-fpm.service apache2.service
I działa.
Finalnie, po przemyśleniach, mój główny trop prowadził do błędnej interpretacji/konfiguracji apache2, który korzystał z mod_php zamiast obecnego i skonfigurowanego PHP-FPM. Nie wiem dlaczego tak się do tej pory działo, tym bardziej, że z konfiguracji takiej korzystam od PHP w wersji (co najmniej) 8.1 i do tej pory działało.


Dodaj komentarz