Strange Behavior when Uploading Image
-
@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?
-
Either way it looks like there is plenty of space of sda and sdb, unless he is uploading one whopper of an image.
I’ve seen the ntfs volume inconsistent when the target is shutdown incorrectly. Booting it back up and then properly closes the disk. I’ve also seen this with a bad / corrupt disk. Either way I’m leaning towards the target’s hard drive at fault.
-
@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
-
@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
-
@george1421 said:
unless he is uploading one whopper of an image.
I remember once a guy uploaded a 1TB image… RAW.
-
Not sure if this is related?!?! https://forums.fogproject.org/topic/6664/virtualbox-image-upload-r4792
Might current kernels really have issues in VMs??
-
@mecsr what’s the output of
df -i
? -
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.
-
@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
-
@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.
-
@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. -
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??