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 (2nd draft) – #TODO: clean up and add better formatting; Write a Bash script that will handle most of this;

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 for XCP-ng; some details/ideas:

• “clean yum cache”
• Conditional statement for checking which XCP-ng is installed via kernel version 4.19.0+1 (or other “alt-kernels” used by XCP-ng) and/or simple uname -*** checking
• “sed” for replacing */dsu/* with */DSU_YY.MM.DD/*
• uses correct –enablerepo=$repo_name_1,$repo_name_2,…$repo_name_n
• more…

The Fix That You Probably Came To This Page For:

(For now, let’s do this “manually”, I’ll have to improve this later)

Manually Edit the dell-system-update.repo File (DSU)

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

---

---

After the above “hack” is applied, you should be able to successfully install the Dell specific packages you want for the XCP-ng as your host OS / Hypervisor, such as:
yum install srvadmin-idracadm srvadmin-nvme srvadmin-storage* srvadmin-all

You can see more available packages here: https://linux.dell.com/repo/hardware/DSU_22.08.12/os_dependent/RHEL7_64/srvadmin/

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 on point).

Regarding OSMA, as this final version of DSU for RH7/XCP-ng may not work for your situation: I did find someone else that has already encountered this issue (using a sed substitution command) to resolve this issue for installing Dell’s OpenManage Server Administrator (but the post doesn’t provide any additional details about “why its necessary”) – https://www.hostduplex.com/kb/article/how-to-install-dell-openmanage-on-xcp-ng-8-2/

---

The TL;DR Backstory, In Case Your XCP-ng 8.x or Red Hat 7.x OS on a Dell PowerEdge Chassis is a Production Environment and You Need More Context for Your Documentation

Important Links / URLs:

• https://linux.dell.com/files/supportmatrix/RHEL_Support_Matrix.pdf
• https://www.dell.com/support/manuals/en-us/red-hat-entps-lx-v7.0/rhel7_ig_pub/installing-or-reinstalling-red-hat-enterprise-linux-7
  • Note the lack of any warning or further instructions
• First mention from the Community I could find for acknowledgement of this issue: https://www.dell.com/community/en/conversations/systems-management-general/has-centos7-support-just-been-removed-for-dsu/647f9ff3f4ccf8a8de4e3429
• 1
• This awkward situation with the Dell Rep and the community (lots of these to be in this forum…) for how to install OMSA 10.2+ on Red Hat 7: https://www.dell.com/community/en/conversations/poweredge-hardware-general/where-is-omsa-10200-or-omsa-10300-for-redhat/647f9ebcf4ccf8a8de364fbb

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.

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 apparently dropped its support for DSU with the Red Hat Enterprise Linux 7 “Family” from its “it-just-works with default yum update”, since around 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 (above) 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 that are still supported (some even as “LTS”) by the vendor and/or OSS community.

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 – notice that this “older version” 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.

(Left side is “the one we need” – Right side is “the one that is installed by default”)

Assuming you see the issue, now that I’ve explained it, you might be asking: “How would you ever be 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?

Unfortunately… No…

More About Dell’s Engineering History With Critical Software Updates

Dell has been known to make sweeping changes to its back-end systems that often breaks the “integrated” and sometimes “automated” functionality for a variety of its 3 or 4+ previous generations of server chassis… We are seeing this here with Red Hat 7, as how it was not added or included in the DSU repo configuration after mid-2022.

You will also note that there is no changelog, no “heads up”, no “here is a work around”. Just *poof*, gone. Broken.

Nothing from Dell, officially, in the documentation for DSU.

What this also likely means, is that suddenly one day, during a “server refresh” or a typical yum update, it all just “broke”. This would most likely get “discovered” during the execution of an installation script for XCP-ng (eg: unattended install), or a “fresh install”. In any case where it would be discovered, it would be like “being blind-sided” with the additional and unexpected efforts to resolve this issue.

This lack of basic customer etiquette is a “breaking change” without even a hint as to what is happening with the abrupt cutoff of support. While this would not be as major of a “showstopper” issue for systems that were already up and running since the services and package files from the final update would still be present on the system, it would still cost customers time and money. It will create some messy logs, extra workaround commands to the broken yum packages and a few thousand collective hours of troubleshooting for on-the-clock engineers, which is very expensive for Dell customers. To play devil’s advocate, only a portion of PowerEdge customers are likely running Red Hat 7. But the market share for Linux the Server-centric Distributions that use the Red Hat 7 upstream yum / EPEL package management is

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/customers)
• 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. So it’s most likely that Dell is just inconsiderate, rather than its Engineering Leadership is being malicious, here.

For its customers that are using Linux Red Hat 7 or XCP-ng, though, this issue that we have outlined in this post is literally costing its customers a great deal of time and money (and engineering headache). Consider that ALL of the Dell Server platforms and ALL of every single last one of Dell’s chassis and model numbers are causing this issue, and will continue to do so, forever. Also consider that the only documentation for how to resolve this problem for these still-supported (re: Not End-of-Life) Hypervisor-centric OSes is coming from “the community”, and not the Dell Engineering team. (Hence why I’ve done my best to create this page, which has already seen an impressive number of page views, as I edit and revise it with your feedback.)

• The old adage of “Never attribute to malice what can be attributed to stupidity” is more than like the case here, as Dell has performed very poorly in comparison to its competitors since “losing its way” nearly a decade ago.
• One of Dell’s largest competitors, SuperMicro (SM), has provided better support for its community of “home lab enthusiast”, which are often either already industry professionals or future industry professionals that will have influence in purchasing decisions in the future. SM is now reaping the rewards from that effort, in the recent years.

• 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 more broadly related to future “mismatched OS and DSU version bugs” from Dell and other OSes it may decide to drop early without any regard for its customers or community, as we see was done with Linux Red Hat 7.x.