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++ с двумя корзинами, там системные разделы создаются только в основном устройстве, в корзинах их нету), пробовал его менять - такое ощущение что он вообще не влияет ни на что. Кто нибудь знает на что влияет этот параметр?