I'm seeing the exact same issue. Also, when I updated to the latest build a few minutes ago...when I go into the main Backup overview page, all the jobs are there, but the schedules are missing, the area is just blank. I have to roll back to a previous build

@julien-f Just one question.....do you guys EVER sleep?
I'm blown away at the responsiveness of this project....thanks for the efforts!

@olivierlambert Well.....now I did.
After much hair pulling and gnashing of teeth, it worked as it should. I was unaware I needed to. Thanks

@julien-f OK, it seems to be fixed. I created a job and kicked it off manually and no issues, it seems to be back to normal.
Thanks again!

@julien-f Well, I tried to delete all.....and got this output:

tony@xenorchestra:~/XenOrchestraInstallerUpdater$ xo-cli rest del tasks
✖ TypeError [ERR_INVALID_URL]: Invalid URL
    at new NodeError (node:internal/errors:405:5)
    at new URL (node:internal/url:611:13)
    at Object.exec (file:///opt/xo/xo-builds/xen-orchestra-202312212125/packages/xo-cli/rest.mjs:152:21)
    at Object.del (file:///opt/xo/xo-builds/xen-orchestra-202312212125/packages/xo-cli/rest.mjs:46:33)
    at Object.rest (file:///opt/xo/xo-builds/xen-orchestra-202312212125/packages/xo-cli/rest.mjs:149:28)
    at async main (file:///opt/xo/xo-builds/xen-orchestra-202312212125/packages/xo-cli/index.mjs:396:14) {
  code: 'ERR_INVALID_URL',
  input: 'undefined'
}

@julien-f said in Latest commit smoked NFS remotes:

@fataugie Should be fixed, let me know if there are any issues left!

https://github.com/vatesfr/xen-orchestra/commit/194db8d0dd28ccfd058c97e8c16b32d853b26cf8

Will do! Thanks for the quick attention.
I'm currently remote and my network has decided to not let me in so it will be probably 10+ hours until I can get the update installed and tested. I'll report back one way or the other asap.
Thanks

@olivierlambert said in Latest commit smoked NFS remotes:

@fataugie I can confirm and reproduce this bug, thanks for the report!

No problem....If I had any idea how to submit via Github, I would have there....but I'm a novice at best with Git

@Andrew
So on release 5cf5d on the master, there was a strange issue of when you create a backup job, fill everything in and hit save, the first time it would not save the schedule. Edit the job, and the schedule was not there....so I recreate the schedule and hit save again. This time, the schedule was saved, but the retention count reverts to either null or zero (nothing is shown in the gui), and if you try to run it would complain that you can't have a blank retention in the schedule section. Edit the job again and change the retention and then....if you hit save, is everything finally committed properly.

In the meantime, I see four more commits have taken place on the Xen Orchestra so I'm updating and will test once that's complete and report my results.

Thanks for all the hard work guys!

UPDATE: No joy, same progression through the failures to create a backup job.

So I've got a similar issue, but with slightly different additional sticky logs. So in my pic, "A" refers to this topic, but I also have the list "B" that is persistent between reboots of the Xen instance and even the Host server.
"A" will disappear with a refresh of the page... "B" is like the walking dead....

Is there a location I can go to on the server and remove them via the cli?

@julien-f Cool, I'll run the update and let you know.

@olivierlambert Yeah, sorry I didn't get the one I was actually on when it died. I believe about told me I was 7 behind the one I rolled back to this morning when I ran the update last night.

Not sure who needs to hear this, but I applied last nights updates (7 or so commits from 12/16) and overnight my backups to NFS shares failed. I rolled back to 4784b and was able to re-enable the shares.
The error message was remotes were disabled. When I tried to re-enable, the log message was the same....remote disabled.

remote.test
{
  "id": "7ec02e68-7d51-4ea0-afdd-532747e33034"
}
{
  "message": "remote is disabled",
  "name": "Error",
  "stack": "Error: remote is disabled
    at _class2.getRemoteWithCredentials (file:///opt/xo/xo-builds/xen-orchestra-202312190034/packages/xo-server/src/xo-mixins/remotes.mjs:191:13)
    at _class2.testRemote (file:///opt/xo/xo-builds/xen-orchestra-202312190034/packages/xo-server/src/xo-mixins/remotes.mjs:105:20)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202312190034/packages/xo-server/src/xo-mixins/api.mjs:445:20)"
}

@florent I would love to....but I transitioned from Hyper-V a few months ago. No VMWare to be found around here.

Without fail, these OVAs will be downloads from a variety of applications.

Thanks again!

@florent SUCCESS!

Just grabbed and built XOCE with that branch, ran an import and it worked just as expected.

I'll probably run a half dozen more imports over the next day or so. If anything weird pops up, I'll report back but this looks like it fixed the problem.

Thank you, I appreciate it!

Any updates on this?
As of this morning's build (afadc) it's still an issue.

While I was waiting on a fix for the OVA import issues I was experiencing, I decided to work on a solution myself to getting a template I could use Cloud Configs on.

Through much trial and error, I managed to figure out a build template that works for Ubuntu 22.04 LTS that gets you a base image that will recognize standard Cloud Configs in XOCE and apply them successfully. I thought I'd write it up for anyone else who may be banging their heads against the wall like I was.

***Note: almost ALL of this was knowledge gleaned from other users in other posts, comments and various forum posts here and on other websites. All I did was figure out what worked, in a repeatable fashion, so I could actually use the configs as intended.

How I built my cloud disk and used Cloud Config ;

• Installed Ubuntu 22.04 LTS as VM, (I used 2 cpu, 8G ram, 10G drive)

• Upon reboot, I updated/upgraded w/apt

• Installed Guest Tools

• Ran sudo apt install cloud-initramfs-growroot

  • (an absolute MUST if you want your VM to apply a Cloud Config...took me 4 or 5 times reinstalling and trying various things not realizing how important this was for success. I thought it was automatically installed with the Cloud-Init package.....it is not).

• Ran sudo cloud-init clean

• Ran sudo truncate -s 0 /etc/machine-id /var/lib/dbus/machine-id

  • Used to clear out machine-id for regeneration. Found that if you deleted the file, it would not be regenerated during the reboot but if you zeroed it out, it would.

Shutdown VM and created a template from that image.

Doing this allowed me to apply Cloud Configs and have them actually stick to any new VM created from that image.

One thing...the configs MUST be in perfect YAML format so running through a verifier helps spot issues. I was missing a space between the hashed_passwd: colon and the start of the password. It took a verifier to point that out.

Hopefully this helps someone in the future

@florent I tried a barebones cloud disk from Ubuntu (22.04) in OVA format last night for grins and giggles...... and that failed with the same message.

@olivierlambert Yep, here is the link:

LibreNMS OVA

Trying to import an OVA file via the XOCE import VM section and it's failing with this log entry in settings -
No user expected grain marker, received [object Object]

Here's a clip from the full error if that helps.

"crash_dumps": [],
    "virtual_size": 10485760000,
    "physical_utilisation": 24064,
    "type": "user",
    "sharable": false,
    "read_only": false,
    "other_config": {},
    "storage_lock": false,
    "location": "2538546e-f69b-4ed5-8b77-9b0caba33c02",
    "managed": true,
    "missing": false,
    "parent": "OpaqueRef:NULL",
    "xenstore_data": {},
    "sm_config": {},
    "is_a_snapshot": false,
    "snapshot_of": "OpaqueRef:NULL",
    "snapshots": [],
    "snapshot_time": "19700101T00:00:00Z",
    "tags": [],
    "allow_caching": false,
    "on_boot": "persist",
    "metadata_of_pool": "",
    "metadata_latest": false,
    "is_tools_iso": false,
    "cbt_enabled": false
  },
  "message": "expected grain marker, received [object Object]",
  "name": "Error",
  "stack": "Error: expected grain marker, received [object Object]
    at VMDKDirectParser.parseMarkedGrain (/opt/xo/xo-builds/xen-orchestra-202304010309/packages/xo-vmdk-to-vhd/src/vmdk-read.js:163:13)
    at VMDKDirectParser.blockIterator (/opt/xo/xo-builds/xen-orchestra-202304010309/packages/xo-vmdk-to-vhd/src/vmdk-read.js:197:17)
    at generateBlocks (/opt/xo/xo-builds/xen-orchestra-202304010309/packages/vhd-lib/createReadableSparseStream.js:119:22)
    at iterator (/opt/xo/xo-builds/xen-orchestra-202304010309/packages/vhd-lib/createReadableSparseStream.js:142:5)"
} 

Any ideas what's malfunctioning? I'm using the latest CE build - 8a07b
It's been doing this for the past few builds (been trying for a few days updating thinking it was maybe being fixed in the most recent build).

Thanks

Tony

@julien-f Thank you!!!! Just applied and so far, so good.
I assume that also screwed with the stats because they are now working again....

Much appreciated!