It looks like FOG is working with Ubuntu 20.04 LTS

[Fog_Newb]

SOLVED

I was on 18.04 and ran “sudo do-release-upgrade -d”, It finished, I rebooted and was able to access the FOG web interface and deploy an image. I am running the latest stable version: 1.5.8

UPDATE: I had some issues when I upgraded to 20.04 on a different FOG box. It has been resolved.

Thanks

[Sebastian Roth]

@Fog_Newb Thanks for testing. I did expect this to cause an issue because PHP versions are different between 18.04 and 20.04. I have added some checks and fixes in the latest dev-branch code a few weeks ago that should take care of this. So for anyone who reads this, I would insist on updating to the latest dev-branch or a FOG release after 1.5.8 (not yet released as of now) just to make sure.

[Fog_Newb]

@Sebastian-Roth I tried the same upgrade on another FOG box and it failed. LOL So I have removed and reinstalled MSQL cause I forgot the root password. Now I am trying to install FOG on it but I get to

Stopping web service…Failed!

I can’t seem to get the dev branch. I can only get Version: 1.5.8.30 Installer/Updater

git clone https://github.com/FOGProject/fogproject.git /opt/fogproject
cd /opt/fogproject/
git checkout dev-branch
git pull
cd bin
./installfog.sh

[Fog_Newb]

@Sebastian-Roth

I see okay I pull from working-1.6
Version: 1.5.8.978 Installer/Updater

That is the newest one I could get. I am at a loss why can not get 1.6

Anyway, yeah, it does not like PHP 7.4

• Setting up Apache and PHP files…Failed
  ###########################################

  PHP Failed to install properly

  ###########################################

  Could not find /etc/php/7.3/fpm/php.ini!

The first FOG box I updated, I must have left php7.3 on it.

[Sebastian Roth]

@Fog_Newb Wait a second!! Don’t mix up FOG 1.5.x and 1.6.x! Both have different changes in the DB schema and you can’t move forth and back.

I can’t seem to get the dev branch. I can only get Version: 1.5.8.30 Installer/Updater

This is what we call dev-branch. I know the version numbers might be a bit confusing so let me explain:

• Current stable FOG is 1.5.8 (master on github)
• Latest developer version of FOG 1.5.x is 1.5.8.30 (dev-branch on github)
• Latest alpha developer version of FOG 1.6.x is 1.5.8.978 (working-1.6 on github) <- this one is really confusion but it’s got that version number because the code was based on and diverged from the 1.5.x code some time ago.

So let’s try to get this fixed…

I tried the same upgrade on another FOG box and it failed.

Please give us more details on this. Post the logs you find in /opt/fogproject/bin/error_logs/ here. The last 15 lines of the latest two files should be enough (one is the actual output you see on the console as well and the other is debug information we need too).

[Fog_Newb]

@Sebastian-Roth

oops nano was only showing me a little bit

Here is the last of the log

fog_error_1.5.8.978.log

ii xinetd 1:2.3.15.3-1 amd64 replacement for inetd with many enhancements
ii zlib1g:amd64 1:1.2.11.dfsg-2ubuntu1 amd64 compression library - runtime
New password: Retype new password: passwd: password updated successfully
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.
mysql: [Warning] Using a password on the command line interface can be insecure.
Failed to stop php7.3-fpm.service: Unit php7.3-fpm.service not loaded.

And last of the install.log

Please enter a new database root password to be set:

To improve the overall security the installer will create an
unpriviledged database user account for FOG’s database access.
Please provide the database root user password. Be asured
that this password will only be used while the FOG installer
is running and won’t be stored anywhere:

OK

• Backing up user reports…Done

• Stopping web service…OK

• Setting up Apache and PHP files…Failed
  ###########################################

  PHP Failed to install properly

  ###########################################

  Could not find /etc/php/7.3/fpm/php.ini!

[Sebastian Roth]

@Fog_Newb Sorry, should have been more clear in my message. I do not recommend you to move over to FOG working-1.6 (version 1.5.8.978) just now!!

Please post the last 15 lines of fog_error_1.5.8.30.log…

[Sebastian Roth]

