@ovicz Yes, it's loaded lsmod | grep i915 i915 5373952 0 i2c_algo_bit 20480 2 xe,i915 drm_buddy 32768 2 xe,i915 video 81920 2 xe,i915 ttm 135168 3 drm_ttm_helper,xe,i915 drm_display_helper 331776 2 xe,i915 cec 106496 3 drm_display_helper,xe,i915 dmesg starts the same as your output, the only difference is that I have GuC disabled. dmesg | grep i915 [ 1.609000] i915 0000:00:08.0: [drm] Found alderlake_s (device ID 4690) integrated display version 12.00 stepping C0 [ 1.609986] i915 0000:00:08.0: [drm] VT-d active for gfx access [ 1.610073] i915 0000:00:08.0: [drm] Using Transparent Hugepages [ 1.611342] i915 0000:00:08.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x4556 [ 1.611345] i915 0000:00:08.0: [drm] Failed to find VBIOS tables (VBT) [ 1.612136] i915 0000:00:08.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=io+mem [ 1.614455] i915 0000:00:08.0: [drm] Finished loading DMC firmware i915/adls_dmc_ver2_01.bin (v2.1) [ 3.583673] i915 0000:00:08.0: [drm] [ENCODER:261:DDI A/PHY A] failed to retrieve link info, disabling eDP [ 3.605422] i915 0000:00:08.0: [drm] GT0: GuC firmware i915/tgl_guc_70.bin version 70.49.4 [ 3.605426] i915 0000:00:08.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3 [ 3.615402] i915 0000:00:08.0: [drm] GT0: HuC: authenticated for all workloads [ 3.615410] i915 0000:00:08.0: [drm] GT0: GUC: submission disabled [ 3.615414] i915 0000:00:08.0: [drm] GT0: GUC: SLPC disabled [ 3.616508] i915 0000:00:08.0: [drm] Protected Xe Path (PXP) protected content support initialized [ 3.617330] i915 0000:00:08.0: [drm] Registered 4 planes with drm panic [ 3.617354] [drm] Initialized i915 1.6.0 for 0000:00:08.0 on minor 1 [ 3.627390] i915 0000:00:08.0: [drm] Cannot find any crtc or sizes [ 3.637349] i915 0000:00:08.0: [drm] Cannot find any crtc or sizes [ 3.657358] i915 0000:00:08.0: [drm] Cannot find any crtc or sizes Having edited /etc/modprobe.d/i915.conf by adding options i915 enable_guc=3 enable_huc=1 fixed the GuC part as well, however I still have the same issue. Cannot find any crtc or sizes is the only part which is not in your output. /etc/default/grub is clean, I don't have NOMODESET: cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/root rhgb quiet" GRUB_DISABLE_RECOVERY="true"

@shinuza The version inside the Debian image and the version on GitHub may be different. It is likely that there will be more recent versions on GitHub. Just don't select a version and the latest version from the Debian repository will be installed. const k8sInstall = k8sVersion !== undefined ? `apt-get install -y kubelet=${k8sVersion} kubeadm=${k8sVersion} kubectl=${k8sVersion}` : "apt-get install -y kubelet kubeadm kubectl";

Depends on what you expect from "manage", but once a template is deployed (or recipe applied), it's all regular VMs.

Just updated to lastest commit https://github.com/vatesfr/xen-orchestra/commit/4bd5b38aeb9d063e9666e3a174944cbbfcb92721 It's fixed now. Working wonderfully. Thanks! [image: 1683882828176-603fbea0-1c07-45b8-a005-54c100a74663-image.png] 0 fbeauchamp committed to vatesfr/xen-orchestra fix(backups): fix health check task during CR (#6830) Fixes https://xcp-ng.org/forum/post/62073 `healthCheck` is launched after `cleanVm`, therefore it should be closing the parent task, not `cleanVm`.

@julien-f said in XOA Proxy Error when updating: @bullerwins XO Proxy Appliance deployment is not supported in XO built from sources. my bad, it used to work a few months back I believe @olivierlambert said in XOA Proxy Error when updating: I missed that in the original message, indeed FYI @bullerwins there's no such thing as XOA built from sources, you have either: XOA is Xen Orchestra virtual Appliance, that's the VM we distribute with pro support and QA/stable channel, updater and such XO from the sources is from Github, without pro support but community support, no QA no stable version, no udpater and such Thanks, I got confused with the naming, I'm using the second option. As a workaround I used a VPN to manage the remote XCP-ng host, thanks!

We made the proxy with the smallest attack surface possible, so I would say it's pretty safe. But indeed, and as usual, it's a perpetual balance benefits and costs