IG-88

the other option (also for getting to the data on the raid volumes) is to boot a recovery/live linux or open media vault the network config is stored in /etc/sysconfig/network-scripts/ you would need to mount the raid1 sys volume (1st partition on every disk) manually https://xpenology.com/forum/topic/7004-tutorial-how-to-access-dsms-data-system-partitions/ https://xpenology.com/forum/topic/42793-hp-gen8-dsm-623-25426-update-3-failed/#comment-200475 also with the newer iterations of the loaders it should be possible to reach the console usually available be serial cable just from the loader when monitor and keyboard are connected (like this: https://github.com/fbelavenuto/arpl-addons/blob/main/console/manifest.yml) so dont break a sweat just because dsm does not boot anymore or you loose network connection, you can keep a boot media with open media vault ready to use if you want and would be able to access your data if dsm does not work (like after updating it) and you also would be able to access the dsm system raid1 or do a backup

du gehst in den loader, kontolliertst unter modules (kernel module) das die virtio sachen auch aktiv sind und dann kommt "build the loader" du hattest ja schon mit einem parallel konfigurierten loader getestet das es an sich geht weiter unten im menü gibt es auch noch eine update funktion die den loader über internet aktualisieren sollte, das wäre auch noch eine zusätzlichen funktion die man mit nutzen kann bevor man "build" erneut aufruf (so als 2. versuch)

independent from that, dsm is build around lvm2 and mdadm as software raid and single disks, depending on the raid hardware used there might not be a driver to use it with dsm places a system partition on every disk as raid1 so as long as even one disks is still alive dsm will start and you can look for the raid (repair/restore) lets assume to have a "hardware" raid of 3 disks then dsm would see one disk and it would end in a single system partition, in case 2 disks fail the hardware raid is broken and cant start, then its also no dsm to start, 3 separate disks would have 3 raid1 partitions for dsm system and 3 raid5 partitions, two fail and you would still be able to run dsm (and depending of the problems could try to repair the raid5 or "force" it to work and selvage data) as for raid0 vs. jbod, in case of a one disk fail both will loose data but in raid0 all data will be lost and in jbod you would still be able to use recovery tools to get some data off the disk still working (and in most cases also from the 2nd faild disk - depending on how far you want to go, without raid0 way easier to dig into that as its just file system to reconstruct) raid0 might gain some speed but with a 1 gbit network you will not see any of this, so no usable gain for the higher risk of data loss

du hättest das data volume/speicherpool der vorhandenen installtion löschen können (dabei würde aber zusätzlich installierte pakete wie videostation verloren gehen), alle platten bis auf eine entfernen und durch leere/neue platten ersetzen, dann sollte dsm das raid1 der "alten" platte auf die anderen drei ausdehenen (dsl läuft als raid1 über alle platten) und wenn diese erst mal "intiailisiert" sind dann kannst du im nächsten schritt die alte platte entfernen und durch die 4. nene ersetzen, die wird dann auch eingebunden und dassollte es dann gewesen sein das mit dem raid1 kasst du die auch leicht ansehen, auf der cosole "cat /proc/mdadm" das ganze dauert nur ein paar minutn das die 2 oder 8GB der DSM partition schnell als raid1 erzeugt werden, man könnte auch schrittweise jede platte einzeln austischen und alles bejalten, dauert dann aber wegen der kompltten raud wiederherstellung der wesentlich größeren data bereich länger aund man hat das 4x und danach noch eine erweiterung des volumes auf die neue größe, macht bei einem ohehin neu ausgesetzten system nicht viel sinn, wäre nur ein test der hardware wie sie sich beim recovery verhält (aber das kann man auch einfach durch entferneen und hinzufügen einer platte machen ohne das daten auf dem system sind)

after 7.2 release they made 7.1 source available https://archive.synology.com/download/ToolChain/Synology NAS GPL Source/7.1.1-42962

you would either need to disable memory and file quiesce (and any application awareness) in the job or install vmware tools in dsm https://xpenology.com/forum/topic/66323-open-vm-tools-für-dsm-71711/ https://github.com/AuxXxilium/synology-dsm-open-vm-tools/releases/

https://gofile.io/d/eplc0L or https://pixeldrain.com/u/oh1sBe7U https://pixeldrain.com/u/z5thUMyN https://pixeldrain.com/u/3uqAKzsK

