Since August 7, it has not been possible to upgrade FlashSystem systems currently running pré-9.1.0 codes to any of the 9.1.0.x LTS versions available on the portal. The restriction is enforced by Upgrade Test Utility v51.1, through the SVAPAR-217342 alert, which appears to be related to certificates or certificate chains.

In practice, for almost ten days now, systems with maintenance windows already scheduled for upgrades from 8.7.x to 9.1.0.x have been left waiting for a solution. The same applies to newly delivered systems that arrived with 8.7.0.x firmware and need to be upgraded to 9.1.0.x before they can be placed into production.

At this point, it appears that we are waiting either for an iFix for 9.1.0.7 or for a new patch level that resolves the issue. However, based on the publicly available information - and even after opening a support case - I still have not been able to clearly understand the exact technical condition that caused the upgrade to be blocked.

That level of detail would be particularly useful. If we knew exactly which scenarios are affected, we could at least evaluate possible workarounds for environments that are not exposed to that specific condition, including, where technically appropriate and supportable, whether an older version of the Upgrade Test Utility could be used.

What concerns me even more, however, is that this does not appear to be an isolated event.

In recent releases, we have seen issues and limitations affecting very mature and long-established platform functionality. One example is SCSI Persistent Reservation, where I had systems running 9.1.0.4 affected during a simple volume UNMAP operation by the issue documented under SVAPAR-191039.

I also encountered another SVAPAR - I do not recall the number right now - related to the amount of time Ethernet ports took to come back online after a node reboot, something that obviously occurs during a normal upgrade process. If I remember correctly, one of the recommended workarounds even involved physically removing certain adapters to avoid triggering the issue.

Individually, software defects can happen on any platform. What is becoming concerning is the frequency and, more importantly, the nature of these regressions.

We are talking about issues affecting functionality that has existed for many years and was previously considered mature and reliable. When changes introduced in newer firmware cycles begin causing regressions in these established areas, it inevitably starts to undermine confidence in the upgrade process itself.

This is especially important for LTS releases, where the primary expectation should be stability, predictability, and lower operational risk.

Perhaps it is time to reassess the development and validation methodology for these release cycles, with a stronger focus on preserving the behavior of mature functionality in LTS releases, while keeping more extensive changes, new features, or architectural modifications primarily in non-LTS release streams until they are sufficiently proven and stabilized.

I sincerely hope this recent sequence of issues is being reviewed by IBM engineering, because the impact goes beyond the individual defects themselves. It is beginning to affect administrators' confidence when deciding whether to upgrade production environments, many of which support critical workloads.

And, of course, I also hope that an iFix or a new patch level addressing SVAPAR-217342 is made available as soon as possible so that the upgrades currently being blocked can finally proceed.