@Lucas26 Thanks for letting us know and should be fixed in the latest.

Also found a similar class of bug for FTP ports and we are porting the FTP side to dev-branch as we speak.

Please let us know if this is working now?

@toschulz So I suspect the problem is due to a divergence of db schema between dev-branch/stable + working-1.6

If you can update yoru Mysql directly:

sudo mariadb -u root fog (if no root password of course - if you have a root password add -p

UPDATE schemaVersion SET vVersion=0;

Then refresh your screen, click the install/update, and hopefully the error will go away.

The way the schema is configured is it will attempt (idempotently) to rerun every single SQL query in the schema chain.

This should fix the problem you’re seeing.

I believe there’s a column on the login history piece being requested that may just simply be missing which would cause the issue with datatables.

@csurepair Have you tried one of the expermental (recent) kernels?

They’re using 6.18 and use a lot more stuffs that might help you.

Is this preventing things from working in the UI?

What version of 1.6 are you running (should tell you exactly at the bottom right of the UI)

@Strahd Try another git pull please then try install again?

@Strahd IS your fog server actually having issues now?

I know you have the schema testing stuffs, but that was less important.

it seems you have a database and all that jazz

@Strahd IT’s likely the \ character in the line that casued the error you saw.
Either way it seems like it’s working now?

@Strahd Simply put:

Please try a repull and install:

cd /root/fogproject
git pull
cd bin
sudo ./installfog.sh -y

should work?

@Strahd @Strahd Those logs were exactly what I needed, thank you. Two separate things going on
and neither one is your fault.

First, this line is your 500:

[proxy:error] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:9000 (*) failed
[proxy_fcgi:error] AH01079: failed to make connection to backend: 127.0.0.1

Apache was trying to hand PHP off on port 9000 and php-fpm wasn’t listening there yet.
Notice apache came back up at 08:57:16 and there are no more of those errors after it.
So before you do anything else, just reload the page:

http://10.46.10.40/fog/management

There’s a decent chance it works now.

Second, “Updating Database…Failed!” is the part I still need to see. That curl’s
output goes into the install log, so please post:

sudo grep -A5 -i "schema\|Updating Database" /root/fogproject/bin/error_logs/fog_error_1.6.0-beta.3050.log | tail -60

That’ll tell me why the schema update itself came back an error, which is the last piece.

Third - you found a real bug. On 1.6 the schema page makes you log in first, but the
login reads a database column that doesn’t exist until the schema update runs. So it
asks you to sign in, sign in can’t work, and there’s no way out. That hits everyone
upgrading from any released FOG, not just you. I’ve fixed it and pushed it, tracked in
#927.

If the page is still dead, here’s the manual way to force the database update. Get your
token:

sudo grep FOG_SCHEMA_INSTALL_TOKEN /var/www/html/fog/lib/fog/config.class.php

Then paste it into this:

sudo curl -X POST -H "X-Fog-Install-Token: PASTE_TOKEN_HERE" -d "schemaupdate=1" \
  "http://10.46.10.40/fog/management/index.php?node=schema"

You want to see:

{"msg":"Schema updated successfully!","title":"Schema Update Success"}

I tested that against a real 1.5.9 database on PHP 7.4 here, it works.

And to put your mind at ease - none of this touches /images or your tftpboot files. You
are not going to lose your images over this, so please don’t rebuild the box yet.

One last thing. Your install log still had these:

ln: failed to create symbolic link '/lib/systemd/system/mysql.service': File exists

I fixed those on the 27th and the current code can’t print them anymore, so I don’t think
your checkout took. Run this and show me what it says:

cd /root/fogproject
git rev-parse --abbrev-ref HEAD
git log -1 --oneline

Thanks for sticking with this one. You’ve found two real bugs so far

@Strahd Do this:

cd /root/fogproject
git checkout working-1.6
git pull
cd bin
sudo ./installfog.sh -y

@Strahd are you attempting to install dev-branch or working-1.6?

I see the problem appears to be when you’re installing dev-branch this time around, but yesterday it seemed you were attempting working-1.6?

So I’m unsure if the issue is related to a partially updated version now attempting to install against a version that would no longer be directly supported.

Please also post:

sudo tail -50 /var/log/apache2/error.log
sudo php -v
sudo ls /etc/php/*/fpm/pool.d/
sudo systemctl status 'php*-fpm' --no-pager

Findings

@Strahd Please pull dev-branch/working-1.6 again and try again. I think it should work.

I’m trying to test all cases but need the help thanks

@Strahd Can you retry the install again?

Just to be on the safe side of course.

@matia Have you installed the FOG Client on the machine in question?

@Strahd Please reinstall using dev-branch and this should work.

I suspect you’re using PHP version of 7.X potentially which would explain the 500 you were getting and the white page.

Dev-branch appears to have this fixed best I can tell, but also fixed it in working-1.6 (if you want to test this version I think you’ll like it a bit more - but I’ll admit I’m biased lol)

Please let us know.

Thank you!

@GregorS Thanks for letting us know.

I’ve pushed some code into dev-branch if you’d be willing to install and verify that your fog client functions now?

@DiegoP I believe mdadm will still be allowed to work, but I think you’re supossed to use “mdraid=true” for a kernel argument. If this is not set, FOG won’t know to build the array. This would help explain why the disk couldn’t find a partition layout as well since it’s expecting to be part of an array (which then looks/acts as the disk you’re truly working with.

As for “partclone to partimage” I’m not sure I understand.

Fog moved FROM partimage -> partclone way back in the 1.0.0 days as partimage has been obsolete for quite some time now.

@DiegoP I feel like we don’t have enough context.

We have many people using NVME drives, yours appears (from the lsblk output) to be a RAID mode?

Maybe that’s part of why you’re running into issues?

@jerome-m Please install dev-branch and reinstall and try again?

I know capture is a bit more time consuming.

I believe the issue should be fixed but need some testing please.

Thank you!

@vanfifty1 Sweet so it is functional and seems to be much more verbose about the actions it’s performing, thank you!