@sudburr What I meant is re-installing the Linux OS!
Best posts made by Sebastian Roth
-
RE: How to totally expunge FOG and everything it's touched
-
RE: Error decrypting LUKS partition prior to capture/imaging
@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.
-
RE: Error decrypting LUKS partition prior to capture/imaging
@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.
-
RE: PHP install error
@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?
-
RE: Upload Image From HDD 500GB to SSD 120GB
@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.
-
RE: Upload Image From HDD 500GB to SSD 120GB
@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 -
RE: FOG 1.6, identified problems
@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?
-
RE: Failed to read back partitions (runPartprobe)
Fixed now in latest version of FOG: https://github.com/FOGProject/fos/commit/5600a5adf952d6cef50f60c4fde1a1551c2ba7ee
-
RE: Multiple master nodes syncing images
@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. - 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
-
RE: 2019...a step by step activating ssl and complying iPXE with it
@marted Your setup is kind of special so there is no common solution to it. But we can try some workaround:
- edit
/opt/fog/.fogsettings
and change the linehostname=foglabunix
tohostname=132.208.x.y
- re-run the installer this time using the command line parameters to re-create CA keys:
./installfog.sh -S -C -K
- download and import the newly generated https://132.208.x.y/fog/management/other/ca.cert.der into your browser
- edit
-
RE: udhcpc: sending discover
@george1421 @tech49 Shouldn’t it be:
for retry in $(seq 3); do sleep 27 /sbin/udhcpc -i $iface --now done
-
RE: Disable additional MAC address feature?
@isaiah658 Finally found the time to change this in
dev-branch
(ref). From what I have tested this only happens if you didn’t have any additional MACs defined for that host yet. Changing the primary MAC would then cause the “old” one to be added as additional. Not anymore after this change. -
RE: Fog 1.5.7 ignoring location settings
@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. -
RE: Image capturing: Updating Database...Failed
@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? -
RE: Workstation does not reboot after imaging
@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.
-
RE: Problem to join a domain (SSL problem ?)
@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.
-
RE: Unable to update Kernel after upgrade
@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.
-
RE: Unable to update Kernel after upgrade
@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/
-
RE: Unable to update Kernel after upgrade
@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…