@Fog_Newb Wait a second. Seeing that Ubuntu 20.04 moved from PHP 7.3 (which it used when I updated our installer a few weeks ago last) to PHP 7.4 I just pushed a fix to dev-branch. Please use FOG 1.5.8.31 and if it fails again, post the log file of that.

[Fog_Newb]

@Sebastian-Roth

UPDATE.

I uninstalled PHP 7.4 and let FOG Version: 1.5.8.31 Installer/Updater install it. All good!!!

My “old” images are still in /images but I am not sure how to get FOG to see them.

[Sebastian Roth]

@Fog_Newb said in It looks like FOG is working with Ubuntu 20.04 LTS:

So I have removed and reinstalled MSQL cause I forgot the root password.

Probably your image definitions are gone because of this. All your hosts are gone as well, right?

Take a look at /home/fogDBbackups/. You should find DB backups there! Please run ls -al /home/fogDBbackups/*.sql and post output here so we can decide which to use.

[Fog_Newb]

@Sebastian-Roth

I got this

1 root root 214677 Feb 24 21:16 /home/fogDBbackups/fog_sql_1.5.8_20200224_091608.sql

[Fog_Newb]

@Sebastian-Roth

Can I just give the images the same names and point them to the correct image path?

Actually I for got what the original names were but I made an image and pointed it to an existing image path and the size showed 0

[Sebastian Roth]

@Fog_Newb said in It looks like FOG is working with Ubuntu 20.04 LTS:

Can I just give the images the same names and point them to the correct image path?

Yes you can. Doesn’t really matter what name you give the images but they are usually same to the folder names you find in /images/.

I made an image and pointed it to an existing image path and the size showed 0

Size information should be updated when you deploy the image to a host.

So are you good like this or should we look into the DB backup?

[Fog_Newb]

Should be good.

Thanks

[Fog_Newb]

@Sebastian-Roth

Hello,

I have been able to deploy the images however the image size in the fog web interface shows 0.

I have also updated to 1.5.8.32
Another odd thing is using acpi=off in the kernel args.

We have a mix of UEFI and Legacy network boot systems. If I enable acpi=off the EFI network boot systems are able to make it to the fog menu but images can not be deployed or captured or registered it just goes to a blinking cursor unless I remove acpi=off.

I was able to get around this before by using an older FOG kernel. I do not recall which one but it was about a year or so old. I didn’t need the acpi=off switch to deploy and capture from HP dc7800s and newer EFI network boot workstations were able deploye and capture too. I am not sure if I should just keep using that older kernel.

I guess I could make a different group with that switch but it seems so odd that an older kernel just works.

Thank you for your help

[george1421]

@Fog_Newb said in It looks like FOG is working with Ubuntu 20.04 LTS:

acpi=off

You should only need this setting for an old and defective bios that doesn’t support acpi properly. It really isn’t a requirement of the linux kernel but its intended for defective firmware. In general this setting should not be used on a global basis.

[Fog_Newb]

@george1421

So… Was the fix going to 1.5.2 init? https://forums.fogproject.org/topic/12924/hp-dc7800-network-boot?_=1587922835837

I will try that and if not use one of the older Tom Elliot kernels from the web interface.

[Sebastian Roth]

@Fog_Newb said:

I have been able to deploy the images however the image size in the fog web interface shows 0.

Sorry, I was wrong. This is only updated when the image is being captured.

We have a mix of UEFI and Legacy network boot systems. If I enable acpi=off the EFI network boot systems are able to make it to the fog menu

To me it seems like you are mixing things up here. The kernel parameter does not play a role until the host actually boots the Linux kernel. So adding or removing a kernel parameter should not prevent any host from making it to the iPXE menu!!

Was the fix going to 1.5.2 init?

It’s all your choice but I’d not go back to such an old kernel unless there is no other way!!

May I ask you to open a new topic on this particular issue? We try to keep things sorted so other people find answers more quickly. The Ubuntu 20.04 issue is fixed as far as I see and we shall discuss a new issue in a new topic.

[Fog_Newb]

@Sebastian-Roth

Yes.

I just want to add real quick, the DC 7800’s can boot to the menu with any kernel and without and kernel parameters. They fail when deploying.

[george1421]

This post is deleted!