@sudburr What I meant is re-installing the Linux OS!

@humoss233 said in Error decrypting LUKS partition prior to capture/imaging:

I run 1.5.5 because that’s the latest available as a docker container (https://github.com/Mudislander/fogproject).

Do you know the person creating this? Would be interesting to know why 1.5.5 was used and not updated since.

@george1421 said in Error decrypting LUKS partition prior to capture/imaging:

The openssl libraries are already included in FOS Linux for other reasons. Are we passing things between FOS and FOG today that should be protected a bit better in the future? Possibly in 1.6.x it would add some value (??)

We’ll do as soon as we see it’s needed.

@viggo said in PHP install error:

OS Ubuntu 14.04.6 LTS (Trusty)

Is there a good reason you still use a Linux version that is end of life?

@Gilberto-Ferraz Ok, the issue might be caused by that third hidden (type=27) partition on your source disk. It’s more or less preventing FOG from properly resizing your layout to a smaller size disk.

The other things is that your FOG version 1.5.4 is fairly old. There have been a lot of fixes and improvements since then. I am not sure but possibly there was a fix in the resize scripts since then. So my first suggestion would be you upgrade to the latest version (latest release is 1.5.7) and see if it fixes the issue. If not we can take it from there.

@Gilberto-Ferraz Too bad I have been away for a couple of hours and did not know the Linux OS you have. If I’d known I would have warned you.

There is a known issue when upgrading to 1.5.7 on Ubuntu!! If you say yes when the installer asks if it should re-install Apache/PHP it will also try to force a migration from mysql to mariadb and fails.

Here are the steps to manually roll back to MySQL that will still have all your FOG information:

sudo -i
mv /var/lib/mysql /var/lib/mysql-mariadb
apt-get remove mariadb-client mariadb-server
cp -a /var/lib/mysql-5.7 /var/lib/mysql
apt-get install mysql-client mysql-server
systemctl start mysql

For more detailed infos read:
https://forums.fogproject.org/topic/13492/fog-1-5-7-update-database-issue
https://forums.fogproject.org/topic/13703/missing-data-after-fog-1-5-7-upgrade
https://forums.fogproject.org/topic/13447/lost-database

@lebrun78 Sorry, updated my post…

Found and fixed an issue in the advanced menu code just now. Please re-pull the latest and re-run the installer.

On a other test with Version 1.5.7.49, I did have to edit this file to change the adress of the chained server.

So what is the difference between 1.5.7.49 and working-1.6?

Fixed now in latest version of FOG: https://github.com/FOGProject/fos/commit/5600a5adf952d6cef50f60c4fde1a1551c2ba7ee

@Baessens In this special case I’d suggest you use basic Linux commands to export/import image definitions and sync the image files to your other node.

• Optional: Create a sync user account on your main master node - otherwise you’d use the root account to do that but don’t use the fogproject account!
• Setup SSH keys to be able to login using the sync (or root) account from node B to node A
• Setup a cron job on your node B to do the DB and file sync
• Make sure rsync is installed on both nodes.

Here is just a quick outline of how you might do this (untested!):

#!/bin/bash

ssh syncuser@nodeA mysqldump -u root -pPassw0rd fog images >/tmp/images.sql
mysql -u root  -pPassw0rd </tmp/images.sql
rsync -ave ssh syncuser@nodeA:/images /images >>/var/log/fog/myimagesync.log 2>&1

This will wipe the images table on your node B and import all the definitions you have on node A.

@george1421 @jeremyvdv Probably a spanning tree issue?!

@marted Your setup is kind of special so there is no common solution to it. But we can try some workaround:

1. edit /opt/fog/.fogsettings and change the line hostname=foglabunix to hostname=132.208.x.y
2. re-run the installer this time using the command line parameters to re-create CA keys: ./installfog.sh -S -C -K
3. download and import the newly generated https://132.208.x.y/fog/management/other/ca.cert.der into your browser

@george1421 @tech49 Shouldn’t it be:

for retry in $(seq 3); do
       sleep 27
       /sbin/udhcpc -i $iface --now
done

@cbrherms It’s been a long time… sorry! Finally found the time to set this test case up myself but I can’t replicate the issue as described. In my setup it deploys from the right storage node if a host is set to be at that location. Both doing single deploy as well as group deploy. If I create a group with two hosts, one at each location and deploy to that group they both pull the image from the correct server (one from master and one from storage node).

Tested on dev-branch as this is the version we currently work on. So either I got things wrong or this issue is not existing in the latest version (anymore). I’ll mark this topic solved until someone else comes along and is able to replicate the problem.

@EStegenburgs said:

The first network adapter is NAT (enp0s3), and the second one is VM internal (enp0s8).

So when the installer asks you about which network adapter you want to use, what did you say? I have to admit that my setup is a little different and that I have not tested it this way yet. But I remember there is an issue in the installer script with network adapter enumeration. Possibly this is causing the issue for you in the end. On the other hand I do wonder that PXE boot seems to work find then.

Do you still get the Error: Failed to retrieve directory listing when trying to connect via FTP?

@greichelt Great to hear you were able to figure out what was causing the reboot hang on the machine. Maybe you can put in the kernel parameter acpi=off only for the machines that really need it. Probably someone added it for a good reason. But doing this as a general option caused some/most to hang…

Would you mind opening a new topic for the hang on first boot issue? We try to keep things a bit organized so other people find answers more quickly and might be able to help themselves. I will mark this one as solved now. If you open a new one, I can move your last to posts over to the new one.

@loutrage Yes, you need to install the fog-client on your host(s). It’s not something FOG does automatically. Usually people install the fog-client on the “mother” image and deploy that to all the hosts.

16/12/2019 10:50 HostnameChanger Users still logged in and enforce is disabled, delaying any further actions

Now this time the client communication seems fine. But it doesn’t try to join the domain because a user is still logged in to the host and the force option (host’s AD settings -> Name Change/AD Join Forced reboot?) is not enabled.

@Jpolk91 While George is pointing out the right configs to look at I think the issue is not about upload/download an image but only the error message initially posted about kernel update, right??

So I’d suggest you follow @george1421’s advice on testing the FTP connection but instead of using /images you want to test this:

cd /var/www/html/fog/service/ipxe
mkdir backup
put testfile.bin

The last line simply means uploading a binary testfile.

@Jpolk91 said in Unable to update Kernel after upgrade:

ls -la /var/www/html/fog/service/ipxe

Maybe I am blind but I can’t see directory backup here!! Later in your post you say “the backup directory already exists”?!

CWD /var/www/fog/service/ipxe/backup

Watch out /var/www/fog and /var/www/html/fog - one should be just a link to the other directory. Please run the following commands and post output here:

ls -al /var/www/
ls -al /var/www/html/

@Jpolk91 Great to hear this has fixed the issue for you!

Is there anything else I may need to do or be aware of re: the double install or you think I should be good?

Not that I know of from the top of my head. While I cannot promise you anything I would leave things as is and wait if any issue comes up.

At some point you might need to think about updating your Ubuntu install but 16.04 LTS is still fine at the moment. No rush.

also I know it would be hard to guess with what we’ve shared and my assumption is I did something stupid without realizing it (I really need to find time to learn more about linux in general especially since I need to keep this server alive) but is there a “common” reason these issues may happen so I can avoid it in the future?

I don’t think it is something you did. If I remember correctly there was an issue with this link in an older version. As you updated FOG from 1.4.x there is a chance that old version has messed it up. Sorry.

Learning Linux is a live long task. Even for me, working on Linux every day for many years. Just keep on playing with it and find yourself getting more and more comfortable. A great way is setting up a test environment in a VM where you can snapshot, test and re-install without much trouble…

@Quazz @shruggy Ok, after a major debugging session I am fairly sure I found why partclone.imager doesn’t work anymore the way we are used to it. Find new details here: https://github.com/FOGProject/fos/issues/35

On the question why we use partclone.imager instead of partclone.dd - also discussed in the other forum topic but just to give you the full picture: Intially partclone only had the dd mode that would save sector-per-sector (dd style) images that you’d need to restore using partclone.dd as well. But as partclone.imager was added it made things for us a bit easier to simply use partclone.restore for all images.