Updating Build 4820 on CentOS 7.1

[Sebastian Roth]

Did you try restarting mysql by hand? What do you see? service mysql restart

[sudburr]

Issuing prior to update attempt:

systemctl restart mysql
Failed to issue method call: Unit mysql\x2a.service failed to load: No such file or directory.

This is CentOS. It uses MariaDB .

[Wayne Workman]

@sudburr said:

Issuing prior to update attempt:

systemctl restart mysql
Failed to issue method call: Unit mysql\x2a.service failed to load: No such file or directory.

This is CentOS. It uses MariaDB .

I’ve got a fog box right here running CentOS 7 and systemctl restart mysql works fine.

If you’re still getting this error, try reinstalling mariadb and mariadb-server

yum remove mariadb mariadb-server
yum install mariadb mariadb-server

[sudburr]

Reinstalling mariadb is a bad thing, mkay. Toasted the database. Sends me to the schema updater, then error 500.

I don’t know how much cleaner from scratch I can make this install, but at no time is MySQL available as a service.

[sudburr]

Interestingly, removing mariadb-server prior to attempting the upgrade, the installer breezes through the MySQL setup/start.

But 404 remains.

[Tom Elliott]

@sudburr what’s the error or errors you’re seeing in the Apache error logs? Centos 7 I believe uses systemd and needs systemctl restart mariadb

[sudburr]

Found it… I think. I’ll get back in a sec.

[sudburr]

A few things.

Removing MariaDB prior to upgrading, removes the MySQL fail from the FOG Installer. The FOG installer fixes things up.
Running the FOG installer twice gets things just as far.

At the:

You still need to install/update your database schema.
  This can be done by opening a web browser and going to:

      http://x.x.x.x/fog/management

  Press [Enter] key when database is updated/installed.

I can either remote in via another session to apply the following fix, or [Enter] to continue to completion then apply this fix:

sed -i -e "s|/management|/fog/management|g" /var/www/html/fog/index.php

Visit the home page, http://x.x.x.x/ which redirects me to http://x.x.x.x/fog/management , update the schema, and I’m your uncle.

So I have a workaround that completes the process, but it doesn’t explain why it fails to begin with.

[Tom Elliott]

I have solved this thread as the issue received has a fix and a workaround for the fix has been posted here. That said I don’t know that I fully understand what happened. Usually you don’t do a redirect from the base url. This way you can still host other things if needed. So maybe the webroot setting got incorrectly set? Webroot can be species however you want it to be. I will take a look and see if there’s anything I can do to fix the problem but I think I need more details.

[sudburr]

Considering some of the changes I make from default, it may have been self-inflicted, but the changes I’m thinking of are necessary to make some things work.

I’m going to fire up another scratch CentOS 7.1 server and start from there and see where it goes.

[sudburr]

Hmm,

• virgin CentOS 7.1 minimal install
• install build 4820 : no configuration changes made
• install build 5036

The update to 5036 still fails on the first attempt, at the same setting up/start MySQL.

A second invocation to update to 5036 completes properly.

The http pathing problem is due to changes I make.

[Wayne Workman]

@sudburr My CentOS 7 build I have on my desk at work uses “Server with GUI”, with all three virtualization options ticked. Then, inside of a VM on that, I have another “Server with GUI” built. And on that, Fog installs just fine. and updates just fine. That’s with having a fully updated server before hand of course, running yum update -y

Everything about the build is default.
SELinux and Firewalld are disabled of course, as well.

[sudburr]

@Wayne-Workman said: My CentOS 7 build I have on my desk at work uses “Server with GUI”, with all three virtualization options ticked.

Well that’s a major difference right there. I’m only using minimal install. No GUI.

[Wayne Workman]

@sudburr It is major, but I don’t think it would affect the DB stuff…

Maybe you can try this option tomorrow?