Я бы попытался сделать максимально самостоятельное устройство. Т.е. что бы его можно было сбросить и привести тем самым к какому-то состоянию по умолчанию. Если посмотреть на устройство прошивок всяких подобных сетевых хранилищь, да и прочей техники, то можно заметить, что там есть базовая система, которая хранится на отдельном разделе, и этот раздел монтируется в режиме «только чтение». И есть второй раздел, на котором уже хранятся настройки пользователя. Это даёт преимущество на случай неправильного отключения питания — основная система не повредится. Настройки так же можно хранить в двух разделах: текущие и некий бэкап.
Дальше небольшое замечание по идеи самого POSIX. Скрипты хранить в каталоге etc не хорошо. Надо бы перенести либо в /usr/local, либо создать подобную структуру в /opt. Так же запуск скрипта я бы оформил как демон в systemd. Сам systemd его и отслеживать может и в случае падения перезапускать.
Информацию о температуре писать на флешку — тратить ресурс флешки. Имеет смысл всякие каталоги типа /var, /tmp и /run монтировать в tmpfs.
Возможно, как вариант решения первого и последнего моих предложений, использовать overlayfs или aufs. Это такая штука, которая позволяет хранить основную систему нетронутой, используя её только для чтения, а все изменения хранить на другом разделе, либо в оперативной памяти.
По поводу скриптов — согласен, надо было идеологически правильно разместить. Не критично.

Скрипт для температуры сначала хотел оформить в виде демона, потом пошел легким путем, пока не сбоит, ибо прост как палка. Вообще говоря в процессе всех твиков и финтов понял, что можно бесконечно все улучшать и использовать разные методы, решил пока остановиться и сделать начальный гайд.

Про tmpfs тоже была идея в контексте постоянно пишущегося лога, но я решил этого не делать в следствие итак малого размера RAM + сейчас необходимо вести все логи чтобы ловить глюки OMV и чтобы они были доступны даже после ребута. По сравнению с логами, обновление температуры в файле нестрашно. Пока OMV в бете, часто приходится делать apt upgrade. Ну и, как я уже писал, иногда опять приходится включать что-то в ядре, перекомпиллировать и подкладывать ядро.

А вот с overlayfs идея крутая, возьму на заметку, в идеологии решает много проблем.

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

В часности посмотрите на overlayroot.
Он просто устанавливается и как правило не требует лишних телодвижений:


Всего несколько команд и вы уже имеете систему в памяти:


apt-get install overlayroot
echo 'overlayroot="tmpfs"' >> /etc/overlayroot.conf
reboot

На случай если нужно внести какие-то изменения:


overlayroot-chroot

Да, только в Дебиане этого пакета нет. По крайней мере, в стабильной ветке.

Тогда снова берите пример с производителей — сделайте отдельный раздел для логов. По крайней мере, портить флешку вы будете только в одном месте, а на качестве работы испорченный файл с логами не скажется.
портить флешку вы будете только в одном месте
А разве в USB флэшки (как и в SD-карты) не встраивают контроллеры износа? Давно может и не делали, но сейчас… (по смыслу поста — отдельный раздел для логов — понятно, и согласен)
Технически — никто не мешает сделать выравнивание износа, но практически, похоже, никому это не нужно по отношению к USB флешкам. Не предназначены они для такой работы, да и мало кто их использует так. Плюс, довольно распространённая схема использования — вставил, записал, вынул. Контроллеру чисто физически некогда будет заниматься выравниванием износа, особенно, если учесть стоимость всех этих флешек и их скорость работы.
Про tmpfs тоже была идея в контексте постоянно пишущегося лога, но я решил этого не делать в следствие итак малого размера RAM + сейчас необходимо вести все логи чтобы ловить глюки OMV и чтобы они были доступны даже после ребута.
1. Использовать удаленный syslog сервер. Самое кошерное для embedded devices.
2. Для rsyslog и journalctl можно настроить лимит размера лога.

Диски я указал по id, потому что буквы дисков /dev/sd[a-z] могут меняться в зависимости от порядка и кол-ва вставленных физических дисков.
Не понял этот момент. В fstab давно используется идентификация по UUID.
Так же в статье не затронут момент с тюнинга ФС (discard,noatime) для флешки.
Грандиозная работа. По хорошему если компания не хочет поддерживать свой продукт, ей надо платить таким как вы чтобы они занимались этим!

Они скорее в суд подадут, как в той истории с тракторами и украинской прошивкой.

Synology не рассматривал? Если по архитектуре влезет — будет наилучшее решение.
Чтобы портировать Synology DSM — надо будет много мучиться с ядром и модулем SynoBios в частности (Это модуль ядра отвечает за связь с отдельным микроконтроллером на плате, который управляет питанием, вентиляторами, светодиодами и фиг знает чем ещё).
В проекте XPenlogy патчат сами бинарники, лично я нашол реализацию «Заглушки» и дописал её функционал. Работает. (Портировал для WD MyCloud)
Работал с тем, что было на руках. Насколько я знаю, D-Link DNS-325 вообще популярная модель и мини статей по тюнингу уже много накопилось в сети, вот и решил показать что вообще можно сделать глобально.

