Cannot deploy (download) image in 1.2.0

[netman86]

I’ve got two laptops, a source and a destination.
I’ve done the full registration on both laptops to the FOG server via PXE boot.

I created an “image” for the source, and assigned it to the source host, then created an upload task for that host.
Booted the source and it proceeded to run through a partclone process for a few hours.

Once complete, I assigned that same image to the destination host and booted it.
That laptop picked up the PXE boot, then rebooted a few seconds later. FOG managed to wipe its MBR, but didn’t run partclone at all.

I created another task for download-debug on the destination host and restarted it again, entered ‘fog’ at the prompt, and it ran through: (excuse the brevity, I’m typing this)

Looking for hard disks, Done
Press [Enter] key to continue.

Using hard disk /dev/sda
Press [Enter] key to continue.

Press [Enter] key to continue.

Press [Enter] key to continue.

changing hostname done
updating computer database status

database updated
Press [Enter] key to continue.
task completed computer will restart

So what I’m seeing there is two sections where something was supposed to happen, but instead I got the “press enter to continue” immediately. I assume this is when the partclone process is supposed to run.

I’ve not been able to find any more errors or input on this one, so I’m scratching my head.

Running FOG 1.2.0 on ubuntu 14.04 64 bit

[Wayne Workman]

What model is the target host?

Is this image a manufacturer based image that you’ve modified, or is it a “From scratch” image you’ve built?

[netman86]

These are both Asus A53E laptops. I deleted all partitions and did my own factory install.

I wound up running through this troubleshooting guide:
https://wiki.fogproject.org/wiki/index.php/Troubleshooting_an_image_push_to_a_client

I learned that after dumping the MBR to the new box, my partition table was “invalid”- it doesn’t like my partition 5.
Once I deleted partition 5, I was able to go through with the rest of the steps and restore my partitions, sans #5. I’ve shrank that partition down by a couple gigs so it’s not touching the end of the device, and am making a new source image to try again and see if there’s some bug there.

FWIW, my partition layout looks like this:
1- 100M
2- 60GB
3- 208GB
4- (extended)
5- 30GB (now shrank to 25)

Is there a bug with extended partitions, maybe? For this purpose I need three usable partitions within the OS, and since we’re limited to three primary partitions and MS insists on that 100MB partition in the front, I think I’m stuck with it.

[Wayne Workman]

@netman86

What is the name of your image?

via CLI on your fog server, can you go to:

cd /images/<name of image>/

and then issue these commands and give us their output:

ls -lahRt
cat d1.original.partitions;cat d1.minimum.partitions

[netman86]

Clarification: when I say I did my own factory install, I meant to say “Base” install- just a standard MS win7 disk.

ubuntu 14.04
fog 1.2.0

image name was “BitSecSource”

[Wayne Workman]

@netman86
Post the output of this please:

cd /images/BitSecSource/;ls -lahRt;cat d1.original.partitions;cat d1.minimum.partitions

[netman86]

I don’t have any .partitions files in bitsecsource;
only files in there are:
d1.mbr
d1p1.img
d1p2.img
d1p3.img
d1p4.img
d1p5.img

[Wayne Workman]

@netman86

ok, that’s fine… the command would have told me this…

I’d still like to know the file sizes to look for potential issues.

ls -lhaRt /images

[A Former User]

Could be completely wrong but I have ran into a problem that sounds similar to yours where it just skipped the imaging process for no reason. I finally figured out that apparently even though the drives showed the same size and both should be able to handle the same image, I had to shrink the partition size just a little so it was under the max size of the hard drive. Maybe give that a try?

[netman86]

I shrank partition 5 and re-imaged the machine, and now the target machine did run the restore- although partition 5 came up empty on the target machine (yet it IS formatted and has the correct label- curious!)

As requested, here’s the paste from the console- note that bitsecsource was the image that wouldn’t deploy, and source2 is the one that worked minus partition5.

