azhur

Какая версия DSM, давно отвалился? Если 6.2 - то возможно вот в этом дело:

У меня было дело в записи логов на диск. логи пишутся на системный раздел, а его копия - на каждый диск. Если есть дополнительный софт - то нужно и по его логам глянуть, не пишется ли что-то регулярно. Например, в transmission я отключал scrape, насколько помню.

use-nas, Blind4ever, спасибо, понятно!

А как вычисляется адрес для записи значения, ведь для разных моделей материнок (а может и версий BIOS) он разный? Gigabyte j3455-d3h bios f3 - 0x48A ASRock J3455-ITX bios 1.80 - 0x4E2

И на всех 16 был и использовался системный раздел?

Находил в /var/log/dmesg вот такие строки: [Sat Oct 17 10:20:23 2020] md: Autodetecting RAID arrays. [Sat Oct 17 10:20:24 2020] md: invalid raid superblock magic on sda3 [Sat Oct 17 10:20:24 2020] md: sda3 does not have a valid v0.90 superblock, not importing! [Sat Oct 17 10:20:24 2020] md: invalid raid superblock magic on sdb3 [Sat Oct 17 10:20:24 2020] md: sdb3 does not have a valid v0.90 superblock, not importing! [Sat Oct 17 10:20:24 2020] md: Scanned 6 and added 4 devices. [Sat Oct 17 10:20:24 2020] md: autorun ... [Sat Oct 17 10:20:24 2020] md: considering sda1 ... [Sat Oct 17 10:20:24 2020] md: adding sda1 ... [Sat Oct 17 10:20:24 2020] md: sda2 has different UUID to sda1 [Sat Oct 17 10:20:24 2020] md: adding sdb1 ... [Sat Oct 17 10:20:24 2020] md: sdb2 has different UUID to sda1 [Sat Oct 17 10:20:24 2020] md: created md0 [Sat Oct 17 10:20:24 2020] md: bind<sdb1> [Sat Oct 17 10:20:24 2020] md: bind<sda1> [Sat Oct 17 10:20:24 2020] md: running: <sda1><sdb1> [Sat Oct 17 10:20:24 2020] md/raid1:md0: active with 2 out of 12 mirrors [Sat Oct 17 10:20:24 2020] md0: detected capacity change from 0 to 2549940224 [Sat Oct 17 10:20:24 2020] md: considering sda2 ... [Sat Oct 17 10:20:24 2020] md: adding sda2 ... [Sat Oct 17 10:20:24 2020] md: adding sdb2 ... [Sat Oct 17 10:20:24 2020] md: created md1 [Sat Oct 17 10:20:24 2020] md: bind<sdb2> [Sat Oct 17 10:20:24 2020] md: bind<sda2> [Sat Oct 17 10:20:24 2020] md: running: <sda2><sdb2> [Sat Oct 17 10:20:24 2020] md/raid1:md1: active with 2 out of 12 mirrors [Sat Oct 17 10:20:24 2020] md1: detected capacity change from 0 to 2147418112 [Sat Oct 17 10:20:24 2020] md: ... autorun DONE. Из чего сделал вывод, что таки не на всех, а только на первых 12. Но насколько часто встречаются конфигурации с количеством дисков больше 12?

Продублирую тогда сюда и своё решение годовой давности из той темы. Мой вариант изменения файла /etc.defaults/syslog-ng/patterndb.d/scemd.conf, отличается меньшей радикальностью в отключении логирования сообщений. Делался для Microserver N54L, DSM 6.2.3-25426 Update 2 # begin scemd.conf patch to suppress ioctl messages filter f_scemd_ioctl { program(scemd) and match("polling_.*ioctl\ device\ failed$" value("MESSAGE")); }; #log with no destination and final flag = discard log { source(src); filter(f_scemd_ioctl); flags(final); }; # end scemd.conf patch filter f_scemd { program(scemd); }; filter f_scemd_sev { level(err..emerg) }; destination d_scemd { file("/var/log/scemd.log"); }; log { source(src); filter(f_scemd); filter(f_scemd_sev); destination(d_scemd); }; Смысл в том, что добавляем свой блок-правило перед штатным, которорый дискардит ненужные сообщения, возникающие из-за несовпадения железа с фирменным от Сино.

Из-за того, что у Let's Encrypt 30 сентября 2021 г. "протух" сертификат его intermediate CA, а нового в базе нет, на DSM 6.2.3-25426 Update 3 и более старых могут наблюдаться проблемы с валидацией сертификатов ssl, HTTPS и т.п. В частности, будут проблемы с добавлением/доступностью/установкой пакетов из репозитория SynoCommunity. Для решения проблемы нужно заменить файл с базой корневых сертификатов на актуальный, например так: В более новых версиях DSM проблема скорей всего уже исправлена разработчиками, но для них пока нет стабильного лоадера. ЗЫ Админы, может пришпилить тему?

