XCP-ng 8.2 LTS and 8.3 for Dell PowerEdge – Maintaining Dell System Update (DSU) for Linux Red Hat Enterprise 7.x (and Variants) in 2025 and Beyond

#Status: Work In Progress – #TODO: clean up and add better formatting; Add a Bash script that will handle all of this

It took me a little bit of effort and research to sort out how to “get back to where I was before” with XCP-ng 8.x on a clean install to a Dell R710 PowerEdge that I recently “refreshed”. Given the age of the R710, it still never ceases to impress me how performant it is when equipped with dual Intel Xeon X5600 series CPUs, 128GB+ of DDR3 RAM and a handful or two SSDs in RAID0 or a Striped ZFS zpool. I added a few NVMe drives to this last R710 I put my touch on. It seems almost timeless. XCP-ng runs on the R710 extremely well, even before I added the L2ARC and ZIL disks. All that said… I was rather disappointed in Dell, as they have made it increasingly difficult to support these older PowerEdge Chassis. We see this with the R710 and soon the R720/R720xd and R730/R730xd, as well. It’s very deliberate and obvious this is “on purpose”, too.

That said, I will not be too extremely critical until there are absolutely no possible avenues to “fresh install” a Linux Red Hat Enterprise 7.x based system like XCP-ng. This particular post will describe a method to get the “last and final” supported updates for RHEL7 and other “EL7” systems that are no longer supported/getting updates. But chances are, that you will get “shocked and surprised” at how difficult a re-install of a familiar OS with all its packages will become – which can make for some difficult and tedious days and nights for troubleshooting and “manually rebuilding and installing” certain packages and repositories that used to be as easy as “sudo yum update -y”. There is also a very good chance that if you are going through an effort like re-installing an older Linux version, rather than restoring from an image, then something has gone very wrong. This is not a great combination for stress levels and timely restoration and uptimes, at all.

There are “not rare enough” situations where you might need to do this. For example, in one of my previous contract roles, I needed a way to run a specific “custom built service” that was designed for a CentOS 7 container. So I needed a way to install this now End-of-Life Operating System and find a path for updating the container as a stop gap until the service was replaced, rewritten, refactored or “backported with Mock” (…). Even more rare of an edge case, you may need to restore from an archived backup.

All that said, the most likely situation where you will use “Dell System Update” (DSU) for Linux Red Hat 7 packages in 2025 though, is for XCP-ng 8.2 LTS or 8.3.

Dell has dropped its support for DSU with the Red Hat Enterprise Linux 7 “Family” since what seems to be August of 2022. So we now have to consider the nearly decade worth of documentation and general web content that shows a younger generation of aspiring Sys Admins, DevOps and Platform Engineers instructions that no longer work as described. You have to dig fairly deep and be somewhat creative and intuitive to both understand how Dell has made your life harder, but not completely eliminated the access to the supporting packages for RHEL7.

See here for more context:

This screenshot is from 2025Q1 at the URL: https://linux.dell.com/repo/hardware/dsu/

The trouble is… after August for 2022, when you execute these commands below, the results are not easily understood and there isn’t any notable update for the documentation…

curl -O https://linux.dell.com/repo/hardware/dsu/bootstrap.cgi && bash bootstrap.cgi

The above command DOES add the Dell System Update Repo GPG keys, but… the paths that are generated in the following gets created repo file are “a road to nowhere” for those running on RHEL7 and variants…
– The baseurl and mirrorlist parameters below mask the issue by making “everything seem fine”. But as you will experience, it is not “fine” at all.
– There are 2 problematic lines in the yum repo configuration (there are 2 repo endpoints in this single file).

(Additional Note: These pgp pubkeys may change in the future, so it might not work to c/p this exact file and path if /when reading this after Dell modifies its keys, so you may need to follow through this doc for “the lightbulb details” if you have this trouble outlined in this post that you haven’t been able to fix yet)

The issue starts here, for every version of DSU expects valid xml that references correct <location href=””$ENCRYPTED_PATH_GOES_HERE”/> tags that are used here this “current and up to date” repomd.xml file:

• https://linux.dell.com/repo/hardware/dsu/os_independent/repodata/repomd.xml

