snoopy78

aktiv ja....hab es aber nur als bere-metal am laufen..

Check some Posts above...someone did already compile the needed .ko Driver file. This one you Mist then manually add when creating the boot disk.

Beachte, dass du ggfls. für realtek extra Treiber in das Boot Image implementieren musst (das geht glaube ich bei der Erstellung direkt...musst diese .ko Datei in das ensprechende Verzeichnis kopieren....einfach mal lesen, irgendwo hier ist das erklärt, finde den Post nur gerade nicht). Deswegen nutze ich z.b. nur Intel NICs, die werden von QNAP standardmässig unterstützt... Meine HDDs sind je am Marvell, Intel und LSI Controllern angeschlossen, alle werden korrekt vom System erkannt. (nutze nen Asrock SOC Xeon D1541 https://www.asrockrack.com/general/productdetail.asp?Model=D1541D4U-2O8R#Specifications ) schau z.B. mal hier in den Eintrag https://xpenology.com/forum/topic/27543-qnap-auf-eigener-hardware/?do=findComment&comment=278850

in deinen lspci -vtnn steht: +-11.0-[02]--+-00.0 VMware USB1.1 UHCI Controller [15ad:0774] | +-01.0 VMware HD Audio Controller [15ad:1977] | +-02.0 VMware USB2 EHCI Controller [15ad:0770] | \-04.0 VMware SATA AHCI controller [15ad:07e0] in deiner model.conf System Disk 1] DEV_BUS=B02:D04:F0 DEV_PORT = 0 PCI_SWITCH_PORT = 0 ERR_LED = EC:1 PRESENT_LED = EC:1 LOCATE_LED = EC:1 SLOT_NAME = Disk 1 das sollte so nicht passen... denn 11 HEX = 17 DEC ist, dann sollte es zumindest B17:D04:F0 lauten.... aber wie gesagt, mit Hypervisoren kenne ich mich nicht aus...habe die kisten nur als bar metal am laufen

=> i've never got an issue with the default boot images, except, that the old dog version is running in older systems (non uefi) while the new ox image is running only on uefi systems => this sounds like the "old" dog image...with the new "ox" image it should be "patch_extract"/"patch_install"

