Jump to content
XPEnology Community

ilovepancakes

Member
  • Posts

    169
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by ilovepancakes

  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
  16. 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?
  17. 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.
  18. 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.
  19. Now that Redpill loaders for DSM 7 can be reliably created (thanks to many recent contributions from @haydibe, @pocopico, others, and of course @ThorGroup's original code which was very well organized for others to understand), I am trying to focus down on some stability bugs for typical use cases, namely related to running Redpill DSM 7 on ESXi based virtual machines. I'm experiencing an issue where using SCSI based virtual disks (with virtual LSI SAS or Vmware PVSCSI controllers) isn't working properly within DSM, and first off I am curious if anyone else experiences the same symptoms or if it's just me. If I use mptsas or vmw_pvscsi extensions with Redpill, these virtual SCSI disks successfully show up in DSM, and can even be used to install DSM onto instead of SATA data disks. But, even though DSM install goes fine on them, and DSM runs fine, they are highly unstable when it comes to creating a storage pool in DSM on them. This seems to relate to SMART data not being reliably shimmed for these SCSI virtual disks. i.e. Fake SMART data (per TTG SMART shim in Redpill-LKM sometimes shows up, sometimes doesn't, when it does show up, it often causes disks to flip around positions in storage manager, flips the name of the disk back and forth between "Vmware Virtual Disk" and "null Virtual Disk", etc. Most of the time, those issues cause the disk to not report a health status at all or causes an unhealthy status, which of course prevents the disk from being used to create a storage pool in DSM 7. To note, if I add virtual SATA disks to the VM, they show up reliably in Storage Manager, and remain stable and fully usable with no issues. Also, the SCSI virtual disks don't seem to be disconnecting or exhibiting issues at the system level, just in Storage Manager/with health status in DSM itself. This is why DSM can be installed and run off these SCSI disks, but further use of them in DSM is not possible. That being said, I know others have successfully used mptsas (and mpt2sas/mpt3sas or even the built in DSM SCSI driver) extensions to used physical pass-through disks with DSM. I am guessing this works, because real SMART data gets passed through too, and DSM sees this and works with those disks correctly. That further leads me to believe the following (again, assuming others are able to test the above and get the same result): I believe the issue is with the SMART Shim in Redpill-LKM and/or the SAS > SATA Shim code TTG included on their latest commit to the lkm repo. From what I have been able to tell, these shims work through playing with "sd.c" the syno-modified SCSI driver. I'm wondering if the issue is the fact that for the above scenario, other drivers are being used and the shim isn't properly touching those of course. Again, I am first curious though if this issue is widespread or if others are able to get virtual SCSI disks on ESXi to work reliably in their configuration. I don't believe comparing or testing with Proxmox helps here because I think I remember TTG saying Proxmox emulates some SMART data to begin with and you can use VirtIO on Proxmox anyway which redpill is designed to work properly with out of the box. Although, if others DO having fully reliable SCSI virtual disks in DSM on Proxmox, this does further support the issue is likely with the shims not interacting with mptsas and vmw_pvscsi properly.
  20. In latest version Poco preset the password to: P@ssw0rd
  21. Tested, doesn't work on ESXi. Without Vmware tools or open-vm-tools installed, etc... it greys out the option to shutdown or restart the guest VM. Pretty sure those two options in ESXi work differently than typical ACPID events anyway. Was worth a shot.
  22. Yep... and would be great if TTG really is gone (still holding out hope though) to better organize efforts amongst community devs who are capable of continuing the project in various ways.
  23. Ohh I was under the impression that only works with Proxmox and not ESXi, will have to try it out later. Agreed if this does shutdown and restart on ESXi, then IP address display isn't as important. Do you have the package/code anywhere on github for others to test with? Weird restart doesn't work if shutdown does... and I'm assuming it doesn't show IP address in ESXi at all?
  24. Could open-vm-tools somehow be implemented as a Redpill extension? It seems it can't be installed the conventional way (DSM Package) used in DSM 6.2 because DSM 7 doesn't allow packages to run as root, which seems to be needed for open-vm-tools to work 100%. This would allow data (IP address, etc.) to be passed from DSM to ESXi based installs and would allow ESXi VM Guest shutdown/restart features to work.
×
×
  • Create New...