Is that really the complete log? If so, then the update has started and then nothing happened, no database updates were run.

Is that really the complete log? If so, then the update has started and then nothing happened, no database updates were run.

Yes, this is the last content of the /log/joomla_update.log file

Is there another location with a more detailed file?

Is there another location with a more detailed file?

No, that’s the only one, and if that doesn’t show anything then nothing happened.

Do you have a backup from before the update? If so, restore that backup and then try the update again, but make sure to have error reporting set to „None“ in Global Configuration before starting the update.

Now I have deleted DB manually and recovered Akeeba backup with Kickstart and now it gives me the error: 0 Cannot instantiate abstract class Joomla\Module\Login\Administrator\Helper\LoginHelper

P.S.: There is not a single time I want to update my Joomla that I don't have problems. :(

Does it help if you delete the file administrator/cache/autoload_psr4.php? It should be recreated again after a page reload. Maybe the restoration of the backup did not include that file so there is still the 5.1 version.

Does it help if you delete the file administrator/cache/autoload_psr4.php? It should be recreated again after a page reload. Maybe the restoration of the backup did not include that file so there is still the 5.1 version.

No, same result.

Then something else went wrong with restoring that backup. As you said you have used an empty database to restore it, right? Have you also used an empty folders so that no 5.1 files were left

Then something else went wrong with restoring that backup. As you said you have used an empty database to restore it, right? Have you also used an empty folders so that no 5.1 files were left

I had not deleted the entire directory. I just restored having deleted everything (directory + database) and this worked!

I now have my site back in 5.0.3

Any recommendations for updating and not "breaking" anything? Or do I wait for a better time to see if they release any more updates?

Thanks!!!

As I said before, switch error reporting to „None“ in Global Configuration and then try again to update. If that fails again, you now know how to properly restore a backup.

As I said before, switch error reporting to „None“ in Global Configuration and then try again to update. If that fails again, you now know how to properly restore a backup.

I have done what you tell me and now when I update I receive the following error:

An error occurred
The Joomla updater cannot communicate correctly with the file that is responsible for carrying out the update administrator/components/com_joomlaupdate/extract.php. This usually occurs for one of the following reasons:

The file administrator/components/com_joomlaupdate/update.php, which contains the update instructions to be applied, cannot be created. For example: due to permission problems.
The above mentioned file cannot be read by the extract.php script due to permission issues.
Your browser, network equipment, or server is corrupting the password we send with each request to extract.php for security reasons.
Please try using a different browser, without any browser extensions installed, ideally on a different computer connected to the internet and using a different provider. If the error persists, you may want to contact your hosting provider.

Well then check the permissions of the administrator/components/com_joomlaupdate, and if there is a file named update.php, delete that file. Check also if the downloaded zip file is still in the tmp folder and if it is there, delete that too. Then try again.

If all that doesn’t help, someone else should step in because I need sleep soon and tomorrow have a long working day in my regular job.

If all that doesn’t help, someone else should step in because I need sleep soon and tomorrow have a long working day in my regular job.

Same result.

That's what I'm going to do.
I have restored backup again and see if anyone else can help.

Thanks @richard67

P.S.: There is not a single time I want to update my Joomla that I don't have problems. :(

This tells me that at some point you had an upgrade that was not complete and ever since then you have been updating a broken install. No ammount of backups and restore will resolve that.

P.S.: There is not a single time I want to update my Joomla that I don't have problems. :(

This tells me that at some point you had an upgrade that was not complete and ever since then you have been updating a broken install. No ammount of backups and restore will resolve that.

Could be. I had a lot of problems updating my old v3 but very recently we managed to clean up unnecessary extensions and managed to update to v4 and then v 5.1 without problems (at least apparently).

It is true that I did not create this Joomla and it had countless unnecessary plugins before that I eliminated and cleaned.

I don't know how I could find any trace of a previous bad update, if that's what might be causing me problems now. In the meantime, if not, I think we'll have to wait and see if there is more feedback on this upgrade.

