Установка OpenWebRX+ на Raspberry PI 3 Model B

Если SDR приёмник подключается к rtl_tcp, который запущен на Raspberry PI 3 Model B через Wi-Fi сеть (эта модель поддерживает только 2.4 ГГц Wi-Fi), то её скорости иногда не хватает чтобы принимать сигнал без запинок. Решил попробовать OpenWebRX+ чтобы декодирование I/Q сигнала выполнялось локально на Raspberry а по сети передавалось меньше данных.

Записал образ Debian 13 для Raspberry на microSD карту которая подключена через USB считыватель и видна в системе как /dev/sda

curl -fsSLO https://cloud.debian.org/images/cloud/trixie/daily/latest/debian-13-raspi-arm64-daily.tar.xz

tar -xzf debian-13-raspi-arm64-daily.tar.xz

sudo dd if=disk.raw of=/dev/sda bs=10M oflag=direct status=progress

После записи образа установил microSD карту в одноплатник, подключил проводную сеть, клавиатуру и монитор и загрузился в систему (при первой загрузке попросит задать пароль для root пользователя и часовой пояс).

Далее поставил минимальный набор пакетов, настроил имя хоста, локаль и отключил проверку дубликатов IP адресов в Network Manager.

sudo apt --update install network-manager openssh-server openssh-client locales vim less

echo pi3 | sudo tee /etc/hostname

echo '127.0.1.1 pi3.local pi3' | sudo tee -a /etc/hosts

sudo hostname -F /etc/hostname

cat << _EOF_ | sudo tee /etc/locale.gen
en_US.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8
_EOF_

sudo locale-gen

cat <<_EOF_ | sudo tee /etc/NetworkManager/conf.d/50-no-ipv4-dad.conf
[connection-dad-default]
ipv4.dad-timeout=0
_EOF_

sudo systemctl restart NetworkManager.service

Дальше настроил подключение к Wi-Fi точке через nmtui и установил сервис для управления антенной из SDR приложения.

Эксперимент с обновлением Raspbian через QEMU

Прошлое обновление сервера печати, который построен на базе Raspberry Pi 1B и Raspbian, с Bullseye на Bookworm заняло несколько часов. В нём установлена micro SD карта на 4 гигабайта, которая работает довольно медленно, но для печати быстрее и не нужно. Debian Trixie вышел в начале августа, но обновить эту систему руки дошли только сейчас.

Тогда обновление системы напомнило былые времена с Gentoo. Тогда и появилась идея попробовать запустить образ SD карты в QEMU, обновить систему и записать его обратно на карту.

Поставил SD карту из сервера печати в ноутбук и сделал её образ в двух экземплярах - один будет использоваться для обновления, а второй будет в качестве резервной копии если после обновления он не начнёт работать.

$ sudo dd if=/dev/mmcblk0 of=sdcard-20251230.orig.bin bs=1M iflag=direct
3849+0 records in
3849+0 records out
4035969024 bytes (4,0 GB, 3,8 GiB) copied, 300,146 s, 13,4 MB/s

$ cp sdcard-20251230.orig.bin sdcard.img

Теперь нужно выровнять размер образа для эмуляции иначе QEMU будет ругаться "qemu-system-arm: Invalid SD card size: 3.76 GiB SD card size has to be a power of 2, e.g. 4 GiB."

$ qemu-img resize -f raw sdcard.img 4096M
Image resized.

Не вынимая SD карту из ноутбука копирую ядро (kernel7.img) и device tree (bcm2709-rpi-2-b.dtb) в директорию с образом накопителя.

Чтобы обновление прошло быстрее я использовал эмуляцию Raspberry PI 2B в QEMU. С подбором опций пришлось повозиться, т.к. загрузка висла когда включалась сетевая карта. В итоге нашёл что для эмуляции Raspberry PI 2B рекомендуют передать ядру параметр dwc_otg.fiq_fsm_enable=0 и после этого система загрузилась.

Проблема с обновлением rpi-eeprom в Raspbian Bookworm

