Strange Behavior when Uploading Image

[JJ Fullmer]

@mecsr Have you run test disk on the vm your uploading that image from that gave you that message?

Still unsure why uploading an image would cause a cpu halt

[JJ Fullmer]

@mecsr said:

I updated FOG two days ago, so I think I should be good in that respect.

Just fyi, there’s typically at least a few if not a bunch or very many updates to the fog trunk version any given day containing many bug fixes and optimizations. It’s a program that just keeps getting better and you get the benefits of instantly.

The current version is 6303 and you’re on 6271. So I would suggest considering updating

[Wayne Workman]

@george1421 said:

unless he is uploading one whopper of an image.

I remember once a guy uploaded a 1TB image… RAW.

[Sebastian Roth]

Not sure if this is related?!?! https://forums.fogproject.org/topic/6664/virtualbox-image-upload-r4792

Might current kernels really have issues in VMs??

[Tom Elliott]

@mecsr what’s the output of df -i?

[mecsr]

I haven’t had too much time to look at this since yesterday morning, so I haven’t really had an opportunity to run any of the suggested commands on the server yet - I will get around to that very soon. But I do think that there is an update on the situation - last night I started a computer imaging with one of the images that we already have had uploaded for quite some time. It’s worked before, but this time, on imaging, the image almost completes and then fails at the last moment. I have yet to see what the error message says.

I’m starting to to think that the suggestion of hard drive issues might be correct.

[mecsr]

@Tom-Elliott Here’s the output of df -i

Filesystem        Inodes   IUsed     IFree IUse% Mounted on
udev             2035414     522   2034892    1% /dev
tmpfs            2038213     691   2037522    1% /run
/dev/sda2      243122176 9464955 233657221    4% /
tmpfs            2038213       1   2038212    1% /dev/shm
tmpfs            2038213       7   2038206    1% /run/lock
tmpfs            2038213      15   2038198    1% /sys/fs/cgroup
/dev/sdb1      244195328 9354922 234840406    4% /mnt/mist
/dev/sda1              0       0         0     - /boot/efi
tmpfs            2038213       4   2038209    1% /run/user/1000

[mecsr]

@Wayne-Workman said:

@mecsr Can you run find / | grep /dev/.mntcheck please to locate where your image directory is?

Also, how big is the image you’re trying to capture, In terms of space used?

The image I’m trying to capture is at most, 300 GB. My image directory is just at /images.

[Wayne Workman]

@mecsr said:

@Wayne-Workman said:

@mecsr Can you run find / | grep /dev/.mntcheck please to locate where your image directory is?

Also, how big is the image you’re trying to capture, In terms of space used?

The image I’m trying to capture is at most, 300 GB. My image directory is just at /images.

So you only have 431GB of space available on / and if your image is 300GB, then the FTP move at the end may cause issues if the data is copied and then deleted, instead of just moved. Going to ask the @Developers for clarification on the process - this has come up before.

[Sebastian Roth]

FTP move should not be an issue or we should see a somehow FTP related error message - which would happen much later anyway. To me it seams like the image/VM might be corrupted. Although disk space and inodes are not running out yet.

@mecsr Have you tried running chkdsk /f within the client system as suggested on the screenshot??

I really don’t hope that this is the case but could it be the server disk is failing??