Not tonight as I am going to sleep but in the coming days, I am willing to help you over a Google Meet to try to check out what's happening etc.

I had the same issue, (with the resulting 0 Cannot instantiate abstract class Joomla\Module\Login\Administrator\Helper\LoginHelper error).

Issue was that the files on your site where upgraded, but your database due to restore are still on 5.0.3.

The error thrown comes from the guided tours that tries to execute on first login but cannot complete because the database is missing a field.

When you turn on maximum error logging in configuration.php you will see what file the error comes from.

You need to comment out the guided tours lines that cause the error. Then you can login.

DO NOT repair your database as that will indeed repair your database but render you interface useless as then all extensions miss the save / save & close etc. toolbar...

You need to go to the Joomla update and upload the Joomla 5.1 upgrade file and install that: then all files are again copied and your database is upgraded correct.

That fixed it for me.

Sorry that I do not have the detailed steps / filenames etc.

Hope this helps.

@sergio-scl were you able to use @Ruud68's advice/instructions to fix things?

I had the same issue, (with the resulting 0 Cannot instantiate abstract class Joomla\Module\Login\Administrator\Helper\LoginHelper error).

Issue was that the files on your site where upgraded, but your database due to restore are still on 5.0.3.

The error thrown comes from the guided tours that tries to execute on first login but cannot complete because the database is missing a field.

When you turn on maximum error logging in configuration.php you will see what file the error comes from.

You need to comment out the guided tours lines that cause the error. Then you can login.

DO NOT repair your database as that will indeed repair your database but render you interface useless as then all extensions miss the save / save & close etc. toolbar...

You need to go to the Joomla update and upload the Joomla 5.1 upgrade file and install that: then all files are again copied and your database is upgraded correct.

That fixed it for me.

Sorry that I do not have the detailed steps / filenames etc.

Hope this helps.

This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43328.

Hello, sorry for not answering sooner but I haven't been able to take a moment to deal with this.

I have activated the log to maximum detail and I have gotten the same error when updating:

Now therefore when I enter the Joomla update I receive the following error:

An error has occurred.
1146 Table 'ddb69566.anvgy_tuf_metadata' doesn't exist

And the components in red do not work on the dashboard:

@exlemor @Ruud68

After you received the error message did you follow the advice in the message.

I checked permissions, that wasn't it. I tried in other browsers and neither.
I don't know what more tests to do.
I have also not seen any message appear when the error log has been changed to the maximum.

@sergio-scl Maybe you have for some reason a modified .htaccess file with additional security rules, and that is from 4.0 times to it doesn’t allow to access the extract.php file? Could you check your .htaccess file if the thing described on this page https://docs.joomla.org/Htaccess_changes_after_joomla4.0.4 applies to it?

Same problem here and on multiple sites according to Dutch Joomla forum. But different error. I can even reproduce it on a clean 5.1 install.
TUF Debug Message: Syntax error
JROOT/libraries/vendor/php-tuf/php-tuf/src/Metadata/MetadataBase.php:90

@Pinkeltje as you can reproduce it then this is very useful information. Can you please post firther information on your server or probably more useful are you avle to provide access to the server so that this can be debugged on a server where the probelm is reproducible

@brianteeman
Attached you'll find server information.
systeminfo-2024-05-15T09 13 25+02 00.txt
Can give you access later today. Please advise as how to get credentials to you safely.

@SniperSister I guess you are the correct person to look into this. At least with a server that the issue is reproducible on it should help.

@Pinkeltje You can use the secure form https://developer.joomla.org/security/contact-the-team.html unless @SniperSister suggests otherwise.

Thanks in advance

@brianteeman @Pinkeltje the retrieval of the timestamp file from the CDN was malfunctioning, the error should be resolved already. Could you please retry?

@SniperSister Are we able to provide a better. more relevant and informative error message in this scenario?

See #43477

@brianteeman @Pinkeltje the retrieval of the timestamp file from the CDN was malfunctioning, the error should be resolved already. Could you please retry?