Был бы Synology, тюнили бы Synology :)
Интересно, что данный девайс (И некоторые другие серии Dlink nas) аппаратно похожи на девайсы серии WD MyCloud. Причем на столько похожи, что даже в исходниках прошивки WD можно найти упоминания DNS327.
Ну а в самой прошивки — ровно теже баги с незасыпанием девайса, глюками Twonky (DLNA) и обилие костылей, которые можно было сделать в разы проще (И «правильнее»).
Интересно — это наследие некой SDK от Marvell (Производитель SoC) или просто обе компании заказали прошивки для своих девайсов одной фирме со стороны?
с DNS-323 можно такое же как в статье провернуть? или лучше сразу на свалку?
Можно, но во некоторых местах процедура будет отличаться. Например, поддержку другого чипа надо включить в ядре, вентилятор по другому настроить. В статье старался делать рассуждения и расписывать как правильно прийти к конкретным конфигам.

Но тут я согласен, такие эксперементы лучше проводить с настроением «или на свалку», ибо если это рабочий инструмент, убить его ненароком труда не составит :)
Посмотрите эту ссылку. Installing Debian On D-Link DNS-323
проделана работа грандиозная, но главное, вы нашли «правильный» проект, который смогли импортировать на железку, так что плюсую, а вот по поводу DLNA плагина — к сожалению и в этой версии наблюдаются сбои в индексировании контента… по умолчанию, стоит обновление базы каждый час, если не ошибаюсь, но уже дважды за месяц приходилось вырубать и снова включать службу((( грешу на траблы с загрузкой процессора и пр. перепетии с локалкой, которые сам же и вызвал своими же экспериментами, но все же случаи когда загрузил фильм в папку, а телек его не видит — были… возможно стоит поставить по крону задачу на перезагрузку данного сервиса, например в глубокой ночи, но чессло пока не нашел, как правильно это сделать((( плюс наблюдаются траблы с miniDLNA, на телеках гнусмас и филипс, когда через N кол-во минут фильм вылетает((( тоже вариантов решений много данного трабла, но пока и в этом направлении ничего дельного не нашел((( все сугубо ИМХО
На то она и бета, буду отлавливать баги и связываться с разработчиками.
У меня NAS WD My Cloud, как штатно хранит систему на том же HDD, что и данные. Также существуют сборки OMV по тому же принципу.
Много лет всё нормально работает, хотя девайс мне один раз меняли по гарантии. После неудачной штатной прошивки штатными же средствами было три варианта: разобрать и восстановить штатную прошивку, поставить OMV и поменять девайс целиком по гарантии (что я и сделал). Благо, там только WEB-морда накрылась, а доступ по SMB был. А сервисный центр был как раз по пути дом-работа.
PS: правда там внутри штатно сразу debian, и он совершенно открытый.
Не очень вкурсе, потому хочу спросить. kwboot — фишка только для Marvell SoC? Есть в наличии NAS eTRAYz и вот хотелось бы с ним что-то подобное провернуть.
Нет, kwboot подходит для всего, где есть U-Boot.

Кто-то уже пытался, кстати: http://orangepi.pp.ua/index.php?topic=565.0
Да собственно я и пытался) Но уже давно было. А тут увидел Вашу статью, и прям аж вдохновился и захотелось всё же закончить начатое.
Также включены обязательные параметры для поддержки systemd.
systemd — в нём была необходимость? Можно обойтись без него? (как на обычных архитектурах типа amd64)

В данном случае разработчики OMV озаботились поддержкой только systemd, увы.


http://packages.openmediavault.org/public/dists/erasmus/main/binary-armel/Packages


Package: openmediavault
Version: 3.0.76
Architecture: all
Maintainer: Volker Theile volker.theile@openmediavault.org
Installed-Size: 6364
Depends: ..., systemd, systemd-sysv, ...
А на EMC / iomega StorCenter ix2 (теперь Lenovo ix2-2) прокатит ли такая модификация прошивки?
Вроде сходная платформа, но не нагуглил для неё прямого рецепта…
root@ix2-2:/# cat /proc/cpu
cpu/     cpuinfo
root@ix2-2:/# cat /proc/cpuinfo
Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1589.24
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Feroceon-KW
Revision        : 0000
Serial          : 0000000000000000
root@ix2-2:/# uname -a
Linux ix2-2 2.6.31.8 Thu Feb 16 17:58:20 EST 2017 v0.0.9 Thu Feb 16 17:58:20 EST 2017 armv5tel GNU/Linux

В теории — да.


Device Tree исходник — arm-soc/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts

вот бы так замутить на DNS-320 rev.A1 — ни в какую не хочет u-boot компилироваться с Джеймевского гита, а со статьи для 325-ого не подходит.

В чем проблема, на что ругается? Я привел универсальный способ, введите 320 вместо 325 и должно все сработать.

Только зарегистрированные пользователи могут оставлять комментарии.
Войдите, пожалуйста.