Обновил как-то систему на своем старом HP 6930p до Debian 13, начались странности – не стартует графика. В lsmod 2 модуля для графики – radeon и amdgpu. Ок, заблеклистил amdgpu. Не особо помогает. Сейчас решил чуть больше покопать, плюс поделать оптимизации.
Архив рубрики: Компьютерное
System is booting up. Unprivileged users are not permitted to log in yet
Решение вопроса с невозможностью логина по sshd при незавершенной загрузке системы в случае, даже если сеть и sshd запущены:
Добавляем в
/etc/pam.d/sshd
auth [default=ignore success=1] pam_succeed_if.so quiet user ingroup adm
перед “auth requisite pam_nologin.so”
ESP Home, venv, pip, Debian 12->13
После обновления Dashboard не стартует, ругается в логах на “ImportError: No module named pip”, при этом python3-pip в системе стоит. Решение тут, выполняем под целевым юзером
python3 -m ensurepipFly 4410 в режиме мессенджера на 3G
Еще один небольшой тест автономности старого телефона – теперь включил передачу данных у мобильного оператора и вывел в сеть jabber-клиент Conversations (старая версия, которую еще можно было поставить на 4-й Андроид). По факту в сеть могли лазить еще ряд приложений – в трафике отметились всякие там “Службы Google”, “ОC Android” и тому подобное – top-5 приложений, помимо Conversations. Соответственно, при наличии сети они и проц использовали активнее. При первом тесте вообще получилось чуть больше 1 дня, потом снова зарядил батарею и повторил тест. Как и в прошлый раз – красивого скриншота не вышло, в 11:11 перед входом в настройки телефон выключился. В итоге получилось 2 дня и 9 с половиной часов:
Update 2025-12-25: сделал замер емкости батареи – 1411 мА*ч из 1800 (78%) при разрядном токе 200 мА и нижнем пороге 3В.
bsv core and blockchain size
Потребовалось тут проверить один старый адрес в сети одного из форков BTC – BSV – “правильного биткоина” по мнению его разработчиков. Правда, бинарных сборок для такого правильного кошелька они не предоставляют, пришлось вспоминать, как собирать самостоятельно. Ок, собрал. С дефолтным набором опций не запускается, запустил так:
./src/bitcoind --excessiveblocksize=0 --maxstackmemoryusageconsensus=0 --minminingtxfee=0
Началась синхронизация. На следующие сутки место закончилось – до того пришлось выделить места с запасом (исходя из размера блокчейна оригинала – BTC). Подключил через USB SSD от KingSpec. mhddfs в Debian 13 отсутствует, зато есть mergefs. Слил каталоги в один, запустил синхронизацию снова. На следующий день KingSpec умер (почти не использовал диск – лежал на полке). Размер архива активно начал расти после 60%, на 63% достиг 1,5 ТБ. К слову, для BTC на сейчас он “всего” 760 ГБ.
Пришлось задействовать HDD. Спустя несколько дней неторопливой синхронизации (из-за смерти SSD пришлось качать все заново, а на HDD оно не особо быстро происходило) словил OOM. На ноуте 24 ГБ памяти, если что.
Как финал этого – через еще несколько дней словил сообщение:
Error: Error:Disk space is low for directory '/home/rain/.bitcoin'! Available:2568500850688, required: mindiskspace:52428800 + additionalbytes:11553330338248163738, free:2568517627904, capacity:6958107836416
additionalbytes колебался от запуска к запуску. Блокчейн на диске в итоге занимал 3,3 ТБ и синхронизация так и осталась на уровне около 65%.
А адрес все равно оказался пустым. Поставил Guarda Wallet, там можно импортировать свой приватный ключ.
Home Assistant, уведомления и логика автоматизаций
Еще один баг, на этот раз со стороны Home Assistant. В последнее время решил хоть для чего-то начать использовать купленный на Али пару лет назад планшет Cubot TAB 20. Накатил туда Android-приложение Home Assistant, поставил его вместо ланчера (удобно, кстати, сделали – такой себе kiosk-mode из коробки), стоит теперь постоянно включенный. Для нескольких существующих автоматизаций решил сделать уведомления – пусть планшет подает звук, если кто-то звонит в ворота или если закончилась стирка. И поначалу вроде даже работало, но…
Сегодня заметил, что логика “звонка в ворота” сломана. Стоит сказать, что у меня на звонок стоит уведомление в джаббер, а дальше идет минутная пауза – т.е., не важно, как часто гость жмет кнопку, сообщения я буду получать лишь раз в минуту. Сейчас между сообщением в jabber и паузой добавилось еще уведомление на планшет. И – пауза перестала работать. При этом у меня на планшете нет никаких уведомлений, зато сообщения в джаббер могут идти как угодно часто. При попытке запуска уведомления на планшет вручную (в редакторе автоматизации) ничего не происходит. В другом случае (в уведомлении про стирку) получил сообщение, что устройство не подключено к локальному пуш-сервису (или как-то так). Так или иначе, проблема с одним “блоком” в автоматизации приводила к ее “вылету” и до паузы дело просто не доходило – появлялась возможность повторного запуска процесса целиком.
HA у меня не самый новый – 2024-го года, может в более свежем что-то и пофиксили, но проверить пока не могу.
esphome 2025.10.0 ломает связь с HA
Не было печали – апдейтов накачали.
Поставил свежий esphome – при прошивке девайсов (в моем случае на базе esp8266) при подключении к Home Assistant получаем
[D][api:160]: Accept 192.168.1.111 [D][api.connection:1383]: Home Assistant (192.168.1.111) connected [W][api.connection:1880]: Home Assistant (192.168.1.111): Reading failed CONNECTION_CLOSED errno=11
Даже если удалить / добавить девайс со стороны HA – не помогает. Сам девайс видится (передобавить его можно), но при этом список объектов не передается. При этом в веб-интерфейсе устройства все в порядке.
Решается откатом на прошлую версию и прошивкой девайса с этой версии:
pip install esphome==2025.9.3
Со стороны HA ничего менять и передобавлять не надо.
Продолжаем наблюдение.
lm-sensors и Asrock A520M-ITX/ac
В последние несколько дней навожу порядки на “большом” домашнем сервере:
- Обновил domU с сервером статистики. На самом деле – раскатал новую систему и мигрировал данные, так как пришлось бы последовательно апгрейдить Debian 9 -> Debian 13. Реально, но в чистовой установке будет меньше мусора, да и Nagios за это время сменил мажорную версию и простого апдейта не получилось бы.
- После чего подобавлял кое-где munin-node и мониторинг хостов в Nagios’е: наконец-то убрал заглушку “return-ok” в мониторинге хоста и теперь карта красиво подсвечивает неработающие “ветки”, а также получаю меньше писем, если отвалился корневой узел.
Глаз зацепился в том числе и за подсвеченный красным раздел sensors в munin’е. Честно говоря, никогда не обращал внимания на ALERT’ы в выводе sensors, что-то показывает – и ладно.
Во-первых, поисключал явно нерабочее. Помогла эта ссылка. Дальше – больше: в ряде сенсоров (прежде всего – напряжения) были не прописаны минимальные и максимальные значения (либо было что-то неадекватное) – например, даже при корректном значении измерителя линии 3.3В в минимальных и максимальных значениях стоял ноль и датчик выдавал ALERT. В итоге чуть расширил свой кастомный конфиг для lm-sensors – /etc/sensors.d/local.conf. В целом, синтаксис оказался достаточно простым: описываем секцию, обозначая чип или маской, или точным именем, дальше описываем то, что хотим сделать с опциями отдельных сенсоров, которые можно посмотреть по sensors -u.
/etc/sensors.d/local.conf
# https://superuser.com/questions/1828051/how-to-exclude-sensors-from-output
chip "nct6792-*"
ignore temp1
ignore temp4
ignore temp5
ignore temp6
ignore temp8
ignore temp9
ignore temp10
ignore in1
ignore in4
ignore in5
ignore in14
set temp3_max 75
set temp3_max_hyst 70
# +/- 5% для линий, которые на 3,3В
set in2_min 3.3 * 0.95
set in2_max 3.3 * 1.05
set in3_min 3.3 * 0.95
set in3_max 3.3 * 1.05
set in7_min 3.3 * 0.95
set in7_max 3.3 * 1.05
set in8_min 3.3 * 0.95
set in8_max 3.3 * 1.05
# Что-то непонятное. Задал диапазон или 0-1В, или 1-2В.
set in9_min 1
set in9_max 2
set in12_min 1
set in12_max 2
set in13_min 1
set in13_max 2
set in10_min 0
set in10_max 1
set in11_min 0
set in11_max 1
set in6_min 0
set in6_max 1
# Пара SSD. Адрес может смениться, если менять слоты
chip "nvme-pci-0b00"
ignore temp3
set temp1_min 0
chip "nvme-pci-0c00"
set temp1_min 0
set temp2_max 100
set temp2_min 0
set temp3_max 100
set temp3_min 0
[свернуть]
В тех сенсорах, в которых что-то показывалось, но непонятно, к чему оно относится (если они вообще подключены на плате) – просто задал широкий диапазон значений, чтобы не ругалось.
Еще одна полезная команда – sensors -s от рута, чтобы применить изменения в конфиге.
Накрылся очередной SSD от Kingspec
Накупил в конце 2023-го / начале 2024-го несколько SSD от Kingspec – сначала вторым для ноута, потом еще несколько для различных целей. Дешевые ж – на тот момент.
На сейчас – в ноуте иногда отваливается до перезагрузки, но пока живет. Терабайтник mini SATA, поставленный в плеер (т.е., крайне редкая запись и немногие чтения) накрылся некоторое время назад, остался без плеера.
Сейчас пришел черед мелкого диска на 256 ГБ, поставленный в малом сервере в пару с диском, шедшим с HP 820. Куплен был 13-го февраля 2024-го – т.е., хватило на полтора года. Сначала отвалился до перезагрузки, потом пропал насовсем. Купил замену на “Розетке” на 512 ГБ – объем про запас, смысл брать снова на 256? А в целом, цены на 256 локально сейчас дешевле, чем на Али “тогда”.
Сохранил SMART на тот момент, когда диск еще опознавался:
SMART
root@melissa:/home/rain# smartctl -a /dev/nvme1n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-39-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: XF-256 2280
Serial Number: 0009556000221
Firmware Version: 0629479F
PCI Vendor ID: 0xfe19
PCI Vendor Subsystem ID: 0x1d89
IEEE OUI Identifier: 0x000000
Total NVM Capacity: 250 059 350 016 [250 GB]
Unallocated NVM Capacity: 0
Controller ID: 0
NVMe Version: 1.4
Number of Namespaces: 1
Namespace 1 Size/Capacity: 250 059 350 016 [250 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 4f0000 000023c1ab
Local Time is: Tue Sep 23 10:33:27 2025 UTC
Firmware Updates (0x02): 1 Slot
Optional Admin Commands (0x0007): Security Format Frmw_DL
Optional NVM Commands (0x0016): Wr_Unc DS_Mngmt Sav/Sel_Feat
Log Page Attributes (0x02): Cmd_Eff_Lg
Maximum Data Transfer Size: 64 Pages
Warning Comp. Temp. Threshold: 100 Celsius
Critical Comp. Temp. Threshold: 110 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 4.00W – – 0 0 0 0 1 1
1 + 4.00W – – 1 1 1 1 10 10
2 + 4.00W – – 2 2 2 2 50 50
3 – 0.1000W – – 3 3 3 3 10000 5000
4 – 0.0050W – – 4 4 4 4 20000 125000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 35 Celsius
Available Spare: 83%
Available Spare Threshold: 10%
Percentage Used: 223%
Data Units Read: 12 537 201 [6,41 TB]
Data Units Written: 22 550 782 [11,5 TB]
Host Read Commands: 85 562 699
Host Write Commands: 586 078 813
Controller Busy Time: 29 138
Power Cycles: 19
Power On Hours: 13 721
Unsafe Shutdowns: 11
Media and Data Integrity Errors: 23 534
Error Information Log Entries: 171
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 45 Celsius
Temperature Sensor 2: 35 Celsius
Error Information (NVMe Log 0x01, 4 of 4 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 171 2 0x90ed 0x2281 – 2465024 1 –
1 170 2 0x80ed 0x2281 – 2465024 1 –
2 169 2 0x90f8 0x2281 – 11612896 1 –
3 168 2 0x80f8 0x2281 – 11612896 1 –
[свернуть]
Примечательно “Percentage Used: 223%”. У “Тошибы”, стоявшей в паре (которая до того была в ноуте) – только 26%.
На сейчас из живых Kingspec’ов остался только терабайтник в USB-кармане, который пока не использовал.
Несчастливые они какие-то.
ping и код завершения процесса
Давно уже использую в скрипте, рулящем маршрутами на несколько ISP, проверку доступности канала через ping несколькими пакетами на 8.8.8.8. Основной канал частенько переподключался без видимых на то причин. При этом пускал отдельно свой ping – там потерь пакетов вообще не было. Дошли руки подебажить. Если из 5 проверочных пингов пролазят только 2 – то ping -q отдает false. При 3 нормально. Вероятно, граница проходит по половине заданного числа попыток. В man’е вроде ничего на этот счет.
Переделал логику; теперь канал считается мертвым при полной потере пакетов на интерфейсе. Пока полет нормальный.