У меня есть принт-сервер для HP LaserJet 1018 на базе Raspberry Pi B+ в котором установлен Raspbian и CUPS. В конце октября я без проблем обновил эту систему с Raspbian Bullseye до Raspbian Bookworm, но сегодня при установке обновлений выдало ошибку:

Errors were encountered while processing:
 raspi-firmware
 rpi-eeprom
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up raspi-firmware (1:1.20231024+ds-1+rpt2) ...
stat: cannot read file system information for '/boot/firmware': No such file or directory
Error: missing /boot/firmware, did you forget to mount it?
dpkg: error processing package raspi-firmware (--configure):
 installed raspi-firmware package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of rpi-eeprom:
 rpi-eeprom depends on raspi-firmware; however:
  Package raspi-firmware is not configured yet.

dpkg: error processing package rpi-eeprom (--configure):
 dependency problems - leaving unconfigured
Processing triggers for initramfs-tools (0.142) ...
Errors were encountered while processing:
 raspi-firmware
 rpi-eeprom

Установка Prometheus Node Exporter на Raspberry PI 3 OpenELEC

Это пошаговое руководство описывает установку Prometheus Node Exporter v1.5.0 на Raspberry PI 3 с OpenELEC 9.2.8.

Скачиваем дистрибутив Prometheus Node Exporter для Linux с архитектурой armv7 (BCM2835 не поддерживает arm64) в /storage (в OpenELEC все пользовательские изменения должны сохраняться в /storage).

# cd /storage

# curl -fsSLO https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-armv7.tar.gz

# tar -xzf node_exporter-1.5.0.linux-armv7.tar.gz

# mkdir /storage/node_exporter/

# install -o root -m 755 node_exporter-1.5.0.linux-armv7/node_exporter /storage/node_exporter/node_exporter

# rm -fr /storage/node_exporter-1.5.0.linux-armv7 node_exporter-1.5.0.linux-armv7.tar.gz

Решение проблем с GPIO на Raspberry PI 4 в Debian Bullseye arm64

Обновил Raspberry PI 4 с Debian Buster до Debian Bullseye и подключил схему управления оборотами вентилятора чтобы сделать его тише. Для управления PWM я использую GPIO 16.

https://www.raspberrypi.org/documentation/computers/os.html

В прошлый раз я тестировал на OpenELEC с python 2.7, но в Bullseye используется python 3.9.2. Для работы с GPIO в Debian нужно установить пакет python3-rpi.gpio

$ sudo apt-get update
$ sudo apt-get install python3-rpi.gpio

Теперь можно установить сервис для управления оборотами в зависимости от температуры процессора

$ git clone https://github.com/tataranovich/Raspberry-Pi-PWM-fan.git
$ cd ./Raspberry-Pi-PWM-fan/
$ sudo python3 fan.py
Traceback (most recent call last):
  File "/home/andrey/Raspberry-Pi-PWM-fan/fan.py", line 42, in <module>
    GPIO.setup(FAN_PIN, GPIO.OUT, initial=GPIO.LOW)
RuntimeError: Not running on a RPi!

Апгрейд сборочного окружения ARM

Затеял обновление своего сборочного окружения, которое используется для компиляции пакетов для armel, armhf и arm64 архитектур. Сейчас оно построено на Raspberry PI 4 2GB и загружается с SD карточки на 32GB в которой /var/cache/pbuilder/build использует bcache поверх NFS и ram диска (подробности есть тут).

Это прилично ускоряет сборку в pbuilder, но только если размер билда не превысит размер ram диска. Raspberry PI 4 умеет загружаться с USB без плясок с бубном и поэтому самым простым решением для ускорения будет отказ от SD карт. Для этого я прикупил Orico M.2 NVMe SSD enclosure и Kingston A2000 на 256GB.

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

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

Ускорение сборки в 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.

Решил проблему с медленным запуском jenkins slave на Raspberry PI 3

Продолжение истории с jenkins, предыдущие посты тут и тут.

Откатил версию jenkins agent с 3.25 до 3.15 на Raspberry PI

