Upload / Download issue

[Sozen]

@Quazz And… What I should I do to fix this?
Thx

[Quazz]

@Sozen /images/dev should be empty (bar .mntcheck) after a successful upload.

However, given that it is obviously not working properly, something else is up. Might be worthwhile to try and capture again and watch it closely.

Does it resize before capture? (if no, then you’re not using resizable image type)

Does it capture every partition?

Does it report any errors at any stage?

[Tom Elliott]

@Sozen If you were capturing the image, the and the image is NOT in /images/dev, it means all things went fine. However, the naming convention of the /images/dev folder is typically /images/dev/<macofhostuploading>

The other reason the image might be exactly the same size? A resizable image moves the partition layout to allow the image to go onto a smaller disk. All imaging formats FOG uses (partial exception with RAW) only captures the used space. So it’s entirely possible, if the machine that uploaded the image before is uploading the image again, but as resizable, the data didn’t change at all.

[Wayne Workman]

@Sozen I agree with Quazz. You should watch the upload process.

[Sozen]

@Quazz

Yeah I’ll try to do that !
Not sure about how I can check if he captured every partition tho…
Any idea?
Edit : is it normal that when the data block process end, the total block process in at 20-30%?

Thx !

[Wayne Workman]

@Sozen said in Upload / Download issue:

Not sure about how I can check if he captured every partition tho…

With any Linux Live CD - or FOG Debug capture, you can get a listing of partitions with fdisk -l or with lsblk

Edit : is it normal that when the data block process end, the total block process in at 20-30%?

Yes. Resizable only captures the areas that have data. It doesn’t capture blank space. Also total block progress is the whole HDD, not the partition I think. RAW would capture the whole-thing. with RAW, a 500GB drive equals a 500GB image… beastly… should always be the very last resort - and only if you’re crazy desperate.

[Tom Elliott]

We might want to add the 1.2.0 did not capture with the same finesse as the RC’s currently do. I’m only guessing that our OP is still running 1.2.0?

[Wayne Workman]

Yeah I think he’s on 1.2.0. I’m trying to not go completely crazy with recommending the 1.3 RC if 1.2.0 can get by. In this case I think 1.2.0 can get by. Of course the 1.3 can do better.

[Tom Elliott]

@Wayne-Workman I think the entire problem is he cannot get by with 1.2.0.

[Wayne Workman]

@Sozen Please move to FOG 1.3.0 RC, you can find instructions here: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk