Jump to content
XPEnology Community

flyride

Moderator
  • Posts

    2,438
  • Joined

  • Last visited

  • Days Won

    127

Everything posted by flyride

  1. Just because you have "disabled" the disks in the BIOS doesn't mean that the ports don't still exist. Is it reporting 8 disks or 8 ports? It gives the opportunity to override if you want not to map those ports, but if you take the default, it will do what you ask. I think it is doing exactly what it is supposed to do - map 8 ports of the SATA controller, then add in the HBA ports afterward. Again, post the output from ./rploader.sh satamap if you want more advice.
  2. Especially under DSM7, I don't recommend using that guide to create Storage Pool or volumes. There is DSM "space" metadata that is not created when it is done this totally manual way. DSM only partially understands what you've built. All the DSM array tools ONLY work with SATA. If any event that involves array management occurs, your array will be crashed. IMHO the only "SAFE" way to use NVMe other than cache is to virtualize it and show it to DSM as SATA.
  3. FWIW the script doesn't recognize "now" anymore and you cannot specify the mac address with realmac. It just takes the actual MAC from the hardware. Same result though, as long as you were typing in the hardware MAC. ./rploader.sh serialgen DS3622xs+ realmac The only way to specify your own MAC address that is not the hardware MAC is to edit user_config.json yourself.
  4. DSM at its core still does not support port multipliers. So in that respect, nothing has changed and there still is a general recommendation for AHCI SATA controllers without them. Have you followed the tutorial here? https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/
  5. Yeah, you should see a lot more than that. Not much to diagnose with there. Hopefully someone else has some ideas too. I would get down to simple. Disable 10Gbe controllers and one of your 1 Gbe adapters. Get a SATA disk and get a basic DSM install going with that. Then gradually add in the other components until you find the one that is misbehaving. Sorry I don't have better suggestions but there isn't much here to go on.
  6. The compile looks good, although I am not sure what device you are booting TinyCore from as you have no SATA disks and nothing apparently attached to the HBA? (EDIT: obviously booting form USB) Odds are that the loader is kernel panicking on boot for some reason. Serial console will help with that.
  7. satamap only actually cares about AHCI SATA cards. It probably doesn't see the H310's if they are classified as HBA's. There is an update in the pipeline that will show the drives attached to HBA's because this is a common concern, even though it may not change the outcome. If you post the satamap output I could confirm it for you.
  8. Serial console is always helpful to see what is going on. EDIT: your Supermicro probably supports serial redirection so you might be able to view the serial output from a Java console launched via the IPMI. Are you certain the loader is compiling without errors? If you have an Intel CT (e1000e) card you could drop that in temporarily see if you can find what is going wrong with the i350.
  9. Try assigning MAC to the lowest-ordered 1 Gbe port. You might need to look at the mobo manual to be certain which it is. No need to add the other addresses.
  10. - Outcome of the update: SUCCESSFUL (mostly) - DSM version prior update: DS3617xs 6.2.3-25426 U3 (Jun 1.03b loader) - Loader version and model: TCRP 0.8 DS3622xs+ - Using custom extra.lzma: NO - Installation type: VM ESXi 7 - Additional comments: driver conflict encountered with Mellanox ConnectX-3 10Gbe NIC This particular system is very complex - RDM NVMe boot drives, RAIDF1, passthrough SATA and 10Gbe network and multiple storage pools. It is not unusual to encounter problems with this system even after extensive testing and other successful upgrades. The Mellanox card created a driver conflict, resulting in an incomplete upgrade. The system would boot to junior mode and instantly ACPI shutdown as soon as any http connection was made to the system. Finally a reinstall was forced (synodsdefault --reinstall), which allowed me to see that TCRP was injecting the mlx4/mlx5 modules on top of the native Mellanox support in the DS36xx platforms. After rebuilding the loader WITHOUT the Mellanox extension, the system operated normally and 10Gbe network was functional with the DSM native Mellanox drivers. The Storage Pools and package/Docker configurations survived the event completely intact, so no significant harm was done.
  11. There are different methods of making NVMe functional depending on the platform. I doubt all combinations have been tested so you may need to experiment. On DS918+, lib file needs to be patched. On DS3622xs+, there is a configuration file for the NVMe PCIe addresses DS3617xs is probably like DS3622xs+ DVA3221 method is not known, although I saw a post saying no lib file so it may be configuration file like DS3622xs+ On DS920+ and DS1621+, NVMe is supposed to be configured with Device Tree. If the Device Tree patchdtc script that is part of the loader build gets it wrong, DSM may not find it. Underlying Linux will probably see it, but DSM will not. This command reports detailed information about the NVMe PCIe address: udevadm info /dev/nvme0n1 You should review the Device Tree configuration and see if it is consistent with what is returned by udevadm. https://xpenology.com/forum/topic/62894-only-hdd-in-bay-1-are-found-by-storage-manager/#comment-285068 If necessary, you can edit the Device Tree manually but it is not fun: https://xpenology.com/forum/topic/62894-only-hdd-in-bay-1-are-found-by-storage-manager/?do=findComment&comment=285075 You could try the lib file and configuration file methods, although I doubt they will work for DS1621+
  12. With TCRP and DS1621+, if adding more drives to ports that have not yet been used, the loader will need to be rebuilt. DSM only supports NVMe as cache. In Storage Manager, if you can see the NVMe device, it is working. DS1621+ supports up to 16 threads (8 cores + 8 hyperthreads, or 16 cores).
  13. More likely to be this: https://macandegg.com/2021/06/synology-dsm-7-0-ends-support-for-usb-devices/#:~:text=DSM 7.0%3A No more USB sticks&text=First%2C the support for external,LTE sticks%2C Bluetooth dongles anymore.
  14. Yes, there are circumstances that require this. A better solution is to use the "realmac" argument in the MAC assignment during the loader creation. @Acidflash this is probably your issue as well. The tutorial has been amended to assist the user with this decision.
  15. Yes, any changes to user_config.json require a rebuild of the loader to take effect.
  16. Wow. I thought mine was full with 11 drives Your placement of the M.2 SATA drives in the fan space is innovative. I used a split AC/DC fanless power supply so the rectifier module and heat sink live in that area. I do like the result but building the thing was quite the project. It's good to see others who share the mild obsession. Good luck with the 10Gbe upgrade. Cheers
  17. FYI @techhit @pocopico this was a driver embedded in the Jun loader but I can't find evidence it is compiled for TCRP. https://linux-hardware.org/index.php?id=pci:1095-3132-1095-7132
  18. There is value in seeing how you did it and the link is in your last post. Anyone investigating will see the whole story. Thanks for the update!
  19. There is a second riser slot position, but I have not populated it. I think it would interfere with the use of the other slots (see below). The CX-3 is the MCX311A. It's technically a HP rebranded card 516937-B21. The ports are dual SFP+ which I prefer because it removes a lot of heat from the PHY to the case/chassis instead of being trapped inside. Then DAS cables to connect to 10Gbe guests, as they are inexpensive. The motherboard has 8x SATA ports and 2x Intel Gbe ports so I don't need slots for those. I used the remaining slots for NVMe U.2 interfaces. Here's a few more pics so you can see the arrangement.
  20. As you can see the PCI ids of the controllers that are reported by satamap are different than the error. The red highlighting is yours. My understanding is that this particular controller is part of the RedPill model and no extension is required. You might have missed that notice on your previous build. I think you are okay to proceed. However, if you use the full test procedure as outlined in the tutorial, however, your risk would be minimal. EDIT: Are you saying you have a third controller? The 1b21.0612 is the second on-board controller, which has TCRP support. Did you build with the manual argument? If so, omit "manual" and see if you get a different result. If you really have a third controller and it is an HBA, it may not behave as an AHCI SATA controller. If that is the case, it is treated as a SCSI controller which is unaffected by sataportmap/diskidxmap. There is a pending update for rploader.sh which will confirm the status of HBAs in satamap because that question is a common one.
  21. Did you build the loader again after making the user_config.json change? Anything in user_config.json will override what is in synoinfo.conf
  22. The issue is that DS918+ has limit of two lan ports from Synology. Add maxlanport=4 or whatever you need in user_config.json and TCRP will patch it on bootup. MAC address configuration is optional, it uses the hardware addresses by default. I don't really know what my.sh does with it.
  23. Thanks! You might also want to be aware of these: https://github.com/perrin-1/synology-dsm-open-vm-tools https://github.com/pocopico/synology-dsm-open-vm-tools https://github.com/Grandma-Betty/synology-dsm-open-vm-tools
×
×
  • Create New...