amikot

- Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 7.1.0-42661 (failed update with TCRP v9.2.9) - Loader version and model: Auto Red Pill Loader v0.5alpha1 - DS3615xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - HP N54L Followed very easy steps of menu.sh - selected bromolo-7.1.0-42661. newer version were unavailable for DS3615sx. Unfortunately, generated loader didn't boot - probably DSM partition is broken with TinyCoreRedPill and don't want to boot into any shape. With ARPL machine cannot be discovered in the network as it was with TCRP.

- Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 7.0.1-42218 - Loader version and model: Tinycore-Redpill v9.2.9 - DS3615xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - HP N54L Proceeded the upgrade via GUI uploading version bromolo-7.1.0-42661. After reboot tried to run loader script with postupdate parameter, but was passing incorrect option and was getting error: platform not found. When finally passed correct platform version (didn't know available platforms can be listed - no info about that in help file. After passing postupdate script, machine boot into new DSM but can't be discovered in the network, so I think it may Now will try ARPL.

Hi, I have TCRP installed since some time, but had only version DSM 7.0 Today I've upgraded it to DSM 7.1.0-46661 (from file) as found information on this forum that 1st I should install the upgrade from GUI and then run postupdate script. Problem is that when I try to run postupdate, script answers with error: Error : Platform not found. My platform is DS3615xs / bromolow-7.1.0-46661 Version: 0.9.2.9 Hardware; Microserver N54L DiskStation model: DS3615sx platform prior update was: bromolow-7.0.1-42218 and that version is still displayed as my platform Isn't my platform supported by TCRP? or what? What to do ? Thanks.

Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.3 - Jun's 1.03b bootloader - Loader version and model: Tinycore-Redpill.v0.4.6 DS3615xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - HP MICROSERVER N54L - Additional comments: Used USB stick - SanDisk Cruzer 16GB Used commands: ./rploader.sh update now ./rploader.sh fullupgrade now ./rploader.sh serialgen DS3615xs ./rploader.sh identifyusb now ./rploader.sh satamap now ./rploader.sh build bromolow-7.0.1-42218 ./rploader.sh clean now Regardless that it was migration, I didn't keep my old config and as is listed above, has generated new SN etc. For all questions during installation answered "Y". And for "satamap" just pressed ENTER to confirm discovered number of sata ports and disks. Didn't build 7.1 bootloader because it fails to install DSM in lower version than 7.1 which wasn't released for DS3615xs yet.

Okay - I just have done as it was explained in first post and it worked. So in this case universal guide was better then dedicated one.

Hello everyone, after months I've decided to migrate my old N54L to RedPill DSM7 and unfortunately nothing work for me. I found one French thread dedicated to N54L and there everything was clear, but from some reason after installation my machine stuck on Loading Kernel and is invisible in the network. I'm not using anything unusual, just regular N54L, so I'm surprised it didn't work. Of course I tried 3615sx as it was suggested in that French thread. But maybe it's not up to date? Maybe now procedure is different? Could someone help me with that? Thanks And one more - my disks are now with DSM 6.2.3 - I hope it will migrate automatically when it will just boot up? Thanks

Bootloader is waiting for user to start installation. If you can't find your Xpenology server with find.synology.com, than probably your network card is not configured correctly in bootloader settings. If your installation starts, but after restart instead of Synology login/password configuration page you see migration page as you showed above. Than most probably HDD in your NAS is faulty and system didn't install correctly. I don't know how it would be with multiple discs. There might be also that you're trying to install incorrect DSM version. You should remember that since Synology released version 6.2.4 - you cannot do automatic installation anymore and you have to manually install DSM 6.2.3 appropriate to your bootloader configuration. There should be option to upload file in web interface. Remember that instead of web interface and fund,synology.com you can use DSM assistant software for Windows PC. It should let you find and install DSM as well. However, error visible on photo can be also related to hard disk failure, so no sure.

I have just suggestion - if someone want's to report successful installation of DSM 6.24 or 7.0 with redpill - could you use template as in normal reports? After all it is interesting what hardware, what mode baremetal or virtual, what exactly version of installation file and what version of loader. And than maybe some details.

Before everything else you should test your HDD - if there are bad sectors it may explain installation issues. I made that mistake and was trying to fix USB stick, configuration, BIOS version, but real reason of installation failure was HDD with bad sectors.

You can always block address of update server on the router. What is that address - I don't know. Hopefully it's not the same as for packages centre - otherwise you would have no ability to install any synology software.

WebDAV is secure if you use HTTPS. Over HTTP it may be not so secure, but I think in another area than it's with SMB. Mounting FTP in Windows - I may be wrong, but I think it's possible if you use just raw FTP. If you want to use SFTP (FTP in SSH session) and FTPS (FTP over SSL) Windows can't do it. There was one project made by someone in the past for that (mounting FTPS/SFTP as drive in Windows), but it's abandoned and it doesn't work well with Windows10.

Exposing SMB to the internet is like invitation for hackers. Never ever do that. There are other ways to share data over internet: 1. SFTP + DDNS - simple and secure, supported by Linux, simple clients needed for other operating systems. 2. WebDav + DDNS - as others described. Easy setup on DSM, client app needed. 3. SMB or AFP or NFS over VPN + DDNS- Rather complicated setup on both server and client machines. 4. SMB or AFP or NFS over VirtualLAN (ZerotierOne) - Apps needed on both - server and clients ends + free management account on zerotier-one.com (where you create your virtual LAN networks). No need for DDNS. Safety like with VPN but easier setup and management (for instance you can block users, assign them IPs)

SHR is for Synology Hybrid Raid, so yes it's only for Synology (and Xpenology of course). I don't know anything about QNAP - my suggestion is to google it. SHR is nothing about stability or self healing. SHR lets to use full disks capacity for different size disks. If you have all disks of the same capacity SHR is pointless. Synology or QNAP? Qnap has it's features as well - for sure you can install additional software as well (Entware?). Biggest benefit of DSM (Synology/Xpenology) is number of android/ios apps to access data remotely. Everything else can be achieved on any PC setup with Open Media Vault. And one more word about Xpenology - studying forum is needed only to find hardware that you could use + information how to prepare USB stick with bootloader.

@xReppa: you opened samba port to the world and you're surprised with the attack? Only safe way to share samba over internet is through Virtual LAN like ZerotierOne. There is Zerotier client for most of devices including DSM and any linux/android/windows etc. So you just need to register on their webpage, create virtual network, share network ID with clients and when they join you just accept them in your admin console. All traffic is encrypted and safe. Apart of that, it's good to separate upload section from download section. All downloads should be read-only for all external clients, upload folder should be only for that purpose. Transfer from upload folder to downloads and whole downloads management should be done using DSM file manager or by SSH.

@Steveyg777: if you're update freak then you should go with Synology and actually you always may consider some older models . As from observations, Synology supports their devices with DSM updates for 6-7 years, so even with models from 2017-2018 you would have better guarantee of future updates then with Xpenology. With Synology you also have easy access to your NAS with Quick Connect which is not supported on Xpenology and on Xpenology you have to use DDNS or Virtual LAN (like ZerotierOne). Sometimes also you may experience hardware compatibility issues, installation issues etc. To avoid that you have to spend time studying forum, tutorials, installation reports etc. When you decide what hardware to use, only easy part left - prepare loader (which takes maybe 15-30minutes) and set up your Xpenology NAS the same way as you would do with Synology. Xpenology also has it's benefits - you can use better hardware then any genuine Synology device, you can use very cheap old PCs (I spent 50 quid for my HP Gen7 Microserver) and install pretty new DSM. So it's not so pointless to use Xpenology, but building it isn't for everyone. You must want to learn some knowledge, and decide to live with some weaknesses of it. In terms of usage and maintenance and rescuing data there is no real difference. Just to remember to not update DSM without checking if it's save and how to do it. So actually Xpenology if installed by someone who know the rules can be administrated by anyone with just that simple rule - to not do firmware update. Everything else is normal - packages updates, management etc. Maybe I'm writing a bit chaotic way - sorry I'm getting old.

If you want to CHANGE disks for bigger it will work only if you have SHR volume and you can change at once only your redundancy number of disks, but I wouldn't suggest that. If you have just RAID5 or RAID6 disk change for bigger ones wont add any capacity to the volume because of RAID limitations. Another situation is when you're ADDING disks as merve04, then if you have SHR you will add full capacity of the drives. In case of RAID5/6, for each added disk you will get additionally capacity of smallest unit in the raid (or nothing if you added drive for additional redundancy).

What have you updated, how?

Really ? could you share the link, please? I'm googling, duckduckgoing and binging and nothing found

On AmigaOS there was something called "buffers" that was basically ram allocated space that user could set for disk. In those days hard drives had very limited cache and adding buffers did speed up HDD access. To be honest I don't know how it's organised in modern OSes since HDDs has their own cache now. But here we have situation where actually we need kind of additional cache, so maybe it would be good idea to go back to that old solution? You could create ram disk and maybe you could allocate it as SSD cache? Actually Synology DSM may not permit to use something that's not typical SSD, so maybe it would let use something like DDRive which is PCIe SSD based on DDR memory. This kind of solution would have no r/w cycles limit. Of course the size can be rather limited. I don't know if there is any newer/other RAM based SSD solution, but I hope this idea won't be forgotten.

@unmesh: according to installation guide I've linked earlier you don't need to edit grub.cfg to get DSM booted. To achieve that you have to enter grub console (press "c" when you see grub menu). In grub console you use following commands to enter your data (enter each line separately): vid 0xYOUR 4 DIGITS USB DRIVE VID pid 0xYOUR 4 DIGITS USB DRIVE PID sn YOUR NAS SERIAL NUMBER mac1 YOUR NAS MAC1 ADDRESS Then, you press ESC to return to menu and you can boot DSM with adequate grub menu option. Of course entered data will be gone after reboot.

It must be image and even more ... your changes of grub.cfg doesn't matter, because as I understand your problem is that grub is not starting. So it must be one of: 1. grub.cfg access error. 2 grub.cfg syntax error (this can be probably caused if for editing you used wrong editor - I suggest to use Notepad++) 3. faulty or incorrect synoboot.img (I'm using this one) I would do fresh start - from scratch as described in the guide with taking care about details.

