Cannot deploy (download) image in 1.2.0

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

the windows 100mb boot partition
C drive
D drive (required for this purpose)
extended for 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…

Cannot deploy (download) image in 1.2.0

191

12.0k

17.3k

155.2k