[quote=“Tom Elliott, post: 42523, member: 7271”]Right now I only know of one person who’s natively capable of imaging Mac’s with fog.[/quote]

Make it two on your list Tom! I’ve successfully tested imaging our mac minis with FOG and I am in the process of making it all working in our normal lab scenario.

So to answer the initial question: Yes it can be done and I love it for the exact same reason (mixed linux, win, macos environment!). HFS+ is not an issue (anymore). Network booting is a bit different to PC-BIOS style but can be done en mass! WOL is even more tricky.

Please let me know if you run into trouble and I’ll point you the way.

[quote=“domii666, post: 42414, member: 24204”]fogsettings, advanced menü.[/quote]
Only if you have upgraded to a SVN version, right?? Version 1.2.0 does not come with cumstomizable menu afaik!

You could edit the PHP files to change the menu (ugly) or try upgrading ([url]http://www.fogproject.org/wiki/index.php/Upgrade_to_trunk[/url]). But be warned that this is not a stable release and might break things.

If you only want to remove some of the options from the menu you probably are best of with editing ‘/var/www/fog/lib/fog/BootMenu.class.php’ until the new version of FOG is being released.

Hold on a second. I think you are mixing things up here. Let me explain. When you start deploying an image your client boots up via PXE and comes up with the FOG client. This small linux is made up of several shell scripts to do the magic and deploy an image from your server to that client. First it mounts the image directory from the FOG server via NFS into the local filesystem. So ‘/images’ on the client is essentially the same as ‘/images/<imagename>’ on the server. ‘/dev/sda’ is simply the first hard disk on the client and this is where the image will be restored to (aka destination disk).

From what I can see your ‘/images’ seams perfectly alright (we’d see other error messages if not!).

[B]BUT, are you sure that the disk you pulled the image from is NOT larger than the disk to be deployed to…[/B]

[quote=“lsalv, post: 42408, member: 27895”]Not clear for me: what file to edit, what to extract and loopmount? I suppose to fog.upload to be edited (I did)[/quote]
Where and how did you edit fog.upload??? Are you aware of this: [url]http://www.fogproject.org/wiki/index.php/Modifying_the_Init_Image[/url]

When you edit fog.upload please search for the string ‘mps’ and you should find this part of the script:
[CODE]…
elif [ “$imgType” == “mps” ]; then
gptormbr=gdisk -l $hd | grep 'GPT:' | awk '{$1=""; print $0}' | sed 's/^ //';
…[/CODE]
First partition tables and MBR are saved and then about 40 lines of code further from this point you can see partclone being called…

FOG is trying to restore the MBR using the following command when the error occours:
[CODE]sgdisk -gel /images/d1.mbr /dev/sda[/CODE]
Possibly failes because the destination disk is too small?? Or somehow different to the original source disk??

And there’s still the “connection” problem. Either you use dyn-DNS and port forwarding (all unencrypted) to connect the FOG servers located at different sites or you go the “long way” of setting up vpn gateways everywhere…

Possibly one of the most uncommon scenarios to use an imaging software like FOG over the internet but hey, up to you!

Do all the locations use private (e.g. 192.168.x.y or 10.x.y.z) or public IP adresses and do you have VPN tunnels set up between the sites?

Depending on what your answers are it would be just a piece of cake to use FOG within your organization OR you will have to go a very long way and first learn about a lot of others things before FOG will happen for you.

I personally have never seen or heard about this error. Could you please be more specific: Exact error message, possibly a screenshot or photo taken… (maybe download debug session is helpful when noting down things).

[url]http://myworldofit.net/?p=975[/url]

Can you see DHCP (or any other) traffic on the virtual network interface within your windows host using wireshark? I don’t have windows with virtualbox installed here but as far as I remember it should be possible to caputre those packets.

The internet is full of similar kind of issues (not really a ‘FOG problem’):
[url]http://softwarefromnorth.blogspot.de/2011/04/virtualbox-fatal-could-not-read-from.html[/url]
[url]http://eitwebguru.com/virtualbox-pxe-boot-fatal-could-not-read-from-the-boot-medium-system-halted/[/url]
…

Maybe try hitting the ‘PAUSE’ key just at the right moment or take a video with your smartphone or camera might help…

Please let us know about the OSID and image type you use and we should be able to point you the right way within fog.upload. As far as I know there aren’t any other places to set partclone options. Well, maybe in ‘usr/share/fog/lib/funcs.sh’.

By the way. Did you extract & loopmount before editing the file?? Just asking…

As you probably found out already this error means: ‘Unrecognised HTTP response code’. iPXE is being loaded via TFTP and then tries to load the boot menu or the kernel/init.xz (if a task is scheduled for this host). This obviously fails. What do you get browsing this URL: [url]http://<fog-server-ip>/fog/service/ipxe/boot.php[/url]

And please check your apache log files to see if any errors occour: /var/log/apache2/error.log or /var/log/httpd/error_log

[url]http://fogproject.org/forum/threads/ipxe-error-1d0c6139.11529/[/url]

[quote=“Mark Cheavens, post: 42226, member: 28207”]Still can’t image/deploy a windows7 computer if using single disk resizable.[/quote]
What exactly do you mean by this? Error messages? Deploy going through but windows 7 is damaged afterwards?

Probably a good idea to check the partition tables and see what FOG does with it. Please run a debug upload session with your master pc and run this commands before you start the upload:
[CODE]# sfdisk -d /dev/sda[/CODE]

After downloading the image to another computer you can start another debug session and see how the partition table looks like…

Ok I get what you’re saying about OSID 1/2 check and moving but I still wonder why ‘$ftp->delete($dest)’ is called before moving the new image to that destination. If things go wrong with moving you end up with no image in ‘/images’. What about renaming ‘/images/<imagePathName>’ e.g. to ‘/images/<imagePathName><random seed>’ and deleting it after moving from dev was successful??

Is it always the same machines failing or randomly?? Not easy to track down if it happens randomly I suppose. You can capture all TFTP traffic on the FOG server but might be pain in the ass to go through that packet dump afterwards and find out about those failed clients. TFTP is not the easiest protocol to capture/filter as it uses unknown port numbers when transfering data.
Start off with capturing just the TFTP requests on your FOG server:
[CODE]sudo tcpdump -i eth0 -w tftp_requests.pcap port 69[/CODE]
Copy the pcap file to your PC and open it using wireshark. See if you can find anything useful in there (like missing requests from some of your clients)…

If you want to take it one step further and capture the TFTP answers too you’ll probably have to capture all UDP traffic. Setting ‘snaplen’ (-s) to a sensible number might give you a smaller pcap file and still have all the information you want. See ‘man tcpdump’ too.
[CODE]sudo tcpdump -i eth0 -s 512 -w tftp_all.pcap udp[/CODE]

Upload them to the forum if you want me to have a look at those packet dumps. I’ll see what I can find out.

From what I can see in the mysql log files your database seams to be corrupt since 09.01.15. Possibly because you updated that package. See here:

[CODE]…
150109 12:29:46 InnoDB: 5.5.40 started; log sequence number 1720871
…
150109 12:29:46 InnoDB: Starting shutdown…
150109 12:29:47 InnoDB: Shutdown completed; log sequence number 1720871
150109 12:29:47 [Note]
150109 12:29:47 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
150109 14:30:12 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
…
2015-01-09 14:30:14 9509 [Note] InnoDB: Waiting for purge to start
2015-01-09 14:30:14 9509 [Note] InnoDB: 5.6.22 started; log sequence number 1725017[/CODE]

See the different version numbers… After that you have lots and lots of errors in your log file!!

[CODE]…
2015-02-09 15:19:23 14629 [ERROR] Native table ‘performance_schema’.‘users’ has the wrong structure
2015-02-09 15:19:23 14629 [ERROR] Native table ‘performance_schema’.‘accounts’ has the wrong structure
2015-02-09 15:19:23 14629 [ERROR] Native table ‘performance_schema’.‘hosts’ has the wrong structure
…
2015-02-09 15:27:08 a469db70 InnoDB: Error: Table “mysql”.“innodb_table_stats” not found.
2015-02-09 15:27:08 a469db70 InnoDB: Error: Fetch of persistent statistics requested for table “fog”.“images” but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.
…[/CODE]

Searching the web for this error messages you find a lot of people having kind of similar issues with mysql!!

See here: [url]http://dba.stackexchange.com/questions/48166/cannot-open-table-mysql-innodb-index-stats[/url]
Possibly a solution: [url]http://forums.mysql.com/read.php?22,578559,579891[/url]

Did you do a fresh upload already?? Hope you didn’t. One idea I just had is that possibly something went wrong when renaming the image from ‘/images/dev/<mac>/’ to ‘/images/<imagename>/’ on your last upload. So the image was still sitting in ‘/images/dev’… (maybe?!?).

I am new to this part of FOG and tried to find out about this in the source code. Would anyone with more insight please comment on this if I got this wrong. From what I can see in fog.upload script and Post_State2.php it seams like the old image gets deleted BEFORE the new one is moved in place. In case anything goes wrong when moving the new image you end up with the new image in ‘/images/dev’ and no old image in ‘/images’… is that correct??? I’d suggest to rename the old image first, then move the new one from dev and only then delete the old one!
Post_Stage2.php
[CODE]…
// Try to delete the file. Doesn’t hurt anything if it doesn’t delete anything.
$ftp->delete($dest);
if ($ftp->rename($dest,$src)||$ftp->put($dest,$src))
($_REQUEST[‘osid’] == ‘1’ || $REQUEST[‘osid’] == ‘2’ ? $ftp->delete($StorageNode->get(‘path’).‘/dev/’.$macftp) : null);
else
throw new Exception((‘Move/rename failed.’));
$ftp->close();
…[/CODE]
And another (unrelated) question arises, why check for OSID 1/2 here???

Fresh install?? Upgrade?? I wonder if this is an issue with the installer…