@george1421 The capture was successful.

I do not remember shutting down Windows unsafely (on either install), but it seems likely that I did. I had since shutdown from the start menu.

I did see this error:

I am not sure if it will cause any problems.

I plan on running more tests to ensure that everything is working properly, but it looks like the partclone capture problem has been solved. I am curious, however, as to why dd also failed. Shouldn’t the state of the filesystem(s) be irrelevant for dd?

Thank you for your help.

@george1421 After doing so, the error was the same except that partclone failed on sda2:

Args Passed: /dev/sda2 1 /images/782bcbb0e075 all

partclone.log reports that “NTFS Volume ‘/dev/sda2’ is scheduled for a check or it was shutdown uncleanly. Please boot Windows or fix it by fsck.”

I will do this and attempt to recapture.

@george1421 Should I remove it and try again?

@george1421 Here is the output:

[root@fogtest tmp]# showmount -e 127.0.0.1
Export list for 127.0.0.1:
/images/dev *
/images     *

[root@fogtest tmp]# ls -la /images/
total 16
drwxrwxrwx.  4 fog  root 4096 Nov  1 14:19 .
dr-xr-xr-x. 22 root root 4096 Nov  6 13:29 ..
drwxrwxrwx.  4 fog  root 4096 Nov  1 14:28 dev
-rwxrwxrwx.  1 fog  root    0 Nov  1 14:19 .mntcheck
drwxrwxrwx.  2 fog  root 4096 Nov  1 14:19 postdownloadscripts

[root@fogtest tmp]# ls -la /images/dev
total 16
drwxrwxrwx. 4 fog root 4096 Nov  1 14:28 .
drwxrwxrwx. 4 fog root 4096 Nov  1 14:19 ..
drwxrwxrwx. 2 fog root 4096 Nov  6 14:05 782bcbb0e075
-rwxrwxrwx. 1 fog root    0 Nov  1 14:19 .mntcheck
drwxrwxrwx. 2 fog root 4096 Nov  1 14:19 postinitscripts

moderator note: fixed formatting

The FOG version is 1.5.4. The problem with tftpd seems to have been caused by systemd and xinetd fighting over it, and has been resolved. I still get the same error during the capture though.

Also, /var/log/partclone.log does not exist.

Hello,

I am consistently getting an error when capturing an image (single disk, multi-part) that says to “maybe check available disk space.”

My setup is currently composed of three machines:

• dhcp server (Debian 9)
• fog server (Centos 7)
• img host (Ubuntu 18.04 & Windows 10)

The fog server root partition (images stored in /images) has several hundred GB available, and the img host disk is only 80GB. I found a previous post (https://forums.fogproject.org/topic/10967/error-capture-image/2) that prompted me to replace the hdd in the img host & fog server.

What I have tried:

• SMART & on-board diagnostic test for hdd’s (fog server and img host) -> both passed.
• Memtest86+ on fog server and img host -> both passed without error.
• Replacing the hdd in the img host and also the fog server.
• Replacing the switch (a 5 port to an old Cisco switch).
• Replacing the NIC on the img host (It was previously undetected by fog, although the transfer process started).
• Using dd instead instead of partclone.
• Replacing the entire machine for the img host.
• Re-installing fog (after replacing the hdd).
• Running the DHCP server on the on the fog machine, rather than the Debian one.
• Ensuring that the DHCP server has a very long lease (2 days)

I still get the same error each time. There was one exception, where the capture was successful with dd, as was deploying it on the same machine. After creating a new image and trying again as a test, it failed with the same error I was getting previously.

I have not yet tried:

• A single partition image.

Other strange behavior:
Systemd reports that tftp.service goes down after a time, sometimes 10 min, sometimes several hours. Whether it goes down during the capture process, before, or after, it still fails with the same error.