IG-88

i wonder what loader, dsm type or dsm version (+extra.lzma) you used - among other things (kind of minimalistic your information's) the network chip is Atheros AR8131, the driver would be atl1c.ko and thats part of jun's driver set in loader 1.02b and 1.03b if you got the *.pat installed you should have done usb vid/pid right and storage was set to ahci (?)

einen hätte ich noch ersetze andoid tablet durch win10 tablet, sowas wie surface pro oder (was ich benutze) fujitsu stylistic oder etwas von dell, lenovo in der art gibts gebraucht mit 8GB ram und 256GB ssd für unter 500€ die haben die gleichen merkmale wie cameras, gps, ... aber man hat dann das win10 gleich parat, medien kann man von einer 1TB microsd oder von usb (3.0) haben für mehr schnellen storage kann man entweder die interne ssd gegen etwas größeres tauschen (wenn das den geht, bei meinem stylistic geht das) oder man schließt über usb 3.0 eine ssd an wenn man bedarf an vm's hat (auch android) kann man z.b. virtual box nutzen (hyper-v ginge ja bei win10 auch) strom gibts bei bedarf aus dem bordnetz des autos und man ist mit dem ding recht flexibel (ist ja nicht ans auto gebunden) rj-45 netzwerk gibts über usb 3.0 (das gibts auch als 2.5 und 5Gbit) und da ist dann gleich ein 3er hub mit dabei (zumindet bei meinem 1Gbit nic) ersetzt bei mir ein notebook und android tablet hier mal beispiele für <500€ https://www.esm-computer.de/hp-tablet-elite-x2-1012-g1-intel-core-m5-6y54-1-10-ghz-webcam-b-ware-1020163/ https://www.esm-computer.de/lenovo-thinkpad-x1-tablet-intel-core-i5-7y54-1-20-ghz-256-gb-ssd-m.2-webcam-b-ware-1022910/ https://www.esm-computer.de/microsoft-surface-pro-4-core-i5-6300u-2-4-ghz-8-gb-240-gb-ssd-webcam-b-ware-1019748/ klar 16GB ram wären besser aber da muss man sehen was man bekommt und was es kostet, bei diesen kompakten ist häufig ram aufrüsten nicht möglich aber für unterwegs ist das als hybrid auch eine mögliche lösung um ein android tablet mit nas zu ersetzen, wenn man den preis von beiden zusammen nimmt kommt man je nach art wie man rechnet und bereitschaft geld auszugeben vieleicht auch bei einem win10 tablet mit 16GB ram raus nein, 32Gb habe ich schon häufiger bei usern hier gesehen, ein festes limit sind die cpu cores im kernel (den wir nicht ändern können) 8 bei 3615/918+, 16 bei 3617

how does your disk configuration looks like? sata ahci mine looks like this (same for all three types/loaders)

soweit ich mich erinnere gibts auch nach der installtion fehlermeldungen wenn usb vid/pid nicht übereinstimmt habe ich das letzte mal vor ein paar monaten mal ausprobiert installieren ohne passende usb vid/pid habe ich schon ewigkeiten nicht mehr versucht, meine test img datein sind auf meine test usb sticks angepasst , so das ich da immer die passende kombo habe beim testen edit: eben noch mal mit einer installierten 918+ probiert, wenn ich die pid einfach mal um eins hochzähle und dann versuche zu booten gibts nicht im syno assistant und auf der seriellen console sieht man "mount failed" und nichts geht mehr

if its the same system keep mac, usb vid/pid needs to mach the usb device used mac is only needed for WOL and convenience (some protection, like in survailance station, check the match on sn and mac to it might be important to keep a sn and mach together if they are from a original system or "valid" generated) if adding or removing nic's it need to be looked for as the order of nic's may change, so the mac's 1,2,3, ... might not fit the hardware anymore also still some special in 918+, only 2 nic's are default, so when adding a 2 port nic one port will be outside when installing a update in my system its the onboard nic gets 3rd and the maintenance nic (onboard 1G) is not working anymore and also the eth0 eth1 in dsm will not be working anymore as before, can get messy to regain access over network if you worked with 9k mtu, vlan, or teaming serial console can help here but most people dont have/use this, a good amount of logic and knowledge can help too to get things back to normal but best would still be a extended patch to also patch the number of nic's at boot like the number of drives (as i'm back to 918+ for my main nas i got the nic fun after the cross upgrade from 3617 so i#m kind of motivated to have this patched as its annoying to care about this after updates) yes but if you dont and boot up the system will not start and when you use synology assistant then it will offer you to fix this (usually reading the kernel from system disk and write it to the loader, only takes seconds) its more important to know/remember that there is a kernel mismatch when redoing the loader no only grub.cfg, extra(extra2 if its 918+) if you changed them from the original loader and the kernel files of dsm on the 2nd partiton beside the usb vid/pid, number and mac of nic's there can be other changes to the grub.cfg that need to be documented, like adding kernel parameters to handle special adjustments like disable NCQ for the kernel (seen WD drives having problems with NCQ last week with newer jmb585 on 3617 ahci driver) when doing changes like this later on they might not end in the "documentation" same goes for bios settings, might be important for CSM/legacy mode on uefi bios or disabling vt-d for a asm1061 controller, if a cmos battery dies it can be a lot of fun getting the system up again ("why is thin happening i did not change a single thing in two yaer's")

thats interesting, the presence of a usb adapter should not make a difference also with my systems (having 3 diffrent hardware types and about 6 ot 7 different nic types) i never had the problem that a driver present would not work atm i would not have a logical explanation why a usb nic would make a difference or why a working nic driver only is working if a 2nd one is present original synology units use a specific unique id of f400/f400, in some way the loader needs to spoof that and i guess its a comparison spoof where the f400/f400 gets replaced with the values we put in grub.cfg and if the code compares what it should be (our grub values now) it comes out with a true and continues its checked when installing the *.pat file to disk and later after install its also checked in the start/boot process (along other things aka protections) beside spoofing some things making the dsm think its still running on a original hardware it just provides the dsm original kernel for being able to start reading the system from disk (raid1 over all disks), after boot its unmounted and the only occasion where its used with dsm running is when making a update, in that process the new kernel (if there is any) needs to be copied to usb before booting the new updated version so its no problem removing the usb while dsm is running but you will need it on every boot as its the boot loader (just a few megabyte are processed so no need for some huge or extra fast usb flash drives) yes thats too, at least it looks for it and try's to change things if needed, there is also a patch mechanism involved that, if it hits a already patched file, it will not patch, but after installing a update there are files back to default and will be patched on 1st boot with a new dsm new version (among other things restoring the 16 drives we have with 918+, syno's default is just 4) - there are lots of things that can go wrong after udpates of dsm, but in most cases it does not and synology obviously does not care much, they could easily throw in some changes to specifically hinder the loader to do the patching (but we a could also adapt the patching of the files if needed so it would be a dead race, usually synology "rises the bar" with new main versions like 6.1, 6.2 or 7.0) also it compares the added kernel module files on boot and if they are different they will be copied again from loader to disk (so even if you replace one of the modules manually on disk - in the update directory where the loader keeps its modules -then it will be replaced with the one from the loader because its different (there is also a pre boot kernel that is loaded before synologys original kernel, my guess it emulates hardware devices present on the original hardware so when dsm checks for there presence they come back as existing, one of the reasons why a loader is specific for a certain dsm hardware model) if you want to have a closer look just open extra.lzma with 7zip and look for the files in etc, there is jun.patch, that is tried to apply on booting (918+ has a extra2.lzma containing a 2nd different patch, witch one is loaded seems to be decided in the pro boot kernel, so its up to guessing when extra2 is used, my guess is when its a fresh install and on normal boots its extra) the pre boot kernel is bzImage on the 1st partition on the loader, with the proper tools that one can be decomposed too but you will end with code you would need to reverse engineer so thats for some more hardcore coder, i was not able to find out he logic about extra/extra2 that way so its based on trying a little with modding rc.modules in both extra's to see what is used on what occasion, thats what my guess is based on

you can consult synologys selector and check what hardware chips they use https://www.synology.com/en-global/compatibility?search_by=products&model=DS1621%2B&category=network_interface_cards&p=1 and hope the card you buy is compatible anough to run (did that with a tehuti card i bought from qnap but did not work with a later bought tehuti card as this card had another phy chip and did not work with the older/limited synology driver) mellanox itself is not listed its also possible to look at the drivers the 1621+ comes with and look insede the *.ko files in question for the supported pcie vendor and device id's that driver would be bna.ko and thats not present in the 6.2.3 dsm *.pat file but there are mellanox drivers present in the *.pat file looks the same as in 3615/17 the device id's supported from the 1621+ mlx drivers are 15B3:1002 15B3:1003 15B3:1004 15B3:1005 15B3:1006 15B3:1007 15B3:1008 15B3:1009 15B3:100A 15B3:100B 15B3:100C 15B3:100D 15B3:100E 15B3:100F 15B3:1010 15B3:1011 15B3:1012 15B3:1013 15B3:1014 15B3:1015 15B3:1016 15B3:1017 15B3:1018 15B3:1019 15B3:101A 15B3:101B 15B3:101C 15B3:6340 15B3:634A 15B3:6354 15B3:6368 15B3:6372 15B3:6732 15B3:673C 15B3:6746 15B3:6750 15B3:675A 15B3:6764 15B3:676E 15B3:A2D2 15B3:A2D3 if you compare this with mlx's vendor id's for pci https://pci-ids.ucw.cz/read/PC/15b3 it looks like connectx-3 is supported by the drivers the chips and connectx type are this ConnectX MT254xx ConnectX-2 MT264xx ConnectX-3 MT275xx ConnectX-IB MT276xx ConnectX-4 MT277xx (ConnectX-5 MT278xx, MT288xx) so looks like the card in your link would be ok connecting to a brocade 1020 should be no problem as long as both have sfp+ then dac or optical can be used, if one has sfp+ and the other rj-45 10G the its not that easy

ich habe für mein (home) nas wegen der option auf virtualisierung einen 9100 genommen, hat ausreichend reserven (im moment baremetal mit option auf vmm, aber wenn ich es ernst meine mit vm's würde ich vermutlich eher auf esxi setzen, das kenne ich vom job - aber für ernst gemeinte vitualiserung hätte die cpu wieder zu wenig kerne) ob eine "große" desktop cpu wirklich für ein fahrzeugt taugt müsste man mal ausrechnen mit all der last die so ein system insgesamt produziert (oder produzieren kann, meist idelt das ding ja vor sich hin) ich habe beim camping schon mal die pkw batterie mit einem desktop replacement notebook an einem abend entleert, ist echt unpraktisch wenn man dann den motot nicht mehr anbekommt (aber dafür gäbe es ja große und kleine start hilfe packs zum mitnehmen, habe ich mir dann auch gekauft) wenn man die cpu drosselt um den durst zu reduzieren kommt man unter umständen auch wieder bei der performance eines gemini lake raus der am ende kompakter und billiger gewesen wäre, auch die wärme kann im austo eine rolle spielen, das heizt sich in der sonne mit unter ordentlich auf (aber ssd's lieben ja eher wärme) und insgesamt sind die möglichen schwankungen von -15 bis 70 schon ganz ordentlich, das kann selbst nicht aktiv benutze hardware (lagernd) vor probleme stellen wenn du eine 720+ hast dann kennst du die möglichkeiten der gemini lake hardware ja und kannst vorher testen, ich würde ja vermuten mit ausreichend ram und ssd geht das (habe aber keine apollo lake oder gemin lake hardware, kann also nichts über praktische erfahrungen sagen)

that depnds on the kernel config you use for compiling a normal linux might try to be universal as possible a appliance like dsm is made to fit a purpose being a appliance with lots a custom kernel mods impacts other functions, so they tend to only activate whats needed and its also limiting customers going wild with uncertified hardware or extending in a way its not intended (like deliberately removing multiplexer support in ~2013/2014) also they broke sata_*.kon and pata_*.ko modules with modifications and as they dont need them they did no care about the broken code in the kernel, if WE need it we will have to fix it ourself (why should they care for hacker and freeloader?) there is virtual dsm for that purpose and they include all thats needed for virtio there and if needed all the necessary kernel options are that in this as of the appliance model its not intended to visualize a 3615/3617 or 918+ so it does nor need this stuff (same for hyper-v extensions in the kernel) no idea where that is comming from, i cant do any kernel source mod's as i'm not a coder (just a monkey with a keyboard when it comes to this)

beside the missing " " the original/default is usb beyound internal port 20, yours match the 24 drives you choose (one 0 more) and would be correct the following is a direct copy&pate from synoinfo.conf usbportcfg="0x300000"

maybe its not the drives, there might be other sources for your problems when new drives fall out of a newly created raid it can be seen as a sign for deeper problems (its still possible that a new drive is faulty but it needs to checked in both directions, drive and system) - so what about logs? /var/log/dmesg /var/log/messages SHR can be SHR1 = one drive redundancy and SHR2 = two drive redundancy to pick up your 1st post with 4 x 4TB and 1x 6TB it will be 5 x 4TB and the left over 2TB cant have a one disk redundancy as there is only one 2TB "piece", if you add 2nd 6TB disk a 4TB piece will be added to the 4TB array (a raid5 array) and the 2TB piece can form a raid1 (one disk redundancy) with the unused 2TB and the two raid's (6x4TB as raid5 and 2 x 2TB as raid1) will be glued together by lvm2 and you will see 5x4TB + 1x 2TB as usable date over thumb its the sum of all disk minus the biggest disk of the system yes not exactly, your wording might be the description of raid4? shr1 uses raid5 and the parity is distributed over all disks in that case https://en.wikipedia.org/wiki/RAID_3#RAID_4 https://en.wikipedia.org/wiki/RAID_5#RAID_5 but resulting capacity is the same, number off (same size) disks minus 1 yes and yes but thats plain raid5 not SHR, if SHR(1) is used with same size disks it will result in a raid5 and the content of that raid set will be put into a lvm2 volume and that is what you see as disk size, plain raid5 would be without that lvm2 volume the trickery with SHR is you can later on add different type and size raid sets to the lvm2 volume (extending it), with a plain raid5 volume you would only be able to add a same size disk (and if the disk is bigger its simply unused and will stay like this for all bigger disks you add) SHR is a clever use of whats already there, mdadm software raid and lvm2 but there are also things you can't do with SHR, like adding a smaller disk to really do that you would need to destroy the whole set and start with the new smallest disk from scratch, that way the 1st raid5 created will be in the size of the smallest disk (even if its just one small disk) like 1+2+2+4+4 TB disks will result in a raid5 of 5 x 1TB, raid5 of 4x1TB and a raid1 of 2x2TB, usable 9TB (remeber from above? sum up all disks and remove the (one) biggest)

maybe try to install with a fresh loader (redo usb vid/pid and check), (the loader originally comes with kernel from dsm 6.2.0, if you install a newer version with it the loader gets updated and will contain a newer kernel resulting in not being able to install a lower dsm version with it, like when used with 6.2.3 and kernel of 6.2.3 is on the loader you cant install 6.2.0 with it, synology assistant will show a info that you if its the case) !!! do not use internet, use a file and user dsm 6.2.0 (first dms 6.2 version), following link https://global.download.synology.com/download/DSM/release/6.2/23739/DSM_DS3615xs_23739.pat if that works out install a fix for 6.2.3 from here https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/ then update to 6..2.3 (or 6.2.3 u3) by web gui as long as you get 6.2 installed (like 6.2.0) without error the loader is proven to work and the problem must be something else and just to rule out other problems start installing to a empty disk that does not have partitions (you dont need to zero it completely or anything just no partitions)

ja dazu neigen wir hier häufig und wenn man darüber nachdenkt und man selbst in der situation wäre will man gar nicht das andere das projekt an sich hinterfragen man hat ja seine gründe und häufig viel darüber nachgdeacht (dann aber nicht alle aspekte in dem thread dargelegt) ist ok alternativen aufzuzeigen und anzubieten das ist genau der punkt, warum soll er hier jemanden überzeugen, ist eigentlich nicht notwendig, wenn er sicher ist was er machen will warum nicht ein server im auto, manche haben soundanlagen im auto die weit weniger sinn machen und die motorisierung mancher fahrzeuge ist bar jeder vernunft und trotzdem wollen manche 1000PS unter der haube

the loaders are all gpt, if it would be a loader gpt vs. mbr problem is would not boot at all (mbr loader is often needed with older hp desktops and only if uefi boot is not working like with loader 1.03b), if you find you system in network its not a boot problem 3617 uses the same kernel as 3615, just some minor kernel settings different then 3615, never seen it behave different when installing, most likely usb vid/pid wrong, sometimes it can be a problem if the disk is not empty (have partitions on it) if 3615 works for you dont bother, 3617 only supports 16 instead of 8 cpu cores and has some newer lsi sas drivers

remeber the faq? https://xpenology.com/forum/topic/9392-general-faq/?do=findComment&comment=82391 if you need it to shown the real cpu then you can use this https://xpenology.com/forum/topic/13030-dsm-5x6x-cpu-name-cores-infomation-change-tool/ not important anymore if the driver in the extra/extra2 is working there are lots of possibility's, wrong/old extra.lzma used, rj-45 connector not plugged in properly,. cable problems you would need to repeat your steps and might find out you cant reproduce it most simple test just take any empty usb, put the loader on it (dont bother about usb vid/pid, as long as you dont start installing is does not matter if its wrong), add the newer extra/extra2, disconnect your drive(s) and working usb, connect your test usb boot and try to find it in network with synology assistant

21st of November 2014 is the date code of the intel driver in kernel 3.10.105, giving a hint about hardware being released way later like 2016 will not be covered only hardware already planned to release in 2015 might work (and from the source it seems to be max. skylake that came out 2015) from gut feeling about what was wrong about i915 driver for 3615/17 i tried to build, it was about missing parts in the kernel of dsm and as we can't make a new kernel we only can use drivers (aka kernel modules) that are working with the kernel synology provides, logical result it never even got tested because of this 918+ is different as it already comes with i915 drivers and jun backported a newer i915 driver for 918+ making gpu's up to coffee lake working, later with 6.2.3 synology backported a newer i915 driver by themself as they needed a gemini lake capable driver for x20+ models if its 6 + 2 then your lsi's usually start with port 9 on your map in dsm gui (maybe 7 if the asmedia is found later then the lsi's but thats unlikely usually its ahci first as its part of the kernel and then lsi's as the driver is loaded later on in boot process), if you get them really disabled the disks connected to the lsi's will start lower so you can look at the disk map in the web gui where your lsi connected drives start (if you dont have anything connected to the 8 onboard sata's) btw. the asm1061 is just one pcie 2.0 lane so its max. 500MB/s for both ports together, so best try to disable these as its the weakest part (the 6 from the chipset should be able to work at full sata3 speed), also the asm1061 can have problems when vt-d is enabled in bios as its unclear how its configured atm i'd say a dmesg will get a better picture, as we will see all controllers found an see how the disks are numbered/counted if you look at the dsm gui you will usually see the number of drive slots the system is configured for by the synoinfo.conf, 16 is the default for 918+ i dont know how you have done the 20 drives, it needs to be done the right way or it might not working properly, so if its not default anymore then specify what values you used in synoinfo.conf

not exactly like this when using jun's initial loader it will have the kernel of dsm 6.2.(0) in most cases you will have 6.2.3 installed on the disks when booting that way the system will not just start because of that mismatch at least two ways to fix it: 1. use synology assistant, it will recognize the mismatch and offer repair it (copy's the newer kernel from disk to loader), that is a synology covered scenario because if a customer gets a replacement unit, it might come with a older loader and then the dsm version the customer has on its disks, so they need to be prepared for this (and as they do not support downgrade they need to get the loaders kernel (usb dom) renewed) 2. do it manually, use the *.pat file of the dsm version you have installed depending if its a main version or a update (like u3 now for 6.2.3) if its a main version (200-300MB *.pat) its zImage and rd.gz directly in the *.pat filen (you can open it with 7zip) and if its a update version you open the *.pat look for a "flashupdate_6.2-25426-s3_all.deb" (s3 is for update 3, 6.2-25426 is 6.2.3) further open it with 7zip and you will find zImage and rd.gz zImage and rd.gz need to be copied to the 2nd partiton of the usb replacing the old files

i deliberately suggested the other way as it can be happen that even if you disable some sata stuff in bios the kernel will still find the device and still block the ports, its much safer to just have the two cache drives on the 1st two ports its also possible that the bios offers more then the two ports you have usable, i often have seen systems with 4 ports on the board and the kernel blocking 6 ports to be sure about that you could provide the dmesg log, in that one we would see what the kernel finds and how its counted you did read the red marked stuff in my extra driver thread for 6.2.3 about the lsi drivers and 918+ if you want smart you can use the older extra/extra2 that has juns driver but when using disk hibernation it would be risky

the old 3.10.105 kernel has a i915 driver but its only supporting old/few devices from now days point of view its date code is "20141121" and it might go up to skylake (gpu gen9), your cpu would be 8th gpu gen and covered here a snippet from the driver of kernel 3.10.105 #define INTEL_INFO(p) (&__I915__(p)->info) #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id) #define IS_I830(dev) (INTEL_DEVID(dev) == 0x3577) #define IS_845G(dev) (INTEL_DEVID(dev) == 0x2562) #define IS_I85X(dev) (INTEL_INFO(dev)->is_i85x) #define IS_I865G(dev) (INTEL_DEVID(dev) == 0x2572) #define IS_I915G(dev) (INTEL_INFO(dev)->is_i915g) #define IS_I915GM(dev) (INTEL_DEVID(dev) == 0x2592) #define IS_I945G(dev) (INTEL_DEVID(dev) == 0x2772) #define IS_I945GM(dev) (INTEL_INFO(dev)->is_i945gm) #define IS_BROADWATER(dev) (INTEL_INFO(dev)->is_broadwater) #define IS_CRESTLINE(dev) (INTEL_INFO(dev)->is_crestline) #define IS_GM45(dev) (INTEL_DEVID(dev) == 0x2A42) #define IS_G4X(dev) (INTEL_INFO(dev)->is_g4x) #define IS_PINEVIEW_G(dev) (INTEL_DEVID(dev) == 0xa001) #define IS_PINEVIEW_M(dev) (INTEL_DEVID(dev) == 0xa011) #define IS_PINEVIEW(dev) (INTEL_INFO(dev)->is_pineview) #define IS_G33(dev) (INTEL_INFO(dev)->is_g33) #define IS_IRONLAKE_M(dev) (INTEL_DEVID(dev) == 0x0046) #define IS_IVYBRIDGE(dev) (INTEL_INFO(dev)->is_ivybridge) #define IS_IVB_GT1(dev) (INTEL_DEVID(dev) == 0x0156 || \ INTEL_DEVID(dev) == 0x0152 || \ INTEL_DEVID(dev) == 0x015a) #define IS_SNB_GT1(dev) (INTEL_DEVID(dev) == 0x0102 || \ INTEL_DEVID(dev) == 0x0106 || \ INTEL_DEVID(dev) == 0x010A) #define IS_VALLEYVIEW(dev) (INTEL_INFO(dev)->is_valleyview) #define IS_CHERRYVIEW(dev) (INTEL_INFO(dev)->is_valleyview && IS_GEN8(dev)) #define IS_HASWELL(dev) (INTEL_INFO(dev)->is_haswell) #define IS_BROADWELL(dev) (!INTEL_INFO(dev)->is_valleyview && IS_GEN8(dev)) #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake) #define IS_MOBILE(dev) (INTEL_INFO(dev)->is_mobile) #define IS_HSW_EARLY_SDV(dev) (IS_HASWELL(dev) && \ (INTEL_DEVID(dev) & 0xFF00) == 0x0C00) #define IS_BDW_ULT(dev) (IS_BROADWELL(dev) && \ ((INTEL_DEVID(dev) & 0xf) == 0x2 || \ (INTEL_DEVID(dev) & 0xf) == 0x6 || \ (INTEL_DEVID(dev) & 0xf) == 0xe)) #define IS_BDW_GT3(dev) (IS_BROADWELL(dev) && \ (INTEL_DEVID(dev) & 0x00F0) == 0x0020) #define IS_HSW_ULT(dev) (IS_HASWELL(dev) && \ (INTEL_DEVID(dev) & 0xFF00) == 0x0A00) #define IS_HSW_GT3(dev) (IS_HASWELL(dev) && \ (INTEL_DEVID(dev) & 0x00F0) == 0x0020) /* ULX machines are also considered ULT. */ #define IS_HSW_ULX(dev) (INTEL_DEVID(dev) == 0x0A0E || \ INTEL_DEVID(dev) == 0x0A1E) #define IS_PRELIMINARY_HW(intel_info) ((intel_info)->is_preliminary) /* * The genX designation typically refers to the render engine, so render * capability related checks should use IS_GEN, while display and other checks * have their own (e.g. HAS_PCH_SPLIT for ILK+ display, IS_foo for particular * chips, etc.). */ #define IS_GEN2(dev) (INTEL_INFO(dev)->gen == 2) #define IS_GEN3(dev) (INTEL_INFO(dev)->gen == 3) #define IS_GEN4(dev) (INTEL_INFO(dev)->gen == 4) #define IS_GEN5(dev) (INTEL_INFO(dev)->gen == 5) #define IS_GEN6(dev) (INTEL_INFO(dev)->gen == 6) #define IS_GEN7(dev) (INTEL_INFO(dev)->gen == 7) #define IS_GEN8(dev) (INTEL_INFO(dev)->gen == 8) #define IS_GEN9(dev) (INTEL_INFO(dev)->gen == 9) if the driver would load/work it would at least be possible to use plex or any package that just need the i915 device to work, videostation might be working i do have a skylake so i should be able to test this (i did make a i915 about 2-3 years ago but was not able to test it myself so it might never have left my system, it seemed to be a fruitless idea back then, also possible something else did not work, i can't remember) i think i will try it tomorrow, sounds interesting and less complex then trying to get in nvidia support the other way would be to find someone who backports a more recent i915 driver to the old kernel

7-zip is ok for having a look (unpack) for repacking it there is a proper way everyone can use on any linux (live/recue linux from usb or in a VM), the unpacking and repacking is part of the description for having new drivers, for repacking just skip the parts about making the kernel drivers https://xpenology.com/forum/topic/7187-how-to-build-and-inject-missing-drivers-in-jun-loader-102a/ i'm already on it in case of kvm/proxmox and 9p you log does not really help as it does not show what symbols are missing, you would also need to check dmesg and messages in /var/log/ i guess i know at least one missing module (aufs.ko) but there might be more, so if you could provide more details about what the modules are missing also the sequence of loading the modules need to be right order insmod just try's to load a module and if you dont do it in the right order you will get unknown symbol even if you have the right module, in theory "modprobe" would look for dependencies of modules and automatically load them is present but that not helping for rc.modules for that i need to know exactly waht modules are needed and if possible the order (dependencies of modules can be checked. in theory there should be a entry in the module for a dependency atm i have this but i dont know if its right and if something is missing (i also have a note on my todo that "virtio_input.ko" is missing) virtio virtio_ring virtio_pci virtio_mmio virtio_net virtio_blk virtio_scsi 9pnet 9pnet_virtio 9p i want that to be present in the next version or at least a have special version for this but atm i struggle with whats needed and in what order it needs to be loaded can you boot a live/rescue linux and see what lspci has about that device (vendor and device id including sub id's if present)

also die 512er und 400er karten (langsam schreibend) gibts für weit weniger als ein extra nas kostet, man hat dann nicht alles zusammen aber meist hat man ja eine liste von sachen die man sich ansehen will und die hat man dann auf der karte im tablet, kommt in der praxis dann gar nicht so häufig vor das man eine andere karte braucht mittlerweile gibts auch 1TB microsd karten, da die das obere ende sind zahlt man da mehr als 2x512MB aber 1TB ist für <200 zu haben https://geizhals.de/?cat=sm_sdhc&xf=298_microSDXC~307_1024&sort=p#productlist edit: small talk zu urlaub und leben mit resiekranheit enfernt

i guess so, i tinkered with the original code from git and 6.2.2 but cant remember exactly (and have not changed my build environment to 6.2.3) in the end its not important for compiling modules its just for the kernel itself that you cant use in the end if you keep it to "make ... modules" instead of "make ... all" you should not need libhydrogen

läuft auch auf einer menge hardware die nicht zertifiziert ist und es gibt auch zusätzliche treiber die nicht zertifiziert sind hatte ich eigentlich noch nie probleme, habe schon ein paar mal desktop hardware verwendet und es lief (und die zertifiziert vmware sicher nicht für den betrieb von esxi) dsm hat ein paar einschränkungen in sachen storage controller (z.b. hardware raid), bei sachen wie temp und lüfter steuerung und der anzahl der prozessor cores (da muss man HT als core mitzählen oder es abschalten) wenn man hardware transcoding will (intel qsv basiert) get das nur mit der 918+ und die ist auf 8 cores beschränkt (4 core+ht) da läuft man schnell gegen eine wand wenn es eine universelle hardware für virtualisierung sein soll und selbst die 3617 kann "nur" 16 cores, darüber hinaus geht nichts (mit dsm 6.x) wenn du eine üppige hardware hast und ordentlich vm's auflegen willst kommst du fast zwangsläufig bei esxi oder proxmox (kvm) raus und lässt dsm in einer vm laufen

also wenn du den orginal loader von jun verwendet hast sollte es eigentlich wie oben in der grub.cfg stehen (und es sollte beim installieren einen fehler geben wenn es nicht übereinstimmt, ist neben csm mode bei loader 1.03b der gängiste fehler) den bereits geschriebenen usb mit windows 10 zu bearbeiten kann ein wenig lästig sein, versuch notepad++ öffne es mit "als administrator ausführen" und wenn du in notepad++ dann über öffnen gehst kannst du die erste der beiden partitionen (laufwerksbuchstabe) auch zugreifen und die grub.cfg checken

???, there is nothing like that for a hacked loader to run a "copy" of DSM reread the part about the grub.cfg and to insert the usb's vid and pid (of the usb flash driver you use for booting) https://xpenology.com/forum/topic/7973-tutorial-installmigrate-dsm-52-to-61x-juns-loader/ maybe try one or two youtube videos about installing xpenology, that usb part is essential and should be in every video/tutorial