ilovepancakes

I was able to get all my instances of 7.1.1 updated to 7.2.1 pretty smoothly using that method. In fact, I changed loaders and re-built to 7.2.1 all in one step to save time, and that worked okay. The only hiccup I noticed when using your loader is that the SataPortMap and DiskIdxMap values set in your loader or even by manual editing of the user_config.json file are NOT saved when building the loader. After the build, both those values in the user_config.json file are reset to nothing and just show "". And when rebooting to boot into DSM, the loader SATA boot options line also shows no set values for these. I have to hit "e" add them in that screen manually to the SATA boot line, and then it seems to save them and use them in the future. Why would setting them in your loader build settings or user_config.json before build not be honored and actually save the values for use when booting DSM?

Thanks Peter. I remember a while ago you mentioning you were going to make an mshell version of TCRP, nice to see it now!! So, if I understand correctly, I should first switch from my current loader to your loader, without even updating DSM, just to get the loader itself switched? And I assume this just involves replacing the current loader VMDK (I am on ESXi) with your loader VMDK, then building in your loader using same settings as current loader/DSM? Then once that is all complete and DSM is working on 7.1.1 using your loader, then follow the steps you outlined to rebuild again for 7.2.1, then reboot, and then it will prompt to install 7.2.1? Do I have that all correct?

Been a while since I have updated DSM or had time to visit here. Wondering if someone can outline for me the proper steps to get on DSM 7.2. I am currently running TinyCore Redpill Friend 0.9.3.0 loader image and am on DSM 7.1.1 Update 5. What is the order and steps I need to do to get on latest DSM 7.2 along with getting to latest TCRP loader?

Mailboxes are per user. If you are using the same user account added to both email domains like in your example, there is one login for that user and one mailbox, it just adds both domains to that one user so they can use both. I believe you'll need to create separate user accounts to use each email address as its own. I don't know if gmail still works this way but I believe you used to be able to send emails to a gmail user via "username@gmail.com" or "username@googlemail.com" so kinda the same concept.... both are same user mailbox just two different addresses going to it.

Just boot tinycore RP on the same VM you already have running and use built-in generator to generate a SN then run commands again to build redpill using that SN. It will update your existing install to use the new SN. That being said, I don't know if using a generated serial # will work or not. Wondering if AME needs an actual real SN from a real SN unit.

Awesome, thank you! Activation works and initial testing seems to play HEVC files just fine now.

I am running TC Redpill with 3622xs loader on 7.1 Update 4. AME doesn't activate, so I changed the grub commands on boot to reflect netif_num=2 and added a 2nd mac address so 2 mac addresses and correct netif_num and AME still does NOT activate. Guess that netif_num isn't the solution?

Building off this, I have noticed in the past that many users experienced issues with docker, specifically databases that cause high CPU usage. This would cause Redpill to crash, and was something @ThorGroupwas going to look into before they disapeered. Just this week, I noticed crashing behavior in Redpill when Synology Drive attempts to index a lot of files, which sucks because it makes using Synology Drive pretty unstable on Redpill, which is a major feature to be missing out on. Indexing involves database operations in DSM of course so obviously there are still stability issues in Redpill with things that involve databases unless they are small databases. My concern is.... it seems that fixes to problems like that are handled in Redpill-LKM or even the base Redpill-Load. As far as I know, there have been zero developments to RP-LKM since TTG left. All of this work people have been doing lately to make installing Redpill easier like RPTC, etc. are amazing... but, they jump the gun in the sense that they are just allowing easier install of a buggy implementation of LKM. This is just going to cause headaches for everyone especially as more people install with these easy tools and then have problems like the above. I'm really hoping someone is capable of actually updating RP-LKM to make the underlying system more stable.

Depends on the update. Some updates like 7.0.1 U3 and 7.1 require a newer version of loader generated by different branch versions of redpill-load some users have made. If the update you are going to is compatible with the loader you already built, you don't need to rebuild the loader simply for the update. I don't believe Tinycore-Redpill has been updated to work with 7.0.1 U3 or 7.1 yet. I know it's coming though. In the meantime: https://github.com/dogodefi/redpill-loader-action

Ahh interesting. It seems then there is no practical downside to FMA3 missing from DS3622 then other than maybe slightly worse performance on code that has to multiply numbers and then add to them?

I could be completely off on this but doesn't 3622 use the newer kernel version (v4)? And if so, isn't that the reason 918 doesn't work on older CPUs? How would 3622 work then when 918 doesn't?

You have to create a custom PAT file for now if you want to upgrade to U1/U2/U3 on 3617 as the format Synology used on their PATs changed so RP TinyCore can't patch them yet. See here:

Successfully migrated an install from Jun's 1.04b 6.2.3 to RP-TC 7.0.1 Update 2. Does the FixSynoboot.sh script need to be left "installed" or it can be removed and is not needed by RP to operate correctly?

Awesome, as usual, you all rock. The ncurses interface sounds great…. Just when we all think the project is already in a state above and beyond it gets better!

OK that makes sense, so basically building the loader using data from the generated PAT for 7.1 rather than the original 7.1 PAT that can't be unpacked/read anymore by TC. I wonder if there is an eventual way to automate that building of the generated PAT. Unless we find a way to unpack the original without booting it and generating live from DSM telnet, I would imagine it would be pretty dang hard to automate your procedure you came up with since it seems to involve a running instance of DSM to be able to telnet into and build the PAT manually.