cpresco

Yeah... this doesn't look great.

The cable for the serial connection on my Lantronix Spider KVM requires a 9pin serial port and I have tried a 9pin serial to USB converter but wasn't able to get any output from that configuration. The driver you reference was likely the missing component and is likely an excellent candidate to be added to default ARPL/TCRP installs. I believe you'll be happy with the H370M-ITX, i5-8400 and 16GB RAM, I would have migrated to a similar configuration (H370M-ITX, i5-9400t and 16GB RAM) if I hadn't found the IMB-1211-D.

I have an Asrock H370M-ITX/ac and was considering migrating from the Jetway NF9J-Q87 I'm currently using. I last tested with ARPL 1.09 using a spare USB stick and spare hard drives and recall seeing that both the i219v and i211at were available in DSM. The WiFi NIC was not available (I believe that is to be expected). The reason I have not migrated to the Asrock H370M-ITX/ac is because the Asrock H370M-ITX/ac doesn't have onboard serial ports(which in my opinion are essential for troubleshooting) but I was able to add a serial port via a PCIe card in the single available PCIe slot on the Asrock H370M-ITX/ac. I have since decided on migrating to an Asrock IMB-1211-D which has onboard serial ports which leaves the PCIe slot available for a future upgrade like a 2.5Gb NIC. Additionally I'd also highly recommend using a Lantronix Spider KVM with motherboards that don't have out-of-band management port(HP iLO or Dell iDrac are examples). The Lantronix Spider KVM also provides a serial connection that is accessible via SSH.

This thread could be relevant to this discussion about governors in Xpenology/TCRP/ARPL.

Yes. I have the User field set as root on the General tab with a similar scheduled task.

You could try setting that with a Boot-up User-defined script in Control Panel/Task Scheduler.

Per https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt 2.1 Performance ----- The CPUfreq governor "performance" sets the CPU statically to the highest frequency within the borders of scaling_min_freq and scaling_max_freq. Per https://wiki.archlinux.org/title/CPU_frequency_scaling#Scaling_governors Governor Description performance Run the CPU at the maximum frequency, obtained from /sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq. Per https://documentation.suse.com/sled/15-SP3/html/SLED-all/cha-tuning-power.html Performance governor The CPU frequency is statically set to the highest possible for maximum performance. Consequently, saving power is not the focus of this governor. Per https://wiki.gentoo.org/wiki/Power_management/Processor Option Module Supported Processors Note 'performance' governor cpufreq_performance Sets the frequency statically to the highest available CPU frequency. For Intel core processors, this should be selected as default.

Understood and the status update is appreciated.

Your efforts in creating ARPL and responsiveness to issues that are being reported are impressive and appreciated.

I believe in an earlier post Peter Suh recommended migrating an exiting DS918+/7.0.1-42218 to DS3622xs+/7.0.1-42218 before upgrading to 7.1.0-42661. I'm going to try these steps on spare hardware with DS918+/7.0.1-42218 that is similar to my in-use DS918+/7.0.1-42218 system. Data backup is #1 on the list of steps before doing this on my in-use DS918+/7.0.1-42218 system. Brunox, your reply is appreciated. I'd be interested to know/hear anyone's experience with migrating an existing DS918+/7.0.1-42218 to DS3622xs+/7.0.1-42218.

Anyone?

@anyone I'm considering migrating from DS918+ to DS3622xs+ for various reasons and recommendations I've seen in this thread. DSM is currently at 7.0.1-42218U3. TCRP is 0.4.5. Hardware is in my sig. Are these the correct steps for migrating an existing DS918+/7.0.1-42218U3 to DS3622xs+/7.0.1-42218U3? 1. Backup all data 2. Create a new USB loader with TCRP 0.4.6 from pocopico github 3. Remove existing USB loader and boot with new USB loader 4. Select Tiny Core Image Build during boot 5. Run following commands ./rploader.sh update now ./rploader.sh fullupgrade now ./rploader.sh clean now ./rploader.sh serialgen DS3622xs+ ./rploader.sh identifyusb now ./rploader.sh satamap now ./rploader.sh build broadwellnk-7.0.1-42218 I'm guessing that DSM will do it's own migration when I access DSM after the reboot. Once I have a successful migration to DS3622xs+/7.0.1-42218U3 I'll be considering the upgrade to DSM7.1 and am guessing that would be the two step update but I'm not sure what the sequence of events/commands would be for that.

- Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 7.0.1-42218 UPDATE 3 - Loader version and model: Tinycore-Redpill UEFI v0.4.6 DS918+ - Using custom extra.lzma: NO - Installation type: Baremetal - Additional comments: Tried updating to DSM 7.1-42621 Release Candidate Update completes and reboots successfully and Synology Assistant is able to find updated DSM through a scan but the status is Recoverable and the version reported is 7.0.1-42218 (update 3 is now missing from the version).

To be clear, DSM 7.1-42621 Release Candidate has been released. https://www.synology.com/en-global/releaseNote/DSM

I have successfully migrated an existing DSM 6.2.3-25426 Update 3/Jun Loader 1.04b/DS918+ installation to DSM 7.0.1-42218 Update 3/tinycore-redpill 0.4.5/DS918+ without any issues. DSM 7.0.1-42218 Update 3/tinycore-redpill 0.4.5/DS918+ has been running for about a week now.