@julien-f said in Move build to use npm and Turbo:

should work on FreeBSD, what issues do you have?
The FreeBSD instructions has been contributed by the comm

It seems to me like they have explicitly excluded any platform that is neither windows nor linux (nor darwin):

root@xo:/srv/xo # yarn
yarn install v1.22.18
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
[4/5] Linking dependencies...
warning "workspace-aggregator-9be715c1-80fc-4c5d-b807-b5414e3a3afa > @xen-orchestra/fs > @aws-sdk/lib-storage@3.241.0" has unmet peer dependency "@aws-sdk/abort-controller@^3.0.0".
warning Workspaces can only be enabled in private projects.
[5/5] Building fresh packages...
[1/20] ⢀ turbo
[6/20] ⢀ @fortawesome/fontawesome-common-types
[3/20] ⢀ highlight.js
[7/20] ⢀ vue-demi
error /srv/xo/node_modules/turbo: Command failed.
Exit code: 1
Command: node install.js
Arguments: 
Directory: /srv/xo/node_modules/turbo
Output:
/srv/xo/node_modules/turbo/node-platform.js:38
    throw new Error(`Unsupported platform: ${platformKey}`);
          ^

Error: Unsupported platform: freebsd x64 LE
    at pkgAndSubpathForCurrentPlatform (/srv/xo/node_modules/turbo/node-platform.js:38:11)
    at checkAndPreparePackage (/srv/xo/node_modules/turbo/install.js:252:28)
    at Object.<anonymous> (/srv/xo/node_modules/turbo/install.js:302:1)
    at Module._compile (node:internal/modules/cjs/loader:1155:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1209:10)
    at Module.load (node:internal/modules/cjs/loader:1033:32)

I have found this (seems it's the correct project):
https://github.com/vercel/turbo/pull/2408
and this:
https://github.com/vercel/turbo/issues/2339
I guess I could modify the sources, compile from sources with patches and make it to work somehow... but it's probably better to just move to linux.

yonas created this issue in vercel/turbo

closed [turborepo] Failing to build on FreeBSD 13 #2339

yonas opened this pull request in vercel/turbo

closed [turborepo] Fix build on FreeBSD #2408

@julien-f I guess that rules out freebsd as a platform for building xen orchestra from sources.

I have been using it in a Tuenas core jail, but it's no use because I have found that this stuff is not supported:

• turborepo
• fuse-shared-library (https://xcp-ng.org/forum/topic/6564/xen-orchestra-unsupported-on-freebsd-because-of-fuse-shared-library?_=1673445212328)
• who knows what else

Not ranting about it, I understand if you need better tools. Maybe you should remove freebsd from the build instructions? Just saying...

Best regards.

Hello, when I try to compile from sources, it seems it needs fuse-shared-library which is not supported in freeBSD (only linux and OSX).

What is that library used for? Can it be avoided if the functions are not needed?

In fact I recently get:

error /srv/xo/node_modules/fuse-native: Command failed.
Exit code: 1
Command: node-gyp-build
Arguments: 
Directory: /srv/xo/node_modules/fuse-native
Output:
gyp info it worked if it ends with ok
gyp info using node-gyp@9.1.0
gyp info using node@16.16.0 | freebsd | x64
gyp info find Python using Python version 3.9.15 found at "/usr/local/bin/python3.9"
gyp info spawn /usr/local/bin/python3.9
gyp info spawn args [
gyp info spawn args   '/usr/local/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/srv/xo/node_modules/fuse-native/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/usr/local/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/root/.cache/node-gyp/16.16.0/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/root/.cache/node-gyp/16.16.0',
gyp info spawn args   '-Dnode_gyp_dir=/usr/local/lib/node_modules/npm/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/root/.cache/node-gyp/16.16.0/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/srv/xo/node_modules/fuse-native',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
/srv/xo/node_modules/fuse-shared-library/include.js:17
    throw new Error(`fuse-shared-library is not currently supported on: ${platform}`)
    ^

Error: fuse-shared-library is not currently supported on: freebsd
    at Object.<anonymous> (/srv/xo/node_modules/fuse-shared-library/include.js:17:11)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at [eval]:1:1
    at Script.runInThisContext (node:vm:129:12)
    at Object.runInThisContext (node:vm:305:38)
gyp: Call to 'node -e "require('fuse-shared-library/include')"' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error 
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:284:16)
gyp ERR! stack     at ChildProcess.emit (node:events:527:28)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
gyp ERR! System FreeBSD 12.2-RELEASE-p14
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /srv/xo/node_modules/fuse-native

Hello guys, this is just a report about a silly problem that I "solved", which may be of interest to someone. I have to point out the scenario I am describing is not supported at all. So.

Short story: do not use sync=always on a ZFS remote of any kind with Xen Orchestra.

Long story: I have switched from VMware a year ago and my setup is:

• a FreeNAS server for my backups,
• two XCP-ng 8.1 hosts, with local nvme or hdd storages.

Basically, all on ZFS.

I have been messing around with XCP-ng and Xen Orchestra for quite some time now, with a decent level of satisfaction I must say, except backup speeds on my home 1Gbit network has never been quite as I expected.

First I tried XO on a bhyve ubuntu VM, reaching somewhere around 20-30 MB/s. Then I moved it on a linux vm on one of the hosts, still around 30+ MB/s. Not painful for my needs, but annoying.

Finally recent versions of XO updated node.js to version 12 (as opposed to version 8 which in FreeBSD has been EOL for quite some time now) and I figure: since I am using XO from sources, why not run it directly from a FreeBSD (FreeNAS) jail on the backup target? No VM, less network overhead and more direct access to the backup storage (I mean: nullfs, but who cares).

Given I don't know s**t about FreeBSD, nodejs & C., so, so many thanks to this guy:

https://sysadm.russerver.org/wiki/Install_Xen_Orchestra_on_FreeBSD

Pretty straightforward, it worked like a charm.

Problem was: backup speed of 5 MB/s. Uh? I was getting so pissed.

Then I remembered this is around the expected performance with sync=always on the same pool (raid-z2 6x4TB HDD) without the SLOG nvme device. Weird coincidence, right?

So, zfs set sync=standard on a dedicated dataset and voilà, 90-100 MB/s. Now, that is more like it and I am content with this setup, but I still wonder: what is going on here?

If I run backups via an agent like veeam linux/windows free agent, acronis, etc, let's say on SMB shares, backup speed is stable at least at 50+ MB/s with sync=always. Locally, if I move data from the second pool I have, it's minimum 100 MB/s, even on a pretty full pool with less than 20% free space.

I am sure there is some explanation for the abysmal performance I am getting with synchronous writes for XO backups.

So that's the story.

To sum it up, the only thing I don't like at the moment with XCP-ng and XO is the lack of support for quiescent snapshots.

I mean, that's very, VERY bad. Memory snapshot? Mmm... Maybe. But no, sorry. If this was a production environment, I would probably end up with agent-based backup.
Of course, this is no topic for this forum because we all know whose "fault" that is.