Capture task not completing after finishing and then loops

[Tom Elliott]

Is this supposed to be multipartition all disk or are you only trying to do a single disk?

[arainero]

@Tom-Elliott This is a Windows 7 image. There are two disks, the first one has the Win7 OS and the second one is the 1TB storage disk. So multipartition, all disk.

I have used these options before and never had a problem with a capture. This problem has only come to surface after my multicasting problem was fixed, from https://forums.fogproject.org/topic/6129/multicasting-stuck-on-starting-to-restore-image

In regards to my previous thread, I did change password for the FTP, FOG user, and FOG config to trouble shoot that problem before. I did change them back though. I am not sure if that would be related to this new problem or not as I can FTP in just fine.

[arainero]

@Tom-Elliott Do you think I should try updating to the latest trunk version or hold off on that for the time being?

[Tom Elliott]

I say hold off, updating won’t hurt or help anything (I don’t think).

[arainero]

@Tom-Elliott Is there anything that I should test or attempt to narrow down what may be causing this?

[Sebastian Roth]

@arainero Re-watching the video you posted three days ago I noticed something really strange. We see the end of one partclone cycle which is capturing from /dev/sdb. Notice that there is something missing. There is no number showing the partition in that first run. Then we see a black screen at 1:14 saying:

* Image uploaded
* Processing Partitions: /dev/sdb1 (1)
* Using parclone.ntfs

I am still not sure what’s going on but I feel certain that this is really not what we expect to see (first capture full sdb in RAW and then sdb1 as NTFS). Please do me a favour and boot this client into debug mode (Host -> Basic Tasks -> Debug). I am not exactly sure what we are looking for so we might need several iterations on this.
First try the command fogpartinfo --list-parts /dev/sdb Depending on the version you are at this might fail with “command not found”. That’s ok then. After that please run lsblk -pno KNAME,MAJ:MIN -x KNAME | grep sdb and grep sdb /proc/partitions. Please take a picture and post this here so we can see as well.

[Wayne Workman]

@Sebastian-Roth Good catch.

PartClone not only says raw, but the partition number is missing! A big clue indeed.

I can confirm that the partition number should be there, if you look at the example video below the partition number is included in the PartClone screen.

When would the upload process choose RAW when the image type is not set as RAW?

[arainero]

@Sebastian-Roth Here is the picture.

This includes output of requested sdb and I included sda just in case that proved useful too.

http://i.imgur.com/jnhNKhW.jpg

[Sebastian Roth]

Checking our script code again and again I found out what’s causing this!! Lately we re-worked the code on enumerating the partitions on disk(s). In earlier revisions a self written tool called fogpartinfo was used. This has caused some trouble (for example on brand new empty hard disks). So we decided to get rid of it and use well known linux commands to get the partition information. This is a lot more flexible but we are still in the process of getting it fail proof in all cases. But turns out that we haven’t been aware of “Multiple Partition Image - All Disks” being a bit more tricky.
Please download init.xz/init_32.xz from here https://drive.google.com/folderview?id=0B-bOeHjoUmyMazJLZDhGaEl5VTQ&usp=sharing and put into place in /var/www/fog/service/ipxe/ or /var/www/html/fog/service/ipxe/ (probably a good idea to rename the original files instead of just overwriting them!)

Please test and report back if capturing is working properly again.

@Wayne-Workman said:

When would the upload process choose RAW when the image type is not set as RAW?

The scripts collect filesystem information to be able to run the correct partclone command which corresponds/is aware of the filesystem on each particular partition. sdb has no filesystem and is cloned RAW because of that.

[Wayne Workman]

@Sebastian-Roth I don’t know what we’d do without you Sebastian. You’re really appreciated by me and numerous others here. All of the @Developers are really appreciated by me. You all have put in some work, and a fresh pair of eyes always helps out.

[arainero]

@Sebastian-Roth I replaced those files and things are looking good! I was able to take an image without it going into a loop. I am now pushing that image out and hopefully all will go as planned.

Thank you for finding what was causing this. Should I refrain from upgrading from trunk for the near future or will a new version be pushed out that will correct this issue?

[Wayne Workman]

@arainero Until Sebastian replies, I’d recommend sitting on the version you have. And if the changes are successful for you, we can probably expect them to be implemented into trunk. The developers are pretty quick with fixing things with a known solution.

[arainero]

I was able to take an image and successfully multicast it to another computer. I’m going to call that success! Thanks again to everyone who helped!

[Sebastian Roth]

@arainero Thanks for reporting back so quickly! Great to hear that I was on the right track and this seams to be fixed for you. Please do not upgrade (run the installer again) yet as we are still waiting for others to report back if their (closely related) issues are fixed as well. Tom won’t update the init files till we hear back from them. So your issue would come back if you’d upgrade just now. Feel free to ask about upgrading here in this thread by the end of next week again. Hopefully we know more from the others by then and have updated the inits as well.