Upload / Download issue
-
Server
- FOG Version: 1.2
- OS: Ubuntu 14.04
Client
- Service Version:
- OS: Windows 7 32
Description
Hello ! I’m pretty stuck right now…
In fact, when i upload any image they seems so light like client one is 200g and server one is 2go
obs I cant deploy anything it’s just rebooting endlessly or putting me an" _" in the top right corner
I’m kinda new to fog and tried to find things by myself but it seems like I’m the only one with those problems
any help would be appreciated
thx in advance
-
@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
-
@Wayne-Workman I think the entire problem is he cannot get by with 1.2.0.
-
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.
0http://perpetuum.io:20080/fog_distro_check/installer_dashboard.html
Was my post helpful? Give me two thumbs up: http://goo.gl/forms/isZdOUuhyp
Wiki: https://wiki.fogproject.org/wiki/index.php/Main_Page
one_reply_to_this_post
-
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?
-
@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 -lor withlsblkEdit : 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.
-
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 !
-
@Sozen I agree with Quazz. You should watch the upload process.
-
@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.
-
@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?
-
@Quazz And… What I should I do to fix this?
Thx
-
@Quazz
Hmmm you are right there is nothing in /images/dev
All my images are in /images
-
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?
-
@Tom-Elliott
Vous parlez francais?
-
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
-
@george1421 That’s because I’m on my way to create a new images ! Resizable this time… Hopefully the upload wont take too long
-
@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.
-
@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.
1http://perpetuum.io:20080/fog_distro_check/installer_dashboard.html
Was my post helpful? Give me two thumbs up: http://goo.gl/forms/isZdOUuhyp
Wiki: https://wiki.fogproject.org/wiki/index.php/Main_Page
one_reply_to_this_post
-
@Tom-Elliott
So I’m gonna upload a rezisable one, try to download it on the client ! I’ll keep u informed about the progress !Thx for everything but imo this will continue tomorrow its already late in france
-
@Sozen Based on what I’m seeing. It is indeed due to size of the originating hdd.
Both disks have the exact same partition layout (but the originating system the hdd is 250GB while the receiving system is 150GB).
This has to be the problem. No you do not need to upload, but I do think you need to change the image from a non-resize mode and capture it as resizable.
