Jump to content
XPEnology Community

Leaderboard

Popular Content

Showing content with the highest reputation on 09/16/2020 in Posts

  1. NOTE: This problem is consistently manifested when running Jun's loader on a virtual machine with 6.2.3, but some also have problems on baremetal, and under certain conditions, other 6.2.x versions. The fix can be implemented safely on all Jun loader installs. You can verify if you have the issue by launching SSH and issuing the following command: $ ls /dev/synoboot* /dev/synoboot /dev/synoboot1 /dev/synoboot2 If these files are not present, your Synoboot devices are not being configured correctly, and you should install the fix script. If synoboot3 exists that is okay. TL;DR: When running DSM 6.2.3 as a virtual machine (and sometimes on baremetal), Jun's 1.03b and 1.04b bootloaders fail to build /dev/synoboot Bootloader SATA device normally mapped beyond the MaxDisks limit becomes visible if /dev/synoboot is not created DSM 6.2.3 update rewrites the synoinfo.cfg disk port bitmasks which may break arrays >12 disks, and cause odd behavior with the bootloader device Background: Setting the PID/VID for a baremetal install allows Jun's loader to pretend that the USB key is a genuine Synology flash loader. On an ESXi install, there is no USB key - instead, the loader runs a script to find its own boot device, and then remakes it as /dev/synoboot. This was very reliable on 6.1.x and Jun's loader 1.02b. But moving to DSM 6.2.x and loaders 1.03b and 1.04b, there are circumstances when /dev/synoboot is created and the original boot device is not suppressed. The result is that sometimes the loader device is visible in Storage Manager. Someone found that if the controller was mapped beyond the maximum number of disk devices (MaxDisks), any errant /dev/sd boot device was suppressed. Adjusting DiskIdxMap became an alternative way to "hide" the loader device on ESXi and Jun's latest loaders use this technique. Now, DSM 6.2.3: The upgrade changes at least two fundamental DSM behaviors: SATA devices that are mapped beyond the MaxDisks limit no longer are suppressed, including the loader (appearing as /dev/sdm if DiskIdxMap is set to 0C) The disk port configuration bitmasks are rewritten in synoinfo.conf: internalportcfg, usbportcfg and esataportcfg and on 1.04b, do not match up with the default MaxDisks=16 anymore (or if you have modified MaxDisks). NOTE: If you have more than 12 disks, it will probably break your array and you will need to restore the values of those parameters Also, when running as a virtual machine (and sometimes on baremetal), DSM 6.2.3 breaks Jun's loader synoboot script such that /dev/synoboot is not created at all. Negative impacts: The loader device might be accidentally configured in Storage Manager, which will crash the system The loader partitions may inadvertently be mapped as USB or eSata folders in File Station and become corrupted Absence of /dev/synoboot devices may cause future upgrades to fail, when the upgrade wants to modify rd.gz in the loader (often, ERROR 21 or "file corrupt") Unpacking Jun's synoboot script reveals that it harvests the device nodes, deletes the devices altogether, and remakes them as /dev/synoboot. It tries to identify the boot device by looking for a partition smaller than the smallest array partition allowed. It's an ambiguous strategy to identify the device, and something new in 6.2.3 is causing it to fail during early boot system state. There are a few technical configuration options can can cause the script to select the correct device, but they are difficult and dependent upon loader version, DSM platform, and BIOS/EFI boot. Fix: However, if Jun's script is re-run after the system is fully started, everything is as it should be. So extracting the script from the loader, and adding it to post-boot actions appears to be a solution to this problem: Download the attached FixSynoboot.sh script (if you cannot see it attached to this post, be sure you are logged in) Copy the file to /usr/local/etc/rc.d chmod 0755 /usr/local/etc/rc.d/FixSynoboot.sh Thus, Jun's own code will re-run after the initial boot after whatever system initialization parameters that break the first run of the script no longer apply. This solution works with either 1.03b or 1.04b and is simple to install. This should be considered required for a virtual system running 6.2.3, and it won't hurt anything if installed or ported to another environment. FixSynoboot.sh
    1 point
  2. La solution OPenMptcpRouter reste intéressante si tu parviens à l'installer en VMM sur le Syno, ce serait le plus simple et le moins cher puisque tu n'aurais à priori pas grand chose à modifier dans ton réseau pour faire fonctionner cette solution. Fais un tuto si tu y parviens Mais effectivement, quoi qu'il en soit, pour NATter de la connexion 4G, à part peut-être la Box 4G Bouygues Telecom, il faut passer par un VPS extérieur pour récupérer une IP publique exploitable. Concernant ta question sur la télé, je ne suis pas certain d'avoir compris, tu voulais parler du multiposte TV de la Freebox, permettant d'accéder aux chaînes TV via la playlist m3u de la Freebox? Je ne sais pas si cela répond à ta question, mais j'ai omis de préciser que dans mon installation, la connexion ADSL est prioritaire sur la 4G; cela se règle au niveau du routeur sous Freshtomato en attribuant un "poids" ("Load Balance Weight" dans l'interface du routeur) à chacune des connexions: l'ADSL a le poids maximum de 256 et la 4G est à 1. Du coup, si je ne force pas un équipement à passer par la ligne 4G grâce au menu "Multiwan routing" de Freshtomato, tout équipement connecté au routeur utilisera par défaut la ligne ADSL. Et concernant l'ip de la TV, oui c'est possible de lui attribuer une IP fixe dans le sous réseau de la Freebox, c'est ce que je fais pour le Freeplayer puisque le DHCP de ma Freebox est désactivé. En gros pour schématiser même si j'ai depuis passé la Freebox en bridge et que ça change quelques trucs, ça donne ça (les IPS sont différentes dans mes captures d'écran, c'est juste pour l'exemple): Freebox (IP :192.168.1.1, sans DHCP) \ > Routeur R7000 sous Freshtomato (IP:192.168.3.1 avec DHCP) --> machines du réseau local en IP:192.168.3.xxx Modem 4G (IP:192.168.2.1, sans DHCP) / Mon modem 4G est un Netgear Nighthawk MR1100 que je ne recommande pas car il faut le bidouiller au niveau des antennes (4x4 mimo). Un bon vieux Huawei B715S ou équivalent fait très bien l'affaire. EDIT: j'ajoute deux captures de Freshtomato pour illustrer un peu mieux mon propos, dans le premier tu verras la page de configuration des modems ADSL (Wan) et 4G (Wan2). Dans le second, le Multiwan routing, où il suffit d'entrer seulement les périphériques Wan2 (4G) puisque Wan (adsl) est prioritaire et ne nécessite donc pas d'être forcé (j'en avais quand même entré un ou deux, just because).
    1 point
  3. У меня ниже var, на втором уровне владелец у всех каталогов root, ниже не смотрел досконально, но встретились несколько файлов (не каталогов) у которых группа была не root. Еще как вариант, смотрите права в каталоге-шаблоне /var.defaults и делайте соответствующие в /var, может быть так будет правильней. По поводу вебинтерфейса DSM - выходит у разных моделей сино отличаются вебморды, я честно говоря не знал, т.к. немного имел дело только с хренологией 918 и 3615. По вопросу переустановки с восстановлением настроек - не имею пока должного опыта, если решитесь, напишите лучше в соответствующую ветку форума, думаю обязательно помогут, просто в ветку некстклоуда могут опытные товарищи не заглядывать.
    1 point
  4. А почему у вас два порта на SSH значатся, 22 и 223? А сменить владельца этого каталога (chown или по крестьянски через мс) на root даёт, не пробовали? У себя посмотрел, владелец каталога root:root, права 700. У меня картинки DSM по другому выглядят, наверное у Вас версия старенькая. Вполне возможно, что когда то вы с правами в файловой системе намудрили, не проще переставить систему с нуля, если знаний в линухе недостаточно? Заодно тогда может и версию DSM посвежее поставите, если конечно с железом оно совместимо.
    1 point
  5. Проверьте, включена ли галка ssh в панель управления / терминал и снмп, sftp работает поверх ssh... Так же поройтесь в районе безопасность / учетная запись на предмет блокировки айпишников, пропишите вашу локальную подсеть в список разрешенных. Брандмауэр точно выключен?
    1 point
  6. Not sure what else you are using the virtualized environment and storage for... but if it is intended mostly to run DSM, then yes, passthrough of physical drives is preferable. btrfs on DSM will provide RAID, RAIDF1 (if you are using SSD's), and SHR (for dissimilar drives). btrfs on DSM, combined with array duties will offer inline bitrot and file corruption repair, plus snapshots and snapshot replication. I have a very similar system to yours running ESXi. One NVMe SSD hosting the VM configurations and virtualized storage for non-DSM VM's. SATA controller and 10GBe passthrough for DSM full management since that's the primary workload.
    1 point
  7. This is not ideal. DSM is intended to have access to the physical disks for the features you mention. Why use DSM over a regular Linux server if you aren't going to take advantage of the disk optimizations? Storage pool should be Basic for a single virtual disk. btrfs is still superior if you intend to run the docker client in DSM. Otherwise the filesystem type doesn't really matter all that much in this neutered state.
    1 point
  8. За редким исключением, обновление и миграция, проходит просто и безболезненно. Не забывайте резервировать свою конфигурацию. Править, точнее, необходим новый загрузчик. Если у вас 1.02, то необходим 1.03 https://mega.nz/folder/yQpw0YTI#DQqIzUCG2RbBtQ6YieScWg/folder/7AoyySoS Как я уже писал выше, это скрытые Системные папки. Для их видимости, необходимо получить, так называемый ROOT доступ. Без этого доступа, сложно показать местоположение этой папки. Ну а так...... "Два пальца левее Алголя...." ))) Сделайте эти рекомендации и вы её сами увидите https://www.synology.com/ru-ru/knowledgebase/DSM/tutorial/General_Setup/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet
    1 point
  9. Если настраиваете на хосте, указывайте адрес субд как 127.0.0.1 (или может даже 127.0.0.1:3307 уже не помню точно по прошествии времени) а не localhost, и в настройках пхп проверьте что касается марии/мускула, чтоб порт стоял 3307 а не 3306. В самой хрени брандмауэр не включен ли, может он тоже что-то блокирует?
    1 point
  10. So it does seem that the PAT files are actually publicly accessible now. I am merging this topic with a post that was made earlier by @ed_co with links to all DSM 7 Preview PAT files (see 2 posts above this one). NOTE to anyone trying to upgrade their DSM 6 installation to DSM 7 with Jun's loader. Please do us all a favor: DON'T, unless you are doing it for test purposes on a test installation for debugging purposes. Jun's loader will not work with DSM 7.
    1 point
×
×
  • Create New...