Разобрался, таким боком мне аукнулся протухший CA-сертификат letsencrypt. Решение есть в английской ветке тут:

Thanks, this helped me too!

Только вот почему-то в моём случае в списке доступных для установки пакетов ни один из "Synocli *" не значится. Пришлось выдёргивать с сайта файл .spk и ставить вручную. На первый взгляд - поставился без проблем. HP Microserver N54L, DS3615xs, DSM 6.2.3-25426 Update 3. Кто-то может подсказать, это у меня что-то в работе с пакетами перекривило, или так и должно быть?

Насколько я в теме: 1. Если не прописать реальные MAC-адреса - WoL точно работать не будет. 2. Если не прописать правильные адреса от реальной фирменной железки Synology - точно не удастся зарегаться на фирменном сайте Синологии и пользоваться завязанными на него сервисами. Оба пункта - "необходимо, но не достаточно".

1. Актуальная версия - DSM 6.2.3-25426 Update 3. 2. Первые две - по большому счёту без разницы, с переходом на DS916 насколько помню стоит заморачиваться только если нужен аппаратный транскодинг (и железо его поддерживает). 3. Смотря что иметь в виду под "системным диском". Раздел с системой зеркалирутся на все внутренние диски (ну на первые 5 из них - точно). На первый диск по умолчанию ставится дополнительный софт. Сам отключать часть дисков на момент обновления не пробовал, у меня их не так много. Может кто-то ещё подскажет. 4. Вроде так: делаешь бэкап настроек системы, выключаешь, заменяешь флешку с загрузчиком на новую, (???отключаешь лишние диски???), включаешь, вместо веб-морды видишь мастер с предложением обновления или миграции данных, далее по мастеру. Если после первой удачной загрузки часть настроек слетела - восстанавливаешь из бэкапа.

Я Noctua NF-A4x20 5V в блок питания поставил: https://www.dns-shop.ru/product/2f47f736f2221b80/ventilator-noctua-nf-a4x20-5v/ Корпусный поменять пока так и не собрался.

По принципу "лучше поздно чем никогда" отписываюсь о текущих успехах в борьбе с "бессонницей" у хренологии. По материалам темы в английской части форума сделал свой вариант исправленного файла /etc.defaults/syslog-ng/patterndb.d/scemd.conf # begin scemd.conf patch to suppress ioctl messages filter f_scemd_ioctl { program(scemd) and match("polling_.*ioctl\ device\ failed$" value("MESSAGE")); }; #log with no destination and final flag = discard log { source(src); filter(f_scemd_ioctl); flags(final); }; # end scemd.conf patch filter f_scemd { program(scemd); }; filter f_scemd_sev { level(err..emerg) }; destination d_scemd { file("/var/log/scemd.log"); }; log { source(src); filter(f_scemd); filter(f_scemd_sev); destination(d_scemd); }; После этого сообщения в логе "ioctl device failed" из /var/log/scemd.log пропали, а в Log Center появились сообщения вида "Internal disks woke up from hibernation". То есть какой-то из двух дисков всё-таки иногда засыпает, но какой и надолго ли - непонятно. Начал искать, где бы посмотреть подробности. Пока всё что нашёл - вот такого типа записи всё в том же /var/log/scemd.log 2020-11-15T00:32:20+05:00 synoserver scemd: led.c:270 Enable power & phy LED 2020-11-15T00:32:29+05:00 synoserver scemd: event_disk_hibernation_handler.c:44 The internal disks wake up, hibernate from [Nov 14 23:59:36] 2020-11-15T02:50:09+05:00 synoserver scemd: led.c:270 Enable power & phy LED 2020-11-15T02:50:17+05:00 synoserver scemd: event_disk_hibernation_handler.c:44 The internal disks wake up, hibernate from [Nov 15 02:04:16] 2020-11-15T04:32:09+05:00 synoserver scemd: led.c:270 Enable power & phy LED 2020-11-15T04:32:16+05:00 synoserver scemd: event_disk_hibernation_handler.c:44 The internal disks wake up, hibernate from [Nov 15 04:30:47] То есть какой диск засыпает - по-прежнему непонятно (попробовать отследить по индикаторам на корзине?), но есть данные когда заснул и когда проснулся. По просмотренным меткам времени в логе за последние несколько дней получается, что диск засыпает до десятка раз за сутки, но спит не более часа. Есть подозрение, что виновник - Transmission, даже в простое что-то регулярно пишущая на диск, так как стороннего постоянно запущенного больше ничего нет. Буду проверять эту версию.