UNSOLVED Upload / Download issue


  • @Tom-Elliott
    Ok there is the result !

    http://hpics.li/a25cc46

    Should I run the upload ?

  • Senior Developer

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


  • @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 _

  • Senior Developer

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


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

  • Senior Developer

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


  • @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?

  • Senior Developer

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

    sfdisk -A 1 /dev/sda


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

  • Moderator

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

  • Senior Developer

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


  • @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 ?

  • Senior Developer

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


  • @george1421 ![alt text](0_1476275324825_Screen1.png image url)

    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 !

  • Senior Developer

    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.

  • Moderator

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


  • @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 🙂

  • Moderator

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

  • Moderator

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

366
Online

8.0k
Users

14.9k
Topics

140.7k
Posts