Hi everyone,
Thanks for the honest feedback here — losing a straightforward rollback is a fair thing to be annoyed about, especially when an update causes a real regression like the RTX / Nvidia driver problem some of you ran into. Let me clear up what actually changed, and more importantly what your options are.
First, the practical part, because there’s a misconception worth correcting: a downgrade on h6 is not impossible. What changed is that it’s no longer a self-service action in the GUI. If a build causes a problem for you, our support team can still roll your system back to a previous h6 build — it’s handled through Support rather than a button in the interface. So “downgrading is not an option” isn’t quite right: it’s not a one-click thing anymore, but it is a supported path. If you’re stuck after an update, open a ticket and ask specifically for a downgrade.
On the why, since it’s a real change from 5.x: on 5.x and earlier the GUI warned you and then let you downgrade anyway. Starting with QTS 6.0 and QuTS hero h6.0, downgrade — including between minor builds — is no longer exposed in the GUI, and that’s deliberate. Reverting a device to older firmware also returns it to a state with security fixes stripped back out, and preventing that (anti-rollback) is now part of the security requirements we have to meet under the EU’s new cybersecurity regulation — the Cyber Resilience Act — that is now being phased in. Handling downgrades through an assisted support process, rather than a one-click GUI action, is how we meet that requirement while still being able to get you back on your feet when a build genuinely misbehaves.
None of that makes the inconvenience less real. The point several of you made — that production environments need a dependable way back — is legitimate, and we’re taking it back as product feedback. We’re sorry you’ve run into trouble on 6.x — please reach out to our support team, and we’ll do our very best to help you.