Actually it is pretty easy to determine. It can't be Microserver itself nor BIOS settings because USB stick taken from N54L works in N40L. It must be something with USB dongle or with image written on it. If you're sure image is prepared correctly, then only possibility is that your USB stick is rubbish. Just try another USB dongle.

For SN I used that -> generator In case of the rest I'm completely confused. I have N54L as well, but I don't know what FixSynoBoot.sh is. Only what I did to get Xpenology working on my N54L was: 1. Flashed in modified BIOS version to N54L. 2. Switched C1E off in the BIOS and generally prepared all settings in the BIOS. 3. Flashed USB stick with synoboot.img with prepared grub.cfg with USB stick VID, PID, Serial Number (generated on the web) and MAC address taken from BIOS and PCIE card. 4. Booted bootloader with no problems. I had issues on next steps, but caused by faulty HDD and loader itself was working fine. Just instalation stuck always on some point.

Serial number looks strange for me it doesn't look like from generator. About MAC addresses - are you sure that nic1 isn't internal and nic2 pcie? After all it doesn't matter - just MAC addresses will be swapped. As your error messages suggests missing commands, I think you should ensure your image is flashed completely, with all partitions. What program are you using for flashing? I've used Win32DiskImager.

Actually there is something that could be checked without network to determine if it's genuine machine. New firmware may do check if NIC MAC addresses belongs to expected pool (brand). This is easy to check actually because MAC addresses can be set easily in loader - just need to obtain what address pools belongs to which DS models.