Nice tool here: http://www.fogproject.org
Latest - My Windows 10 Fog how-to
I have had success doing Windows 10 (Enterprise) as a single partition (resize-able).
Here is what I did:
Have a Libvirt/KVM/Qemu setup. Use qemu-img to create an empty disk - I used 50GB for my example.
Run fdisk on that disk file and create 1 partition of type 7 HPFS/NTFS/exFAT.
Start the install for your vm by using that disk with the full partition, but set the boot to be your iso Win10 Enterprise disk image.
Install as usual.
I did follow the turn off hibernation steps in the article here
https://wiki.fogproject.org/wiki/index.php/Windows_8_UEFI_Imaging_Tips
In case they go away, here they are:
- run elevated cmd prompt;
powercfg.exe /H off
Turn off: "Turn on fast startup",
located here: Control Panel (Classic View) ->
Power Options ->
Choose what the power button does ->
Change Settings that are currently unavailable ->
"Turn On Fast Startup & Hibernate" - i.e. Un-check the box.
I did not have to delete the hibernate partition, as it did not exist - we fdisk created a full disk partition above.
Set the boot to be "network" for your vm, and inventory and push your fresh Win10 image to the FOG server.
- I have set it to be resizeable and pushed to other physical machines, with the bios set to boot legacy first and this has worked for me. I.E. the disk resized and booted fine.
Good luck on your hardware.
Ok, updated to 1.2.0 - here is what I found:
My upgrade was failing due to a probable Mysql upgrade crash issue due to Mysql 5.5.37 on Ubuntu, so I just dropped the db and moved the old code out of the way in /opt.
After a couple of false starts, I found that I needed to upgrade Mysql to 5.5.38.
Post install, I needed to change some passwords:
In Storage Management -> Default member -> set the password to the fog user password (also set that using passwd -u fog).
It seems ftp is used and the config file must have moved on me, so I used the gui.
The symptom of this not being set is the image will stay stuck in /images/dev and not move (via ftp) to the /images/imagename directory.
Also, set the date.timezone = America/Chicago (or whatever you use), for the logs to have the correct date.
That is for the /etc/php5/apache2/php.ini
Last and not least....
As in the previous fog installs I did, it would seem the daemons don't wish to stay running.
To fix:
/etc/init.d/FOGScheduler restart /etc/init.d/FOGMulticastManager restart /etc/init.d/FOGImageReplicator restart
That seems to get the scheduler to at least reboot hosts. Not sure the replicator is needed, but you never know when you might need to add storage.
If you have IDE mode set (legacy mode) in the bios and your pushed image won't boot on new hardware
do a dd if=/dev/zero of=/dev/disk to zero out cruft left over and re-try the image push to the troublesome victim.
Stop the presses! Quick tips for getting Windows 7 x64 on UFEI booting machines...
Rule 1. Don't
Instead, image a basic Windows 7 x64 on a VM with IDE drive setup, or an older 64 bit machine that does BIOS / MBR.
Use that image as a "push" image to the new stupid UFEI booting computers.
Make sure you set the SATA controller to IDE as well on the victim machine you will push the MBR / BIOS setup image to in order to:
1. Set up drivers and software (monolithic setup) - i.e. golden image.
2. Updates etc....
Push and pull, but make sure the UEFI booting machines are set to use LEGACY or if not available IDE for the sata controller.
Probably not the best solution, but it is better than chasing GUID numbers in the registry and debugging FOG for now.
Sounds like GUID / UFEI support is forthcoming though.
One thing that bit me (it was in the documentation though), was the inability to push a large "Snap-in".
without the network slowing to a crawl and having disconnect errors in MySQL.
Turns out, I forgot to tweak the PHP / Apache to have a bigger default memory limit.
/etc/php5/apache2
The FOG folks suggest:
memory_limit = 1900M
I think it would be good to have that in the install section rather than the "Snap-ins" section, but having it documented is good!
Also, if you skin on more storage, make sure there is a .mntcheck file (can be zero byte, in the /images root and /images/dev root.
If you don't change permissions wide open on it, the copy operations will fail as well.
If you don't like world readable / writable, get an app not written in PHP!
Another multi-part problem that comes in to play with that same error:
and / or you get fog to say that it can't find a partition table to upload...
Say you get that error on a Windows 7 install on a Leveno E30
Here is another solution:
Problem 1: The E30's that I have shipped with the cdrom drive plugged in to sata port 1 (hdd in sata port 0). The port 0 and 1 on this mobo is a raid controller, and linux detects 2 drives and tries to do raid with hdd and cdrom. You could guess that this will end in failure. Solution 1: Move the cd / dvd drive to sata port 2 (outside of the 2 port raid). Problem 2: The original install of Windows 7 shipped with a GPT partition table. Solution 2: Re-installing Windows 7 will just make a MBR partition table and ignore the GPT table (this confuses fog and makes it say it could not find a partition table on uploading of the image). Boot with sysrescuecd (*now that you got the problem 1 out of the way), and do this: -------------------------WARNING DATA LOSS CAN RESULT FROM THIS ACTION------------------- DO NOT RUN THIS COMMAND ON A SYSTEM WITHOUT BACKING UP YOUR DATA YOU HAVE BEEN WARNED! sgdisk --zap /dev/sdX (where X is the drive to remove the ghost GPT table).
Also, you might try setting the SATA to IDE mode before imaging to see if it falls back to not including guid partitions in the registry of Windows 7.
If you get errors connecting to the MySQL db, try this:
Edit both files:
/var/www/fog/commons/config.php /opt/fog/service/etc/config.php
I am thinking the second one is key, but ya never know - again PHP
Getting unable to move /images/dev/macaddr to /images/imagename?
Try chown on the directory:
chown -R fog:root /images
Are you getting:
* No job was found for MAC Address: AA:BB:CC:DD:EE:FF (0 sec) * No job was found for MAC Address: AA:BB:CC:DD:EE:FF (5 sec) * No job was found for MAC Address: AA:BB:CC:DD:EE:FF (10 sec) ... etc
It seems jobs can get stuck.
Clear out the file with the same name as the mac address from /tftboot/pxelinux.cfg/