But since mid August of 2022 was the final release that supported RHEL7, there is no longer a valid encrypted path for the “still perfectly installable” DSU instructions. This creates a very difficult-to-understand problem for those that are still using these older OSes.

The version of this file that you actually need for XCP-ng 8.2 LTS and 8.3 is actually here:

• https://linux.dell.com/repo/hardware/DSU_22.08.12/os_independent/repodata/repomd.xml

Note and compare the differences – not that this older file uses sha1 (sha) hashes, and the “latest version” (at the time of this writing) is using sha512 hashes. Also note the “revision” tag near the top (line 2) of both xml docs.

How was I able to track this down in the first place?

Let’s walk one directory back within the URL referenced in the dell-system-update.repo file that was generated by the documented installer script:

• https://linux.dell.com/repo/hardware/

It took me some trial and error, but I sifted through a few of the listed “DSU Versions” until I found the very last version that still included Red Hat Enterprise Linux 7 (RHEL7_64) under the “os_dependent” path, which worked out to be here:

• https://linux.dell.com/repo/hardware/DSU_22.08.12/os_dependent/

Hopefully, this saves you a LOT of time, as I hope to be able to reference and recall my own findings again in the future by referring back to this post as well. (You’re welcome, future self!)

But is it just that simple? Do we just change */dsu/* to */DSU_22.08.12/* in the *.repo file and “yum update -y” and call it a day?

If only things were that simple…

Since Dell often creates these rather complex problems that are “solvable… but… not obvious or intuitive” while deliberately dropping support for its older platforms like the R710 (11th Gen) and R720 (12th Gen), there is a high likelihood that Dell will continue to deliberately create these challenges for its future platforms as well. Is this just a design flaw in the repo system Dell as created, and “accidentally” dropping previous functions as it quits supporting OSes before the End of Life dates, like it did with RHEL7?

• RHEL7 was dropped by Oracle in mid-2024, not in mid-2022 when Dell removed it from the DSU
• Dell could have included a “legacy parameter” in the xml for this DSU after “22.08.12”, but did not
• Dell could have created a far more obvious “legacy path” – even if they deliberately avoided allowing for it to continue to be as simple as “yum install dell-system-update -y”
• Furthermore, Dell could have added an output to signal to the user that they were using a legacy system that is no longer supported in the “original and still actively used” url and install script (its a common courtesy other devs for other projects often provide users)
• Its most likely a simple case of bad practice and a lack of consideration to legacy systems users, but at least there is still a “path” available, without having to recreate a self-hosted repository or some similar extreme
• This does beg the question of “what if Dell stops hosting these legacy files, completely?” – To be (extremely generous and) fair, once XCP-ng finally upgrades to a later Linux kernel that uses a more modern base Linux OS, which should be XCP-ng v9+ (which seems very far into the distant future, at the moment)

I mention all this because it might be something that you will want to “custom add” into your own documentation or scripting solutions when providing your servers. This is speaking more broadly now for future “mismatched OS and DSU version bugs” from Dell.

Note that if you have already ran the “documented installer *.cgi file via bash, you will need to also clean your yum cache first before making the “downgrade” to the earlier DSU version (This is a serious “gotcha!”).

# ### TODO: Create a a bash script that installs that corrected version of DSU by via simple uname -r check that contains:

• “clean yum cache”
• conditional statement for checking if XCP-ng is installed via kernel version 4.19.0+1 (or similar OS/Platform)
• “sed” for replacing */dsu/* with */DSU_YY.MM.DD/*
• uses correct –enablerepo=$repo_name_1,$repo_name_2,…$repo_name_n
• more…

For now, let’s do this “manually”, since its late and I’ll have to improve this later (“make it work, but improve later”)

Use the following file content for the file /etc/yum.repos.d/dell-system-update.repo for XCP-ng 8.2 LTS and 8.3 on Dell PowerEdge systems (True for all Dell PowerEdge chassis) == vi /etc/yum.repos.d/dell-system-update.repo

This is a rough outline of the troubleshooting and details for the fix – quick and dirty – will update with a script (eventually) – but this should be enough to solve your immediate problems, if you know what you are doing (and my SEO skills are still in point).