/images/Source2:
total 19G
drwxrwxrwx 6 root root 4.0K Jul  9 16:37 ..
-rwxrwxrwx 1 root root 7.5G Jul  9 16:37 d1p5.img
drwxrwxrwx 2 root root 4.0K Jul  9 16:01 .
-rwxrwxrwx 1 root root  296 Jul  9 16:01 d1p4.img
-rwxrwxrwx 1 root root 152M Jul  9 16:01 d1p3.img
-rwxrwxrwx 1 root root  11G Jul  9 15:59 d1p2.img
-rwxrwxrwx 1 root root 8.2M Jul  9 15:07 d1p1.img
-rwxrwxrwx 1 root root  512 Jul  9 15:07 d1.mbr

/images/BitSecSource:
total 18G
drwxrwxrwx 6 root root 4.0K Jul  9 16:37 ..
-rwxrwxrwx 1 root root 7.5G Jul  9 12:31 d1p5.img
drwxrwxrwx 2 root root 4.0K Jul  9 11:54 .
-rwxrwxrwx 1 root root  295 Jul  9 11:53 d1p4.img
-rwxrwxrwx 1 root root  69M Jul  9 11:53 d1p3.img
-rwxrwxrwx 1 root root  11G Jul  9 11:52 d1p2.img
-rwxrwxrwx 1 root root 8.2M Jul  9 11:01 d1p1.img
-rwxrwxrwx 1 root root  512 Jul  9 11:01 d1.mbr

Mod edited to use code boxes.

[Wayne Workman]

@netman86 Would you consider upgrading to FOG Trunk? Your issue might be resolved by this alone.

[netman86]

I can’t say I’ve got a compelling reason not to, assuming it’s a fairly pain free process and the TRUNK version is considered fairly stable.

This FOG machine was built just for this job (I’ve always wanted to try it out) so I don’t have too much to lose if it goes awry.

[netman86]

Since I see the d1p5 has data in the image, I’m going to upgrade to trunk and try to re-deploy to another laptop- assuming it lets me deploy an image made with 1.2.0

[netman86]

So after spending a few hours fixing everything after attempting to upgrade to trunk, I’m running trunk.

I tried to deploy the same image to another laptop and had the same issue I had in 1.2.0.

I then tried to create a NEW image from the source, and that appeared to go fine- but it overwrote my old source instead of creating a new one as I had specified (Odd issues with changing options in host management not sticking)

For whatever reason, the image didn’t work. It went through and did a partition copy, and wrote new files to /images/source2, but under image management that source shows up as 0.00B when it’s about 50G on disk.

I went and changed it to source3 again and created an upload job, which failed- I had to manually create a Source3 directory in /images/ for it to start the process, which tells me that maybe something is screwy with permissions for /images- but everything appears to be 777 so I can’t fathom what it could be.

Creating a new source3 image now just to see what happens…

[netman86]

New image appears to have created correctly, and shows up in image from the web UI with a size- but the restore back to another box had the same results.

[netman86]

update:

after the failed deployment, the size listed under image management changed to 0.00iB. Odd.

[Wayne Workman]

This post is deleted!

[Wayne Workman]

@netman86 said:

update:

after the failed deployment, the size listed under image management changed to 0.00iB. Odd.

That’s a minor bug that is non-impacting. I have a few images that list as 0 in size on client, but they work just fine.

Why do you have 5 partitions?

[netman86]

1. the windows 100mb boot partition
2. C drive
3. D drive (required for this purpose)
4. extended for 5
5. backup partition with image of C for on the road re-imaging (also required…)

I might be able to get away with keeping the image on partition 3 as a file, but TPTB want it on its own partition.

[netman86]

I just spoke to the guy wanting these and the requirement has changed- I also need a small (100mb) partition for the lab, so that’ll be six partitions in all.
I’m testing a RAW image clone right now, I can’t think of a reason it wouldn’t work if FOG manages to initiate the copy on the destination…