Tested on a clean Joomla 5.4.5 → 6.1.0 upgrade with a multilingual setup.

Steps performed:

• Installed multiple languages (French, German, Spanish)
• Verified language update sites are enabled and pointing to translationlist_6.xml
• Rebuilt update sites and cleared cache
• Checked updates multiple times

Result:
No error appears. Updates are fetched correctly and the system behaves as expected.

Conclusion:
Unable to reproduce the issue in this environment. It may be related to specific server configurations, cached data, or legacy database entries after migration.
@Valentyn-M Could You help me to reproduce the bug by giving some hints.

Thanks for testing.

Important clarification: this is probably not a Joomla 6.1 migration-only issue.

I can confirm that the same red error was already present on my site before the upgrade, while it was still running Joomla 5.4.x. After upgrading to Joomla 6.1.0, the same behaviour remained.

So the issue seems to be older and not strictly caused by the 5.4 -> 6.1 migration itself.

Another important hint:
the problem reproduces not only on the production server, but also on a local restored copy of the same site.
That suggests it is likely related to the specific site data / multilingual setup / update-site state, not only to the hosting environment.

What I already tested:

• rebuilding update sites
• clearing Joomla cache
• manually reinstalling/updating language packs
• enabling/disabling the official language update sites

Result:

• when the official language update sites are enabled, Extensions -> Update shows the red error
• when those language update sites are disabled, the red error disappears

So a clean Joomla install may not reproduce it, but an existing multilingual site with older data does.

If useful, I can provide more exact details from the affected site state and test additional scenarios you suggest.

Yes please.

What exact additional information would be most useful for you to reproduce this issue?

For example, I can share:

• specific screenshots,
• the exact language/update-site configuration,
• database rows related to update sites,
• debug output,
• or results of any particular checks you would like me to run.

Please let me know what would help most.

Thanks! To help reproduce this, could you please share:

• The debug error output (with Debug System enabled)
• The exact language update site URL(s)
• Whether the issue happens for all languages or only specific ones

This should help identify the failing condition.

Thanks. Here are the requested details.

1. Debug error output (with Debug System enabled)
   I enabled Debug System and reproduced the issue again on the affected site.
   In browser DevTools -> Network, the Extensions -> Update page request returns 200, but the response still contains the Joomla red error message: "Could not fetch update information, enable system debug mode for further information."
   I also checked the Joomla Debug Bar / Queries tab, but it does not show an obvious SQL exception. I am attaching screenshots of the page, the Network response, and the debug output.

2. Exact language update site URL(s)
   The official language update sites on this affected site point to: https://update.joomla.org/language/translationlist_6.xml
   This is shown under: System -> Update Sites -> Accredited Joomla! Translations

3. Whether it happens for all languages or only specific ones
   On this affected site, the issue is not limited to one specific language.
   It appears whenever the official Accredited Joomla! Translations update-site group is enabled.
   In my current Update Sites list, this affects the official language update entries present there:
   Dutch, English, French, German, Polish, Russian, Spanish, and Ukrainian.
   Swedish is installed on the site, but it does not appear there as a separate official language update-site entry.

response-update-page.txt

swedish does not appear because the manfiest file is missing the update server information in the file administrator\manifests\packages\pkg_sv-SE.xml

	<updateservers>
		<server type="collection" priority="1" name="Accredited Joomla! Translations">https://update.joomla.org/language/translationlist_6.xml</server>
	</updateservers>

@tecpromotion can look at fixing that bug

However after installing all the languages you have installed I cannot replicate the reported problem when checking for updates on the other languages. I do see in your screenshot that you are getting a 303 redirect to something called speculationrules - I am guessing but maybe thats some cdn thing

Thanks, I checked that part more carefully.

The earlier speculation entry in DevTools was misleading because I had Preserve log enabled in Network.
After disabling Preserve log and testing again, that speculation request disappears from the fresh request list.

So the remaining 303 is not a redirect to speculationrules.
It is the Joomla request:

index.php?option=com_installer&task=update.find...

which returns 303, and then redirects back to:

index.php?option=com_installer&view=update

with 200.

The red Joomla error still appears in this clean test.

I also tested with Cloudflare Speed Brain disabled, and the problem still remains.
So at this point it does not look like the speculation / Cloudflare Speed Brain request is the cause of the Joomla update error.

Current language update site URL for all installed language packages is:
https://update.joomla.org/language/translationlist_6.xml

The issue happens regardless of which of the installed language update sites is enabled.
If at least one official language update site is enabled, the red error appears.
If all official language update sites are disabled, the red error disappears.

If useful, I can provide a fresh screenshot from Network with Preserve log disabled, showing only the real requests from the current test.

Thanks, I checked that part more carefully.

