diff --git a/lts24-lts26-upgrade/autoremove после апгрейда - как не снести нужное b/lts24-lts26-upgrade/autoremove после апгрейда - как не снести нужное.md similarity index 82% rename from lts24-lts26-upgrade/autoremove после апгрейда - как не снести нужное rename to lts24-lts26-upgrade/autoremove после апгрейда - как не снести нужное.md index 8c11c01..3505449 100644 --- a/lts24-lts26-upgrade/autoremove после апгрейда - как не снести нужное +++ b/lts24-lts26-upgrade/autoremove после апгрейда - как не снести нужное.md @@ -1,3 +1,5 @@ +# autoremove после апгрейда - как не снести нужное + После апгрейда `apt-get -s autoremove` хотел удалить 640+ пакетов. Вслепую - ни в коем случае. Что делал: @@ -13,7 +15,7 @@ apt-get -s -o Dir::State::extended_states=$HOME/копия autoremove Грабли: - `apt-mark manual пакет` помечает только родную архитектуру. 32-битную копию надо называть явно: `пакет:i386`. Иначе vdpau/libxml2 для 32-битных игр уедут; -- apt НЕ знает про то, что собрано руками в /usr/local и ~/bin. Свой ffmpeg, OBS из make install, WiVRn - их библиотеки для apt "никому не нужны". Сначала пересобрать/удалить самосборки, проверить `ldd`, и только потом autoremove; +- apt НЕ знает про то, что собрано руками в /usr/local и ~/bin. Свой ffmpeg, OBS из make install, WiVRn - их либы для apt "никому не нужны". Сначала пересобрать/удалить самосборки, проверить `ldd`, и только потом autoremove; - пакет может быть "manual" и висеть вечно (у меня libvpx9) - `apt-mark auto` ему. Перед запуском: @@ -22,4 +24,4 @@ apt-get -s autoremove | grep -E 'nvidia|linux-(image|modules)|pulseaudio' ``` Пусто - можно `sudo apt autoremove`. -После - `dpkg -l | grep ^rc` покажет удалённые пакеты с оставшимися конфигами. Они ничего не делают, `--purge` по желанию. +После - `dpkg -l | grep ^rc` покажет удалённые пакеты с оставшимися конфигами. Они ничего не делают, `--purge` по желанию. Можно забить. diff --git a/lts24-lts26-upgrade/chromium deb без снапа на 26.04 b/lts24-lts26-upgrade/chromium deb без снапа на 26.04 deleted file mode 100644 index 71a346b..0000000 --- a/lts24-lts26-upgrade/chromium deb без снапа на 26.04 +++ /dev/null @@ -1,22 +0,0 @@ -Chromium у меня шёл .deb из Debian stable через пин. Апгрейдер источник отключил, версия застряла. -На 26.04 нормальный .deb (не снап) есть в PPA xtradeb/apps. Но там ещё куча приложений - пускаем из него только chromium. - -``` -sudo add-apt-repository ppa:xtradeb/apps -``` -`/etc/apt/preferences.d/xtradeb-chromium.pref`: -``` -Package: * -Pin: release o=LP-PPA-xtradeb-apps -Pin-Priority: 1 - -Package: chromium* -Pin: release o=LP-PPA-xtradeb-apps -Pin-Priority: 600 -``` -``` -sudo apt update && sudo apt install chromium -``` -Старый пин на Debian удалить. Профиль `~/.config/chromium` остаётся тот же. - -chromium-sandbox (setuid-песочница) можно сносить, если user namespaces разрешены - Chromium сам переходит на них. diff --git a/lts24-lts26-upgrade/chromium deb без снапа на 26.04.md b/lts24-lts26-upgrade/chromium deb без снапа на 26.04.md new file mode 100644 index 0000000..3e43dd1 --- /dev/null +++ b/lts24-lts26-upgrade/chromium deb без снапа на 26.04.md @@ -0,0 +1,24 @@ +# chromium deb без снапа на 26.04 + +Хромиум у меня шёл .deb из Debian stable через пин. Апгрейдер источник отключил, версия застряла.
+На 26.04 нормальный .deb (не говноснап) есть в PPA xtradeb/apps. Но там ещё куча всякого - пускаем из него только chromium. + +``` +sudo add-apt-repository ppa:xtradeb/apps +``` +`/etc/apt/preferences.d/xtradeb-chromium.pref`: +``` +Package: * +Pin: release o=LP-PPA-xtradeb-apps +Pin-Priority: 1 + +Package: chromium* +Pin: release o=LP-PPA-xtradeb-apps +Pin-Priority: 600 +``` +``` +sudo apt update && sudo apt install chromium +``` +Старый пин на Debian удалить. Профиль `~/.config/chromium` остаётся тот же. + +chromium-sandbox (setuid-песочница) можно сносить, если user namespaces разрешены - хромиум сам переходит на них. diff --git a/lts24-lts26-upgrade/dkms не пересобрал модуль после апгрейда b/lts24-lts26-upgrade/dkms не пересобрал модуль после апгрейда.md similarity index 71% rename from lts24-lts26-upgrade/dkms не пересобрал модуль после апгрейда rename to lts24-lts26-upgrade/dkms не пересобрал модуль после апгрейда.md index 1ed66c0..a8b5a71 100644 --- a/lts24-lts26-upgrade/dkms не пересобрал модуль после апгрейда +++ b/lts24-lts26-upgrade/dkms не пересобрал модуль после апгрейда.md @@ -1,17 +1,18 @@ -Ядро 7.0.0-42 было и на 24.04 (hwe), и на 26.04. Номер тот же, сборка разная (gcc 13 против gcc 15). -DKMS смотрит на номер ядра - раз модуль под 7.0.0-42 уже собран, пересобирать не будет. -Итог после перезагрузки: +# dkms не пересобрал модуль после апгрейда + +Ядро 7.0.0-42 было и на 24.04 (hwe), и на 26.04. Номер тот же, сборка разная (gcc 13 против gcc 15).
+DKMS смотрит на номер ядра - раз модуль под 7.0.0-42 уже собран, пересобирать не будет. Итог после перезагрузки: ``` vhba: disagrees about version of symbol module_layout ``` -`dkms install --force` НЕ помогает - берёт старую сборку из `/var/lib/dkms`. +`dkms install --force` НЕ помогает - берёт старую сборку из `/var/lib/dkms`. Force, ага.
Помогает только удалить и собрать заново: ``` sudo dkms remove vhba/20260313 -k 7.0.0-42-generic sudo dkms install vhba/20260313 -k 7.0.0-42-generic sudo modprobe vhba ``` -В выводе должен быть шаг "Building". Нет его - значит опять взял старое. +В выводе должен быть шаг "Building". Нет его - значит опять подсунул старое. Проверка: `dkms status`, `ls /dev/vhba_ctl`. diff --git a/lts24-lts26-upgrade/ffmpeg из исходников - gnutls not found и lto b/lts24-lts26-upgrade/ffmpeg из исходников - gnutls not found и lto.md similarity index 67% rename from lts24-lts26-upgrade/ffmpeg из исходников - gnutls not found и lto rename to lts24-lts26-upgrade/ffmpeg из исходников - gnutls not found и lto.md index 5fdd2fc..3ffdcea 100644 --- a/lts24-lts26-upgrade/ffmpeg из исходников - gnutls not found и lto +++ b/lts24-lts26-upgrade/ffmpeg из исходников - gnutls not found и lto.md @@ -1,4 +1,6 @@ -Свой статический ffmpeg в ~/bin надо пересобрать под 26.04 - иначе он держит библиотеки 24.04 (x264-164, x265-199, vpx9), и их нельзя удалить. +# ffmpeg из исходников - gnutls not found и lto + +Свой статический ffmpeg в `~/bin` надо пересобрать под 26.04 - иначе он держит либы 24.04 (x264-164, x265-199, vpx9), и их нельзя удалить.
Конфигурация та же, что была: `~/bin/ffmpeg -buildconf` покажет её. Сначала доставить то, что апгрейд снёс: @@ -10,14 +12,15 @@ sudo apt install libvpx-dev libmp3lame-dev libass-dev libunistring-dev ``` ERROR: gnutls not found using pkg-config ``` -Хотя libgnutls28-dev стоит. В `ffbuild/config.log` видно правду: `cannot find -lunistring`. С `--pkg-config-flags=--static` нужны все зависимости gnutls, а libunistring-dev апгрейд снёс. +Хотя libgnutls28-dev стоит. В `ffbuild/config.log` видно правду: `cannot find -lunistring`.
+С `--pkg-config-flags=--static` нужны все зависимости gnutls, а libunistring-dev апгрейд снёс. Грабли 2: ``` ERROR: SvtAv1Enc >= 0.9.0 not found using pkg-config ``` -В логе: `bytecode stream ... generated with LTO version 13.1 instead of the expected 15.1`. -libSvtAv1Enc.a был собран gcc 13 с LTO - внутри не машинный код, а байткод gcc 13. gcc 15 его не ест. Только пересобрать SVT-AV1: +В логе: `bytecode stream ... generated with LTO version 13.1 instead of the expected 15.1`.
+libSvtAv1Enc.a был собран gcc 13 с LTO - внутри не машинный код, а байткод gcc 13. gcc 15 это говно не ест. Только пересобрать SVT-AV1: ``` cd ~/ffmpeg_sources/SVT-AV1 && mkdir -p build-2604 && cd build-2604 cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="$HOME/ffmpeg_build" -DCMAKE_BUILD_TYPE=Release -DBUILD_DEC=OFF -DBUILD_SHARED_LIBS=OFF -DSVT_AV1_LTO=ON .. @@ -31,7 +34,7 @@ for a in ~/ffmpeg_build/lib/*.a; do echo "$a $(readelf -S --wide $a | grep -c gn Мораль: при ошибке configure сразу лезть в `ffbuild/config.log`, сообщение в консоли врёт. -После сборки проверить, что старых библиотек нет: +После сборки проверить, что старых либ нет: ``` ldd ~/bin/ffmpeg | grep -E 'x264.so.164|x265.so.199|vpx.so.9|not found' ``` diff --git a/lts24-lts26-upgrade/lightdm спрашивает имя пользователя b/lts24-lts26-upgrade/lightdm спрашивает имя пользователя.md similarity index 80% rename from lts24-lts26-upgrade/lightdm спрашивает имя пользователя rename to lts24-lts26-upgrade/lightdm спрашивает имя пользователя.md index e1bd245..7d1d161 100644 --- a/lts24-lts26-upgrade/lightdm спрашивает имя пользователя +++ b/lts24-lts26-upgrade/lightdm спрашивает имя пользователя.md @@ -1,10 +1,12 @@ -Раньше в greeter был мой пользователь - только пароль ввести. После 26.04 просит и имя, и пароль. +# lightdm спрашивает имя пользователя + +Раньше в гритере был мой юзер - только пароль ввести. После 26.04 просит и имя, и пароль. lightdm 1.32 принёс `/etc/lightdm/lightdm.conf.d/01_debian.conf`, а там: ``` greeter-hide-users=true ``` -Свой lightdm.conf я при апгрейде оставил, но это новый файл рядом - его никто не спрашивал. +Свой lightdm.conf я при апгрейде оставил, но это новый файл рядом - его никто не спрашивал. Кайф. Файл пакета не трогать (будут вопросы при обновлениях), а перебить в своём `/etc/lightdm/lightdm.conf` - он читается последним: ``` diff --git a/lts24-lts26-upgrade/mono и python3.12 - конфликт файлов при установке b/lts24-lts26-upgrade/mono и python3.12 - конфликт файлов при установке.md similarity index 61% rename from lts24-lts26-upgrade/mono и python3.12 - конфликт файлов при установке rename to lts24-lts26-upgrade/mono и python3.12 - конфликт файлов при установке.md index e9c8c2e..1f101b1 100644 --- a/lts24-lts26-upgrade/mono и python3.12 - конфликт файлов при установке +++ b/lts24-lts26-upgrade/mono и python3.12 - конфликт файлов при установке.md @@ -1,9 +1,13 @@ +# mono и python3.12 - конфликт файлов при установке + Два раза наступил на одни и те же грабли. -Mono: стоял 6.12 из репы mono-project (136 пакетов - по пакету на библиотеку), в 26.04 Ubuntu даёт 6.14 одним пакетом `mono-libraries`. Файлы пересекаются, а apt распаковывает новый РАНЬШЕ, чем удаляет старые. Даже в одной транзакции. dpkg падает, куча пакетов висит ненастроенными. +Mono: стоял 6.12 из репы mono-project (136 пакетов - по пакету на либу), в 26.04 убунта даёт 6.14 одним пакетом `mono-libraries`.
+Файлы пересекаются, а apt распаковывает новый РАНЬШЕ, чем удаляет старые. Даже в одной транзакции. dpkg падает, туева хуча пакетов висит ненастроенными. + Python 3.12 с deadsnakes: у deadsnakes для resolute нет `python3.12-minimal`, а `/usr/bin/python3.12` лежит в `python3.12` без Replaces на пакет убунты. Та же история. -`apt -s` (симуляция) такие конфликты НЕ видит. Вообще. +`apt -s` (симуляция) такие конфликты НЕ видит. Вообще. Поди угадай. Решение одно: сначала удалить старое семейство отдельной командой, потом ставить новое. ``` @@ -11,7 +15,7 @@ sudo apt-get remove <всё старое семейство> sudo apt-get install <новое> sudo apt-get -f install ``` -Mono я в итоге снёс целиком - .NET 10 и wine-mono от него не зависят. +Mono я в итоге снёс целиком - ну его нахер. .NET 10 и wine-mono от него не зависят. Проверить заранее, перезапишет ли новый пакет чужие файлы: ``` diff --git a/lts24-lts26-upgrade/nvidia - autoremove сносит драйвер b/lts24-lts26-upgrade/nvidia - autoremove сносит драйвер.md similarity index 54% rename from lts24-lts26-upgrade/nvidia - autoremove сносит драйвер rename to lts24-lts26-upgrade/nvidia - autoremove сносит драйвер.md index e55ee84..c502193 100644 --- a/lts24-lts26-upgrade/nvidia - autoremove сносит драйвер +++ b/lts24-lts26-upgrade/nvidia - autoremove сносит драйвер.md @@ -1,12 +1,15 @@ -Удалил мета-пакет nvidia-driver-580-open (когда переходил на готовые модули) - и всё, что он тянул, осталось с пометкой "auto". -`apt install` поверх уже стоящего пакета пометку НЕ меняет. Первый же `apt autoremove` снёс бы X-драйвер. И апгрейдер в конце тоже предлагает удалить "ненужное". +# nvidia - autoremove сносит драйвер + +Удалил мета-пакет nvidia-driver-580-open (когда переходил на готовые модули) - и всё, что он тянул, осталось с пометкой "auto".
+`apt install` поверх уже стоящего пакета пометку НЕ меняет. Первый же `apt autoremove` снёс бы X-драйвер нахрен. И апгрейдер в конце тоже радостно предлагает удалить "ненужное". Лечится явной пометкой: ``` sudo apt-mark manual xserver-xorg-video-nvidia-580 nvidia-utils-580 libnvidia-gl-580 libnvidia-gl-580:i386 libnvidia-decode-580 libnvidia-encode-580 libnvidia-fbc1-580 libnvidia-extra-580 libnvidia-common-580 nvidia-settings nvidia-prime ``` -После апгрейда та же засада, только с ядром: `linux-generic-hwe-26.04` и `linux-modules-nvidia-580-open-generic-hwe-26.04` стоят как auto и держатся на переходных пакетах hwe-24.04, которые сами в autoremove. Второй autoremove убил бы модуль nvidia. +После апгрейда та же херня, только с ядром: `linux-generic-hwe-26.04` и `linux-modules-nvidia-580-open-generic-hwe-26.04` стоят как auto и держатся на переходных пакетах hwe-24.04, которые сами в autoremove.
+Второй autoremove убил бы модуль nvidia. Моё любимое. ``` sudo apt-mark manual linux-generic-hwe-26.04 linux-modules-nvidia-580-open-generic-hwe-26.04 ``` @@ -15,4 +18,4 @@ sudo apt-mark manual linux-generic-hwe-26.04 linux-modules-nvidia-580-open-gener ``` apt-get -s autoremove | grep -E 'nvidia|linux-(image|modules|generic)' ``` -Пусто - можно. +Пусто - можно. Не пусто - не ссыте, но и не запускайте. diff --git a/lts24-lts26-upgrade/nvidia - готовые модули вместо dkms b/lts24-lts26-upgrade/nvidia - готовые модули вместо dkms deleted file mode 100644 index e054e0a..0000000 --- a/lts24-lts26-upgrade/nvidia - готовые модули вместо dkms +++ /dev/null @@ -1,23 +0,0 @@ -Годами сидел на nvidia-driver-580-open через DKMS и думал, что иначе никак. -А у убунты, оказывается, есть уже собранные модули nvidia под каждое ядро. Из тех же самых исходников, просто собраны Canonical. -Если модуль не патчил - бери готовый. DKMS оставлять только для того, у чего готового нет (у меня это vhba). - -Ставится так (пример для ядра 7.0 на 24.04, на 26.04 то же самое, только hwe-26.04): -``` -sudo apt install linux-generic-hwe-24.04 linux-modules-nvidia-580-open-generic-hwe-24.04 nvidia-headless-no-dkms-580-open nvidia-utils-580 xserver-xorg-video-nvidia-580 -``` -v4l2loopback туда же - тоже есть готовый: -``` -sudo apt install linux-main-modules-v4l2loopback-7.0.0-42-generic -``` -Потом удалить `nvidia-driver-580-open`, `nvidia-dkms-580-open`, `v4l2loopback-dkms`. - -Плюс: новое ядро приходит сразу с модулем. Никакого "ой, DKMS не собрался, сижу в tty". -Минус: версия userspace обязана совпадать с версией модуля. Проверять так: -``` -modinfo -F version nvidia -dpkg-query -W nvidia-utils-580 -``` -Цифры разные - не перезагружаться. - -Перед апгрейдом обкатал ядро 7.0 + модули прямо на 24.04 - X, CUDA, Bluetooth, OpenRGB, Steam. Всё завелось, только после этого полез в do-release-upgrade. diff --git a/lts24-lts26-upgrade/nvidia - готовые модули вместо dkms.md b/lts24-lts26-upgrade/nvidia - готовые модули вместо dkms.md new file mode 100644 index 0000000..3286220 --- /dev/null +++ b/lts24-lts26-upgrade/nvidia - готовые модули вместо dkms.md @@ -0,0 +1,25 @@ +# nvidia - готовые модули вместо dkms + +Годами сидел на nvidia-driver-580-open через DKMS и думал, что иначе никак - "только так и работало".
+А у убунты, оказывается, есть УЖЕ СОБРАННЫЕ модули nvidia под каждое ядро. Из тех же самых сырцов, просто собраны в Canonical.
+Короче: если модуль не патчил - бери готовый. DKMS оставлять только для того, у чего готового нет (у меня это vhba). + +Ставится так (пример для ядра 7.0 на 24.04, на 26.04 то же самое, только hwe-26.04): +``` +sudo apt install linux-generic-hwe-24.04 linux-modules-nvidia-580-open-generic-hwe-24.04 nvidia-headless-no-dkms-580-open nvidia-utils-580 xserver-xorg-video-nvidia-580 +``` +v4l2loopback туда же - тоже есть готовый: +``` +sudo apt install linux-main-modules-v4l2loopback-7.0.0-42-generic +``` +Потом сносим `nvidia-driver-580-open`, `nvidia-dkms-580-open`, `v4l2loopback-dkms`. + +Плюс: новое ядро приходит сразу с модулем. Никакого "ой, DKMS не собрался, сижу в tty, кайф".
+Минус: версия дров (userspace) обязана совпадать с версией модуля. Проверять так: +``` +modinfo -F version nvidia +dpkg-query -W nvidia-utils-580 +``` +Цифры разные - ***не перезагружаться***. + +Перед апгрейдом обкатал ядро 7.0 + модули прямо на 24.04: X, CUDA, Bluetooth с дуалсенсом, OpenRGB, Steam. Всё завелось - только после этого полез в do-release-upgrade. diff --git a/lts24-lts26-upgrade/obs portable - пересборка под ffmpeg 8 b/lts24-lts26-upgrade/obs portable - пересборка под ffmpeg 8.md similarity index 53% rename from lts24-lts26-upgrade/obs portable - пересборка под ffmpeg 8 rename to lts24-lts26-upgrade/obs portable - пересборка под ffmpeg 8.md index 476e4b4..2a3b36d 100644 --- a/lts24-lts26-upgrade/obs portable - пересборка под ffmpeg 8 +++ b/lts24-lts26-upgrade/obs portable - пересборка под ffmpeg 8.md @@ -1,10 +1,12 @@ -Портативный OBS, собранный на 24.04, сидит на FFmpeg 6 (libavcodec.so.60). В 26.04 FFmpeg 8 (so.62), а шестой уходит в autoremove - и OBS вместе с ним. -Пересобрал тем же cmake, что и раньше, просто в новую папку: `release-2604`. +# obs portable - пересборка под ffmpeg 8 + +Портативный ОБС, собранный на 24.04, сидит на FFmpeg 6 (libavcodec.so.60). В 26.04 FFmpeg 8 (so.62), а шестой уходит в autoremove - и ОБС вместе с ним.
+Пересобрал тем же cmake, что и раньше (см. репу про манджаро, two.md), просто в новую папку: `release-2604`. Нюансы: - в libobs зашиты абсолютные пути папки установки. Собрал в release-2604 - не переименовывать потом, иначе плагины не найдутся; -- ярлык должен ставить `LD_LIBRARY_PATH` на `.../release-2604/lib`. И `ldd bin/obs` без этой переменной врёт "libobs.so.30 not found" - это нормально; -- старый системный OBS (make install в /usr/local) новый не использует - проверить: +- ярлык должен ставить `LD_LIBRARY_PATH` на `.../release-2604/lib`. И `ldd bin/obs` без этой переменной врёт "libobs.so.30 not found" - это нормально, не ссыте; +- старый системный ОБС (make install в /usr/local) новый не использует - проверить: ``` LD_LIBRARY_PATH=$PWD/lib ldd bin/obs | grep -E 'libobs|libav' ``` diff --git a/lts24-lts26-upgrade/plymouth - лого уменьшается и съезжает влево вверх b/lts24-lts26-upgrade/plymouth - лого уменьшается и съезжает влево вверх.md similarity index 56% rename from lts24-lts26-upgrade/plymouth - лого уменьшается и съезжает влево вверх rename to lts24-lts26-upgrade/plymouth - лого уменьшается и съезжает влево вверх.md index 8007840..95b0216 100644 --- a/lts24-lts26-upgrade/plymouth - лого уменьшается и съезжает влево вверх +++ b/lts24-lts26-upgrade/plymouth - лого уменьшается и съезжает влево вверх.md @@ -1,9 +1,11 @@ -На загрузке лого xubuntu сначала нормальное, по центру, а потом уменьшается и уезжает влево вверх. Будто экран уже 2K, а рисуется всё ещё под 1080. +# plymouth - лого уменьшается и съезжает влево вверх + +На загрузке лого хубунты сначала нормальное, по центру, а потом уменьшается и уезжает влево вверх. Будто экран уже 2к, а рисуется всё ещё под 1080. Так и есть: - plymouth стартует на simpledrm - это картинка от UEFI в 1920x1080; - через пару секунд грузится nvidia-drm и переключает монитор в родные 2560x1440; -- тема-скрипт посчитала центр один раз при старте и больше не пересчитывает. +- тема-скрипт посчитала центр один раз при старте и больше не пересчитывает. Мастера. Видно по журналу: ``` @@ -12,16 +14,16 @@ journalctl -b -o short-monotonic -u plymouth-start ``` plymouth-start раньше nvidia-drm - оно. -Лечится ранней загрузкой nvidia - модули в initramfs, тогда plymouth сразу стартует на nvidia в нужном разрешении: +Лечится ранней загрузкой дров - модули в initramfs, тогда plymouth сразу стартует на nvidia в нужном разрешении: ``` printf 'nvidia\nnvidia_modeset\nnvidia_uvm\nnvidia_drm\n' | sudo tee -a /etc/initramfs-tools/modules sudo update-initramfs -u ``` -Прошивку GSP и /etc/modprobe.d (modeset=1 и прочее) initramfs заберёт сам. initrd вырастет примерно с 90 до 175 МБ. -Проверка (файл называется через дефис, не через подчёркивание): +Прошивку GSP и /etc/modprobe.d (modeset=1 и прочее) initramfs заберёт сам. initrd вырастет примерно с 90 до 175 МБ.
+Проверка (файл называется через дефис, не через подчёркивание - сам на этом спалился): ``` lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'nvidia-drm|gsp_' ``` Откат - убрать 4 строки и снова update-initramfs. -Вариант через GRUB (`GRUB_GFXMODE=2560x1440`) работает, только если UEFI видеокарты этот режим умеет. В консоли GRUB (`c`) команда `videoinfo` покажет. +Вариант через GRUB (`GRUB_GFXMODE=2560x1440`) работает, только если UEFI карточки этот режим умеет. В консоли GRUB (`c`) команда `videoinfo` покажет. diff --git a/lts24-lts26-upgrade/qt-программы под pkexec белые b/lts24-lts26-upgrade/qt-программы под pkexec белые deleted file mode 100644 index 06db9cc..0000000 --- a/lts24-lts26-upgrade/qt-программы под pkexec белые +++ /dev/null @@ -1,11 +0,0 @@ -qdirstat запускаю от root через pkexec - после апгрейда он белый-пребелый, тема Qt не применяется. -pkexec чистит окружение, и `QT_QPA_PLATFORMTHEME` до программы не доходит. А у root своего конфига qt6ct нет. - -Ярлык: -``` -Exec=pkexec env DISPLAY=:0 XAUTHORITY=/home//.Xauthority QT_QPA_PLATFORMTHEME=qt6ct /usr/bin/qdirstat %f -``` -И отдать root свой конфиг: -``` -sudo install -D -m 644 ~/.config/qt6ct/qt6ct.conf /root/.config/qt6ct/qt6ct.conf -``` diff --git a/lts24-lts26-upgrade/qt-программы под pkexec белые.md b/lts24-lts26-upgrade/qt-программы под pkexec белые.md new file mode 100644 index 0000000..f40e871 --- /dev/null +++ b/lts24-lts26-upgrade/qt-программы под pkexec белые.md @@ -0,0 +1,13 @@ +# qt-программы под pkexec белые + +qdirstat запускаю от рута через pkexec - после апгрейда он белый-пребелый, тема Qt не применяется. Глаза вытекают.
+pkexec чистит окружение, и `QT_QPA_PLATFORMTHEME` до программы не доходит. А у рута своего конфига qt6ct нет. + +Ярлык: +``` +Exec=pkexec env DISPLAY=:0 XAUTHORITY=/home//.Xauthority QT_QPA_PLATFORMTHEME=qt6ct /usr/bin/qdirstat %f +``` +И отдать руту свой конфиг: +``` +sudo install -D -m 644 ~/.config/qt6ct/qt6ct.conf /root/.config/qt6ct/qt6ct.conf +``` diff --git a/lts24-lts26-upgrade/ssh-агент пропал в X-сессии b/lts24-lts26-upgrade/ssh-агент пропал в X-сессии.md similarity index 59% rename from lts24-lts26-upgrade/ssh-агент пропал в X-сессии rename to lts24-lts26-upgrade/ssh-агент пропал в X-сессии.md index 7392655..af74130 100644 --- a/lts24-lts26-upgrade/ssh-агент пропал в X-сессии +++ b/lts24-lts26-upgrade/ssh-агент пропал в X-сессии.md @@ -1,6 +1,9 @@ +# ssh-агент пропал в X-сессии + После апгрейда `git push` по ssh перестал видеть ключи. `ssh-add -l` - "Could not open a connection to your authentication agent". -В 26.04 ssh-агент - это `gcr-ssh-agent`, сокет `/run/user//gcr/ssh`. Только вот `SSH_AUTH_SOCK` есть в окружении systemd user, а в X-сессию (lightdm + xfce) не попадает. +В 26.04 ssh-агент - это `gcr-ssh-agent`, сокет `/run/user//gcr/ssh`.
+Только вот `SSH_AUTH_SOCK` есть в окружении systemd user, а в X-сессию (lightdm + xfce) не попадает. Поди пойми, зачем так. Создал `~/.xsessionrc`: ``` diff --git a/lts24-lts26-upgrade/v4l2loopback 0.15 - STREAMON EINVAL b/lts24-lts26-upgrade/v4l2loopback 0.15 - STREAMON EINVAL.md similarity index 60% rename from lts24-lts26-upgrade/v4l2loopback 0.15 - STREAMON EINVAL rename to lts24-lts26-upgrade/v4l2loopback 0.15 - STREAMON EINVAL.md index af1bc8c..471e20d 100644 --- a/lts24-lts26-upgrade/v4l2loopback 0.15 - STREAMON EINVAL +++ b/lts24-lts26-upgrade/v4l2loopback 0.15 - STREAMON EINVAL.md @@ -1,13 +1,15 @@ -С v4l2loopback 0.12.7 на 0.15.3 сломалась моя виртуалка-камера (гринскрин на питоне). +# v4l2loopback 0.15 - STREAMON EINVAL + +С v4l2loopback 0.12.7 на 0.15.3 отвалилась моя виртуальная камера (гринскрин на питоне): ``` VCam format set failed: [Errno 22] Invalid argument ``` -Падало на `VIDIOC_STREAMON`. В 0.15 STREAMON требует сначала REQBUFS, иначе EINVAL. -А для 0.12.7 STREAMON был костылём - без него устройство не "занималось". +Падало на `VIDIOC_STREAMON`. В 0.15 STREAMON требует сначала REQBUFS, иначе EINVAL.
+А для 0.12.7 STREAMON был костылём - без него устройство не "занималось".
В 0.15 `write()` сам занимает устройство, `close()` освобождает. Костыль больше не нужен. Решение: STREAMON только для старых версий. Версию модуля брать тут: ``` cat /sys/module/v4l2loopback/version ``` -Меньше 0.13 - делаем STREAMON, иначе просто пишем кадры через write(). +Меньше 0.13 - делаем STREAMON, иначе просто пишем кадры через write(). Оно просто работает. diff --git a/lts24-lts26-upgrade/venv на python 3.12 сдохли b/lts24-lts26-upgrade/venv на python 3.12 сдохли.md similarity index 65% rename from lts24-lts26-upgrade/venv на python 3.12 сдохли rename to lts24-lts26-upgrade/venv на python 3.12 сдохли.md index 383a8ed..143c66b 100644 --- a/lts24-lts26-upgrade/venv на python 3.12 сдохли +++ b/lts24-lts26-upgrade/venv на python 3.12 сдохли.md @@ -1,8 +1,10 @@ +# venv на python 3.12 сдохли + В 26.04 `python3` - это 3.14. А venv, созданные на 24.04, внутри выглядят так: ``` venv/bin/python3 -> /usr/bin/python3 ``` -Т.е. теперь они запускают 3.14, а пакеты лежат в `lib/python3.12/site-packages`. Ничего не импортируется. +Т.е. теперь они запускают 3.14, а пакеты лежат в `lib/python3.12/site-packages`. Нихера не импортируется. Ставим 3.12 с deadsnakes (см. заметку про конфликт файлов) и переводим ссылку: ``` @@ -17,10 +19,10 @@ venv/bin/python -c 'import sys; print(sys.version)' find ~ /opt -xdev -name pyvenv.cfg -exec grep -l 'version *= *3\.12' {} + ``` -Вентиляторы видеокарты (скрипт на pynvml) - там venv вообще не нужен, есть системный пакет: +Вентиляторы карточки (скрипт на pynvml) - там venv вообще не нужен, есть системный пакет: ``` sudo apt install python3-pynvml ``` -и запускать скрипт системным python3. +и запускать скрипт системным python3. После апгрейда они стояли на 0% при 48 градусах - не дай грабли вам такое летом. -Чисто на пакетах 26.04 (без pip) torch не получится: python3-torch только CPU, torchvision и pygame-ce в репах нет. +Чисто на пакетах 26.04 (без pip) torch не получится: python3-torch только CPU, torchvision и pygame-ce в репах нет. Печаль. diff --git a/lts24-lts26-upgrade/vmware workstation на ядре 7.0 b/lts24-lts26-upgrade/vmware workstation на ядре 7.0.md similarity index 61% rename from lts24-lts26-upgrade/vmware workstation на ядре 7.0 rename to lts24-lts26-upgrade/vmware workstation на ядре 7.0.md index 99dc02b..c90b67c 100644 --- a/lts24-lts26-upgrade/vmware workstation на ядре 7.0 +++ b/lts24-lts26-upgrade/vmware workstation на ядре 7.0.md @@ -1,7 +1,9 @@ -VMware Workstation 25 на ядре 7.0 не завёлся: `vmware.service` падает на каждой загрузке, модулей vmmon/vmnet нет. +# vmware workstation на ядре 7.0 + +VMware Workstation 25 на ядре 7.0 не завёлся: `vmware.service` падает на каждой загрузке, модулей vmmon/vmnet нет.
Он собирает их сам из `/usr/lib/vmware/modules/source/*.tar`, не через DKMS, и под 7.0 не собрал. -Мне он оказался не нужен (машин на диске уже не было, всё давно на qemu), снёс: +Мне он оказался нафиг не нужен (машин на диске уже не было, всё давно на qemu), снёс: ``` sudo vmware-installer -u vmware-workstation ``` @@ -11,4 +13,4 @@ sudo vmware-installer -u vmware-workstation - служба `vmware-USBArbitrator` висит в systemd, пока не сделать `sudo systemctl daemon-reload`; - `~/.vmware`. -`xserver-xorg-video-vmware` - это драйвер для Linux ВНУТРИ виртуалки VMware, на хосте он не нужен никогда. +`xserver-xorg-video-vmware` - это драйвер для линукса ВНУТРИ виртуалки VMware, на хосте он не нужен никогда. diff --git a/lts24-lts26-upgrade/апгрейдер молча удаляет твои конфиги b/lts24-lts26-upgrade/апгрейдер молча удаляет твои конфиги.md similarity index 67% rename from lts24-lts26-upgrade/апгрейдер молча удаляет твои конфиги rename to lts24-lts26-upgrade/апгрейдер молча удаляет твои конфиги.md index 7637986..b4cc6ad 100644 --- a/lts24-lts26-upgrade/апгрейдер молча удаляет твои конфиги +++ b/lts24-lts26-upgrade/апгрейдер молча удаляет твои конфиги.md @@ -1,23 +1,26 @@ -do-release-upgrade в конце удаляет "obsolete conffiles" - конфиги, которые больше не принадлежат ни одному пакету. И ему пофиг, что ты их правил. +# апгрейдер молча удаляет твои конфиги + +do-release-upgrade в конце удаляет "obsolete conffiles" - конфиги, которые больше не принадлежат ни одному пакету. И ему пофигу, что ты их правил.
У меня так ушли: -- `/etc/systemd/zram-generator.conf` - zram стал 4 ГБ lzo-rle вместо моих ram/2 на zstd; +- `/etc/systemd/zram-generator.conf` - zram ВНЕЗАПНО стал 4 ГБ lzo-rle вместо моих ram/2 на zstd; - `/etc/sysctl.conf` (повезло, настройки памяти лежали в `/etc/sysctl.d/`, а там всё цело). Вывод: всё своё держать копией в репе/дома и класть в `*.d/` каталоги, а не в главный файл. -zram вернуть: +zram вернуть - в `/etc/systemd/zram-generator.conf`: ``` [zram0] zram-size = ram / 2 compression-algorithm = zstd swap-priority = 100 ``` -в `/etc/systemd/zram-generator.conf` и перезагрузка. Проверка: `zramctl`. +и перезагрузка. Проверка: `zramctl`. На вопросы "Y/I/N/O/D/Z" про конфиги отвечал так: - то, что правил сам (pulse, grub, ssh, samba, lightdm, pam.d/lightdm, privoxy, sleep.conf, 20auto-upgrades, geoclue) - N; -- автозапуски, которые я удалял из `/etc/xdg/autostart` (orca, at-spi, im-launch, update-notifier, ubuntu-advantage) - тоже N, иначе вернутся; +- автозапуски, которые я выпиливал из `/etc/xdg/autostart` (orca, at-spi, im-launch, update-notifier, ubuntu-advantage) - тоже N, иначе вся эта хрень вернётся; - не уверен - D, смотришь разницу и решаешь. + Новые версии лежат рядом как `*.dpkg-dist` - потом можно сравнить. Удаление устаревших пакетов в конце апгрейда - НЕТ. Там 800+ штук, включая то, что нужно. Разбирал руками через `apt-get -s autoremove`. diff --git a/lts24-lts26-upgrade/звук остаётся на pulseaudio b/lts24-lts26-upgrade/звук остаётся на pulseaudio.md similarity index 53% rename from lts24-lts26-upgrade/звук остаётся на pulseaudio rename to lts24-lts26-upgrade/звук остаётся на pulseaudio.md index 6c56590..4dd0a28 100644 --- a/lts24-lts26-upgrade/звук остаётся на pulseaudio +++ b/lts24-lts26-upgrade/звук остаётся на pulseaudio.md @@ -1,5 +1,7 @@ -Апгрейд на 26.04 очень хочет пересадить звук на PipeWire. Мне не надо - проблемы со звуком были даже от одного pipewire без pulse-обёртки. -Библиотеки libpipewire/libspa пусть стоят, их приложения тянут. А вот демоны - нафиг. +# звук остаётся на pulseaudio + +Апгрейд на 26.04 очень хочет пересадить звук на ***pipewire***. Мне это нафиг не надо - со звуком была жопа даже от одного pipewire без pulse-обёртки (см. репу про манджаро, two.md).
+Либы libpipewire/libspa пусть стоят, их приложения тянут. А вот демоны - нахер. До апгрейда: ``` @@ -11,7 +13,7 @@ Package: pipewire pipewire-bin pipewire-pulse wireplumber pipewire-jack pipewire Pin: release * Pin-Priority: -1 ``` -Внимание: в 26.04 `ubuntustudio-pulseaudio-config` - это переходный пакет НА pipewire. Поэтому он тоже в списке. +***ВНИМАНИЕ***: в 26.04 `ubuntustudio-pulseaudio-config` - это переходный пакет НА pipewire. Тот самый, который в 24.04 спасал от pipewire. Поэтому он тоже в списке. А они мастера. При апгрейде на вопрос про `/etc/pulse/default.pa` - N, оставить свой. diff --git a/lts24-lts26-upgrade/репа CUDA перебивает драйвер убунты b/lts24-lts26-upgrade/репа CUDA перебивает драйвер убунты.md similarity index 50% rename from lts24-lts26-upgrade/репа CUDA перебивает драйвер убунты rename to lts24-lts26-upgrade/репа CUDA перебивает драйвер убунты.md index 0607e02..2ea1d72 100644 --- a/lts24-lts26-upgrade/репа CUDA перебивает драйвер убунты +++ b/lts24-lts26-upgrade/репа CUDA перебивает драйвер убунты.md @@ -1,8 +1,10 @@ -Если подключена репа CUDA от NVIDIA - она привозит свой драйвер (580.196), а у убунты 580.178. -У обеих приоритет 500, побеждает версия новее, т.е. NVIDIA. Обычный `apt dist-upgrade` поставил бы userspace 580.196 и УДАЛИЛ готовые модули ядра 580.178. Здравствуй, tty. +# репа CUDA перебивает драйвер убунты -Сузить стандартный пин до `cuda-* libcu* nsight*` мало - всё остальное из репы CUDA всё равно идёт с 500. -Надо ещё задавить остальное до 100. `/etc/apt/preferences.d/cuda-repository-pin-600`: +Если подключена репа CUDA от нвидии - она привозит свои дрова (580.196), а у убунты 580.178.
+У обеих приоритет 500, побеждает версия новее, т.е. нвидия. Обычный `apt dist-upgrade` поставил бы userspace 580.196 и УДАЛИЛ готовые модули ядра 580.178. Здравствуй, tty. + +Сузить стандартный пин до `cuda-* libcu* nsight*` - мало. Всё остальное из репы CUDA всё равно идёт с 500.
+Надо ещё придавить остальное до 100. `/etc/apt/preferences.d/cuda-repository-pin-600`: ``` Package: cuda-* libcu* nsight* Pin: release l=NVIDIA CUDA diff --git a/lts24-lts26-upgrade/свои пакеты xfce после апгрейда - тиринг вернулся b/lts24-lts26-upgrade/свои пакеты xfce после апгрейда - тиринг вернулся.md similarity index 64% rename from lts24-lts26-upgrade/свои пакеты xfce после апгрейда - тиринг вернулся rename to lts24-lts26-upgrade/свои пакеты xfce после апгрейда - тиринг вернулся.md index 48e1a7c..daf9a76 100644 --- a/lts24-lts26-upgrade/свои пакеты xfce после апгрейда - тиринг вернулся +++ b/lts24-lts26-upgrade/свои пакеты xfce после апгрейда - тиринг вернулся.md @@ -1,20 +1,22 @@ -После апгрейда в играх вернулся тиринг. Причина простая: апгрейд заменил мой патченый xfwm4 (gpu-compositor) штатным. Thunar и systemload-плагин - туда же. +# свои пакеты xfce после апгрейда - тиринг вернулся + +После апгрейда в играх вернулся сраный тиринг. Причина простая: апгрейд заменил мой патченый xfwm4 (gpu-compositor) штатным. Тунар и systemload-плагин - туда же. Что надо знать, чтобы это не повторялось: -- версия своего пакета БЕЗ тильды и выше штатной: `4.20.0-1build1+gpucomp5`, а не `~gpucomp`. С тильдой любое обновление перебьёт; +- версия своего пакета БЕЗ тильды и выше штатной: `4.20.0-1build1+gpucomp5`, а не `~gpucomp`. С тильдой любая обновка перебьёт; - после установки - hold: ``` sudo apt-mark hold xfwm4 thunar thunar-data xfce4-systemload-plugin ``` - если пакет зависит от `thunar-data (= 4.20.7-1)` - держать и его, и при обновлении thunar-data пересобирать; -- собирать с `dpkg-deb --root-owner-group`, иначе все файлы в системе будут принадлежать тебе (у меня так годами и было); +- собирать с `dpkg-deb --root-owner-group`, иначе все файлы в системе будут принадлежать тебе (у меня так годами и было, хз сколько); - старые .deb не перезаписывать, новую ревизию - новым номером. -Thunar из git-дерева не собирался: +Тунар из git-дерева не собирался: ``` No rule to make target 'thunar-marshal.c' ``` В тарболе этот файл уже сгенерирован, а в git нет. Надо `./autogen.sh --enable-maintainer-mode`. -Патчи держать в git (у меня форки на своём Forgejo), тогда перенос на новую версию - это cherry-pick, а не ковыряние руками. -Forgejo не принимает push из shallow-клона - делал отдельную цепочку коммитов от дерева upstream (git commit-tree). +Патчи держать в git (у меня форки на своём Forgejo), тогда перенос на новую версию - это cherry-pick, а не ковыряние руками.
+Forgejo не принимает push из shallow-клона - делал отдельную цепочку коммитов от дерева апстрима (`git commit-tree`). Давайте руками, чо.