TomY

I understand. 1621 series is 6 core/12 thread Ryzen, and this is not the only one with >4 cores, so it does work. VM hardware is often way more powerful than a typical nas device. Depending on this, even 1-2 cores might be good enough to start with and still more powerful than a 2 or 4 core J-series. If your VM CPU reaches the limit most the time, there is always possibility to scale up. For typical nas applications CPU overhead is rather less of a concern, memory and bandwidth might be far more important. If DSM runs on VM, most likely there is no sense to apply another level of virtualization, unless this is a convenience issue. Supervisor can handle other VMs and containers more effectively than VM in the VM (less overhead).

Check @FOXBIvideo tutorial on YT. There is simple manual how to update this information. Basically, you see what is assigned to your DSmodel (it is a fix value). Ram is assigned dynamically. Whatever you see, your system uses hardware of your machine. It does not matter what is displayed in CPU section.

To make it bit more precise: "all disks are in place" means that they have to be defined in /home/tc/redpill-load/ds920p.dts, but not yet defined and connected to the VM /physical port as @use-naspointed in his previous post. Turn off the TC (sudo poweroff instead of sudo reboot). Add virtual Sata drives to the VM instance, turn on the VM and check DSM.

Surprisingly, this method works on Proxmox VM, too. Well done!

Downloaded. All extensions up to date. Modified ds920p.dts file at /home/tc/redpill-load/ and /home/tc/redpill-load/custom/extensions/redpill-dtb/ still ignored.

Neither /home/tc/redpill-load/ds920p.dts nor /home/tc/redpill-load/custom/extensions/redpill-dtb/ds920p.dts change give the expected outcome.

the ds920p.dts is found only at these two locations: /home/tc/redpill-load/ds920p.dts /home/tc/ds920p.dts I added that one manually, but this is ignored and build still automatically writes the drives. /home/tc/redpill-load/custom/extensions/redpill-dtb/ds920p.dts Should I edit one of the first two instead of creating new file?

Would it be possible to guide us through the process of manual edit of ds920p.dts in combination with TC build?v Perhaps such a manual has been already created earlier, then please redirect. I did try to update it manually on /home/tc/redpill-load/ds920p.dts right after first build, then changed file (changed data order), run build again and everything has been rewritten to automatic value. After booting, still no drives are detected in DSM.

I saw that pocopico/rp-ext repo has been updated 2 days ago, so I thought it may also fix the loader build issue with e1000. This however still does not happened and loader uses e1000e extension files instead of e1000: ...... [#] ========================================== pocopico.e1000e ========================================== [#] Extension name: e1000e [#] Description: Adds Intel(R) PRO/1000 Network Driver Support [#] To get help visit: <todo> [#] Extension preparer/packer: https://github.com/pocopico/rp-ext/tree/main/e1000e [#] Software author: https://github.com/pocopico [#] Update URL: https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000e/rpext-index.json [#] Platforms supported: ds1621p_42218 ds918p_41890 dva3221_42661 ds3617xs_42621 ds3617xs_42218 ds920p_42661 ds918p_42661 ds1621p_42661 ds918p_25556 dva3221_42218 ds3615xs_42661 ds3622xsp_42661 ds3622xsp_42218 dva3221_42621 ds3615xs_41222 ds918p_42621 ds3617xs_42661 ds3615xs_25556 ds920p_42218 ds920p_42621 ds918p_42218 ds1621p_42621 ds3615xs_42621 ds3615xs_42218 ds3622xsp_42621 [#] ======================================================================================= Found Ethernet Interface : pciid 8086d0000100e Required Extension : e1000 Searching for matching extension for e1000 Found matching extension : "https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000e/rpext-index.json" ------------------------------------------------------------------------------------------------ Starting loader creation .... due to this, the DSM instance can't be detected.. therefore for Proxmox user with e1000 this line still has to be added before build (pick one related to your build): ./rploader.sh ext apollolake-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000/rpext-index.json #DS918+ ./rploader.sh ext geminilake-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000/rpext-index.json #DS920+ ./rploader.sh ext broadwellnk-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000/rpext-index.json #DS3622+ ./rploader.sh ext denverton-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000/rpext-index.json #DVA3221 #./rploader.sh ext <generation-of-your-choice>-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000/rpext-index.json or add it to @Peter Suh m.sh/my.sh/myv.sh scripts: ./rploader.sh ext ${TARGET_PLATFORM}-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000/rpext-index.json before: ./rploader.sh build ${TARGET_PLATFORM}-7.1.0-42661 #or replace ${TARGET_PLATFORM} with Generation of your choice. At least up to the moment loader script is updated

I understand. The only way now then is to run e1000/virtio extensions before build, after all this is just one line extra. I added to my script a vi user_config.json line also, to stop the process and check/add/or modify "mac" addresses. To be frank I do not understand why serialgen creates random mac value. I think for both, BareMetal and VM mac setup should correspond to network adapter mac, isn't it?

I've tested "VMware vmxnet3" network card settings in Proxmox - works smooth with standard build command (without extra extension download of e1000 or virtio). These do not need to be fixed or added to m or my scripts anymore. For those who want to use e1000 a better option is to request updating extension links repository the standard rploader.sh build works with. This fix will eliminate Proxmox users issue permanently. 920+ have the same status still - no hard drives detected still (I tried with virtual Sata driver only).

Good idea with scripts. For some (VM) users a prompt to replace mac1 to own value would be a welcomed script optimization (before build). And perhaps mac2 line could be added, with manual entry of mac address (some users use >1 physical nic or virtual nic with own mac address). For Proxmox users a script line before build line would be also recommended (I've noticed that e1000e standard script does not work, at least for me): ./rploader.sh ext ${TARGET_PLATFORM}-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/rp-ext/master/e1000/rpext-index.json

Clear. So what is the intention of DS920p.dts manual modification if TC overrides it? Unfortunately my build still shows disks not detected.

I did so and noticed the tab formatting difference of pcie_root line which is generated automatically: internal_slot@1 { protocol_type = "sata"; power_pin_gpio = <0x14 0x0>; detect_pin_gpio = <0x23 0x1>; led_type = "lp3943"; ahci { pcie_root = "00:1e.0,01.0"; ata_port = <0x0>; }; shouldn't it be: internal_slot@1 { protocol_type = "sata"; power_pin_gpio = <0x14 0x0>; detect_pin_gpio = <0x23 0x1>; led_type = "lp3943"; ahci { pcie_root = "00:1e.0,01.0"; ata_port = <0x01>; }; ? By the way, I've noticed one of usb lines is also misaligned: usb_slot@1 { vbus { syno_gpio = <0x1d 0x1>; }; usb2 { usb_port = "3-5"; }; usb3 { usb_port = "2-1"; Does this allignment matter? When I build it again ds920.dts is overwritten with autogenerated values. Should satamap and diskidx lines be erased from user_config.json?

at what stage this is modified in TC? Before build it does not exit, after build it is ignored and location is cleared with last commands.