hi... i don't know about VMWare/ESXi, but as long as you have PCIe adressable devices shown in LSPCI / LSPCI - vtnn you should be able to address all devices/disks. For me, i used at the beginning the "old" version, since there is a script, which reads out the used adaptors and addresses and packs it into the model.conf. So with the old version it's actually quiet easy to get it up and running. But after some time, you'll understand how the calculation is done (its a simple HEX to DEC conversion) and you can then manually get it up and running. Personally i moved away from TVS-872XT and onto TVS-1683, since (i don't know why) with the 872 i couldn't get PCIe Passtrough to VMs up and running. Attached 2 of my files. One i use to boot up from an SATA SSD (ox image) and one from USB Stick (old dog image). (my internal SATA Ports i don't use, since i have a SAS3 HBA where are all drives are connected) In both the PCIe 1 & 2 are correct since in PCIe 1 i have a QM2-4P-384 (currently 2 nvme SSDs connected) and in PCIe2 i have a QNAP USB-U31A2P01 for passtrough only (therefor i didn't define the ports as USB port). !! the QNAP QXP-10G2U3A will NOT work for PCIe passtrough, since it's falsely classified in LSPCI and threrefore not detected by QNAP OS (i wasted 2-3 days with a friend to find this f*cking cause)!! model_USB.confmodel_SATA_with_both_PCIe.conf

@banschee habe es gerade noch einmal getestet....die model.conf kann ganz normal zwichen dem Ox und DOG Image hin und hergeschoben werden. Einzig meine Anpassung des SATA Boot im OX image habe ich nicht ins DOG Image und umgekehrt übernommen. Mein Prob ist, dass meine WinVM (hab heut noch mal Win11 frisch reininstalliert) beim Streamen für einige (bis zu 5) Minuten nicht mehr erreichbar sind. Das Qnap dagegen die ganze Zeit, also ist alles bis zum vSwitch soweit i.O...und es ist irgendwas im VM, wenn ich die USB Karte per passtrough durchreiche. der "untere" ist die VM

Wenn du schon eine funktionierende model.conf hast, ist es doch super easy....nimm die uns Spiel die im neuen Image ein.... Wenn du schon ein richtiges Image installiert hast, einfach - in tiny core booten - per SSH auf das System connecten - "patch_extract" ausführen - per winscp auf System verbinden - per winscp die neue model.conf aufspielen - "sudo cp /home/tc/model.conf /home/tc/patch/etc/model.conf" absetzen - "patch_install" - "sudo reboot" fertig bist... Alternativ, mit dem "alten" die model.conf erstellen und wie o.g. in das neue System reinschieben Btw....irgendwie habe ich mit VMs ein Problem....habe mehrere am laufen....die Linux VMs gehen alle soweit.... Bei den Windows VMs (Server 2016 & 2022) hab ich das eine Stabilitätsproblem, wenn ich ne qnap USB Karte per pcie Passtrough durchreiche....(hatte hier mit nem bekannten 2 Tage verschwendet, weil die erste USB 3.2 Qnap Karte anscheinend defekt war und nicht richtig in lspci erkannt wurde...und wir dachten, dass die PCIe Zuordnung falsch sei)...die neue USB 3.1 Karte wird sauber erkannt und kann in die VM durchgereicht werden... Hab der WinVM 6 Lerne & 16 GB RAM gegeben....trotzdem, hängt die manchmal....das merke ich daran, dass mein DVBViewer, welcher in der VM läuft einfach weg ist....wenn ich USB Passtrough mache, dann ist es stabiler, aber ich habe Artefakte im Stream....auf reinem Blech läuft der USB2Sat Adapter stabil.... Bin hier am verzweifeln.....wollte schon das qnap in ne VM legen, aber unter esxi werden die SSDs nicht sauber erkannt....und in hyperV kann ich keine SCSI Adressen auslesen...und hab kein Lan.....

@s2k7 du scheinst das chinesische ja deutlich besser zu verstehen als ich....kannst du ggfls. mal den Modding/Patch-Part genauer erläutern.... soweit ich es verstanden habe, kann man eigene Dateien/Treiber via /home/tc/patch/etc/init.d/file und dann "./patch_install" integrieren.....getestet habe ich das aber bisher noch nicht....

k.a. was du verglichen hast....die neue funktioniert nur! bei UEFI & ist upgradefähig...jedoch ist das Script für die model.conf nicht dabei...musst also deine bestehende nehmen....

nee...schau mal hier..

sooo...habe das jetzt folgendermaßen geregelt....nicht schön, aber geht erst einmal... https://wiki.qnap.com/wiki/Running_Your_Own_Application_at_Startup habe die autorun.sh entsprechend angepasst autorun.sh #!/bin/sh echo "waiting & running new autostart.sh" /mnt/HDA_ROOT/qboot/S10yec.sh echo "All done!" S10yec.sh #!/bin/sh #### modify /lib/udev/rules.d/50-udev.rules sed -i '/UPS_YEC/d' /lib/udev/rules.d/50-udev.rules #### modify /etc/init.d/udev_run.sh sed -i '/UPS_YEC)/d' /etc/init.d/udev_run.sh sed -i 's/not_ups_vid_list=(1d6b 05e3 046d 1005 0b05 1c05 1c05 03f0)/not_ups_vid_list=(1d6b 05e3 046d 1005 0b05 1c05 1c05 03f0 0403)/g' /etc/init.d/udev_run.sh sed -i 's/not_ups_pid_list=(xxxx 0608 0826 b155 17ba 3074 2074 e207)/not_ups_pid_list=(xxxx 0608 0826 b155 17ba 3074 2074 e207 6001)/g' /etc/init.d/udev_run.sh NACH dem vollständigen Boot sind zumindest die YEC-USB Settings weg, so dass die Reader korrekt funktionieren. Wenn ich die Reader während des Bootvorganges dran lasse, dann erkennt das System die YEC-USV mit Abnormal und fährt wieder sauber runter.... kennt sich hier einer der Qnap-/Linuxcracks ggfls. besser aus und kann das eleganter lösen?

hatte heute mein System (siehe vorherige Post) auf das neue Image umgestellt, direkt danach kam das neue Update von QNAP 5.0.0.1932 raus......update ließ sich ohne Probleme einspielen..^^ Einzig meine Modifikationen in der Boot-Disk sind weg, muss mir jetzt halt was anderes einfallen lassen..^^ es soll ja die Möglichkeit geben, die autorun.sh anzupassen...naja...schauen wir mal, ob ich das so regeln kann..^^

Ich nutze für die 872X aktuellste 5er Version, kein QTS Hero...

Ich hab doch die 4 Port Version von deiner Karte.....wo werden denn die nvme SSDs an den Strom angeschlossen?