Upload / Download issue

[Sozen]

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

[Wayne Workman]

Is this a pre-existing production server or did you build it to try fog?

[george1421]

Also what host are you attempting to uploade. (Mfg and model). FOG 1.2.0 stable is a bit old.

[Sozen]

@george1421
W7 version 6.1 (number 7601: Serv pack 1)

@Wayne-Workman
I’m currently working (this summer ) for a company who asked me to find a way to deploy in multicast… So yeah, my first time. There was nothing before !

U guyz answered so quick I though it would take days !
thanks !

(sorry im leaving, ill be back tomorrow)

[george1421]

@Sozen No sorry what computer are you using that you want to capture?

AND did you perform the fog compatibility test from the iPXE boot menu?

[Sozen]

@george1421
Oh! Yeah so I’m using a DELL OptiPlex 380 as client and my server is on a Lenovo T520

The compatibility tell that both memory and disk are Ok !

Thx

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