ilovepancakes

Using e1000e and ESXi I can successfully boot redpill-load now. But when I go to install DSM, it errors out with the file is corrupted (13). Here is my serial output: https://pastebin.com/KcEeaJS1 Hoping @ThorGroupcan provide some insight. Followed the instructions on the GH repo and used the VID/PID there.

Can anyone using this on Virtual Box tell me if there are special settings needed for the VM in Virtual Box? I successfully created a loader with redpill-load and it boots in virtual box but I can’t find it with find.synology.com to try installing DSM.

I am getting the following error when running the redpill-load script. Anyone have any ideas? EDIT: Running as sudo fixed issue for me. Guess the script couldn't access the folder it was trying to write to. lab@ubuntu-lab01:~/redpill/redpill-load$ ./build-loader.sh 'DS918+' '6.2.4-25556' [#] Checking runtime for required tools... [OK] [#] Verifying /home/lab/redpill/redpill-load/cache/ds918+_25556.pat file... [OK] [#] Unpacking /home/lab/redpill/redpill-load/cache/ds918+_25556.pat file to /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked... [OK] [#] Verifying /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/zImage file... [OK] [#] Patching /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/zImage to /home/lab/redpill/redpill-load/build/1627496982/zImage-patched... [OK] [#] Verifying /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/rd.gz file... [OK] [#] Unpacking /home/lab/redpill/redpill-load/build/1627496982/pat-ds918+_25556-unpacked/rd.gz file to /home/lab/redpill/redpill-load/build/1627496982/rd-ds918+_25556-unpacked... [OK] [#] Apply patches to /home/lab/redpill/redpill-load/build/1627496982/rd-ds918+_25556-unpacked... [OK] [#] Patching config files in ramdisk... [OK] [#] Adding OS config patching... [OK] [#] Repacking ramdisk to /home/lab/redpill/redpill-load/build/1627496982/rd-patched-ds918+_25556.gz... [!] Failed to repack flat ramdisk *** Process will exit *** lab@ubuntu-lab01:~/redpill/redpill-load$

Not the folder you mention but anything in here help? https://sourceforge.net/projects/dsgpl/files/toolkit/DSM7.0/

This is a great point and allows the most flexibility for running the project. I love running Xpenology on ESXi, I find it to be pretty darn stable 99% of the time. I hope future loaders/redpill continue to support a "Virtual" Xpenology/DSM option.

The latest security updates and some features which actually do improve DSM. I agree a lot of v7 is fluff but is always nice to run on latest builds especially as they start introducing more new features and eventually 7.1, 7.2, etc.

@ThorGroup To echo everyone else thus far, thanks a TON for your efforts on this. Exciting to see the community and development for new versions still alive. P.S. Really looking forward to a DSM v7 compatible solution, sign me up as a tester 😅

Yeah my hope is more that Synology implementing this features provides resources to jun to implement a loader for DSM 7 since Synology will have to make a native "loader" of their own to boot DSM on ESXi, rather than actually using DSM that way as a replacement for Xpenology. However, I still would love to see Synology release an official "private cloud" version of DSM like Qnap did for their QuTS. For what I use DSM for, I would gladly pay Synology like people do for Qnap for the ability to run DSM on an ESXi VM.

No, I really mean for DSM OS full image backups to run on a hypervisor as DSM, not just backups of VMs and bare metal like ABB does now. Synology said it themselves in this video (watch from 13:15 mark). Hopefully they actually pull through with coming out with that feature. There is a little note on bottom of video that says Coming Later in 2021 so we'll see but I am hopefully this code/feature either eliminated the need for Xpenology on ESXi or provides code that Xpenology can use to much better make a bootloader for ESXi DSM installs.

I'm wondering if there is code/files in Virtual Machine Manager that can assist with developing a better loader, especially one that works with DSM 7. VMM can obviously deal with VDSM so there has to be some sort of "bootloader" as part of VMM that is capable of spinning up a VM of DSM. What I am more intrigued about though is the supposed plan for DSM 7 full image backups having the option to restore directly to and boot on hypervisors like ESXi and Hyper-V. Synology said themselves in one of their DSM 7 announcement videos about backups that Active Backup for Business will be able to take full image DSM 7 backups and restore them for use on other hypervisors like ESXi, not just VMM. If this happens, then I imagine they are writing a bootloader specifically designed for ESXi and others that hopefully we can use.

Just a thought that maybe prompts a discussion or further looking into on a loader for DSM 7.0.... Is there something that can be reverse engineered out of Synology Virtual Machine Manager package that can be used towards a loader to boot 7.0? I'm assuming there is some sort of code/BIOS emulator in VMM for booting Virtual DSM.

