Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    gduperreyG
    Thank you everyone for your tests and your feedback! The updates are live now: https://xcp-ng.org/blog/2026/08/18/august-2026-updates-1-for-xcp-ng-8-3-lts/
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    Coming back to this with what the distros actually ship, because "the fix is upstream" turned out not to mean much on its own. The commit is f24df84cbe05. I checked each distro by grepping kernel/time/jiffies.c at the version they ship, rather than comparing version numbers, since some of them cherry-pick. Already fixed, nothing to do: Fedora 44: 7.1.8 Alpine 3.22: linux-virt 6.12.103. Alpine 3.23 and edge: 6.18.44 Not fixed in what you get today: Debian 13: trixie ships 6.12.94, which doesn't have it. 6.12.100 and 6.12.101 do, and they're in trixie-proposed-updates, so it should land with the next point release. Ubuntu 26.04: -updates moved to 7.0.0-30 this morning and that doesn't have it either. 7.0.0-31 does, sitting in resolute-proposed, expected early September. Rocky 10 I couldn't settle. I don't see it in the CentOS Stream 10 kernel changelog, which does list per-commit subjects, and Stream is at 6.12.0-260 while @henri9813 is on the 10.2 branch at -211. So probably not yet. But I might just be failing to find it, so if someone can check properly I'd rather be corrected. @acebmxer @MajorP93 on Debian, and anyone on Ubuntu: keep tsc_mode=2 and nomigrate for now. One thing that won't help you there, the console=ttyS0 removal from the other thread is an Ubuntu cloud image thing. Debian's cloud image recipe only sets a serial console for Azure, EC2 arm64 and ppc64el, so I don't think the generic amd64 image carries it. Worth a look at /proc/cmdline on yours though. I did check that the fix works rather than assuming it: same VM, Ubuntu 7.0.0-30 against 7.0.0-31, and the sched_clock correction went from about -59s to -0.4s on 6 vCPUs.
  • 3k Topics
    29k Posts
    D
    Hey that sucks after catching up 23 commits. Looks like something broke in the log module during the update. I’d try a clean reinstall of the dependencies first, or drop back to an older Node version for a bit – Node 24 can be fussy with these packages.
  • Our hyperconverged storage solution

    50 Topics
    796 Posts
    olivierlambertO
    Great, thanks for the feedback!
  • 37 Topics
    135 Posts
    AtaxyaNetworkA
    Pour l'ISO montée deux fois : My bad, j'ai ajouter un truc en trop sur mon précédent fix. Une PR est en cours pour corriger ça. Pour le problème principal : J'ai identifié la cause, mais je n'ai pas encore de solution. Sans les drivers Xen (non initialisés avant l'installation), une VM est limitée à 4 périphériques. La séquence de boot ne peut donc pas détecter le second disque contenant le fichier Kickstart (ks). Côté Packer, on semble être bloqués par cette contrainte XCP-ng. Les seules alternatives actuelles seraient de se limiter à : 2 disques + 2 CD ou 3 disques + 1 CD + HTTP (Note : L'installation manuelle fonctionne car l'installateur démarre directement, avec le driver xen_blkfront, alors qu'avec Packer, l'injection de notre fichier interrompt le flux de démarrage classique). Je vais fouiller encore un peu, mais sans certitude d'un contournement possible. (et je regarde pour ajouter le CDlabel)