Upload / Download issue

[george1421]

@Sozen Will you log into the FOG server /images/(image name) and do a ls -la and post the results here. Lets make sure what is uploaded looks complete. We may need to get one of the developers to help here since I don’t remember 1.2.0 very well.

[Tom Elliott]

I think we need more specifics. For example I’m reading and seeing both terms in use at the same time. This is confusing me totally.

[Sozen]

@george1421 

And yeah,you were right ! Size of disk weren’t the same… there is no way we can make it work even with different size?

@Tom-Elliott
Hmmm… sorry I might not understand everything u said I’m speaking English as a 3rd language so maybe can u make it more easy for me?

thx !

[Tom Elliott]

@Sozen said in Upload / Download issue:

For now, I’ve only tried to do it the unicast way . The things is that from the start till the end (upload till end of the download) I have not a single error ! It’s just that there is nothing deployed on the target.
I though that if I achieve to make it work unicast, multicast wont be a problem…

The way I read this it’s saying you upload until the end of the download. Those are two conflicting things. Upload/Capture is totally a different process than Download/Deploy.

Are you failing to upload? Are you failing to download? Are you failing both?

[Sozen]

@Tom-Elliott Ow ok !
No I’m doing doing things in orders like, I’m uploading my image which seems to work (no error, partclone even say that is completed ) then i’ll go for the download on the target ( still no error everything goes right it seems) then when I boot the target there is nothing on it expect a “_” on the top right corner.
I guess its just that there is nothing to boot on ?

[Tom Elliott]

@Sozen Normally this happens because of a change in how the image is being “booted”.

For example, if you have a BIOS based system with an MBR Disk layout, and you put this image on a UEFI based system, you will encounter the problem as you describe. Of course there are many other scenarios as to the “cause” of this.

What may be the problem, at least in your case, is the change of MBR layout.

Normally, Windows 7 defaults to a 2048 sector start point for HDD’s (so long as the HDD can operate on it.) In 0.32 images all disks were reset to use the start sector of 63.

My guess, as to the problem, is much simpler though.

Can you boot the host system that won’t boot but took the image into a Debug mode? Go to FOG GUI->Host Management Page->Search/List and find the particular host. Go to basic tasks and select Download - Debug and schedule the task.

Then boot the system.

If you can get us from that now booted system the command output of fdisk -l /dev/sda I can verify if my thought is correct.

[george1421]

@Tom-Elliott This is a Dell 380 (circa 2007 ish) This system doesn’t know anything about uefi. That didn’t come into the picture until the 390/790 series). So this is mbr / bios system.

From the ls -la I can see partition 1 is about 11GB in size. Does that sound about right for your data size on the source image?

[Sozen]

@Tom-Elliott
http://hpics.li/cd6f921
This is what I get !

[Tom Elliott]

@Sozen Now that you’re in the debug can you run:

sfdisk -A 1 /dev/sda

[Sozen]

@george1421
Pretty much y its a basic w7 install with some company related things but it seems like this the size we should get !

@Tom-Elliott Hmmm it’s not prompting anything. It’s normal I guess?

[Tom Elliott]

@Sozen now reboot the system, but don’t let it network boot.
I want to see if your system starts booting now.

All we’re doing is switching the boot flag from SDA2 to SDA1 and the sfdisk allows us to do that non-interactively. So yes, expected to have no output.

[Sozen]

@Tom-Elliott
Sorry, it remain black screen ft “_”

[Tom Elliott]

@Sozen Do you know if the system had an image before?

Would you mind trying:

sgdisk -Z /dev/sda

Then run the command fog from back within the debug menu?

You’ll be prompted to hit enter a bunch of times but that’s because you’re in debug.

[Sozen]

@Tom-Elliott
Yeah I mean I tried to copy some on this one . And before I’ve started put my images on it there was nothing.

Nothing happened after :
http://hpics.li/f71c535

Tried to reboot and still our lovely _

[Tom Elliott]

@Sozen That’s okay.

I have another suspicion to the problem but not a good way to fix it unfortunately.

Do you still have the machine that you used to “upload” the image originally? Can you perform, more or less the same sequence to get that system into a Debug session (but choose Upload - Debug)?

No I don’t want you to run the sfdisk or sgdisk commands on the “upload” machine. All I want from that is the fdisk -l /dev/sda if you can provide it.

Thank you,

[Sozen]

@Tom-Elliott
Ok there is the result !

http://hpics.li/a25cc46

Should I run the upload ?

[Tom Elliott]

@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.

[Sozen]

@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

[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.