Herrnobiz

Quite the contrary, i read that the 918 and 3622 seems to be the best two option especially when upgranding to newer DSM releases (me too had a 920 stuck after an upgrade, and recovered later migrating it to a 3622), and i if remember correctly it's because they dont use an hardcoded model.dtb

Update: not having eth0 working in arpl 4 alpha6 on the destination machine, i cannot create the loader because arpl cannot dowload the required pat files and extractor. So: -i created another usb drive with arpl 6 and booted on a second machine -setup with the desired serial,mac, modules etc... then created the loader so this second usb contains in his cache the necessary files. They are in arpl3 partition, specifically the dl and extractor directory -Copied those two missing folders onto the first usb drive -Booted the no ethernet machine with the first drive and now complete cache folder and it build succesfully the loader Booting the dsm from arpl initially takes longer (just a few seconds more because arpl cannot get an ip for the aforementioned problem) but then it passes control to the dsm loader that correctly enables the networking. All is good now

Just tried the new 0.4 alpha6: on one pc equipped with realtek gigabit i can get an ip in loader configurator,but if i use my test nas with intel e1000e i get "ip: can't find device 'eth0' ". So no ip like alpha 4 and alpha5

Just tried 0.4 alpha 4 and arpl does'nt give me an IP, my network card driver on TCRP is recognized as an e1000e. Now i'm gonna try the new alpha5, finger crossed Update: no luck with alpha 5 either, no ip assigned at all (checked on router) so port 7681 or whatever doesn't matter

Mine was working great on a ds918+ 7.01u3, but then i migrated to 7.1 ds920 and i got the same "not such file error"

- Outcome of the update: SUCCESSFUL - DSM version prior update: Redpill Tinycore V0.4.6 DSM 7.0.1-42218 UPDATE 3 (DS918) - Loader version and model: Redpill Tinycore V0.4.6 DSM 7.1-42661 Update 1 (DS920) - Using custom extra.lzma: NO - Installation type: Baremetal on msi-h510m-a pro migrated from ds918+ to ds920+ - Additional comments: Added i915 patched modules to enable gpu transcoding on i3-10105 and libsynonvme.so.1 patch i made on ds918 7.01 seems to be already in place after migration to 7.1.u1 ds920

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.3-25426 Update 3 - Loader version and model: Tinycore RedPill DS918+ v7.0.1-42218 update 3 - Using custom extra.lzma: NO - Installation type: BAREMETAL - MSI h510m-a pro - i3-10105 - 1x120gb nvme as SSD cache- 2x 8tb WD RED - 1x60gb ssd for docker containers - Additional comments:ACPI manual add to have power button working: ./rploader.sh ext apollolake-7.0.1-42218 add https://raw.githubusercontent.com/pocopico/rp-ext/main/redpill-acpid/rpext-index.json Pached libsynonvme.so.1 in order to change fixed address and recognize NVME as SSD cache

No sorry, i'm currently triyng to extract the bios in order to mod or fix it

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.3-25426 Update 2 - Loader version and model: Jun's Loader v1.03b DS3615xs - Using custom extra.lzma: Yes - Installation type: BAREMETAL - Terramaster F2-421

in putty i see 7620mb (because of reserved video memory i guess) admin@f2:/$ free -m total used free shared buff/cache available Mem: 7620 263 6856 39 499 6993 Swap: 6619 0 6619 but in DSM only 4gb and therefore i cannot use virtualization assigning more than 2gb of ram per VM

Hi, i'm currently using a terramaster NAS F2-420 (j1900 cpu, 2 realtek lan) updated with the latest DSM 6.2.3 update 2, with extra.lzma from IG-88 ver.0.11 with the 1.03 DS3615XS loader and now i moved to this new upgraded model f2-421 (j3455 cpu, 4 realtek lan). On the old model i had upgraded the ram with another 4gb stick and it was correctly reported in xpenology (8gb total) and the system was running as smooth as butter. The two models share the same type of memory stick (ddr3 1600 low profile),so i moved the ram stick into the new nas and checked bios (8gb reported) and double checked even in the original terramaster operating system that all 8gb was displayed, so i started i the installation of the DSM but problems arised... I've tried all 3 loader types, first with the 1.04 918 with extra v0.13.3 because they have the same cpu and then the 1.03 3615 with extra 0.11 and then even the 3617 with extra 0.11.2... the nas boots and i succesfully installed DSM with all of them but: -it's painfully slow even during installation: for example the picture of the nas in the first setup screen when i upload the pat file is loading from top to bottom and as if it was downloaded with an old 56k modem -the amount of ram reported in dsm it's all garbled up see screnshot attached : it doesn't seem a mere cosmetic problem (as with the cpu) because with the previous nas it was reported correctly Any help/advice?

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2 - Loader version and model: JUN'S LOADER v1.03b - DS3615xs - Using custom extra.lzma: yes (0.5 test) - Installation type: BAREMETAL - Terramaster F2-420 8gb - Additional comments: Manual update got error 21, so i installed FixSynoboot.sh, restarted the sistem, updated USB partition with new extra.lzma 0.11 (thanks to IG-88) and rd.gz and zimage extracted from DSM_DS3615xs_25426.pat

just use the updated driver extension (extra.lzma) for your DSM version you want to use and the NIC card will be recognized. I got the f2-420 quadcore dualbay and i'm on DSM 6.2.2 upd 4 3615xs(latest one available); without the updated driver extension i've been stuck ok 6.2 because of the NIC not recognized just as you

Go straight and download the 3615xs named DSM_DS3615xs_24922.pat and proceed with the 1.03b loader tutorial to create the usb drive, then modify the second partition of the usb drive where reside the extra.lzma file and follow the guide https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/ (basically extracting/replacing the 2 files on the stick with the ones from the original pat and adding the new extra.lzma vers. 0.5 from the topic above). This way you should be on DSM 6.2.2 (the latest one)

Tried a "safe" install onto a fresh disk and IT WORKS wonderfully, so now i'm planning on migrating my existing 6.2 setup, thank you. Btw my nas is a terramaster f4-220 3615xs with integrated realtek NIC and AHCI storage. Previously i cannot upgrade to 6.2.2 because of the no-more supported NIC adapter. How stable i am if i use your pack in production? If i understand correctly the possible unstability may come only from the added non-AHCI storage drivers (but my system use generic AHCI), so i guess i'm ok as far my system is using only the updated realtek driver?

I've the f4-220, and tested both the 1.03b ds3615 (DSM 6.2 update 2) and then the 1.04b ds918 (6.2.1 update 4) . The best combo is to use the 1.03b ds3615 mainly because: -there are many more third party packages available -virtualbox 5.20 works (no package for apollo lake platform of the 918+) -it's possible to use lm-sensors package to control the fan speed of our nas (otherwise it just spins upd and down constantly and in bios there's no option to control it) ...Just my two cents

- Outcome of the installation/update: UNSUCCESSFUL - DSM version prior update: DSM 6.2-23739 Update 2 - Loader version and model: JUN'S LOADER v1.03b - DS3615xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - Terramaster F2-420 - Additional comments: Lan is dual Realtek (lspci reports 10ec:8168 rev 07 therefore a 8168f)

All is gone well, upgrade from 6.1.7 to 6.2 using latest jun 1.03b. I've got the f4-220, only thing that i've had to change is to enable force legacy boot in bios(known bug of 1.03b loader if booting from uefi)