With the extended partition, when I go to restore, it simply fails. Running through debug it said something about the partition table in the image being no good.
With no extended partition, it worked a treat- that’s what I used today. It re-sized the partitions a bit funny, but I got over it.
I love when it’s just one after another…
these machines have to be on a plane Monday so I just did the unthinkable and multicasted them without the extended partitions (multicast worked like a charm!) and then went to each one and created the partitions and added the data. Yuck!
It’s done, anyway.
Onto the next project…
@Wayne-Workman That appears to be a dhcp issue- what I’m seeing is something along the lines of the thing booting network just fine, but it finds the partition table to be corrupt if there’s an extended partition, and refuses to download the image.
I built a base win7 and imaged it- worked fine. Ran all the updates and imaged it, worked fine.
Created my D partition, worked fine.
As soon as I created an extended partition, the download failed- even though the upload still runs flawlessly.
I suspect that it’s related to SDA4 (the extended partition that SDA5 exists inside of) touching the end of the disk. I’ve seen odd problems with images in the past where shrinking a partition by just a few megs would make a difference.
Of course, windows won’t let me do that…
I’ve not had any success since moving away from 1.2.0 so I feel like I’m missing something.
I created a new image, type 4 (raw dd) and set partition to “everything” with compression set to 1 hoping it’d not store the 300 some odd gigs of 0’s that way.
I then assigned the image to my source machine and scheduled an upload task. Booting the source machine to the network brought me to the clone process, which took about two hours. (Expected for a dd)
Then I assigned my target host that same source, and scheduled a download task (in debug mode, because I expected it not to work). Booted the target machine to the network and it started fine. Started the fog process and went through it at each step.
Variable dump:
osid=5
osname=Windows7
mbrfile=/usr/share/fog/mbr/win7.mbr
type=down
storage=ip.addr:/images/
img=Source4
imgType=dd
imgFormat=
imgPartitionType=all
hd=/dev/sda
part=/dev/sda1
typed in ‘fog’ enter
attempting to send inventory, done
checking in, done
mounting filesystem, done
checking filesystem, done
starting image push
using image Source4
looking for hard disks, done
wiping /dev/sda partition info
erasing mbr/gpt, done
creating disk with new label, done
initializing /dev/sda with ntfs, done
processing partition /dev/sda ()
partition file missing /images/Source4/d1p.img
stopping fog status reporter, done
changing hostname, done
database updated
task completed
So, it would appear it can’t find the image file…?
I went on the server and looked in /imgages/Source4, there’s only one file- Source4 with a size of 187GB
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…
Thanks- Caught me off guard is all, I use randomly generated passwords whenever possible so you never know what might come up 
I just generated a different one that didn’t involve the $ character as a workaround on my end.
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.
update:
after the failed deployment, the size listed under image management changed to 0.00iB. Odd.
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.
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…
Just what I was looking for- thanks!
After a failed upgrade to fog-trunk, I couldn’t get fog-1.2.0 to work again either- so I deleted the /var/www/fog and /opt/fog folders (leaving the DB and the /images folder alone) and re-ran the fog-trunk install.
While I’ve got the web interface back now, booting to fog is broken.
The issue is that the boot is trying to load a file at http://<ip>/service/ipxe.boot.php that isn’t there.
The file is, however, at http://<ip>/fog/service/ipxe.boot.php that isn’t there.
I tried correcting this by adding a softlink in /var/www to point to the /var/www/fog/service directory to no avail, so I’m wondering what the correct way to fix this would be. Is there a setting somewhere I can change to point ipxe to the correct path?
I hate to ask the obvious, but are your xenserver tools on that VM up to date? XenServer does wonky networking things if the VM tools are out of date- and IIRC reverts to 100mbit if they’re not installed at all.
It was suggested that upgrading to ‘trunk’ would solve an issue I’m having with Fog.
I followed the ‘wget’ procedure (super complex! ) here:
https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
When it got to the section where I should browse to <host>/fog/management to set up the database, that webpage is completely blank.
Finishing the install script does nothing, the whole interface refuses to render, now.
A quick search here had me check the .fogsettings file, where I noticed my SQL password was wrong- it appears to have truncated a $2 out of the password I had used for sql root. (possibly a bug?)
fixed the password and restarted the install with the same outcome.
I then went back into .fogsettings and removed the $2 from the password field and saved- then changed the root pw to match what is in .fogsettings and re-ran the install for trunk again and am still getting a blank page, so I’m fairly certain this isn’t password related.
If I look in the apache2 error log file, when I hit the blank page for DB setup, I’m getting the following error:
PHP Fatal error: Class ‘System’ not found in /var/www/html/fog/commons/init.php on line 78
A quick search for that error came up with nothing. Suggestions welcome!
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
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.
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.
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
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”