ilovepancakes
-
Posts
175 -
Joined
-
Last visited
-
Days Won
2
Posts posted by ilovepancakes
-
-
10 hours ago, Peter Suh said:
Please follow this sequence.
However, pocopico's TCRP does not support the latest version.
I recommend using TCRP-mshell, which I maintain.https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v0.9.5.0
Instead, you will need to re-record this loader to USB.
Since it is the same TCRP, existing DSMs are compatible with each other.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?
-
1
-
-
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.
-
On 2/23/2023 at 4:41 AM, waazdakka said:
Nice, thanks for the fast answer! (For those who search for it:
But what about finding a valid serial? I can't find any serial generator for the DS3622XS+
Or I can make a new VM installation to get RedPill again and access to the integrate seralizer 😂
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?
-
On 3/16/2022 at 11:02 AM, flyride said:
3. More success data for complex installations and issue recovery
Regarding the latter, I am still periodically reading about how large arrays suddenly drop off. Do we know why? Are we sure that they are recoverable? This is the main reason I haven't moved my production data to a new loader or DSM 7.
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.
-
1
-
-
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
-
20 hours ago, Orphée said:
Yes and No.
DS918+ does not work because it's built with FMA3 instruction set : https://en.wikipedia.org/wiki/FMA_instruction_set
The fact that it use Kernel V3 or V4 is not related.
DS3615/17/22 are not built with FMA3, so loaders work with old CPUs.
The fact DVA3221 does not start on HP Gen8 let me think it is also built with FMA3 instruction set.
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?
-
7 hours ago, Orphée said:
DS3622xs+ is usefull for old CPU before haswell...
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?
-
3 hours ago, wimsan said:
hi all,
I am successfully running a ds3617xs in proxmox using redpill-tinycore. I am also running a ds3615xs in proxmox.
the ds3615 has been upgraded to 7.0.1-42218 update 3 but when I try to update the ds3617 as well it gets stuck in a install loop after the upgrade. Does someone already have a redpill-tinycore ds3617 running update 3 ? If so how have you managed to do the upgrade?
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?
-
6 hours ago, buggy25200 said:
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!-
1
-
-
2 hours ago, buggy25200 said:
Installation must be done with original PAT from synology download center. But the loader for the reboot have to be done with generate PAT
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.
-
4 hours ago, buggy25200 said:
Hello,
Be careful: update to 7.1 beta is for the development purpose only .
It's not working !! .... yet ???
Indeed, we have seen with Yanjun that an security has been added by Synology, which requires, i think, requires a lot of research.
After the update, the problem is that a connection to the GUI causes an immediate system restart.
7.1 beta support for 3617xs is available on my github. To update you must use the same method as for 7.0.1u2 (via the creation of its PAT file)
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?
-
24 minutes ago, Dvalin21 said:
The pat file you see during the build is being patched. If you have the chance take the time to download and install the pat file from the site and then install pat file thats downloaded to usb stick. You will see the difference.
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?
-
On 1/15/2022 at 6:39 PM, buggy25200 said:
Here you have your PAT file !
In this tutorial I work with the rp-helper tool but you can use what you prefer.
Put your PAT file in the cache download directory so that it can be used without downloading synology's one, or host your file on a server and modify the pat_url!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?
-
- 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.
-
5 hours ago, Vortex said:
Now it's encrypted
Wonder if this is because it is beta/preview? Have they done this in past with major non-stable releases?
-
https://prerelease.synology.com/en-global/download/dsm71_beta?builtin_name=synology_bromolow_3615xs
SpoilerImportant Note
This beta software is for evaluation purposes only and should not be installed in production environments. Synology cannot be held responsible for any damage, such as accidental data loss, caused by this beta software.
After installing this update, you will not be able to downgrade to a previous DSM version.
This update will restart your Synology NAS.
For the following models, DSM 7.1 will be the last upgradable version.
XS Series: RS3413xs+, RS10613xs+, RS3614xs+, RS3614xs, RS3614RPxs, RC18015xs+, DS3615xs, DS2015xs
Plus Series: DS2413+, DS1813+, DS1513+, DS713+, RS2414RP+, RS2414+, RS814RP+, RS814+, DS214+, RS815RP+, RS815+, DS2415+, DS1815+, DS1515+, DS415+, DS215+
Value Series: RS814, RS214, DS414, DS214, DS214play, DS114, RS815, DS1515, DS715, DS415play, DS115
J Series: DS213j, DS414slim, DS414j, DS214se, DS215j, DS115j, DS216se
Adjusted the LED indicator for drives' health status. When a drive's health status is critical or failing, the indicator will show static orange.
Windows 2000 domains are no longer supported.
Removed the "Synchronize with an NTP server every time a domain user signs in" option for Domain/LDAP advanced settings. Users can configure the "Synchronize with NTP server" option at Regional Options > Time instead.
Added support for the UPS power-off function at Control Panel > Hardware & Power > UPS.
Synology Storage Replication Adapter can only be used with DSM 7.0.1 or earlier versions. If you are using or plan to use Synology Storage Replication Adapter, please continue to use the current DSM version.
What’s New
SSD Cache Groups can be allocated to multiple volumes, allowing for more flexible management of SSD cache capacity.
Storage Manager now supports the management of the drives and storage of both active server and passive server in a Synology High Availability cluster.
If there is a file system error, DSM will unmount the volume to run file system checks without interrupting the services on other volumes.
Reduced the minimum threshold for low capacity notification from 5% to 3%.
Added support for custom OIDC (OpenID Connect) settings to integrate DSM with external SSO servers.
Added support for the RTF editor to allow users to preview notification message content and style in real-time when editing.
Added support for bypass traverse checking at Control Panel > File Services > Advanced to allow users to traverse folders and access permitted files or subfolders.
Supports specifying domains from the list of trusted domains to synchronize domain data.
Added the Greenwich Mean Time (GMT+00:00) time zone option at Control Panel > Regional Options > Time.
Added the synchronization status between DSM and NTP servers at Control Panel > Regional Options > Time.
Added icons on the taskbar to indicate ongoing background tasks that might affect system performance.
Users can now open tabs directly from search results in Control Panel.
Supports automatically updating the domain database and syncing domain data regularly. For Synology NAS that are used to create domains, the "Update User Groups/Lists" option in Control Panel > Domains/LDAP will be disabled by default after updating to DSM 7.1 Beta.
Limitation
The update progress bar on a Synology High Availability cluster might not display the actual progress percentage. This won't affect the update progress.
-
This page seems to have gone live recently but the download links don't work for me. https://prerelease.synology.com/en-global/download/dsm71_beta
Anyone happen to have them work and try out if v7.1 is an easy update for Redpill/Tinycore to handle?
-
On 1/10/2022 at 3:32 PM, flyride said:
AFAIK there is only one modern underlying virtual disk structure (perhaps not with vATA, haven't tested with vNVMe). You can change a virtual disk to connect to a vSATA controller, or any dialect of the virtual SCSI controller and the data remains accessible.
That's a good point and I believe correct. If I take a virtual disk used under a vSATA controller and move it to vSCSI controller, it will still be accessible. The only thing I thought that made SCSI more performant when virtualized is a more performant driver, like Vmware Paravirtual SCSI.
But, if performance really is the same or so similar, it doesn't matter to me with DSM. It isn't like I'm running a giant database or 1,000 users trying to access and write/read at same time. There definitely are performance gains in other operating systems when using PVSCSI for example over vSATA controllers with the VM. Plenty of people have tested.
-
1 hour ago, flyride said:
I guess I should point out that "real" SCSI devices (as opposed to SAS) don't have SMART.
While SCSI disks were functional in 1.02b/DSM 6.1.x, the install FAQs since 6.x was released have always advised virtual SATA devices. With 1.03b/1.04b and 6.2.x, virtual SCSI (and probably physical SCSI too) stopped working reliably. Some of my own analysis back in the early days of 6.2.x is here which may be informative and correlate to the experience you are currently having.
Just a conjecture, but I suspect this is not a Redpill problem at all, and the configuration is using "leftover" SCSI support code in DSM which Synology doesn't test anymore, since there is no hardware to support it.
Thanks for the insight. I agree it isn't a "problem" with Redpill itself other than simply not being supported/coded (to make the SMART data shim work on virtual SCSI/SAS drives like Redpill does with SATA.
That being said, on 1.04b 6.2.x I have used virtual SCSI disks in ESXi as the main DSM drives and have had 0 issues with them. The only reason I did this is because from my beginning days with Xpenology, I thought everyone would always say the virtual SCSI disks would be more performant than virtual SATA, especially with Vmware Paravirtual SCSI ones since that is made specifically for virtualization. But, if vSATA vs. vSCSI really doesn't make a a difference and both are equally as performant, then I'll just use SATA and call it a day with the SCSI stuff. Very rudimentary "benchmarks" lead me to believe they are in fact basically the same, but I didn't run anything scientific or in depth at all. Just compressed a few files and duplicated a few large files, etc... and the timing was basically the same between vSATA volume on DSM and a vSCSI volume on the same DSM VM.
-
16 minutes ago, xsspark said:
I did but my main problem is the machine is not detected on my network and it’s connected to my router by Ethernet.
Sounds like a driver issue. What NIC do you have?-
1
-
TinyCore RedPill Loader (TCRP)
in Loaders
Posted
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?