Это продолжение истории с медленным запуском Jenkins агента на Raspberry PI.

Jenkins slave стал запускаться дольше 5 минут на Raspberry PI 3

После обновления плагинов Jenkins перестал запускаться агент на Raspberry PI 3. Попробовал увеличить таймаут до 5 минут, но это не помогло

Подключение принтера HP LaserJet 1018 к Raspberry Pi

Пытаюсь скрестить Raspberry Pi Model B+, принтер HP LaserJet 1018 и сканер Mustek 1200CU и получить домашний МФУ, доступный через ethernet. Но вот засада - не получается пока каменный цветок.

Сначала не получалось запустить установку минимального raspbian, используя raspbian-ua-netinst. В конце концов оно заработало и я получил чистую систему без lxde и прочих излишеств. Настала очередь оживить принтер, который был "отломан" в процессе отказа от стационарного компа, ранее выполнявшего и роль сервера печати.

Подключаю принтер к USB порту и проверяю, что он теперь виден в системе:

# lsusb 
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 008: ID 03f0:4117 Hewlett-Packard LaserJet 1018

Теперь нужно установить cups и printer-driver-foo2zjs

# apt-get update
# apt-get install -o APT::Install-Recommends=false cups printer-driver-foo2zjs
# cupsctl --remote-admin
# cupsctl --remote-any
# getweb 1018

