kekesed97

Glad to hear that work for you. I don't know the exact answer, but you can use this info as reference: x77(desktop)/x77XU(rack) - Ryzen Gen1 based x73A(desktop)/x73AeU(rack) - V1000 based x73/x73e - R series based (APU) I can't find any reference for any AMD APU based QNAP other than x73, so that maybe as low as you can go. Also you can try other intel based and see how it works. You can start by comparing the CPU capabilities. Maybe start with x51?

I encountered that problem when I don't pull out my USB DOM (with original CSM firmware) when I tried to install. Try to reboot. What happened to me next was the USB became wiped. It just gone, shown as unpartitioned. Maybe legacy install? By the way, what was the USB boot type? Is it legacy or UEFI? @pocopico

I can't really say. In my QNAP, the CPU and RAM usage was <20% for fresh install. Well, there were many broken packages so that result might be inaccurate. What about in Xpenology? Windows? Ubuntu live? Is the same happened? Or do your BIOS have power saving features like you'd found in laptops or ultrabooks (performance limiting features)? That thing is taking quite atoll on performance, you can feel Windows operate more sluggish even though it runs on SSD.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 7.1-42661-1 - Loader version and model: TCRP 0.8.0.0 DVA3221 - Using custom extra.lzma: NO - Installation type: BAREMETAL – QNAP TS-469 Pro

You can. I tried to put TS-253D into TS-269 Pro. I recommend to pull out the USB DOM before loading any loader. It can boot, it read the disk (you will need to modify mymodel to point to the right device), it can install. But I encountered problems with connection to QNAP server. I can't install any app, the web server is broken, I can't do firmware upgrade, fan and temperature doesn't show correct value, etc. etc. Maybe with more tinkering I will eventually turn TS-269 Pro to TS-253D, but I stopped because I can run DVA3221 without any problem whatsoever on it, and Surveillance Station is exactly what I need. Check out my post in the german section that discuss this topic.

I made some model number record for x53D and x51 while I at it. Model Number Lookup TS-453D Q04M0_QY580_10_10 TS-453D Q04M0_QY581_11_11 TS-653D Q04O0_Q04N0_11_10 TS-653D Q04O0_QY04N0_10_10 TS-253D Q04W0_QY570_10_11 TS-251D Q04W1_QY570_10_11 TS-253D Q05H0_QY570_11_11 TS-351 Q0190_QZ650_10_10 TS-851 QW371_QW340_16_12 TS-851 QW371_QW340_20_12 TS-651 QW371_QW520_16_11 TS-651 QW371_QW520_20_11 TS-451 QW410_QW420_10_10 TS-251 QW410_QW480_10_10 TS-451 QW410_QW630_12_10 TS-251 QW410_QW640_12_10 TS-451+ QW411_QW420_14_11 TS-251+ QW411_QW480_14_11 TS-451S QW592_QW710_12_10 Hint: you can figure out supported models by throwing any model number to the config, but you have to use a correct PATCHED_FIRMWARE version and let the tools extract the firmware. The script will return "Create model.conf failed". Corresponding models can be found in /initrd/etc/hal_util_*.conf. I configured MODEL_TYPE as TS-451S and the firmware as TS-x85. Firmware version doesn't matter. Then I executed the script. It will return as: It's fine, because our goal is to figure out what MODEL_TYPE is supported in x85 firmware. Now open "/home/tc/initrd/etc/" and locate "hal_util_*.conf" and try to open it. MODEL_TYPE is the file title, and the corresponding model name is written inside the text file. Here, I opened "hal_util_Q05S0_Q0650_10_10.conf" and inside the text, this model is declared as "TS-886". Hence, MODEL_TYPE=Q05S0_Q0650_10_10 corresponds to TS-886. Note: x69 series doesn't work this way. They have their own firmware package and not pack any hal_util_*.conf. I checked for TS-269 and TS-469.

Sorry for english in german forum. I don't speak germany. I've tried to put TS-253D into TS-269 Pro. I'm currently testing it. Is there any mechanism to put serial number and mac addres like redpill does? Edit: it seems I can't access any QNAP service, including AppCenter and firmware upgrade. I don't know if this has something to do with my installation. But this small experiment answered my question: it is possible to turn QNAP TS-269 Pro to TS-253D

Don't. x69 series is EOL and only support up to 4.3.4.1976 build 20220303 dated 2022-03-14. I have 2 x69 series (269 and 469) and happily running Xpenology DVA3221 instead of stock QTS on it. But I do wonder if I can load another model in this.

Are you sure the command is "./rploader.sh fullupgrade now"? I don't speak korean so from google translation you typed "./rploader.sh in-place upgrade now (not working)" which is wrong command. You can see the available commands and platforms by typing "./rploader.sh" without any parameter.

You typed the command in korean?

update the rploader.sh first by ./rploader.sh update now, then do the fullupgrade. Don't forget to type the file extenstion (i.e. ".sh")

I've tried to install broadwellnk-7.1 and bromolow-7.1, and I'm facing shutdown issue after services loaded with both installation methods. Now I'm unplugging my test drives and reverting to broadwellnk-7.0.1.

After 20 hours of running my box as DS3622xs+, here is my observations so far: System boot takes longer than using DS3615xs. It takes approx. 3 mins for ping to reach, and another minute to reach webgui. Disk migration runs as it should be, but upon creating a new pool with "unsupported" drives, it shows a warning of unsupported disk. You can proceed to pool creation. Regarding disk pool editing, I'm facing issues when I try to convert a basic disk to RAID 1 and adding disk to an existing RAID 1 pool with mixed disks. It always ask for the identical disks (I forgot to take any screenshots). I don't have two identical disks to test it on that scenario. On the other side, CPU usage is lower compared when I run DS3615xs. But I made and booted the bootloader in two different ways may be the factor. I used docker build for DS3615xs and used Tinycore for DS3622xs+. I primarily run Adguard, Komga, and Shinobi CCTV with 5-6 camera streams, all in docker, beside file serving. Updating DSM didn't work and leads to infinite recovery. No system crashes or pool drop in this timeframe (configured in RAID 1 with mixed brand of 3TB HDD). TL;DR: Migration went smoothly, boot takes longer, don't do any updates yet, and check your disks upon pool creation.

Thanks for the tip. Thankfully I used a pair of test disks so my production disks was unharmed and safely migrated. On a seperate note, I want to write my observation on first day of system run. I believe this might help someone. I will post it tomorrow to get a better look on it.

Just tested DS3622xs+ loader on QNAP TS-269 Pro, migrated from DS3615xs with docker build method on Ubuntu 20.04. DSM 7.0.1-42218 install just fine, but updating to update-3 results in infinite recovery. Please correct me if I'm wrong but I assume there are no solution for this at the moment?

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.7-15284 Update 3 - Jun's 1.02b bootloader - Loader version and model: RedPill DS3615xs v7.0.1-42218 Beta - Using custom extra.lzma: NO - Installation type: BAREMETAL - QNAP TS-269 PRO - Additional comments: Bootloader auto select countdown seems not working (even in Jun's bootloader), so I have to press enter everytime my NAS reboot.