ThorGroup

Members
  • Content Count

    29
  • Joined

  • Last visited

  • Days Won

    23

ThorGroup last won the day on September 22

ThorGroup had the most liked content!

Community Reputation

272 Excellent

About ThorGroup

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. Update time! This week the updates are going to be less exciting but nonetheless very important, and the first point talks about that in more details. THE BUILD HAS CHANGED - READ ME We're putting this as the first and in red so people see it. The LKM build now requires a version to be specified. We know this will break the @haydibe toolchain but we're sure he will fix it quickly as this is a small change. For reasons why read further. Also, if you used a hack to "fix" the Info Center on 3515xs make sure to read "Hardware monitoring emulation" section carefully.
  2. New release update! This is the biggest release to date and ESXi users will be especially happy to see it! SATA boot support for 918+ (and others) Remember how we said it's nearly impossible to add SATA boot support for 918+ as the kernel physically lacks the code to support SATA DOM on that platform? Well, we've said NEARLY impossible as we had an idea but didn't want to disappoint anyone if it failed. It didn't. With this release we're introducing a SATA boot support for platforms which natively lack the support for it. This is mainly aimed towards hyperv
  3. This post contains responses to questions from mid-page 47 only and was split due to forum's limitations. To see release updates jump to a post on the bottom of page 55: ---------------------------------------------- DO NOT use vanilla kernel sources to build modules for the DSM unless you know what you're getting into. We cannot stop you of course but you should know it's like playing with fire over a tank of gasoline. Let us explain. Syno, despite the version number attached in the kernel, modifies source heavily. So their 4.4.123 can be anythi
  4. Continuation of questions starting from mid-page 37 (forum doesn't allow for more than 50 quotes per post): You cannot change that - that will require rebuilding of the kernel which isn't possible (as syno doesn't share compilable sources of the kernel). You theoretically can use mknod but this causes problems with v7 (synoboot used to be done this way on 918+). Stay tuned: we will figure this out Yeah, Linux and md doesn't care - only the DSM has some hardcoded assumptions for paths which we need to emulate
  5. Today we will break the tradition a bit and respond to all questions first. Since the forum has a limit of 50 quoted posts we have to split our response into multiple posts The last post will be with the actual code updates so if you're reading it and not seeing a post with updates - just wait - we're writing as you're reading this. ------------------------------------------ It's fixed in the today's relese [will be up on GH after the update post] The difference between synoinfo and cmdline is subtle but important. The synoinfo defines the pro
  6. It has been over a week but we're not slowing down! PMU emulation is here This was the biggest feature we were working on, which involved fixing many things around to actually make it stable. The current implementation keeps all the data internally. None of the requests sent by the actual OS needed to be responded to directly, as we shimmed mfgBIOS. However, the interface allows for a very easy plug-in of any hardware-based emulation of the PMU to emulate LEDs etc. The important part here this was one of the bigger roadblocks to make the implementation stable and actually know what
  7. With SATA supported we will say there isn't even a need for any config as the default one works perfectly (just clicking through in the Proxmox UI). As for the one you posted we're curious about two things: Why set the cpu to SandyBridge manually? Why e1000 instead of VirtIO? (virtio will be more performant as it doesn't do a full emulation)
  8. Somehow* we managed to commit the I/O scheduler trampoline script without the exec permissions set... sorry! It's fixed now in https://github.com/RedPill-TTG/redpill-load/commit/7d9881435ad4e69c95cf2aa424d9c1378784c6ca *we refuse to acknowledge that we completely forgot about permissions merging in our internal sync tool ================================================ It looks like your image or storage is damaged somehow. If you look into the log there are ext driver errors saying it cannot save blocks to disk. We would look into ESXi logs. If the
  9. We've got more progress notes. As with every update we have something big today too Revamped loading schema This seems like an implementation detail which isn't important at all. However, this change is a milestone in making the kernel module stable and robust. Previously we went with a naive (but working!) method of simply throwing "insmod rp.ko" into the first bash file loaded after the kernel passes control to the user space. Well, it does work but it has many problems, which aren't obvious at first: module loading is asynchronous (some things may overstep action
  10. @gadreel@scoobdriver@cwiggs@loomes Regarding that mystery bug with execve() shim causing kernel panic - can you check again with the newest version? We may have possibly found a solution. In the previous versions we've missed save call for 3615 (whoops!) but the newest release should save it. Can you confirm it's still not working?
  11. Let's make a small list: Small-yet-big update: v7 for 918+ has been merged - thank you @jumkey! Along the way we've made some more under-the-hood changes to make adding new version less painful: https://github.com/RedPill-TTG/redpill-load/compare/ded0ac6375d441a86dcdfee2ec399d95225a12db...cfd70c78cc231709a2f79439e09eb3941b94b83a There's also way more documentation on the process now and all the symlinks are gone: https://github.com/RedPill-TTG/redpill-load/blob/master/FOR_DEVS.md The disk issue seems to be isolated to 3615xs as creation of pools works perfectly on 91
  12. We're currently trying to tackle couple of problems at once So in summary we have: GRUB last choice not saving on ESXi -> this can be caused by VMDK, if so it will show "error: failure writing sector 0x20ba to 'hd0'" or similar after attempting to boot (and the boot continues) unable to create pools on v7 -> this isn't about SMART from what we know so far but about a bespoke hddmon service, investigation in progress. Disks without SMART should work. At present we don't have a machine at hand where we can pass a whole disk controller to the VM (which will give u
  13. You are correct, you cannot use 7.0-41890 with SATA boot. We can expect 41890 to be available soon for 3615xs. As of now if you want to play with 7.0 and along with SATA you need to use 7.0-41222 on 3615xs.
  14. Good new & bad news - but an update is ready! SATA boot is here In the recent days we were working hard to provide SATA boot support for those who cannot use USB (e.g. ESXi users). We stepped into an uncharted territory here as Jun's loader used a completely different method (which isn't feasible for v7). As of a trivia fact it seems like he did try to plug into SCSI subsystem but he never finish it. The idea behind that is simple. In short we had to intercept the kernel probe events for any new disks and change their vendor name and model name on-the-fly. However, i
  15. We cannot really trick the kernel to see SATA as USB as they're checking if it's connected to a USB port. But we can make a SATA drive appear as the correct one Additionally SATA disks don't really have VID/PID, they have vendor name and product name in forms of strings - just a different approach to the media identification. That's why syno added a separate provisioning for SATA. As for VBox you're probably missing https://github.com/RedPill-TTG/redpill-load/commit/5df3ace2191f6bad818b2f34e802163a96408d59 - yumkey branch doesn't have that commit. We're working on v7 but we f