Retried and everything ok now. Users on Dutch forum also mentioned that it was ok now.

The Google search for "Could not load root metadata" (and @brianteeman) led me here.
I also have an issue with one of my sites (5.1.0 with PHP 8.2.18) which I can not solve or explain.
Everything looked normal until I clicked on the "Joomla ist aktuell" button in the backend, because I wanted to look if I had set the correct update channel. Then the error appeared and I have no chance to see or change the update channel since.
After that the 4 buttons "Backup", Overrides", Extensions" and "Anfragen" turned red.

Everything in the frontend seems to work as usual.
I´m not very familiar with debugging but if you explain what to look for, I will try to give all information to help investigation.

I honestly also didn´t understand what helped @Pinkeltje to solve it.
Should I simply wait for the next Joomla update and will it be solved then?

Regards from Cologne
Martin

@Martin511: I didn't solve anything. It was caused by this:

@brianteeman @Pinkeltje the retrieval of the timestamp file from the CDN was malfunctioning, the error should be resolved already. Could you please retry?

@Martin511 please check the content of the #__tuf_metadata table in your database, it seems to be corrupt. If in doubt, overwrite it with the original data from the installation.sql:

https://github.com/joomla/joomla-cms/blob/5.1-dev/installation/sql/mysql/base.sql#L892

@SniperSister Thank you for this hint - MySQL returned an empty result (i.e. zero records). So this table seems to be empty if I understand this correct.
But I really don´t know how and what to overwrite. I don't have enough skills for that.
I am able to restore a whole database but I need something like a step-by-step manual to overwrite a database table as I did that never before.
Do you know any good tutorials I can read?

@Martin511 Run the query @SniperSister points to in phpmyadmin and replace #__ with your own table prefix.

@Pinkeltje Thank you, but I don´t know how to do this. Sorry.

Hi @Martin511, if you connect with me on Mattermost (or Skype) etc, I can take 15 minutes via video-conference/screen sharing and help you get that done.

Hi @Martin511, if you connect with me on Mattermost (or Skype) etc, I can take 15 minutes via video-conference/screen sharing and help you get that done.

Hey @exlemor , that would be great!
May I invite you to a Nextcloud Talk call?
What time do you prefer?

Assuming a NextCloud Talk call can be done via a web browser, sure... anytime you want between now and midnight CET/Paris hours.

www.worldtimebuddy.com for timezone conversions. ;)

Ok, can you provide an email address to send the invitation link to?

Sent to your info@ company address !

@exlemor Thank you very much Emmanuel!!
@SniperSister Yes, overwriting the #__tuf_metadata table solved it. Thank you.
What leaves the question, why this happened. What corrupted the database table?
There are probably thousands of possibilities...

@Martin511 was the site updated to 5.1 recently? Any issues during the update?

@SniperSister Hi David, yes and yes.
I don´t know if my problem is linked with this but in the last months I used Panopticon to manage my sites.
After some issues I disconnected and uninstalled all sites to see what happens with the next regular Joomla update.
If you want to dig into this, see: akeeba/panopticon#588

The data in the tuf table is written on update, if the update isn’t performed correctly, you’ll end up with exactly the scenario that you described here.

Ok, however - at this point it seems to be fixed and I will check all databases of all sites I had issues with in the past to make sure that the tuf table is correctly filled.
The effort required to find out why the update was not performed correctly is far too great. So I´ll deal with it and hope it works with the next updates.
Fingers crossed ;-)

@SniperSister Do you think it could make sense to catch that case (empty TUF table) in our code somehow and add that record like the update SQL script would have done?

Or alternatively add a special check to the database checker like we had it in past for the utf8mb4 conversion which shows a database problem when the table is empty and adds the record when the database problems are fixed with the corresponding button?

Or alternatively add a special check to the database checker like we had it in past for the utf8mb4 conversion which shows a database problem when the table is empty and adds the record when the database problems are fixed with the corresponding button?

I like that idea!

nice idea but surely its better to find out why it happens