Moderators

@mstabrin I’m wondering if you are going about this from a wrong direction. Why not use rsync to keep your files in sync between your repository and the local server. If you use rsync or git for that matter, if you deployed as a snapin you would use rsync or git from your linux distro then would not need to add it to FOS Linux. It would only need to be in fos linux if you needed it to sync during imaging. (I need to check but I think rsync is already in FOS Linux).

If you didn’t want to deploy via snapin just create a cron job that runs once a days to “freshen” the local files to your repo. With rsync only the changed files would be sync’d on each run.

@rogalskij So you upgraded from a fog server with centos 7 installed and you upgraded to centos 8? Do I understand the situation?

If FOG was installed and you upgraded, this might get messy.

1. Look through the hidden file in /opt/fog/.fogsettings update the settings to reflect the new values for the fog server (like interface names and such).
2. Rerun the FOG installer that might install any missing components as well as correct the rest of the setup.

If step 2 doesn’t work to correct the issue then rename that .fogsettings file and run the installer. It will prompt you for all of the questions again but this time it will do a complete install (it will not touch the image files or database). That should pull in all of the missing bits.

Also with the upgrade make sure that selinux is disabled as well as the centos firewall.

@mikmatcr The problem (most likely) is a non resizable partition as the last partition on the disk. This causes the resize to a smaller disk to be an issue. I think the developers have resolved this is a interim beta release of FOG 1.5.10. If you are using fog 1.5.9 you can upgrade to the dev branch. There may also be an init update if you are still running 1.5.9

ref: https://forums.fogproject.org/topic/15025/move-partitions-on-gpt-layouts-need-people-to-test

@jcrod73 Ok the problem is you are trying to cut the branch you are standing on. You need the fog client to install the snapin to remove the fog client.

So how can you do this (on a high level).

1. Add a task to the RUNONCE registry so the next time the computer is rebooted the command will run to remove the application.
2. Create a scheduled task to run the command after the snapin finishes.

I don’t use the fog client in my environment so I can’t confirm this for you. but look in the registry for the fog client uninstall string. It should be in this area: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer once you have the uninstall string you can then craft msiexec /x <guid> /q to uninstall the FOG client. Or if you have the fog client msi, drop the msi behind on the target computer and then reference that file with the /x command. There are a couple of ways to uninstall it, you just can’t use the fog client itself to uninstall it.

The other option is to no use the fog client (and services it provides) but use a third party tool like pdq deploy to install your packages. This gives a zero footprint on the target computer.

@jcrod73 What is the use case for uninstalling the FOG client after deployment? There may be a different solution available to you.

@patrice Now rereading the thread I see your old server crashed and this is the server where you are trying to get the mariadb running again. If you can’t get the old database server started you might have to rebuild the metadata by hand.

article on fixing corrupt innodb databases: https://chepri.com/mysql-innodb-corruption-and-recovery/

@patrice said in import or migrate images and host to a new serveur:

 /dev/sda2          1,9T    1,7T   53G  98% /

This will be a problem soon. You only have 53GB free. Look in /images/dev directory on the fog server linux console, for any directory names that look like mac addresses. If you are not currently uploading an image those directories should not exist. You can safely delete those bad upload directories to free some disk space.

But I have to say that 53GB is enough free space to allow mariadb to startup.

@patrice connect to the fog server linux console and run the command sudo df -h and post the results here.

@bido Well where its failing we can rule out a lot of things. You have your PXE booting configured correctly because iPXE is running. That is undionly.kpxe. That file is getting transferred to the target kernel and is running. Its iPXE that is having a hard time.

The next test I want you to do is to install a cheap unmanaged switch between the target computer and the building switch. This test will give us an indication if spanning tree is enabled, but you are not using one of the fast spanning tree protocols (RSTP, MSTP, port-fast, FastSTP or whatever your switch mfg calls it). The dumb switch will keep the building switch from resetting the spanning tree counter while booting. Understand this is only a test to tell us if its spanning tree or not. My gut reaction is yes.

@diegotiranya Just to confirm that VMDON works at normal speed without needing to have a usb flash device installed?

VMDON

0000:00:1d.0 System peripheral [0880]: Intel Corporation Device [8086:09ab]

10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:a0b0] (rev 20)
	Kernel driver in use: pcieport

VMDOFF

00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:a0b0] (rev 20)
	Kernel driver in use: pcieport

Looks like the base addressing also changes between vmd on and off.