Jump to content
XPEnology Community

ilovepancakes

Member
  • Posts

    169
  • Joined

  • Last visited

  • Days Won

    2

ilovepancakes last won the day on July 8 2021

ilovepancakes had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ilovepancakes's Achievements

Advanced Member

Advanced Member (4/7)

27

Reputation

  1. 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?
  2. 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.
  3. 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
  4. 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?
  5. 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?
  6. 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:
  7. 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?
  8. 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!
  9. 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.
  10. So is proper procedure to create the custom PAT file using an existing install..... then use that PAT file in a new TinyCore install as the PAT that TC patches? Then use that patched custom PAT file as the install PAT file when installing DSM for first time?
  11. Normally with Redpill so far I have been installing DSM via the PAT file provided directly from Synology's site after creating the loader and it installs and works just fine. But do you mean with U2, generating the PAT via those provided steps and then installing the U2 via that PAT is the only way to make it work? I tried the steps listed and rebuilt the loader by providing the custom U2 PAT file but upon rebooting it is in a boot loop from the GRUB menu, it starts to load the kernel then reboots immediately. Are you saying I should restore from a snapshot back to working 7.0.1 THEN use the PAT written by Redpill (which itself is based on custom PAT) to update to U2?
  12. I ran into the same issue of not being able to update 3622xs to 7.0.1 U2. I don't get what this newly generated PAT file does.... Is it just a gz version of the U2 PAT file from synology? And then why does that need to be re-run through tinycore? Tinycore has to modify redpill code using info from the U2 PAT file?
  13. - Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 7.0.1-42218 UPDATE 2 - Loader version and model: Tinycore Redpill DS3615xs - Using custom extra.lzma: NO - Installation type: ESXi v7U3c - Additional comments: Update completes and reboots successfully but DSM installation wizard comes up after reboot and prompts for a recover/migration of disks. After choosing to "Recover" via button provided, DSM takes a few seconds to "Recover" then reboots again. Same recover prompt/wizard comes up again, so DSM won't load fully.
  14. Wonder if this is because it is beta/preview? Have they done this in past with major non-stable releases?
  15. https://prerelease.synology.com/en-global/download/dsm71_beta?builtin_name=synology_bromolow_3615xs
×
×
  • Create New...