You can zero out the extra space in the VMDK from DSM then use ESXi commands to decrease the size of VMDK. I have done this with Windows and Linux with following guide in past and I am 99% sure I tried with DSM in past too and it worked, but use those commands with caution. Have a backup first. Hope this helps. https://blah.cloud/infrastructure/zero-free-space-using-sdelete-shrink-thin-provisioned-vmdk/

I have 1.04b loader running DSM 6.2.3 on ESXi v7. One of my main data volumes in DSM is a single virtual disk, living on a vSAN datastore. ESXi was updated to v7 U1a and vSAN needed to update the on-disk format of all VMDKs/VMs on the datastore I guess. It is still working on this process of updating the format of vSAN disks but I guess the process of it doing this, causes DSM to think the volume has crashed. The VMDK is still mounted to DSM, I can still read data from the volume, but Storage Manager reports a crash, and I can't do anything other than hit remove and delete the storage volume. I am guessing there isn't really a problem with the VMDK/volume, I can even still read data yet the volume is only a single VMDK in DSM so it's not like it can still read because of a RAID volume or something. My question is, since DSM considers it crashed, yet it most likely is fine, is there a way to get DSM to just forget that crashed state and try re-mounting the disk and using it as normal? I did try simply rebooting DSM but that didn't make a difference.

I am running docker on a VM with Alpine OS. The VM host is ESXi v7.0.0. Only issue I found so far was the first run of container had some error about something missing (don't remember the exact error) but when I restarted the container then it all loaded and worked fine. DSM installed with no issue. Happy to test 3617xs and 918+ implementations when you have them, if that helps you.

This is awesome! Thanks for your work on this. It worked for me. Is there a way to make it work with 1.04b loader for DS918+?

This is a great point. One time fee would be nice for us.... but not for them. Hopefully the recurring revenue like that will allow them to improve QTS constantly and make it better, faster.

I think their pricing is reasonable for the people who really are going to want to run it in a VM as opposed to buying QNAP hardware. I am also glad they did pricing for different core counts as opposed to one price for all. Although, would be nice if it could be a one time purchase rather than paying yearly especially since buying their hardware is a one time purchase. They could charge $1,000 one time fee for this and make way more than selling a box of theirs for $1,000 with the OS included for "free" already. Heck, charge one time fee for only the current major version and then charge an upgrade fee for each next major version you want after that. I *really* hope Synology follows up with DSM like this. Honestly feel like it would be a big blow to QNAP since DSM seems to be the software favorite between the two.

https://www.qnap.com/solution/qutscloud-hypervisor/en-us/ While I imagine it would kill the point of Xpenology for many, would be nice if Synology follows up and does this for DSM. QNAP not only has those images for private cloud infrastructure but makes images of their OS for VPS hosting too like Digital Ocean.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2-24922-update 4 - Loader version and model: Jun's Loader v1.04 - 918+ - Using custom extra.lzma: No - Installation type: VM - ESXi 7.0.0 - Additional comment : Reboot required. "FixSynoboot.sh" implemented after update.

Anybody got this working with 1.04 and latest DSM 6.2.2? I could only get it working working with the 1.02 loader that comes with it and DSM 6.1.3.

My guess is DSM is just trying on it's own to activate push then. This could be the result of one of the packages you have installed trying to activate push, like Chat, MailPlus, etc...

Yes, since your install is not a genuine Synology one, DSM keeps trying to register for push notification server but it can't authorize. Do you have push notifications enabled? Turning off those boxes and disabling it from trying to register might suppress those in the log.

Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2-24922 Update 3 - Loader version and model: JUN'S LOADER v1.03b - DS3615xs and DS3617xs and JUN'S LOADER v1.04b DS918+ - Using custom extra.lzma: No - Installation type: VM - ESXi 6.7u3 - Additional comments: Reboot required

This first method seems to have worked perfectly! Uploading a bunch of data now to fill the increased space to test if volume remains stable. I did not find that tutorial in a forum search, so thank you!

@Kall So after this command I get an error that the type of array cannot have its size adjusted/expanded but if I follow the rest of the steps anyway, it all seems to work and the volume is expanded. What is this non-working command actually supposed to do and do I have any side effects of not being able to use it? EDIT: I was using JBOD mode with a single disk on the volume I tried this with. Confirming that trying this on a Basic mode volume, the above command works and returns a normal output. So I guess on JBOD volumes this command doesn't do anything. That being said, is Basic or JBOD better performing with 1 disk?