Jump to content
XPEnology Community

IG-88

Developer
  • Posts

    4,628
  • Joined

  • Last visited

  • Days Won

    210

Everything posted by IG-88

  1. seem not the same even inside one loader (like tcrp apollolake mlx4 and mlx5, geminilake mlx4 only) you might need to check for your target here https://github.com/pocopico/redpill-modules https://github.com/fbelavenuto/arpl-modules https://github.com/AuxXxilium/arc-modules there is also mlx support in dsm itselft for buisiness units having open pcie slots, in that case synology supports extending with nic's from there list and there are mlx adapters on that list, so you can check that online (no mlx5 there) https://www.synology.com/en-global/compatibility?search_by=category&category=network_interface_cards&p=1&change_log_p=1 as kernel 4.4.180 is base for dsm 7.0/7.1 (expect sa6400 that comes with kernel 5.x and some old units like 3615 that still have 3.10) and there is a mlx4 driver inside it should be possible to have that (i did have mlx5 in my extra drives for 918+ on 6.2.3 and that was also kernel 4.4 based so it should be possible to make drivers for mlx5) so you might need to persuade the dev in question to add at least the original kernel drivers to the platform you need arpl dev lately announced he will not be available much for the net time so look for tcrp and arc when it needs changes) bottom line would be connectx-4 should work widely on business platforms as they are sold by synology, safe bet's are the ones listed from the link above but if any unit in a platform needs it all will have the driver because all units in the platform use the same kernel config and for that get the same driver set from the kernel)
  2. jmb585 oder asm1166 basiert biete sich an (pcie 3.0 support für mehr durchsatz) https://xpenology.com/forum/topic/35882-new-sataahci-cards-with-more-then-4-ports-and-no-sata-multiplexer aber evtl. kann man die disks auch lba mäßig virtuell (raw) durchreichen ohne den hardware controller in die vm durchzureichen, dann wäre der controller egal bezüglich des ursprünglichen problems ich würde einen neuen/andern usb stick nehmen, einen frischen arpl herunterladen und mal davon booten (prüfen das secure boot aus ist?) ansonsten gibt mit menü auch noch https://github.com/PeterSuh-Q3/tinycore-redpill/releases da hat es eine normale und eine uefi version als image für den usb stick
  3. the original geminilake cpu might have more limits then a newer "full" cpu (lets say a 10th gen cpu as the newest working for dva1622) from the point of what the hardware is capable of if dva1622 limit is not implemented as license limit then it might be possible to test how much more is possible with intel qsv on a newer/better cpu the name of the dva1622 SurveillanceStation package indicates that openvino is used so it might be possible to do a estimate when looking into whats possible with openvino and newer intel cpu's and face recognition
  4. at least nothing "inappropriate" in that file but they will for sure be able to track users even when they change dsm type or serial, only way to reduce that would be using VM and virtual disks but whats combined in these file will expose any non legit system for sure and with the hardware id (hwid) they can target a specific system for punishment/piracy combined with these new AI like stuff it might take no effort to very safely target these systems, no matter how many there might be and how often systems change there id the binary of synowedjat in the package looks roughly the same as synowedjat-exec in dsm, the content of the spk is from 02.2023, so why that package if wedjat is already there and working? might be to have recent check with a new wedjat before going into punishment mode (if the system in question in not updated then the wedjat installed might be pretty old) synowedjat.jpg is kind of unnecessary big and the pictures content itself might make it easy to hide payload (steganography) ... one way to counter might be to keep a constant eye on wedjat changes and block the communication (at least to the systems where it would try to downloads something) how about removing the execut flag of synowedjat-exec? the file would still be there and can be checked by checksum but any call of the file might fail as its not executable anymore
  5. exactly, not even as cache drive, only sata ssd's would work in this setup in "older" dsm 6.2.3 it was kernel 4.4 based 918+ what could do m.2 nvme as cache, with 7.0 most units got kernel 4.4 (except 3615) and are now capable of m.2 ssd as cache migrate to the latest 7.1.1 (new loader like arpl needed) and you could even have m.2 ssd as data volume (not only cache as usual up until now), still need some handywork but will be in loader soon i guess https://xpenology.com/forum/topic/67961-use-nvmem2-hard-drives-as-storage-pools-in-synology/
  6. maybe try a loader with a menu/gui thats way easier to handle for tcrp its this https://github.com/PeterSuh-Q3/tinycore-redpill/releases arpl has menu's by default https://github.com/fbelavenuto/arpl/releases and there is also arc as a spin off with some changes https://github.com/AuxXxilium/arc/releases
  7. you can download the missing firmware files from kernel.org https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/bnx2 (hit "plain" for downloading the file in question or use wget to downlaod directly on the system where you need the file) there are other sources too (just any kernel firmware source migth do it as the files did not change for a long time) https://kernel.googlesource.com/pub/scm/linux/kernel/git/firmware/linux-firmware/+/refs/heads/main/bnx2/ that indicates the path ("bnx2/" and filename ("bnx2-mips-09-6.2.1b.fw") of whats missing in the firmware directory and that is /lib/firmware/ so copy the *.fw files to /lib/firmware/bnx2/ (you can also go into the destination and wget the files directly there)
  8. mit units meinte ich die orginal synology geräte bezeichnungen wie ds3622 oder 918+ die man als "basis" wählen kann devicetree - wenn die in die tutorials hier schaust solltest du schnell über das hier stolpern https://xpenology.com/forum/topic/61634-dsm-7x-loaders-and-platforms/ da wird es ein wenig erklärt bzw. kann man in der tabelle sehen was devicetree ist und was nicht (aber muttlerweile gibt es eine so große anzahl als basis da vieles nicht mehr in der tabelle) tcrp (https://github.com/pocopico/tinycore-redpill) war zwar der erste loader und kann viel aber ist ohne menü's, man muss genau wissen was man will "arpl" als loader kam später, war aber schon immer mit menü so das man seine optionen sehen kann wenn man etwas auswählt und wenn man im zweifel ist weiß man wenigstens das es noch andere sachen gibt oder kann noch mal genauer nachlesen (link zu arpl ist ja schon weiter ohen, arc ist von arpl abgeleitet und hat eine deutsche heimat inkl. youtobe kanal, https://auxxxilium.tech/ vieleicht schaust du da mal rein) beim arpl (und vermutlich auch arc) sind die devicetree geräte gut mit DT gekennzeicnetz so das man es leicht unterscheiden kann, vesuch einfach mal ds3622 als basis, du hast jetzt nicht so viel zu deiner hardware geschrieben so das man über den adaptec controller nur vermutungen anstellen kann (generell ist es nicht völlig unwichtig welche cpu man benutzt, kommt beim intel basierten quick sync ins spiel oder wenn man VMM (für VM's) nutzen will - ist aber alles kein so großes problem, man kann bei bedarf den lloader auf eine andere "unit" umstellen und dsm wird dann für den neuen typ drüber installiert und dabei bleiben dann einstellungen und pakete erhalten - man kann das alles mit einer einzelen platte testen und wenn man weiß was man will bzw. den loader passend konfiguriert hat nimmt mein seine leeren platten die man eigentlich will und mach eine frische installation generell sollte man das basis keine zu alte unit nehmen, die letzten zwei jahre geben das release jahr an und nach 5-6 jahren ist meist schluss mit support (bei business units gehts häufig länger wie man an der 3615 oder 3617 sehen kann aber bei der consumer 918+ kann es sein das mit dsm 7.2 dann schluss ist und man in 2 jahren das pferd wechseln muss) der loader hier ist tcrp aber mit menü nachgerüstet: https://github.com/PeterSuh-Q3/tinycore-redpill/releases btw. asm1166 (chip) ist ein pcie 3.0 zwei pcie lane controller mit 6 sata ports und da er ahci ist brauht man keine extr treiber die sata/ahci treiber sind im kernel schon drin, ich persönlich bevorzuge karten mit dem jmb585, ist wie der asm1166, hat nur 5 ports aber weniger eigenartiges verhalten mit dem linux kernel, mein asm1166 meldet 32 sata ports un das kann dsm/xpenology ein wenig aus dem tritt bringen, wenn der controller als letzter kommt ist das egal aber wenn man mehrere controler hat kann das mit den 32 ports zu problemen führen (aber mit 4 oder 6 onboard vom chipsatz und einem asm166 sollte es keine probleme geben), zu dem thema neurer pcie 3.0 fähiger ahci controller gibts das hier (falls du da weiter lesen willst) https://xpenology.com/forum/topic/35882-new-sataahci-cards-with-more-then-4-ports-and-no-sata-multiplexer/
  9. with 7.x laoders there is usually a addon/extension namened cpuinfo, most like you just need to activate it and then just rebuild the loader https://github.com/fbelavenuto/arpl-addons/tree/main/cpuinfo
  10. dann nimm doch einfach eine unit ohne device tree, dann sollte es keine probleme geben im arpl loader sind die mit device tree schön mit DT gekennzeichnet da weiß man gleich was man nicht versuchen muss alternativ kannst du auch einen asm1166 basierten ahci/sata controller benutzen, der läuft mit allen kernel ootb da ahci immer fest immer kernel drin ist perter suh's tcp friend ist der tcrp loader mit hinzugefügtem menü system, ist also das gleiche wie tcrp wenn es um treiber geht https://github.com/PeterSuh-Q3/tinycore-redpill/releases alternativ kannst du noch arpl und arc versuchen, da gibt es dann auch leichte unterschiede bei den treibern https://github.com/fbelavenuto/arpl https://github.com/AuxXxilium/arc
  11. what makes you think so? if you look into the drivers there are all sorts of virtio drivers present https://github.com/fbelavenuto/arpl-modules/tree/main/denverton-4.4.180 kvm based solutions with virtio might be the most often used platform for vitalization here and i think also the dev's use it for the loader
  12. arpl comes with a nice fullscrenn editot for the config file in the advanced options, kind of easy to see the SN there and change it (and then rebuild the loader and start it)
  13. details? see the "openvino" at the end of the filename, thats a different version for dva1622 as it would be for other "normal" dsm systems, dva's are more special in some regards (and more expansive irl as they pack more features) that was for 6.x loaders, the new brand of 7.x loaders are derived from a different base and have all settings collected in a xml file and when "building" the loader the information collected there will be spread to the places it needs to be (like the kernel start parameter in case of the SN) using the former SS version (and then not updating to the new) was to save the hassle of redoing anything with the loader if you dont know much about the loader you might do backups of the usb flash driver too on dsm updates (on dsm updates the new kernel is written to the loader and the loader also contains your file used to build the loader)
  14. intel 2.5G are not as good and safe as there 1G nic's https://www.guru3d.com/news-story/intel-is-experiencing-network-issues-the-i226-v-controller-is-prone-to-connection-loss.html cant say anything from personal experience but as a pcie nic i might take a realtek as its way cheaper (less then half) and intel seems to struggle with its 2.5G tech (2nd time, 1st was in 2020 when they messed up the 1st iteration on 2.5G nic's and some board oem's had to suffer) but there is support for intel's 2.5G nic's even for dsm 7.x and its kernel 4.x as of Jim Ma and his backported igc driver (intel only supports kernel 5 integrated drivers, no separate driver for older kernels - also here realtek is better then intel now) - but seen from the practical side you could use both intel or realtek with xpenology's dsm 7.x https://github.com/jim3ma/synology-igc https://github.com/fbelavenuto/arpl-modules/tree/main/src/4.x/drivers/net/ethernet/intel/igc https://github.com/pocopico/rp-ext/tree/main/igc
  15. there is no consent about that, they just don't tell you about that function and its ability to variably change what is done on you system and the name "punish" for the function is a clear intention to do harm, active insight is that kind of collection but the synowedjat-exec is part of DSM itself and i'm pretty sure a lot of business customers will have compliance issues if synology can upload and execute code at any time, collect data at any time of any data stored on the system and can also "punish" for whatever they think is not within of there view of legal or compliant - and what happens if they get hacked? all units reachable by internet are at risk of a takeover - yeah sure they have consent about that from all customers btw. the link still works, you just removed the "tt" in the visible part (text of the link)
  16. you can do it in the loaders menu (if it has one) or in its config file (same place where you define the mac address for you network card) the sn is used as kernel parameter when the loader begins to start dsm's original kernel it pretty much the same as with jun's old 6.x loader, only difference is that you did it in 6.x loader in the grub.cfg and now its stored in a xml file maybe re-read the howto for configuring the 7.x loader again, there is a part where the sn is configured (usually as random generated but there is also a option to manually enter one and thats where you have to go) alternativ is to uninstall SS and install the old version manually as spk file https://archive.synology.com/download/Package/SurveillanceStation/9.0.2-10061 "SurveillanceStation-x86_64-9.0.2-10061_openvino.spk"
  17. synowedjat-exec is build-in imho this might need more attention and discussion found the same post in a chinese forum https://imnks.com/7800.html i also found way older references like this from 2021 http://www.nasyun.com/thread-78105-1-1.html and there are some references about consuming cpu power on other forums wedjat seems to refer to "wedjat eye" aka "Eye of Horus" https://en.wikipedia.org/wiki/Eye_of_Horus "... that represents well-being, healing, and protection ...", so its synology's eye on "there" systems some people might see it more like this https://en.wikipedia.org/wiki/Palantír ? synowedjat-exec seems to be present since 2020 (DSM 7.0) DSM_7.0 beta 40850 came without it DSM 7.0 beta 41222 already came with it - that was 12/2020 so it looks like synology is actively collecting data for years and the question is what are they doing with this data and active (root) access to the systems as there are no information on what they collect (could even be the data you host on the nas as the content what is downloaded for collection or "punishment" can change at any point) it does rise some serious questions and seen from European law (GDPR) there could be interesting legal follow up's from that and who watches the watchers? edit: my gripe here is about synology making the rules, investigating, judging and punishing, all in one instance without control/transparency and in a democratic system there is a problem with that (or at least it should be or its not a democratic system), https://en.wikipedia.org/wiki/Separation_of_powers
  18. up to 10th is working now on units supporting i915 driver already (918/920/dva1622 or anything based on apollolake/geminilake as dsm plattform, plattform can be seen in the name of the update *.pat file and these have the same kernel settings so usable modules should be the same, example would be 1019+, also supported in tcrp and there should be i915 support) https://xpenology.com/forum/topic/59909-i915ko-backported-driver-for-intel-10th-gen-ds918-ver-701-up3/ 11th will be possible now with sa6400 (early version for testing) because it comes with kernel 5.x and the i915 driver does not need that much backporting as it would with kernel 4.x and 12/13th might come later with that one (already worked on but not in the test version yet), that also might open the way for any other unit coming with kernel 5.x to have i915 driver even when its not in the kernel settings by default as it is the case with apollolake/geminilake https://xpenology.com/forum/topic/68067-develop-and-refine-sa3600broadwellnk-and-sa6400epyc7002-thread/?do=findComment&comment=440534
  19. it's stuck in firmware update mode (driver for update not unloaded), a small hack how to get it working is here https://xpenology.com/forum/topic/68067-develop-and-refine-sa3600broadwellnk-and-sa6400epyc7002-thread/?do=findComment&comment=440597 atm i'm running my test system with just the realtek onboard
  20. you can try "journalctl" in the console (q for quit) files are in /var/log/ my test system (9th gen cpu with tested hardware) did not show unusual behavior but there is not much installed atm, 7 disks and some packages (and no internet access for the system -> synowedjat-exec[18930]: connection error while downloading payload. [35], synowedjat-exec[18930]: Error downloading payload, synowedjat-exec[18930]: Error execute payload, - no thanks not interested in that stuff atm) there are some log messages indicating some minor problems with the loader ... 2023-03-31T20:21:51+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_reg_read.c:46 Read OOB reg 292 failed, ret=-1 2023-03-31T20:21:51+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_reg_write.c:51 Write OOB reg 292 failed, ret=-1 2023-03-31T20:21:52+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_tools.c:107 CMAC RESET error 2023-03-31T20:21:52+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_reg_read.c:46 Read OOB reg 292 failed, ret=-1 2023-03-31T20:21:52+02:00 test3 builtin-libhwcontrol_oob-syno_oob_set_nowtime[19380]: oob/oob_reg_write.c:51 Write OOB reg 292 failed, ret=-1 2023-03-31T20:52:38+02:00 test3 kernel: [174006.217158] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T20:52:38+02:00 test3 kernel: [174006.228753] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed ... 2023-03-31T23:16:27+02:00 test3 kernel: [182634.562114] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T23:16:27+02:00 test3 kernel: [182634.573636] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T23:16:27+02:00 test3 kernel: [182634.585204] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T23:16:27+02:00 test3 kernel: [182634.596803] <redpill/smart_shim.c:686> Expected to copy HDIO_DRIVE_CMD header of 4 bytes from 0000000000000000 - it failed 2023-03-31T23:17:18+02:00 test3 kernel: [182685.586770] <redpill/pmu_shim.c:234> Unknown 1 byte PMU command with signature hex="6b" ascii="k" 2023-03-31T23:17:18+02:00 test3 kernel: [182685.968973] <redpill/pmu_shim.c:234> Unknown 1 byte PMU command with signature hex="6b" ascii="k" 2023-03-31T23:17:18+02:00 test3 kernel: [182686.270364] <redpill/pmu_shim.c:234> Unknown 1 byte PMU command with signature hex="6b" ascii="k" 2023-03-31T23:17:19+02:00 test3 kernel: [182686.571662] <redpill/pmu_shim.c:234> Unknown 1 byte PMU command with signature hex="6b" ascii="k" ...
  21. ich bin mir nicht sicher was du gemacht hast gruppenrichtlinien sind eigentlich etwas windows/domain spezifisches, und haben nicht wirklich etwas mit dem lokalen linux des DSM zu tun wo genau in der gui hast du was eingestellt? der arpl loader hat ein addon mit das über framebuffer eine lokale console auf dem dsm gertät ermöglicht (was es sonst nur regulär mir 0-modem kabel über seriellen port gab) ansonsten kann man auch ein rescue/recovery linux booten , das raid1 der system patitionen mounten und dort sachen zurücksetzen (wenn man genau weiß was man macht) hängt ein wenig davon ab wie viel man konfiguriert hat aber für ein reset der config auf wekrseinstellungen in dsm hat man eher im blick wie der aufwand ist, wenn man neuland betritt und sich erst mal einlesen und ausprobiren muss dann geht da schnell ein mehrfaches an zeit drauf als wenn man einfach zurücksetzt und neu einstellt, evtl. hat man ja auch ein backup der config und pakete so das man nach einem zurücksetzen wieder alles so bekommt wie man es hatte
  22. ok, thats very recent then and its only for year 23 units and and 21/22 units for dsm 7.2 (and thats in beta riht now) i guess if its supported in some units it might be possible to make it on others available too, so just wait for it or look here https://xpenology.com/forum/topic/67961-use-nvmem2-hard-drives-as-storage-pools-in-synology/ sound like one more reason to test and looking forward to have it on the main unit, for now i'm just testing it (but as dva1622 screwed my installation (just dsm config and packages, data are ok) i might switch soon to sa6400 too
  23. hard to say as the loader does shiming to translate drives from the hardware driver to dsm, it might give you no advantage over using a "normal" sas backplane / unit for more drives dsm usually checks about original stuff and its firmware and will handle it differently but with the loaders interference it might not work the same way as on a original hardware
  24. that the dsm default, m.2 nvme is only usable as cache, data volume will be some kind of mangling and can easily break on update (like fallback to unconfigured cache drive) anything measurable or just how the gui feels like?
  25. i've run into a problem with the recent version of the loader, on start the 1st partition is filled up with log's until no space is left and then dsm shuts down and if i check the loader the 50MB partition has no space left any options to disable the log duplication to the 1st partition? exit: i increase the size of the 1st partition and it now cant fill it up (it ends with 57MB on the former 50MB), but still the system shuts down the moment its ready (i can see it already in synology assistant) beside digging into the system partitions log i can use the log on usb edit2: that seems to be the part where it goes wrong and all is shut down "platform error"? might be anything wrong with the shimming and emulation? its 7.1.1 U4 and it was running fine for about 4 weeks, only thing to mention is that i took out the 2nd nic 2 day ago yesterday loaders 1st partition was broken (log file problem from above) and file system was damaged, i replaced it yesterday with a new one and, re-entered sn and mac's and did the option to recover a installed system from the advanced menu edit3: i set up a new usb flash drive from scratch, removed 2nd nic and it did not find my already installed system to uses its configuration, it did a complete new install, so all configuration incl. packages are gone (as i have a backup a will try a configuration restore later), data volume is still there (as it should be), it wanted to do a scrubbing not sure if i will stay with dva1622 after this, its also i little bit concerning to read this (how far will they go in "punish" mode?) https://xpenology.com/forum/topic/68080-synology-backdoor/ journalctl ... Mar 25 09:58:42 TheBox systemd[1]: Started SSDP service. Mar 25 09:58:42 TheBox synosystemctl[17042]: systemd_restart.cpp:24 synosystemd: [ssdp] try-restarted. Mar 25 09:58:42 TheBox synow3tool[17286]: Start Nginx Server in Normal Mode ...... Mar 25 09:58:42 TheBox systemd[1]: Reloaded Nginx. Mar 25 09:58:43 TheBox index.cgi[16670]: external/external_microp_id_check.c:56 Fail to open synobios Mar 25 09:58:43 TheBox root[17323]: platform error Mar 25 09:58:43 TheBox index.cgi[16670]: open synobios error, error=(6)No such device or address Mar 25 09:58:43 TheBox index.cgi[16670]: system_sys_init.c:81 synopoweroff: SYNOHWExternalControl[SYNO_SYS_SHUTDOWN] failed Mar 25 09:58:43 TheBox index.cgi[16670]: feasibility_check.cpp:110 FeasibilityCheck: [Info] Start feasibility check [poweroff] with type [critical]. Mar 25 09:58:43 TheBox index.cgi[16670]: feasibility_check.cpp:129 FeasibilityCheck: [Info] [0] of feasibility check [poweroff] failed. Mar 25 09:58:43 TheBox index.cgi[16670]: system_poweroff_pre_hook.c:22 synopoweroff: Begin SYNOPowerOffPreHook action. Mar 25 09:58:43 TheBox index.cgi[16670]: plugin_action.c:317 synoplugin: [16670][PRE][poweroff][MAIN] Scripts=[CacheAdvisorPoweroffPlugin.sh,esynoscheduler-event-poweroff.sh]; Args=[POWEROFF_TYPE=poweroff] Mar 25 09:58:43 TheBox index.cgi[17333]: plugin_action.c:319 synoplugin: [16670][PRE][poweroff][CacheAdvisorPoweroffPlugin.sh][17333] ExitCode: 0 Mar 25 09:58:43 TheBox index.cgi[17333]: plugin_action.c:319 synoplugin: [16670][PRE][poweroff][CacheAdvisorPoweroffPlugin.sh][17333] Runtime: 0.007s Mar 25 09:58:43 TheBox index.cgi[17334]: plugin_action.c:319 synoplugin: [16670][PRE][poweroff][esynoscheduler-event-poweroff.sh][17334] ExitCode: 0 Mar 25 09:58:43 TheBox index.cgi[17334]: plugin_action.c:319 synoplugin: [16670][PRE][poweroff][esynoscheduler-event-poweroff.sh][17334] Runtime: 0.088s Mar 25 09:58:43 TheBox index.cgi[16670]: plugin_action.c:317 synoplugin: [16670][PRE][poweroff][MAIN] Runtime: 0.089s Mar 25 09:58:43 TheBox index.cgi[16670]: system_poweroff_pre_hook.c:27 synopoweroff: Finish SYNOPowerOffPreHook action. Mar 25 09:58:43 TheBox index.cgi[16670]: feasibility_check.cpp:110 FeasibilityCheck: [Info] Start feasibility check [poweroff] with type [critical]. Mar 25 09:58:43 TheBox index.cgi[16670]: feasibility_check.cpp:129 FeasibilityCheck: [Info] [0] of feasibility check [poweroff] failed. Mar 25 09:58:43 TheBox index.cgi[16670]: system_sys_init.c:133 synopoweroff: System is going to [poweroff] Mar 25 09:58:43 TheBox systemd[1]: Stopped syno-mkdhparam.service. Mar 25 09:58:43 TheBox systemd[1]: Stopping syno-mkdhparam.service... Mar 25 09:58:43 TheBox systemd[1]: Removed slice system-getty.slice. Mar 25 09:58:43 TheBox systemd[1]: Stopping system-getty.slice. Mar 25 09:58:43 TheBox systemd[1]: Removed slice system-serial\x2dgetty.slice. ...
×
×
  • Create New...