Kodi не воспроизводит файлы после обновления ядра NFS сервера до 5.10.13

Уже прошло больше недели как я обновил ядро на домашнем сервере с linux-image-5.9.0-0.bpo.5-amd64 (5.9.15-1~bpo10+1) до linux-image-5.10.0-0.bpo.3-amd64 (5.10.13-1~bpo10+1), но перезагрузку сервера сделал только вечером прошлого воскресенья. В понедельник меня ждали жалобы от домочадцев что Kodi, который в основе всех домашних HTPC, больше не проигрывает ни музыку, ни записи с сервера.

Бегло проверил что проблема затрагивает все установки Kodi и поскольку ничего не менялось кроме перезагрузки сервера, то начал вспоминать что менялось на самом сервере. Вспомнил про обновление ядра среди недели. Поменял параметры grub, чтобы загрузилось предыдущее ядро

GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 5.9.0-0.bpo.5-amd64"

После update-grub и перезагрузки проблема с Kodi решилась, но осталось разобраться что не так с ядром 5.10.13.

Времени нашлось только сегодня и сразу на глаза попался отчет об ошибке Bug 211471 - Kodi/VLC unable to stream from NFS server after updating to 5.10.11. Обещают что починено в 5.10.15, но в buster-backports пока только 5.10.13. Чтобы проблемная версия не мозолила глаза нужно исключить ее из установки обновлений

sudo dpkg -i /var/cache/apt/archives/linux-image-amd64_5.9.15-1~bpo10+1_amd64.deb
sudo aptitude purge linux-image-5.10.0-0.bpo.3-amd64

Теперь нужно не забыть откатить изменения в /etc/default/grub

GRUB_DEFAULT=0

И пометить версию 5.10.13-1~bpo10+1 как запрещенную к установке

sudo aptitude forbid-version linux-image-5.10.0-0.bpo.3-amd64=5.10.13-1~bpo10+1
sudo aptitude forbid-version linux-image-amd64=5.10.13-1~bpo10+1

Осталось проверить что aptitude upgrade не будет пытаться ставить ее снова

sudo aptitude update
sudo aptitude upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

Все в порядке осталось дождаться когда в бэкпорты придет версия ядра 5.10.15 или выше.

Отключение IBus в Debian/Ubuntu

Супруге приходится пользоваться Zoom и с ним в систему притянуло IBus (Intelligent Input Bus). Это фреймворк для методов ввода и наверное тем кто использует иероглифы он полезен, но для меня он не решает никаких проблем, а лишь добавляет глюки с переключением языка ввода (используется переключение по Caps Lock).

Чтобы отключить IBus нужно добавить "отклонение" через dpkg-divert

sudo dpkg-divert --package im-config --rename /usr/bin/ibus-daemon

Включить обратно можно командой

sudo dpkg-divert --package im-config --rename --remove /usr/bin/ibus-daemon

После перезагрузки системы IBus больше не запускается.

Самодельный шунт для амперметра

Еще до праздников купил модуль амперметра 91C16 шкала которого размечена для измерения постоянного тока до 5А. Встроенный шунт отсутствует, а какой нужен для этого модуля в описании не было указано.

Чтобы подобрать шунт нужно знать ток при котором стрелка отклоняется в крайнее положение. Для этого ставлю на лабораторном блоке питания напряжение 1В и подключаю модуль последовательно с резистором 10кОм. В этом случае ток не превысит 100мкА и очень маловероятно что чувствительность этого модуля лучше. В результате стрелка не отклонилась вовсе - меняю сопротивление на 1кОм и стрелка немного отклоняется. Ставлю вместо постоянного резистора многооборотный подстроечник такого же номинала и подбираю положение когда стрелка отклоняется до крайней отметки.

Регулирование оборотов вентилятора для Raspberry PI

Накрылся вентилятор в HTPC на базе Gigabyte Brix и пока из Китая не пришел новый вентилятор приходится обходиться заменой на базе Raspberry PI 4. Проблема четвертого Raspberry в заметном нагреве по сравнению с тем же Raspberry PI 3 и чтобы он не перегревался я брал корпус с активным охлаждением. Мелкий кулер заметно шумит, а если отключить его, то Raspberry быстро нагревается до 60 градусов и выше.

Миграция etckeeper с mercurial на git

В начале 2012 года я начал использовать etckeeper для отслеживания изменения в /etc. Тогда я использовал Mercurial в качестве системы контроля версий и было очевидным использовать его в качестве бэкенда хранения для etckeeper.

Двумя годами позже я сменил место работы и целиком переключился на Git. Все новые инсталляции уже использовали Git для etckeeper, но домашний сервер и ноутбук все еще оставались на Mercurial. Где-то в районе выхода Debian Jessie ноутбук перешел на Git при миграции с i386 на amd64. А сервер оставался на Mercurial до сегодняшнего дня, но несколько попыток починить такую ошибку привели к миграции:

/etc/cron.daily/etckeeper:
abort: path contains illegal component: .hg/undo.dirstate
abort: path contains illegal component: .hg/undo.backup.dirstate
abort: path contains illegal component: .hg/undo.dirstate
abort: path contains illegal component: .hg/undo.backup.dirstate

Когда-то я уже описывал процесс миграции с Mercurial на Git с использованием расширения hg-git, но в этот раз решил попробовать сделать по инструкции с git-scm.com

Midnight Commander 4.8.25 для Ubuntu Groovy

Добавил в свой репозитарий поддержку Ubuntu Groovy (20.10) и собрал пакеты Midnight Commander 4.8.25 для архитектур amd64, armhf и arm64.

Сейчас версия совпадает с той, которую предоставляет Ubuntu, но ситуация скорее всего изменится с выходом Midnight Commander 4.8.26.

Ускорение сборки в pbuilder на Raspberry PI 4

Дошли руки починить сборку Midnight Commander для ARM. Раньше я использовал qemu-user-static и qemu-system-arm для сборки пакетов для архитектур armel, armhf и arm64, но это было медленно и часто заканчивалось ошибками или зависанием сборки. Начиная с Raspberry PI 3 появилась поддержка ARM64 и теперь можно собирать пакеты не прибегая к помощи эмулятора.

После снижения цен на Raspberry PI 4 с 2GB до 35$ я заказал себе такую на Seeedstudio и вдобавок корпус с активным охлаждением. Но если гонять pbuilder на SD карте это будет медленно и карта довольно быстро придет в негодность. Чтобы этого избежать я выношу весь /var/cache/pbuilder на NFS, который раздает домашний сервер. Такой подход хорошо работает с базовыми образами, кешем APT и результатами сборки, но слишком медленный для /var/cache/pbuilder/build/. В этой директории pbuilder хранит распакованные chroot'ы и эти файлы не важны. Чтобы ускорить сборку можно смонтировать tmpfs и сборка будет упираться в процессор, а не в I/O.