Posts made by yann

@Ajmind-0 this was an install not an upgrade of 8.2.1, right? Was your previous working install of 8.2.1 in UEFI mode?

@Ajmind-0 does it still freeze if you add atexit=shell on the linux commandline? In some error situations the installer attempts to reboot the system after a few seconds, this will make it drop into a shell instead.

@Ajmind-0 there may be more details in the log a bit before those last lines, and they would not be visible because of the screen size and volume of logs. You can switch to the console with a shell and have a look into /tmp/install-log, there may be some more useful info in there.

@Tristis-Oris I also reproduced the issue on 8.2.1, and record the issue. As for your pool left in a tricky state, would it be reasonable for you to reinstall the impacted hosts?

@Tristis-Oris and with a 3-host pool I can reproduce you issue on 2nd attempt: new master loses its xapi process

When the master is changed, the xapi service is stopped and then restarted but something seems to get wrong this time.

Among issues I realize that my former-master shows this at the time of the failing switch:

Oct 14 15:20:50 xcpng83-bzkcpvhy xsh: [ warn||0 ||xsh] TLS verification is disabled on this host: /var/xapi/verify-certificates is absent

(while both other hosts do have that file)

daemon.log on new-master shows systemd desperately trying to restart xapi:

Oct 14 15:20:59 xcp-ng-hqerhcgv xapi-init[1244028]: Stopping xapi: [  OK  ]
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Unit xapi.service entered failed state.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: xapi.service failed.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: xapi.service holdoff time over, scheduling restart.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Cannot add dependency job for unit lvm2-activation.service, ignoring: Unit is masked.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Cannot add dependency job for unit lvm2-activation-early.service, ignoring: Unit is masked.
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Starting XenAPI server (XAPI)...
Oct 14 15:20:59 xcp-ng-hqerhcgv systemd[1]: Started XenAPI server (XAPI).
Oct 14 15:20:59 xcp-ng-hqerhcgv xapi-init[1244047]: Starting xapi:
Oct 14 15:21:00 xcp-ng-hqerhcgv systemd[1]: xapi.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Oct 14 15:21:00 xcp-ng-hqerhcgv xapi-init[1244078]: Stopping xapi: [  OK  ]

and xensource.log is very similar to yours. Congrats, that's a nice bug

@Tristis-Oris Oh OK. Had a try to run it several times myself (though on a 2-host pool), and I was able to see the operation performed twice, though apparently the second op did finish.
Running from the shell, if launch a second xe pool-designate-new-master while the first has not returned yet, it gets a DESIGNATE_NEW_MASTER_IN_PROGRESS error, but once it has returned there seem to be a window to do strange things.

@Tristis-Oris very strange, your log seems to show that 2 designate_new_master requests were handled one after the other (at 12:11:33 and 12:12:45), both to switch to the same host - and we see in the logs that while the 1st one got all phases executed (1, 2.1, 2.2), the second one starts to have issues during "Phase 2.1: telling everyone but me to commit". Sending a second request should indeed not trigger the whole thing again, so something apparently went quite wrong, but what is indeed not obvious.

@Tristis-Oris thanks!

I realize one thing is not clear to me: is the "unreachable master" in your situation the one you switched to, or the original master? And how many hosts in total are in this pool when you launch this operation?

The logs we'll need to analyze will be the xensource.log from the first occurrence of designate_new_master on both old and new master, until the time of that exception.

@Tristis-Oris said in XCP-ng 8.3 betas and RCs feedback :

then changed master

Could you please detail that part a bit more? I understand you used XO, but which screen and which action?

@Tristis-Oris Pool_role.This_host_is_broken is a bit scary, and more logs will be needed to understand how it got there. I'm trying to follow the same procedure as you to request the right lines - how exactly did you perform the master change?

@Tristis-Oris is the xapi daemon still running? daemon.log and xensource.log around the time you changed the master could give more insight?

@john-c a rolling-release distro does not have to follow every commit of each software component, that would be a bit extreme They are rather about providing users with latest component releases as they are published.

@kevdog great news, looking forward for this PKGBUILD!
Wouldn't it make sense to build from release packages rather than from Git?

The CI scripts should give you some guidance. For dependencies you should have a list at https://gitlab.com/xen-project/xen-guest-agent#build-requirements. Not sure why you would want python-setuptools?

@kevdog on Linux it really does not care about the interface name, it checks if it is a VIF (see src/vif_detect_linux.rs). On FreeBSD it does filter on the interface name (xn*).

@gb-123 said in XCP-ng 8.3 betas and RCs feedback :

Is that normal? Is it ok to run a cron job for root ?

I´d advise to rather use system crontabs in /etc/cron.d/, one dedicated to each topic you have (but that's rather unrelated to XCP-ng itself, just standard Linux sysadmin practice).

@eb-xcp said in XCP-ng 8.3 betas and RCs feedback :

@yann Never got that far, 8.3 beta 2 would not boot after the install.

Roger that, but when installing beta2, did you select "local" or "http" as package source?

@eb-xcp said in XCP-ng 8.3 betas and RCs feedback :

beta 2 would install, but not boot

Did you use the network to install the packages? I would expect that when getting them from the ISO you should have the same behavior on first boot than when booting the ISO (but obviously, once the packages get upgrade later, that would bring the problem too)

@eb-xcp is it something that also happens with the previous alpha/beta ISOs ?

@sccf that looks really strange. Just made a fresh install with a Debian 12.5 netinstall ISO (disabling any desktop task, only installing the ssh-server one), and I get no such issue

If I understand he question correctly, the requirement is that the snapshot naming convention by ZFS-vol and by syncoid don't collide.
What convention is syncoid using? The current ZFS-vol driver just assigns a unique integer name to each volume/snapshot, and there would be an error when it attempts to create a snapshot with a new integer name that another tool would have created on its own.