"dual-core Freescale QorIQ CPU" nicht x86 und damit gehen die loader hier nicht (alt bis neuester) entweder so weiter betreiben wie es ist (DSM 6.2.4) oder was neues kaufen grundlegend ist das kein weltuntergang wenn man 6.2.4 jetzt ohne updates weiter berteibt, man sollte sie halt nicht über portfowarding (syno quickconnect oder dyn dns) direkt für andere aus dem internet zugreifbar machen, aber man kann ja auch über vpn auf sein heimnetzwerk (inkl. nas) zugreifen, dann sind die einzigen risiken die eigenen client geräte (was bei "familiennutzung" schon mehr sein kann als man tollerieren mag)

https://archive.synology.com/download/Package/CodecPack

the i915 driver in jim ma's loader is a creation of his own its not possible to just compile a i915 for syno's sa6400 kernel (as its done with network drivers from vanilla kernel source from kernel.org) there are parts missing for i915, that under normal circumstances, would be directly in the kernel file he also added the stuff (as loadable modules) you would usually need to have direct in the kernel so its possible to load the "missing parts" as modules and then the i915 driver as 7.1 and 7.2 use the same kernel version (5.10.55, based on syno's own modded kernel source they keep "secret") its in theory possible to also load the modules from jim ma's loader with tcrp or arpl as base (as long as synology did not change to much in the kernel source between 7.1 and 7.2), that would need to be tested but if he publishes new binary's for 7.2 in his github repository it would be possible to use these and it should work for sure, but i cant see that atm so ripping the i915 driver (and related drivers) from his loader and trying them in tcrp or arpl with sa6400 7.2 would be the thing to try, the "right" way might be to make it a addon(?)

some news for M.2 nvme sliverstone has a new M.2 5-port card "ECS07", as its 5 port it will most likely be jmb585 (costs around $65) as seen in the picture it addresses the mechanical problems with a steel casing (looks like some sheet metal taken from a nvme cooling solution, that might also be a good DIY way to handle it and a easier to place cooling can be seen as a bonus) https://www.silverstonetek.com/en/product/info/expansion-cards/ECS07/ there are also ASM1166 M.2 based cards around, all mechanical problems will be the same and in addition there can be the 32port problems mentioned above https://nascompares.com/2023/03/24/cwwk-aio-t6-6-bay-nas-review-bang-for-buck/

lass mal die erstellung des loaders laufen wenn du die virtuelle hardware verändert hast, so das der device tree neu erstellt wird

that one might be about if synology provides a "native" driver or not and what driver you provide instead in the loader for system not having it as native driver like 3617 as example it comes ootb with bnx2x.ko ~1.7MB (that includes firmware and is made from external source - can bee seen when checking the version of that driver) if you compile a driver from the kernel (vanilla or syno's) it will usually be the way kernel.org dev's like it and thats firmware apart from the driver in a separate location, also fine that way as you will see a clean error message if that firmware file is not present (in contrary to my tn40xx.ko example below) a bnx2x.ko driver without firmware might be ~900kB synology does not provide the driver they use in there own kernel source repository's (like 7.0 if anyone wants to check) but if we would use exactly that driver version with the right compile switches it would be the same result for apollo-/geminilake i used tehuti drivers from external source (tn40xx) and they came with just as skeleton and some unused calls in a *.h file for firmware and you would need to collect the firmware from different oem's to "complete" the drivers and have all the firmware inside the tn40xx.ko to make it work with all possible cards (mostly about different phy's as the "core" cpu is the same for all) btw there can also be pitfalls for bnx2x "native" driver as if synology only includes firmware for cards they sell (officially supported), if that would be the case some people might have problems if they have a card that needs the not included firmware, i've seen that kind of problem with my own tn40xx.ko driver in the extra.lzma for 6.2.x - as far as i know it is not that case for syno's bnx2x driver, can't remember cases with 7.x that looked strange bottom line is that if you trust syno's "native" drivers there can be cases where the driver matches but hardware is not usable as of missing components in the driver and the error message will not show anything about firmware it will be difficult to check a if a binary driver really has all firmware files it should or can contain as dsm itself does not have "modinfo" to check for dependencies (like firmware) it need to be done on the build system, if you check syno's bnx2x.ko there should be no firmware dependencies and if you check the one you made for apollo-/geminilake you should see something about firmware dependencies with modinfo

these are usually not exchangeable even if they all use mdadm and lvm2 (both linux native tech) for (software) raid volumes whats going to work is that you can use a synology/xpenology disk set ,boot open media vault (omv) as nas os and you should be able to use the data volume https://xpenology.com/forum/topic/42793-hp-gen8-dsm-623-25426-update-3-failed/#comment-200475 (exception would be raid f1 for ssd's from some synology business units as this is a synology special) as there are no technology changes in that regard that would still be valid might work with other nas venodrs, as long as you can use a normal rescue/live linux and mount the volumes https://xpenology.com/forum/topic/7004-tutorial-how-to-access-dsms-data-system-partitions/ it should be possible to do the same with OMV as its still a normal linux with all features and the option to install any software packages from repository's (unlike DSM or other "appliances" - harder to brick and small but not as flexible as a "full" linux or bsd system)

does that help? https://en.wikipedia.org/wiki/Toolchain https://elinux.org/Toolchains

i replaced the links with new ones

10th gen cpu's funktioniert nicht ootb mit syno's eigenem i915 treiber entweder den treiber ersetzen https://xpenology.com/forum/topic/65055-alder-lake-build-with-hw-transcoding/?do=findComment&comment=442757 oder man geht gleich auf kernel 5.x mit einem triber der bis 11th gen kann https://xpenology.com/forum/topic/68067-develop-and-refine-sa3600broadwellnk-and-sa6400epyc7002-thread/ ist aber etwas heikel da der dev die aktuellste version hinter einer paywall hat, die letzte öffentliche im blog von ende märz funktioniert aber in der regel

imho that was introduced by the SMBService package https://archive.synology.com/download/Package/SMBService/4.15.9-0632 https://www.synology.com/de-de/releaseNote/SMBService the latest 4.15.13-0760 requires DSM 7.2 but the 4.15.9-0632 will work with 7.1.1 (no special update level in in the release notes so u5 in not required)

https://xpenology.com/forum/topic/24864-transcoding-without-a-valid-serial-number/?do=findComment&comment=439520 and there is also https://xpenology.com/forum/topic/65643-ame-30-patcher/ in theory the files in arpl should be the same as these @fbelavenuto

another way around it might be to use a hypervisor, handing the iGPU to the sa6400 vm and use other vm's with the hypervisor (proxmox and esxi are often used)

https://blog.jim.plus/blog/post/jim/synology-sa6400-with-i915 "... known issues VMM cannot run because the official Synology has not compiled the kvm-intel module. At present, I have transplanted the kvm-intel module, which is mainly adapted to consumer-grade CPUs after the 9th generation, and is limited to internal donation groups. ..."

there was a comment on jim ma's blog about disk issues "Due to compatibility or performance issues on some machines, /dev/console was created late, causing redpill.ko to fail to load, and eventually the hard disk could not be found. The donation version has been repaired" i did see a no disk message on a test notebook with 11th gen cpu that only had nvme and was extended to have a jmb585 ahci controller by a m.2 nvme to pcie adapter, my original test system with a m365 chipset and 9th gen cpu did work without problems in that regard

someone would need to compile a new driver from the dsm 7.0 source with the patch and that could be (tested) and installed - i did not follow this thread for a while but a thought they where on the right path, looks like they took a different turn somewhere anyway the best so far might be jim ma's i915 in sa6400 so far, it overcomes some of the backporting issues as the i915 in kernel 5.x can do more and a lot of that stuff was to much effort to backport into kernel 4.4 (and all the other devices of synology is still based in kernel 4.4 and that will be the same with dsm 7.2, so for at least a year there might be no better solution then sa6400 with 10th and above cpu's (for now up to 11th but he wrote that he already had code for 12th gen)

the alternative to this would be the next level of i915 support we've seen lately its a modded arpl loader with sa6400 (only x64 kernel 5.x device) with a extension to use i915 driver up to 11th gen https://xpenology.com/forum/topic/68067-develop-and-refine-sa3600broadwellnk-and-sa6400epyc7002-thread/ the only glitch was with realtek 8168/8111 where it cant use the nic ootb (i added a intel nic and changed something to make r8168 work on boot and then removed the intel nic) also atm it does not come with such a rich driver set as the other loaders, it still some beta but works and it would be possible to use the *.ko files from other loaders like arpl or tcrp (they do have driver sets for epyc aka sa6400 on github)

the driver here is not loaded as its a wrong version from a older dsm version the kernel version of 7.0 and 7.1 is 4.4.180 and the driver needs to be compiled for that kernel version from above its there is nothing about the log after you manually loaded the driver and you could also check if there is something in /dev/dri as alternative but when just loading manually it would be gone after a reboot i also checked the driver in arpl and its "only" a patched driver the way i did it in dsm 6.2.3, the "real deal" is the extended driver that is specifically compiled from extended source that take 10th gen stuff into account (the old patch method is just changing a device id from 9th gen into one from other/newer hardware and that does not worked with all 10th gen afair) earlier in this thread https://xpenology.com/forum/topic/59909-i915ko-backported-driver-for-intel-10th-gen-ds918-ver-701-up3/ there was this patch for the i915 source code that would not need any patching for device id's like seen later in the thread or in arpl, you x9BC8 would just be part of the "better" i915 driver (not 4 different driver files, just one for all)