The earlier speculation entry in DevTools was misleading because I had Preserve log enabled in Network.
After disabling Preserve log and testing again, that speculation request disappears from the fresh request list.

So the remaining 303 is not a redirect to speculationrules.
It is the Joomla request:

index.php?option=com_installer&task=update.find...

which returns 303, and then redirects back to:

index.php?option=com_installer&view=update

with 200.

The red Joomla error still appears in this clean test.

I also tested with Cloudflare Speed Brain disabled, and the problem still remains.
So at this point it does not look like the speculation / Cloudflare Speed Brain request is the cause of the Joomla update error.

Current language update site URL for all installed language packages is:
https://update.joomla.org/language/translationlist_6.xml

The issue happens regardless of which of the installed language update sites is enabled.
If at least one official language update site is enabled, the red error appears.
If all official language update sites are disabled, the red error disappears.

Update: Root cause identified and issue resolved locally (Joomla 6.2.0)

Thanks again to everyone who investigated this issue earlier.

I have now identified the root cause on my affected multilingual Joomla installation and successfully resolved it. The investigation was performed against the actual Joomla 6.2.0 code, database, and update libraries.

1. Confirmed root cause

The problem was caused by an inconsistent update-site record in #__update_sites:

This is an XML collection update site, so its correct type is collection, not tuf.

Additionally, #__update_sites_extensions contained an incorrect relationship between this language update site (106) and Joomla Core (files_joomla, extension ID 700).

Joomla Core already had its own valid TUF update site (101, https://update.joomla.org/cms/).

2. Why the errors occurred

Because the language update site had type=tuf, Joomla selected TufAdapter instead of CollectionAdapter.

The TUF client attempted to retrieve TUF metadata from the language XML URL, resulting in requests to nonexistent resources such as:

• translationlist_6.xml10.root.json
• translationlist_6.xmltimestamp.json

Both returned HTTP 404.

A controlled in-memory test using a pre-expiration clock reproduced RepoFileNotFound, consistent with the original generic error:

Could not fetch update information

The affected update site also contained Joomla Core TUF root metadata (version 9), which expired on June 28, 2026. With the current clock, the same incorrect TUF configuration reproduced FreezeAttackException, explaining the newer message:

Update not possible because the offered update has expired

The pre-expiration test was a simulation, not a captured historical exception trace.

The legitimate Joomla Core TUF source was functioning correctly.

When the language source type was changed to collection in memory, Joomla's actual collection adapter successfully processed the official XML catalog and identified available language package updates.

3. Applied fix and verification

After creating a recovery point, I made exactly two changes to the local database in one transaction:

1. Changed #__update_sites.type from tuf to collection for source 106.
2. Removed the incorrect relationship (update_site_id=106, extension_id=700) from #__update_sites_extensions.

All language package relationships and the legitimate Joomla Core source were preserved.

Result: both errors disappeared immediately.

The standard Extensions → Update → Check For Updates operation now works correctly. Language package updates and third-party extension updates are detected normally.

I subsequently updated all available language packages and repeated the update checks successfully.

A final read-only database audit confirmed that the corrected source type, URL, and relationships remained intact after these installations.

4. Why Rebuild did not resolve the problem

The investigation also found that Joomla's update-site rebuild mechanism protects certain core-related sources and does not necessarily reconcile an existing source's type with its manifest declaration.

The incorrect relationship with Joomla Core contributed to the affected source being preserved instead of reconstructed.

This explains why earlier attempts to rebuild update sites and reinstall language packages did not resolve the issue.

Important: I cannot establish exactly when or how the original inconsistent records were created. Therefore, I am not claiming that a particular Joomla migration or core operation originally caused the corruption.

However, the update-site management code may benefit from additional consistency checks, particularly around update-site type validation and multiple update-site relationships involving Joomla Core.

5. Swedish language package issue remains

There is also an update regarding the Swedish language package issue previously identified by @brianteeman.

I inspected the official sv-SE 6.2.0.1 package, downloaded from the Joomla 6 language catalog.

Unfortunately, its pkg_sv-SE.xml manifest still does not contain an <updateservers> declaration.

The package installs successfully, and updates can be discovered through the shared language collection, but the Swedish package still has no direct update-site relationship in #__update_sites_extensions.

For comparison, the previously incorrect Joomla 5 catalog URL in the Ukrainian package has been fixed in uk-UA 6.1.2.1.

It would be helpful if the Swedish package maintainers could add the missing updateservers declaration in a future release.

Conclusion

The original update-check failure is resolved on my affected installation.

The confirmed immediate cause was an XML language update site incorrectly registered as TUF, combined with an erroneous Joomla Core relationship.

I hope these findings help improve Joomla's update-site validation and error handling so similar database inconsistencies can be detected and diagnosed more easily.

Thanks again for your assistance.

Thanks for the update, I close the issue.