vapet

Засада, какая-то с количеством дисков. Все настроено как в шапке (у меня сервер под 22 диска, соответственно так и настроено, 22 слота видно было изначально). Проблема в том, что при добавлении 13-го диска, он в системе не появляется. Более того экспериментально установлено, что проблема именно в потрохах Xpenology, т.е. ядро диски видит, ручное подключение соотв. устройства к массиву через mdadm проходит, но в интерфейсе больше 12 дисков не появляется (пустые квадратики) и при перезагрузке диск от массива отваливается. Думаю, что эта логика срабатывает из-за того что модель устройства задана как 3612, у которого в основном блоке только 12 дисков. Как это обойти не понятно. Есть идеи или кто-то уже это преодолел? Версия у меня 5.0-4528, на более новую пока не перехожу, т.к. у меня ядро самосборное с добавкой драйвера под контроллер. UPD: Отмена, это я поигрался с параметром internalportcfg и забыл. Результат - поломанный массив с 8ТБ данных, которые придется выкачивать заново. Вывод - надо эксперименты доводить до конца, т.е. возвращать все как было сразу.

Thats what I've done to extract ramdisk from nanoboot in order to include additional driver module in it and make some changes in rc files: 1. We need to extract zImage to vmlinux bunary by using scripts/extract-vmlinux utility in kernel source tree. 2. In vmlinux binary search for cpio magic string '0707'. That will give us start of ramdisk offset. 3. In vmlinux binary search for end of cpio magic string 'TRAILER!!!'. From this we can calculate the size of cpio binary. 4. Strip cpio ramdisk binary from vmlinux by using dd utility and starting offset and size. 5. Extract files from ramdisk using cpio. After making some changes to include your ramdisk files in kernel you need to do a reverse procedure: 1. Use cpio to pack files in one binary. 2. Use make config in kernel sources to set init_ramdisk to your file (somewhere in 'General kernel parameters' menu). 3. Make kernel zImage which will include your ramdisk. Put it in .IMG or simply copy it to mounted flash disk overwriting old version.

awk errors is not a real problem - those errors are normal for installation mode, when normal root having all those utils is not mounted. USB keyboard should be connected to USB 2.0 port, not a 3.0! No network problem should be solved if you include correct mac1 and mac2 parameters to kernel in grub (you can read about calculating them in nanoboot install instructions). Nanoboot uses version in some parts of rc scripts, so it should be better to leave this param to old 5.0 value.

You can see all patches that he done in his github commit history. Some commits after June are not relevant - he tried to play with different FS, i've used his June,1 commit. I don't know exactly from which sources he started, I suggest 4528...

Have no time to give it a try to 5.1 by myself, but I can suggest to enable a VGA console in a kernel which you build, then boot process should be more informative. To see how to enable console, you can look through https://github.com/liwei/xpenology-3.x patches which are fresher than sancome's and closer to last nanoboot version. I have built a new kernel from liwei sources with additional driver and it is working on my server now with nanoboot 5.0.3.2 ramdisk. All my tries with sancome's sources was not successfull.

What is the reason for it to be a much different? Kernel sources have difference, but not disclosed yet.

Про подключение ардуины не скажу, пока не дошел еще до реальных экспериментов. Могу рассказать свою задумку для чего хочу что нибудь такое воткнуть в хрено. У меня оно в большом корпусе стоит под большое кол-во винтов и с многими вентилями. Хочется сделать какой нить независимый от мамы монитор (мама всем не позволит рулить, даже если до нее достучаться), который бы позволял: 1. Снимать температуру с множества зон. В идеале вплоть до каждого винта (в т.ч. брать температуру со смарта винтов). Можно еще датчик на входящий воздух навесить и т.п. 2. Рулить вентиляторами в соответствии с зонами, которые они продувают. Например у меня висит корзина на 8 винтов и с нее тянут 3 вентилятора, стало быть в зависимости от нагрузки на отдельные винты можно снижать-повышать обороты отдельно на каждом. Поставлю еще 2 корзины по 5 - у каждой будет вентилятор, которым корзина тоже сама не управляет, можно влепить PID-регулятор оборотов с поддержанием винтов на целевой температуре. В соответствии с загрузкой выдувающих вентиляторов, рулить всасывающими, чтобы потоки соответствовали. 3. Иметь доступ к консоли в обход сети, на случай проблем с нею. 4. В идеале повесить граф. дисплей на который выводить состояние - загрузку проца-памяти-сети, температуры и т.п. Ну и несколько кнопок чтобы все это листать-настраивать. P.S. Есть интересные девайсы, китайцы торгуют, куда ставится OpenWRT и имеется некоторый набор GPIO. Можно поискать по названию VoCore. Вот тут обзор http://catethysis.ru/vocore-iot-computer/. Там на борту и WiFi и проводная сетка есть тоже.

