@Matdes “check the fog server to ensure disk space is good to go” is not a very detailed error. Partclone doesn’t pass back the actual error to the calling program, only the capture failed. The FOG code tries its best to determine the root cause of the partclone capture failure, but some times it misses.

What we really need to see is the text that sprawls across the partclone screen when it errors out. To get this info please do the following.

Schedule another capture task, but before you submit the capture task, tick the debug checkbox. Schedule the task PXE boot the target computer After several screens of text (where you need to hit enter to clear) you will be dropped to the FOS Linux command prompt. At the FOS Linux command prompt key in fog This will start the capture process in debug mode. At each breakpoint the code will stop waiting for you to press enter to go on to the next step. Somewhere when partclone is capturing partition 3 you will see this error. Take a clear picture of the sprawling text with a mobile phone and post the results here.

That text will actually be the root of why partclone can’t capture that partition.

@Matdes When you delete images on the image list overview the files are not being deleted. This is intended.

If you want to see the files being deleted then go the image settings and use the tab named Delete…

@george1421 Perfect, thanks.

We figured out that an upgrade from mysql to mariadb caused the issue. The database is not completely lost but more or less renamed. We found this hint in the apt logs:

The file /var/lib/mysql/debian-5.7.flag indicates a version that cannot automatically be upgraded. Therefore the previous data directory will be renamed to /var/lib/mysql-5.7 and a new data directory will be initialized at /var/lib/mysql. Please manually export/import your data (e.g. with mysqldump) if needed.

Seems like this is kind of a known problem: https://askubuntu.com/questions/766917/14-04-to-16-04-killed-mysql

Right now we are working on getting the old database back up. Not looking promising. MariaDB crashes terribly when we let it start on the old MySQL 5.7 DB files.

Edit: We were not able to start up the old DB with the new MariaDB version. So the only way I could see was setting up another system (probably old Ubuntu 14.04) with the old MySQL 5.7 version, get up the database there and do a mysqldump as this format can be imported into newer versions. So we decided that it’s probably less work to manually add the image definitions by hand than recovering the old DB. Hope this topic will be helpful for others running into this. Although I guess there aren’t many people still around upgrading from the old version.

@dospace I’ll mark this solved now as the initial issue is found. If you run into issues with manually creating the image definitions just open a new topic and post all the details there (ls -al /images/<IMAGENAME> as well as file /images/<IMAGENAME>/d1p1.img).

@george1421 yes after i tried so much things i remembered that fog runs the batch as SYSTEM. So i think that will be the problem because the Installer copies Files into the Users Folder. I will try your another suggestion with the mapped drive.

@Sebastian-Roth I tried to get a silent command for the installer and tried the standard lines like /verysilent , /silent , /s, /quiet , /q. And yeah it actually worked only with /s 😄

@Sebastian-Roth Yeah, thank you this helps, now is working.

thank you again

@CoxM https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

would you provide the outputs from these commands.
lsblk (I know you already ran this)
df -h

I’m going to bet that you have 500GB of space, but knowing how centos works, it allocated 450GB to /home and not / where /images live. 50GB is the default allocation for the / partition.

@siara Hmmm, I still can’t see why this is failing on your server. Let’s try to get even more into the details. You said that Membership and Delete are working ok. I can understand that because those are handled by a different part of the PHP code. But I can’t think of why Inventory should properly work while all the others don’t. Are you really sure about this?

When you hover over the links with your mouse you should see the link that it would go to, e.g. http://192.168.2.10/fog/management/index.php?node=host&sub=edit&id=1#host-powermanagement
See that it uses the # in the URL to go to the different sub sections. Do the URLs look similar on your server?

Just trying to gather some more information and hopefully stumble upon what’s wrong here.

@chadw18 said:

After running a capture, it will get to 100% then it states unable to locate Database path and reboots.

There are a couple of different messages you can get at this stage. Please take a picture of the message on screen and post here so we know exactly what you run into and can help appropriately.

This problem was solved. I believe that the database server was reinstalled or a new one was installed and thus there was no password.

@george1421 can you please explain with a video tutorial or step by step screenshots. which options i select when i restore only c drive.

@Nabeel Just a few days ago I explained this part of FOG in the forums. Take a look at my latest post here: https://forums.fogproject.org/topic/13430/large-image-sizes

@Fernando-Gietz Actually, we want to use both
Thanks

@Sebastian-Roth

Well if they don’t match that may be part of the issue. The layout is from two identical Optiplex 7060 with 500GB drives. Top was one that imaged successfully, bottom is what I see when it doesn’t. All should match my golden image which is also an Optiplex 7060 with a 500 GB drive. I’m not sure where the disconnect would be from fogs settings, the image, and what ends up on the machine.

Again I’ve more or less gotten around this by modifying my image. So I figure if this issue is unique to me it’s probably safe to let it go. If it does start poking up from others at least my info would be a good starting point.

@CoxM said in Fog Language/location client auto setup:

set the location and keyboard language on a client post image deployment

Is it possible yes with a post install script that updates your unattend.xml file.

For the most complete tutorial on post install scripts look here how to set them up: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Specifically to your question, there is an older tutorial that give you an exact example:
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/6

With a few more hints in the post above:
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/7

@wrinks Any news on this? Did you get this solved?

We seem to have a similar issue here: https://forums.fogproject.org/topic/13422/sub-menu-features-access/6

🙂 marking as fixed…

@george1421 Thank you for the response and this would explain alot of the reason for slow upload times.
Currnetly backing up a Lenovo T470 with standard SSD drive which is currently using about 350GB of storage on the 500GB SSD drive. It’s taking about 2 hours. That being said we are using pretty much the default setup for Fog Server. So the Image Compression Format Default is PartClone Gzip.