После установки можно зайти в интерфейс настройки CUPS (https://hostname:631/). Чтобы начать работу с принтером нужно загрузить в него прошивку - для этого проще всего выключить и включить принтер снова.

kernel: [ 7019.844894] usb 1-1.3: new high-speed USB device number 8 using dwc_otg
kernel: [ 7019.985104] usb 1-1.3: New USB device found, idVendor=03f0, idProduct=4117
kernel: [ 7019.992207] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: [ 7020.001092] usb 1-1.3: Product: HP LaserJet 1018
kernel: [ 7020.005933] usb 1-1.3: Manufacturer: Hewlett-Packard
kernel: [ 7020.011090] usb 1-1.3: SerialNumber: KP0EL9M
kernel: [ 7023.171201] usblp 1-1.3:1.0: usblp0: USB Bidirectional printer dev 8 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
kernel: [ 7023.197038] usbcore: registered new interface driver usblp
kernel: [ 7023.226501] usblp0: removed
kernel: [ 7023.245471] usblp 1-1.3:1.0: usblp0: USB Bidirectional printer dev 8 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
/usr/sbin/hplj1018: foo2zjs: loading HP LaserJet 1018 firmware /lib/firmware/hp/sihp1018.dl to CUPS USB device ...
kernel: [ 7023.321255] usblp0: removed
kernel: [ 7031.385407] usblp 1-1.3:1.0: usblp0: USB Bidirectional printer dev 8 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
kernel: [ 7031.404279] usb 1-1.3: usbfs: interface 0 claimed by usblp while 'usb' sets config #1
/usr/sbin/hplj1018: foo2zjs: usb://HP/LaserJet%201018?serial=KP0EL9M... download successful.

Пробую добавить принтер в CUPS и не вижу его в списке, при этом в логе появляется сообщение о проблемах с принтером:

[  654.542227] usblp 1-1.3:1.0: usblp0: USB Bidirectional printer dev 8 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
[  717.077527] usblp0: removed

Пробую перезагрузить принтер, но все повторяется. Похоже без дебага не обойтись - расчехляю мультиметр и первым делом проверяю напряжение в точках PP3 (ground) и PP1 или PP2 (vcc).

В отличии от rPi Model B, Model B+ не имеет привычных точек проверки напряжения TP1 и TP2, вместо этого у нее есть супервизор питания (отображается красным светодиодом на плате) и точки PP3, PP1/2 . У меня показало 4.93V, что очень хорошо - похоже дело не в питании.

Значит придется разбираться с софтом. Сначала пробую обновить firmware до последней версии:

# apt-get install rpi-update
# rpi-update
# sed -i -e 's/^/#/' /boot/config.txt
# reboot

Обновление firmware и ядра результат не улучшило - принтер все так же отваливается при попытке его определить. Попробовал снизить скорость USB порта до USB 1.1 (12MBit/s). Для этого нужно добавить параметр dwc_otg.speed=1 в файл /boot/cmdline.txt и перезагрузиться:

# lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/5p, 12M
        |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 12M
        |__ Port 3: Dev 8, If 0, Class=print, Driver=usblp, 12M

Хотя скорость порта и снизилась, но принтер все же отваливается. Пока новых идей нету...

Резервное копирование домашнего медиацентра

Сегодня наводил окончательный лоск в настройках домашнего медиацентра (Raspberry PI + OpenELEC) после переноса его директории /storage с SD карты на сервер NFS (SD карта используется только для загрузки, а все файлы конфигурации и пользовательских данных хранятся на сервере и доступны через NFS).

Когда с настройками было покончено я сделал резервную копию средствами OpenELEC, но вот что интересно - резервная копия выполняется без завершения работы XBMC, а значит часть файлов копируется в процессе использования.

Узнать список файлов, которые в данный момент используются, можно на самом медиацентре

OpenELEC:~ # lsof | grep /storage
866 /usr/sbin/connmand /storage/.cache/connman/ethernet_b827eb9ace35_cable/data
946 /usr/lib/xbmc/xbmc.bin /storage/.xbmc/temp/xbmc.log
946 /usr/lib/xbmc/xbmc.bin /storage/.xbmc/userdata/Database/Addons15.db
946 /usr/lib/xbmc/xbmc.bin /storage/.xbmc/userdata/Database/Textures13.db
946 /usr/lib/xbmc/xbmc.bin /storage/.xbmc/userdata/Database/TV22.db
946 /usr/lib/xbmc/xbmc.bin /storage/.xbmc/userdata/Database/Epg7.db
946 /usr/lib/xbmc/xbmc.bin /storage/.xbmc/userdata/Database/Addons15.db

Открытые файлы *.db это базы SQLite, которые могут быть в промежуточном состоянии на момент создания резервной копии.

Чтобы избежать копирования открытых файлов можно выключить оболочку XBMC, создать резервную копию и затем включить XBMC обратно.

После изучения системы инициализации в OpenELEC оказалось, что самым простым способом достичь желаемого - выполнить перезагрузку всего медиацентра. В процессе завершения работы системы выполняется скрипт /storage/.config/shutdown.sh, который запускается после выключения XBMC, но до перезагрузки всей системы.

Собственно скрипт

if [ "`date +'%H'`" != "05" ]; then
 echo "Seems triggered not by cron job, simply exiting"
 exit 0
fi

STAMP=`date +'%Y%m%d%H%M%S'`

if [ ! -d /storage/backup ]; then
 mkdir /storage/backup
fi

echo "Settings backup..."
tar -cf /storage/backup/${STAMP}.tar /storage/.cache /storage/.config /storage/.xbmc

if [ "`date +'%u'`" == "7" ]; then
 echo "Flash backup..."
 tar -cf /storage/backup/${STAMP}_flash.tar /flash
fi

echo "Backup finished, syncing..."
sync
sleep 30s

Скрипт проверяет в котором часу он запущен и если сейчас не 5 часов утра, то создание резервной копии отменяется - скорее всего это перезагрузка по требованию пользователя, а не задания крона. Далее создается TAR-архив, содержащий конфигурацию OpenELEC и XBMC. Также если скрипт запущен в воскресенье, то дополнительно создается резервная копия всей системы (защита от неудачного обновления самого OpenELEC или выхода из строя SD карточки). Перед завершением скрипта выполняется сброс буферов и выжидается 30 секунд (на всякий случай).

Задание крона выглядит так

# crontab -u root -l

# Reboot to create semi-offline backup
10 5 * * * /usr/bin/xbmc-send --action="XBMC.Reboot"

Согласно этому заданию в каждый день в 5:10 утра выполняется команда перезагрузки средствами XBMC, что гарантирует корректное завершение работы.