I've found one interesting configuration for up to 20xhdd nas and built it for Xpenology (all parts without disks costs less than 1000$ here in Russia): 1. Motherboard - ASRock Z87 Extreme 11/ac (having 6SATA + 16SAS ports through LSI 3008 on board, 2 mSATA ports). 2. Chieftec ATX BA-02B-B-B case having int 8x 3,5" + ext 2 x 3,5" + ext 6 x 5,25" (convertible to 10x3,5 with some enclosures like SuperMicros). It have overall 20 hdd slots which fits with MB 20 ports (+2 are used for mSata on board). This config have good further extension possibility since there are 5 PCIe slots on board for controllers and 2x20Gbit Thunderbolt2 ports (Thunderbolt extensions are hard to find now, but situation is changing). I've patched nanoboot kernel sources to include LSI 3008 driver as a module and it is working OK for some time. If somebody needs it, I can give instructions how to do this patch.

3612 - means model which can be maxed with 36 disks (12 in main enclosure + 2x12 additional DX12xx through eSATA or Infiniband ports). 12 means model year 2012. There is also 3614 model - almost the same, some hardware is changed up to date. Same way DS1511 - max 15 disks (5 main + 2x5 additional eSATA), 2011 model year. I have this one on my desk with DX510 and DX513 additional enclosures which means 5 disks each, 2010 and 2013 model years (fully compatible). There is almost the same model DS1812 - 8 disks in main enclosure, using the same DX51х additions (18 = 8+2x5). Letters are DS for DeskStation, RS for RackStation (for 19" racks), VS for VideoStation. There was also a CS - CubeStation, looking like a cube.

У меня матплата с микрухой биоса аж на 64Мб, есть мысль запихать туда хотя бы ядро. Но дальше мысли дело пока не сдвинулось . Микрухи на самом деле даже две с переключателем, так что можно будет даже тестировать второе ядро без потери стабильного. Мечты, мечты...

Значит вы никогда не пользовали свой синолоджи даже на 10%. У меня вообще-то на NAS-ах много чего еще крутится - например Mysql базы, веб-сервер и т.п. Понятное дело, что лучше иметь достаточно реальной памяти, своп это аварийный вариант.

Ага, очепятка.

Докопался до простого решения для свапа. Изучил процедуру в /etc/rc.subr, которая воссоздает свапы. Оказалось что для нее есть параметр swapdisks в synoinfo.сonf, который по умолчанию в DSM не используется, т.е. задействуются все внутренние диски. В этот параметр пишется список номеров дисков, на которых нужны swap-разделы (включаемые в raid1 /dev/md1). Например: "1 2" - использовать под свап только разделы на первых двух дисках. Проверил - после установки параметра при инициализации диска, разделы на новых дисках в свап-массив не включаются, хотя и создаются. Можно их задействовать под что-то другое. Осталось найти решение для рута. Проблема с ним только при подключении новых дисков - партиция создается и подключается в рэйд, если из рейда ее руками исключить, то DSM-у это будет по барабану. Важно: обязательно на md0 и md1 уменьшить количество дисков в массиве до необходимого: mdadm --grow --force -n[кол-во дисков] /dev/md[01]. Иначе постоянно будут попытки туда всунуть еще разделы. Так они смогут добавиться к массиву, но в виде Spare и не будут использоваться. На "восстановить" для системного раздела приходится нажимать два раза. Первый раз к свапу добавятся неиспользуемые разделы. Второй раз они из него удалятся. Чудесная нелинейная логика у DSM . С рутом так не получается, разделы должны быть добавлены к md0 как Spare чтобы веб-интерфейс не ругался что системный раздел умер.

Check the maxdisks parameter in /etc/synoinfo.conf. In my case (booting woth nanoboot 5.3.2) it was reset after each reboot, so in the end I've modified startrup script in nanoboot to set this parameter to 22 and it works as needed - I see my 22 disk slots in DSM.

Вот сижу в похожей ситуации и не могу понять как бы сделать так, чтобы системные разделы не создавались на всех моих 22 дисках... По умолчанию DSM при инициализации нового диска распространаяет на него в рейде 2 системных раздела - рут (dev/md0) и свап (/dev/md1) оба в режиме raid1. Это конечно супернадежно, но есть нюанс - запись в своп и на системный диск приводит к чему? Правильно что все 22 диска дружно хлюпают головками. А у меня вообще 2 отдельных mSATA SDD под систему выделено, зачем мне зеркалить систему на все, чтоб тормозило еще больше? Пока никаких вариантов кроме ручного удаления лишних дисков из рейда не придумал. При этом остается потерянное место по 4 ГБ на диск, ну и как бы автоматизм имени DSM теряется. Можно было бы предположить что вот этот параметр internalportcfg="0x3fffff" влияет на эту логику (у меня есть родной DS1511++ с двумя корзинами, там системные разделы создаются только в основном устройстве, в корзинах их нету), пробовал его менять - такое ощущение что он вообще не влияет ни на что. Кто нибудь знает на что влияет этот параметр?

Заметил что под nanoboot, /var/log/messages завален вот такими строчками: Nov 20 12:44:15 XPenology entry.cgi_SYNO.Core.System.Utilization[1].get[9270]: dbus_client.cpp:38 Failed to get bus connection Они валятся регулярно, если в вебинтерфейсе открыт монитор ресурсов. Монитор все показывает нормально. Что бы это могло быть?

В виде модуля пашет, диски увиделись, SMART читается, форматируется. Так что если кому еще нужен драйвер под LSI 3008 (3108 и 3004), могу рассказать как его в 3.2.40 ядро вставить. Выложить у меня собственно кроме вышенаписанного особо нечего, я в самих потрохах nanoboot (всякие скрипты на ramdisk для подмены файлов, обхода защиты и т.п.) пока не ковырялся. Но судя по тому что в githab у самого sancome валяется, он взял за основу скрипты сборки gnoboot, правил только начинку. Начинку его можно достать из ramdisk вышеописанным способом, распаковать с помощью cpio.

Собирать-то я ядро научился, а драйвер так и не заработал. Не могу понять, в ядро он собирается нормально, а при загрузке его в dmesg вообще нету, как будто и не было. Придется учиться все таки модули в nanoboot пихать.

Да, вариант с liwei прокатил. Если кому интересно как собирать свое ядро в nanoboot: 1. Берем исходники отсюда https://github.com/liwei/xpenology-3.x. Я брал не последнюю версию, лучше берите версию на 01.06, дальше liwei стал зачем-то экспериментировать с aufs, больше ничего содержательного для DSM не менялось. 2. Собираем свое ядро (если не умеем идем читать начало этой ветки). 3. Подменяем ядро в nanoboot по процедуре, которую я описал на 4 поста выше. 4. Не все изменения в ядре так легко прокатят, например доп. модули придется вставлять в ram-диск и прописывать там в modules.d и т.п. Я этот путь пока не проходил, меня волнует только один драйвер, который я компильнул прямо в ядро. В принципе это возможно, но надо будет повозиться с рапаковкой-запаковкой рам-диска через cpio (не потеряв по дороге спец.файлы в папке /dev рам-диска!!!). Если я этой инструкцией обидел авторов nanoboot, прошу прощения. Надо было четче высказывать свою позицию на просьбы народа выдать исходники. Тут как везде - либо вы оперативно реагируете на чаяния народа, либо народ пойдет своим путем .

Я уже нашел несколько вариантов, в том числе и liwei, сейчас пробую по очереди собирать. Свежее июня нигде исходников нет. Корни у них вроде бы одни и те же, в основном что-то в конфиге ядра правится.

Если вы про исходники, то те которые Synology выложили synogpl-4458-bromolow.tbz. Если про nanoboot, то скачал где-то Nanoboot-5.3.1-fat.img. Нашел еще в форуме архив xpenology.zip, в нем как я понял alpha9 исходники сборки от trantor, попробую еще к нему пристроить сборку ядра с драйвером.

Очень хочу получить в Xpenology драйвер для LSI 3008. Он в линухе появился только ядре 3.8, DSM использует как известно 3.2.40. Я его вроде забэкпортил из 3.12.32, всего пара мелких правок понадобилась и он в ядро собирается. Затык в том, что не могу собрать нормально ядро, чтобы его в nanoboot заменить, чтобы DSM грузился (synobios ругается, половина модулей Failed и т.п.). Нужен кто-то кто умеет собрать ядро для nanoboot (имеет нужные патчи к исходникам и конфиг), чтобы либо научить меня, либо собрать самому. Простаивает отличный NAS на 22 диска (собранный за !!! 30к.рублей без дисков), все уперлось в этот драйвер.

В zImage кроме ядра включен еще ram-диск, который отрабатывает между загрузкой ядра и запуском DSM. В nanoboot в этот диск встроена подмена файлов и прочая борьба с защитой Syno. Чтобы подменить ядро на свое нужна след. последовательность действий: 1. В исходниках ядра есть утиль scripts/extract-vmlinux, которая распаковывает ядро в исходный вид. 2. Ищем в файле ядра magic для образа cpio - строка "0707" (второе вхождение, первое попадает в код). Запоминаем смещение. Ищем конец образа cpio - строка "TRAILER!!!". Вычисляем размер. 3. Вытаскиваем этот образ, например с помощью dd. 4. Если в рам-диске менять ничего не надо, оставляем его до лучших времен в покое, лучше с расширением cpio, чтобы он обратно в ядро собрался. 5. Собираем ядро (вот тут все волшебные пузырьки, не имея родных патчей и конфигурации от автора nanoboot, я ни разу пока не смог собрать ядро, которое бы без проблем грузилось, то модули не все грузятся, то synobios на символы ругается). 6. Собрали да? Зря торопились, надо было не забыть в конфигурации ядра указать файл рам-диска в параметре init_ramdisk (где-то в General kernel parameters)... 7. Получаем в boot/bzImage ядро с уже встроенным рам-диском, переименовываем на флэшку в zImage, профит. Еще раз повторяю я пока успеха со сборкой и загрузкой ядра не достиг. Хотя очень хочу. У меня мать ASRock Z87 Extreme 11/ac c 22 каналами SATA и корпус на 22 диска простаивают. Всего-то надо драйвер для LSI 3008 встроить. Из ядра 3.12.32 я его уже в 3.2.40 перенес. Ядро пока собрать до конца не научился, чтобы nanoboot с ним заработал. Либо сам методом тыка за пару лет разберусь, либо авторы сжалятся и дадут патчи и конфиг ядра.

Is it possible to have LSI 3008 driver (mpt3sas) in DSM? So far i've done something in this direction but with no success yet: 1. I've tried to build kernel with mpt3sas and insert it into nanoboot zImage. 2. 3.2.40 kernel have no mpt3sas driver, so i've backported it from 3.12.32 (actually 2 small corrections needed), but can't test them without working nanoboot with my kernel. I tried to build kernels by myself but it is not so easy to guess all patches needed for Syno security and kernel configuration settings. My tries ended with synobios.ko absent symbols and kernels which can't build for some syno modules dependency wreckage. 3. To build correct kernel for nanoboot i need patches and .config with which nanoboot was built or i can give to somebody patches for mpt3sas to build nanoboot (or gnoboot) for me to test. I have an ASRock Z87 Extreme 11/ac mb, which have 16 SAS ports (22 SATA ports including chipset) installed in a box with 22 possible hdd slots - ideal for NAS building, but can't use Xpenology with it because of no drivers in kernel. NAS4Free is obvious option since FreeBSD have this driver starting from 9.3, but I want to try Xpenology way first. I love my 15xhdd DS1511+ sitting on the table.