Upload / Download issue

[george1421]

@Sozen OK so you are using a 380, that is good in a way because you use fog 1.2.0 and that version doesn’t support the latest hardware (like Dell 7040 or P3510). So we can rule out target system issues. You really should update to 1.3.0-RCx to get better hardware support but I understand that may be out of your control.

We we need to identify is will a unicast up capture / deploy work correctly or is this a multicast issue?

When you capture this dell 380 do you select single disk resizable (resizable may not be an option on 1.2.0) or just single disk not resizeable?

Can you capture from one o380 and deploy to another o380 of the same hardware style?

On your destination computer is your hard disk the (exact) same size or larger? I have seen issues with 1.2.0 where someone captures from a 80GB seagate disk and tries to restore to a 80GB WD disk where if the destination disk is even 10bytes smaller than the source imaging will fail if single disk nonresizeable is selected.

When I was on 1.2.0 I would create our golden image on a virtual machine with a 40GB hard drive, this way I was sure the image would fit on any destination computer we would have. Then we would expand the disk once it was on the target computer to the size of the physical disk.

[george1421]

@Sozen The size on the fog server doesn’t sound right. I could understand that if you have a windows computer with a 200GB hard drive and you had selected single disk resizeable or even nonresizable and the image size was 20GB on the FOG server that would be logical, since FOG only uploads data not empty space on the hard drive. So if you look on the golden image there may be 20GB of data used. Also understand that the FOG compresses the image as it uploads to the fog server so that 20GB of raw data may end up 15GB in the image file.

[Sozen]

@george1421
We we need to identify is will a unicast up capture / deploy work correctly or is this a multicast 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…

When you capture this dell 380 do you select single disk resizable (resizable may not be an option on 1.2.0) or just single disk not resizeable?

I’ve tried :
Single disk - Resizable
Multiple partition image - Single disk (not resizeable)
Multiple partition image - All disk( not resizeable)

Same thing everytime like 130g for the client image ends up in 2 on my server !

On your destination computer is your hard disk the (exact) same size or larger? I have seen issues with 1.2.0 where someone captures from a 80GB seagate disk and tries to restore to a 80GB WD disk where if the destination disk is even 10bytes smaller than the source imaging will fail if single disk nonresizeable is selected.

Yeah might be a part of the problem even if they are all o380 maybe disk size are different for what ever reason.
Imma gonna check disks to see if there is a difference. ill keep u informed.
But its like every of my test where on theoricaly “same device”.

Thx a lot

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