XCP-ng 7.5.0 final is here

olivierlambert

Hey guys!

Just before the official announcement tomorrow, please double test our latest ISO: https://xcp-ng.org/7.5/xcp-ng-7.5.0.iso

md5sum: 33adb5d92f56fe6cda0df047f2f60895

Nothing really changed since RC1 (except very few stuff).

Aleksander

Congratulations to the whole team for the release of the new version XCP-NG 7.5.
Great job.

Aleksander

olivierlambert

Well, technically everything will be announced officially tomorrow

stormi

Also, don't use it now, it's broken (my fault!)

DustinB

@stormi said in XCP-ng 7.5.0 final is here:

Also, don't use it now, it's broken (my fault!)

Yeah. . . "Error installing packages"

olivierlambert

Fixed, new ISO incoming!

DustinB

@olivierlambert is the ISO link updated?

olivierlambert

@stormi will tell you when it's up (with the new md5sum)

stormi

It's fixed at last! Same link as before, MD5SUM is c377ccc342bc9f0b96f02c66132c132a

There was a bug that was my fault (wrong product name in configuration files), but not the one about the installation failure actually. That one was dormant and already potentially present in XenServer installation ISOs too. There was some RPM that needed /bin/uname in a preinstallation script but in that version of the ISO, it got installed before the coreutils package that contains /bin/uname, so the script would fail and the installer display an error message. I fixed it by adding Requires(pre): coreutils to the package like it should always have been.

Further explanation: how can that happen?

Actually, when a package A requires another package B, it does not guarantee that B gets installed before A. They can be installed in the same transaction and then the order is undefined unless other dependencies are taken into account. That's what happened here. If A really needs B to be present so that it can be used in pre- or post-installation scriptlets, then one must specify it explicitly: Requires(pre): B or Requires(post): B.

sriccio

Awesome! Thanks a lot for your work. Can the update now be done via yum or it's advised to use the standard upgrade procedure (from 7.4.1).

Cheers,
Sébastien

stormi

It can be done via yum but we still consider it safer to use the ISO (because that kind of installation has been tested for a longer time, because it creates a back-up in the back-up partition...).

We'll give the yum upgrade procedure in the announcement.

Nice! that was fast

sriccio

@stormi Okay, crystal clear thanks.

txsastre

Thanks.

Gonna install it from scratch on the 3 develop servers.

dsiminiuk

Used Rufus to install the ISO to USB.
Booted, upgraded pool master from 7.4.
Tried to migrate all running VMs from the 2nd host (server1) to the pool master (server2) to apply the upgrade to server1.
2 VMs wouldn't migrate. Forcibly shutdown, now they are stuck as "Starting VM on server2..." not completing.
1 VM can't start "The operation cannot be performed because the specified virtual disk could not be found."

Upgrading from Xenserver 7.3 to XCP-ng 7.4 was cleaner.

olivierlambert

Double check your shared SR is connected on all host.

dsiminiuk

@olivierlambert It is. Reconnecting all the SRs was the first thing you're presented with after the upgrade. Even the local filesystem and DVD needed to be repaired.

After a reboot and a "PANIC on CPU 0", I did a cold shutdown. All VMs start now except the one that can't find the VDI, yet I can detach and reattach the VDI in XCP-ng Center.

olivierlambert

that's… strange. Could it be a hardware issue? Panic on a CPU is not commong.

GregW

This post is deleted!

dsiminiuk

@olivierlambert The VDIs are over shared ISCSI on FreeNAS VDEVs. There are other VMs with VDIs on the same RAID10 LUN that are running fine.

It's actually 2 VDIs and I moved both (boot and swap) of the failed VM to an alternate RAID5 LUN and it made no difference.

Is there a log I should be looking in to see more detail?