Jump to content
XPEnology Community

ilovepancakes

Member
  • Posts

    175
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by ilovepancakes

  1. 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$ 
    

     

  2. On 7/20/2021 at 2:16 AM, ThorGroup said:

    DSM v7 sources
    Synology did already publish v7 sources and.... they pulled them quickly: https://sourceforge.net/p/dsgpl/discussion/862835/thread/a519b80124/. They used to be in the "41890branch" as you can see from the project's history: https://sourceforge.net/p/dsgpl/activity/?page=0&limit=100

    We weren't lucky enough to get them. Did anyone maybe was able to grab them?

     

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

     

  3. 42 minutes ago, rok1 said:

    Not sure what 7.0 will give us aside from some minor updates aesthetically and functionally.

     

    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.

  4. On 3/21/2021 at 5:10 PM, IceBoosteR said:

    Abolsutely interesting video. I was just about to get my hands down on a ds920+ and migrate my data to hot (DS920+) and archive data (Unraid) which is currently a single host on Xpenology. But the migration would be a nightmare, and the option to run DSM in ESXi would be awesome (natively). However I guess they will check of a valid license, because they mentioned it is just for a migration/backup intention, so could be an issue for assigning more disks etc. They strongly mentioned the Synology Ecosystem....

     

    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.

    • Like 1
  5. On 2/27/2021 at 2:42 PM, djvas335 said:

    This is already available on current DSM and Active Backup, you can back up a bare metal machine and restore it to esxi or hyperv server

     

     

    On 2/27/2021 at 11:46 AM, flyride said:

     

    That sounds like backing up a client and being able to restore it to indepenent hypervisor a la VEEAM, not virtualizing DSM for profit.  If Synology were to license DSM for virtualization on non-Synology hardware, there would not be much point to XPenology. I am personally all for it, but the model that has emerged so far is subscription-only and the pricing is a bit steep (QuTSCloud, $20/month for 4 cores - yikes).

     

    If Synology were to market a perpetual-use license (even with a limited upgrade mode) for a reasonable price, for virtualization, I would think it would strongly appeal to this community.  I doubt they would do it for general-purpose hardware due to complexity of hardware compatibility.

     

     

    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.

     

     

  6. 4 hours ago, IG-88 said:

     

    what do you prefer? crystalball, tea leaves or throning bones?

     

    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.

  7. 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/

  8. 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.

  9. 21 hours ago, uxora-com said:

    Thank you for your feedback, can i ask you which hardware and os are you using ?
    I haven't tried ds3617xs and ds918+ yet ... I will work on it when got some spare time.

     

    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.

  10. On 10/16/2020 at 11:58 AM, uxora-com said:

    For those, who still are interested in running a Xpenology on a Docker ... I have forked and updated this project to make it works with dsm 6.2.3.


    Here is the link:
    - to the source project: https://github.com/uxora-com/xpenology-docker
    - to the docker hub image : https://hub.docker.com/r/uxora/xpenology

    And last, here is the link to the bootloader with virtio loaded at boot : https://gofile.io/d/bym4Cc
    Note that "download" url in webpage on this link can be used as BOOTLOADER_URL once it has been generated by clicking on the link.

    Instruction:
    - Install Docker
    - Then run:

    
    $ docker run --privileged \
    	-p 5000:5000 -p 5001:5001 -p 2222:22 -p 8080:80 \
    	-e RAM=512 \
    	-e DISK_SIZE="32G" \
    	-e BOOTLOADER_URL="http://example.com/path/synoboot.img" \
    	-e BOOTLOADER_AS_USB="Y" \
    	-e VM_ENABLE_VIRTIO="Y" \
    	uxora/xpenology



    Let me know if it works (or not) for 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+?

  11. Just now, billat29 said:

     In a previous life I used to run software businesses and after that I used to try to rescue others from the ashes. One time licence fee, even backed up with a monthly maintenance charge does not work in the medium to long term. This is why <everyone> has gone to some kind of subscription based service. If they haven't yet, they will.

     

    You can pay annually if you hate monthly 😀

     

    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.

    • Like 1
  12. 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.

  13. - 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.

  14. 3 minutes ago, lolvince said:

    thank you for your reply.
    but I did not activate push notification: /

    I'm looking for what is causing this ...

     

    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...

  15. 4 minutes ago, lolvince said:

    I regularly get this error message:

    
    2020-02-03T18: 38: 40 + 01: 00 N40L synocloudserviceauth: cloudservice_get_api_key.cpp: 21 Cannot get key
    2020-02-03T18: 38: 40 + 01: 00 N40L synocloudserviceauth: cloudservice_register_api_key.cpp: 246 Validate api key failed: Serial number invalid
    2020-02-03T18: 38: 40 + 01: 00 N40L ssnotifyd: pushservice_update_ds_token.c: 52 fgets failed
    2020-02-03T18: 38: 40 + 01: 00 N40L ssnotifyd: pushservice_update_ds_token.c: 147 Can't set api key
    2020-02-03T18: 38: 40 + 01: 00 N40L ssnotifyd: pushservice_utils.c: 325 SYNOPushserviceUpdateDsToken failed.
    2020-02-03T18: 38: 40 + 01: 00 N40L ssnotifyd: pushservice_utils.c: 387 GenerateDsToken Failed

    is this normal?

     

    System info:
    DSM version: DSM 6.2.2 24922 UPDATE 4
    Loader version and model: JUN'S LOADER v1.03b - DS3615xs
    Using custom extra.lzma: 1.03b_mod ds3615 DSM 6.2.2 v0.5_test
    Installation type: BAREMETAL - N40L

     

    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.

  16. 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

  17. On 5/31/2019 at 9:59 AM, Kall said:

    mdadm --grow /dev/md2 --size=max

     

    @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?

×
×
  • Create New...