• TLDR; Rerun the fog installer if you have lost “Database Connectivity” to your fog server, or run the ALTER USER syntax shown below.

    So Ubuntu 16, among others I suppose, enable a “security updates” to be applied automatically as a “default” to things. Why, well it makes it simpler to ensure your Ubuntu systems are in compliance and patched for any potential exploits. This causes unknown and unexpected issues.

    I figured it’d be a safe thing to express that there could be problems (as many of you have already experienced) that when these updates go up (with or without your knowledge) it can break functionality in unexpected and inopportune ways.

    The quickest fix is to simply rerun the fog installer which should correct the problem.

    As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

    The “fix” if you must do it manually is to open a terminal and obtain root:
    Super (Windows Key) + T then sudo -i (in most cases).

    From there, open mysql with mysql -u root

    NOTE: MySQL MUST be run with ROOT.


    ALTER USER 'root'@'' IDENTIFIED WITH mysql_native_password BY ''; AND
    ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

    It’s okay if one of them fails. This is going to fix Most people’s issues.

    I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

    To prevent this problem from happening in the future you could run:

    apt-get -y remove unattended-upgrades (AS Root again).

  • @Tom-Elliott said in Ubuntu is FOG's enemy:

    apt-get -y remove unattended-upgrades

    This saved my bacon, thank you very much, first command failed but second one worked, i have also run the unattended-upgrades command, once again thank you.

  • Very informative thread.

  • @wayne-workman got it…

    so I misunderstood when I thought the database was fully built in the FOG installation…

    anyway thank you!

  • @haylander Typing in a password during the installer does not set a password for the database, it merely tells the fog installer ‘here, use this password to access the DB’, which won’t work if that password isn’t set prior.

  • Hello!

    First of all, my English is terrible!

    I downloaded CentOS 7 and FOG 1.4.4 today, with all updates, i follow exactly all the installation steps contained in FOG Wiki, even so i have the same problem described here.

    I was able to resolve the issue with the instructions in that topic, in this case, as follows:

    PS: At the time of installation I did NOT leave the mysql password blank, I set a password.

    sudo -i
    mysql -u root
    set password for 'root' @ 'localhost' = password('password entered at the time of installation fog');
    set password for 'root'@'' = password('password entered at the time of installation fog');
    update mysql.user set plugin = 'mysql_native_password';

    That done, I was able to access the web GUI normally!

    @wanderson and @Tom-Elliott, thank you so much!

  • @wayne-workman nice try wayne 🙂

  • Hey there Canonical, you’re not doing yourself any favors when you change settings the admin has manually set. I hoped someone on your team would have read this thread and made changes accordingly to prevent the continuance of mayhem, but alas it seems nobody has… Don’t you have Google alerts setup when the words “Canonical” are used on-line?

  • Great I found this as solution for the same problem that suddenly appear here, i remove the “unattended-upgrades” from Ubuntu and I hope that don’t happen again. , solved!

    Thanks @Tom-Elliott !

  • @Wayne-Workman

    How difficult is it to migrate from an existing FOG server / FOG storage node running Ubuntu to Centos from a FOG perspective?

  • @Avaryan said in Ubuntu is FOG's enemy:

    Which linux distro is most preferred by the developers?

    CENTOS 7, Debian 8, or RHEL 7 are my preferences for production.

    Fedora and Debian are my personal favorites for testing and development.

  • update mysql.user set plugin=‘mysql_native_password’;

  • @Tom-Elliott said in Ubuntu is FOG's enemy:

    ALTER USER ‘root’@‘’ IDENTIFIED WITH mysql_native_password BY ‘’;

    I still have the error, can not I leave the mysql password blank?

  • @Tom-Elliott It seems that so far this command has resolved:

    SET PASSWORD FOR ‘root’@‘localhost’ = PASSWORD(’’);
    SET PASSWORD FOR ‘root’@‘’ = PASSWORD(’’);

    chown -R apache:root /var/www/

    Praying that the mistake will not happen again!


  • @wanderson The alter user syntax is only a specific version of mysql and mariadb. IN the case of mariadb I believe it started with version 10.2, and for mysql it started with 5.7.

    So, in your particular case, chances are the version of mariadb is not one that supports the alter user statement. That said, i only recommended the post as it seemed similar to what we’ve recently seen with CentOS 7. It does not mean this was the issue, but trying it wouldn’t hurt anything either.

    The issue that brought you to this posting is most likely related to Max connections being used. I don’t know what settings will fix that for you.

    @Avaryan I try not to specify a specific OS. This posting is mainly just informing users of potential issues we were/are seeing. I’m personally a fan of Fedora/Redhat/CentOS, but I try pretty hard to make our installer distro agnostic. For the most part we support the two main types found (Debian based, and Redhat based). We also support Arch.

    If I had to say which one to use, I’d actually say CentOS as it’s stable, usually minimally offset from Redhat releases. Fedora would probably be the next one on the list, but in a “production” world I wouldn’t recommend it.

  • @Tom-Elliott said in Ubuntu is FOG's enemy:


    Command mariadb?

  • Which linux distro is most preferred by the developers?

  • @Tom-Elliott

    BD this mariaDB


  • @wanderson Have you tried replacing with localhost?