Ubuntu upgrade to 16.04.4 LTS kills Fog

[Julianh]

Hi All,

I just did a minor Ubuntu upgrade to 16.04.4, during which it upgraded php and several other packages. Unfortuately it’s now killed fog!

The fog server url now goes to http://x.x.x.x/fog/management/?node=schema but the page is blank.

I was offered the option of upgrading the php,ini, but kept the existing one.

Fortunatley my images will stil be there, I just need to get fog working.

Before I destroy anythign would this be the right answer https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy, or rather this part of it
“ALTER USER ‘root’@‘127.0.0.1’ IDENTIFIED WITH mysql_native_password BY ‘’; AND
ALTER USER ‘root’@‘localhost’ IDENTIFIED WITH mysql_native_password BY ‘’;”

And why does this happen when I have deadlines?

Thanks

Julian

[george1421]

If you run the fix code from the ubuntu enemy post does it fix the issue?

If you rerun the fog installer is the issue resolved?

If not we can for debugging turn off php-fpm and see what errors are thrown. Do the top two things first and then we can dig deeper.

[Julianh]

Thanks George,

I was checking to see if I was on the right lines before I did ran the commands, I didn’t want to make a bad situation worse, but your reply answered my question, and having run them everything’s up and running. Thank you very much.

I updated using apt-get update/upgrade, but there are still some packages that need updating. This is only done by an apt-distupgrade

I suspect I will have the same issue again. As the fog server is sometimes connected to the internet, I need to keep it up to date patchwise.

Do you have any suggestions re the distributuion update?

Thanks

Julian

[george1421]

@julianh I’m sorry I don’t have advice on how to manage updates. What I would recommend that you do keep your server patched. If you patch under your control then you know when you will need to execute the commands above.

[ddavis]

I actually had the same issue yesterday when I upgrade the OS from 14.04 to 16.04 then after ran the Fog upgrade. Going in MYSQL and changing the password for ‘root@localhost’ and ‘root@127.0.0.1’ I reran the installer and mostly everything worked fine afterwards. I found another issue that the NIC was renamed from “eth0” to “ens32” so I had to change the grub file (https://www.itzgeek.com/how-tos/mini-howtos/change-default-network-name-ens33-to-old-eth0-on-ubuntu-16-04.html) then re-run the installer again. If you get the issue with the host page not loading do this,

sudo gedit /etc/php5/apache2/php.ini
Change
    memory_limit = 1900M
    post_max_size=1900M
    upload_max_filesize=1900M 
Save Changes
sudo /etc/init.d/apache2 restart

and

Raise the web interface’s memory limit: FOG Configuration -> FOG Settings -> General Settings -> FOG_MEMORY_LIMIT
It’s done in megs, so 128 = 128M, 256 = 256M etc…
After changing this, a reboot is recommended

[Wayne Workman]

Just wanted to add my experience about OS upgrading with FOG already installed.

My advice: Don’t do it.

Why? I’ve been active on these forums for about 3 years. I’ve helped several people with FOG since 1.2.x through to 1.5.x concerning OS upgrading. I’ve watched other community members help even more with this. More often than not, it does not go well. There are cases I remember where everything went fine. But there are more cases where things go wrong. When things go wrong - often the community has tried to help the person get things going. From what I can remember, this has taken days to weeks - sometimes these efforts do not result in the repair of the existing installation. I don’t think it’s worth the effort or risk. We have no way to tell you if your OS upgrade would work or not. If things go wrong, you’ll be stuck without a FOG Server, you may not be able to image, and if all of your hosts are setup to network-boot first, that’d be worse still.

What I would recommend: Migrate to a newly built box or VM.

Why? There’s lots of reasons here.

1. Your existing FOG Box will remain unaltered - and not be put at any risk. This is a major safety net. If you are not able to timely build the new box, if the new box has a problem, or any other issue - you still have that old box that is exactly as it was before.
2. We know the exact steps involved for migrating a FOG Server from an old box to a new box - regardless of the OS on either. These are all outlined here: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
3. I test clean installations of the major branches of FOG on several different Linux distributions daily. These tests are automated and the results are available to the general public. The link to the results is in my signature. With these tests, everyone is able to know ‘with a lot of sureness’ if the latest version of FOG will install successfully on whatever Linux distribution - or not.
4. A clean & fresh OS is easier to maintain, has less problems, and is a more ‘known’ state than an upgraded OS where you may or may not have any idea about what’s unique on it.

[Julianh]

Thank you Wayne for such a detailed reply. I think I’ll have to leave it “as is” as I have a dedicated fog Server that was somewhat expensive with its SSD arrays, so I can’t migrate to a new box, I can’t afford it.

What would be nice, for a future development would be a backup and restore option. Both with and without images. Mind you that wouldn’t be an easy 5 minute job, but I suspect it would reduce a lot of support instances, the majority of problems could be avoided.

Would that be possible?

[Julianh]

How do I mark this as fixed?

[Szeraax]

@julianh You can migrate to a VM and prove that your new config works as expected. If so, then you are clear to wipe your expensive box and put a clean OS isntall on it and migrate config to it. Should work with minimal work and you have a good confidence that it work fine.

[Wayne Workman]

@julianh said in Ubuntu upgrade to 16.04.4 LTS kills Fog:

I have a dedicated fog Server that was somewhat expensive with its SSD arrays, so I can’t migrate to a new box, I can’t afford it.

You could migrate to a VM first - then from the VM back to the nice hardware. Keep the VM as a spare - but first use the VM and ensure everything is correct and working - and imaging.