Upload / Download issue

[Wayne Workman]

@Tom-Elliott said in Upload / Download issue:

you need to change the image from a non-resize mode and capture it as resizable.

That’s the answer.

[george1421]

@Wayne-Workman I agree. You can’t play with the format (sizeable vs non-resizable) once the image has been captured. If you capture it resizable you must deploy resizable. The same for non-resizable capture.

[Sozen]

@george1421 That’s because I’m on my way to create a new images ! Resizable this time… Hopefully the upload wont take too long :s

[Sozen]

Hey there !

First thing first,

The upload ended yesterday night all seems to be ok !
(strange thing that the new image got the exact same size than the non rezisable one tho)

I tried to download it on my hosts and I get this:

File: \BOOT\BCD
Status: 0XC0000001
Info: An error occurred while attempting to read the boot configuration data.

I used the options (Single disk resizable) there no others resizable mode on my fog…

Thx !

Edit: forgot to say that the download is instant and I guess it shouldn’t be

[Sozen]

@Tom-Elliott
Vous parlez francais?

[Quazz]

My guess is something went wrong with the upload.

Most likely FTP failing to move the newly captured images.

Can you check in /images/dev if there’s a folder there?

[Sozen]

@Quazz
Hmmm you are right there is nothing in /images/dev
All my images are in /images

[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