On the downloads page: https://fogproject.org/download, the link to download gives you a file named 1.5.7.tar.gz. The instructions say to untar a file named fogproject-1.5.7.tar.gz. No problem for anyone who’s every done ls or tar. But thought I’d give the feedback.
PS. Looks like you guys have been really busy.
@bigjim How was the image you are deploying installed/created? If it is from a BIOS installed OS, it may not boot on a UEFI system. Sorry if this is a trivial answer.
I usually build my multi-partition (6+ partitions, 2+ OSs) image by installing on several systems, then capturing the individual partitions from separate machines, and deploying them all to one machine. I tried to do that with the latest release candidate and saw that on deployment, each image overwrote the MBR, GPT partition types, and partition UUIDs.
If I change the download scripts to only modify the target partition on deploy of single partition images, will it be accepted into the dev branch?
====================
PS. Sorry for the long absence. Life’s good but eventful. I’m really impressed with the progress you’ve made with FOG in two years.
Wanted to document this configuration for others.
I’m using FOG to image UEFI multi-boot systems, with boot-time selection controlled by /EFI/ubuntu/grubx64.efi. UEFI is configured to boot PXE first, then from the hard drive.
When I configure iPXE’s UEFI exit to anything other than rEFInd, I get the infinite boot attempts issue.
When I leave iPXE’s UEFI exit to rEFInd, the default I believe, then rEFInd tries to boot the first .efi file from /EFI/ubuntu/, which fails to boot. This is because the default_selection for rEFInd is set to 1.
I solved my problem with this:
sed -i 's/^default_selection .*/default_selection "grubx64.efi"/' /var/www/html/fog/service/ipxe/refind.conf
BTW: You guys have been busy! I’m liking 1.5.0. Good work.
Capturing all data up to the first partition was intentional. For GRUB2 bootloaders, the space between the MBR and the first partition is used to store extra data.
I suppose we could put an upper limit on the size though…
[quote=“Tom S, post: 34775, member: 25305”]
I did want to talk about the Fog service for Mac support. In my current profession I have written scripts that do what I can tell the Windows Fog service does, but for OS X. They are primarily bash scripts that can easily be piped from a C or another language. My question to everyone here is this:
What language do we want the service built on???
TS[/quote]
TS: The FOG service for Windows is under active development in C#. So, we won’t be using that code for OS X/Linux. I would encourage you to consider C. That will be at least a portable as Java, if we static compile it. It will be easy to write a simple service like you’re talking about being a wrapper for shell scripts. I could give you some boiler-plate networking code and give advice on invoking shell scripts from within, if you want it. This is something I’ve done in previous projects many times.
Thanks for all of your help.
Great news folks!
Today Michael Brown finished the changes to iPXE to support Apple’s EFI implementation with the SNP (generic) network driver.
This makes at least 3 hurdles that iPXE has cleared so that those of us who have to support Apple hardware will be able to use FOG for imaging. 1) Switch into text mode so we can see menus; 2) Get the linux kernel fixed so it doesn’t write to memory it doesn’t own; 3) Generic networking (important for iMacs in the last couple of years.).
Kudos to Michael and the rest of the iPXE team!
If you’re interested in being an alpha tester, follow this thread. In a few days we expect to need a variety of Apple hardware to finish testing the iPXE fixes (only tested on iMacs mid-2011, late-2012 so far), and begin testing the FOG features. We’ll make an additional post when ready.
TS,
Tom did all of the work on the binary. I’m sorry I forgot about the initrd= kernel parameter. I completely spaced it. Tom do you know if the initrd= kernel parameter will give problems to non-efi versions of ipxe? If it doesn’t, we should probably add it to BootMenu.class.php for the $this->kernel specification.
The ipxe team (mcb30) is still looking at the Apple EFI SNP network driver issues for unsupported NICs.
Keep up the good work.
Update on Mac support:
The developers at iPXE (mcb in particular) have been very good to devote time to the issues with supporting Apple’s EFI. At this time, the latest linux kernels (3.10) and above have the kernel patch necessary to be loaded correctly from iPXE. The latest master version of iPXE has the patch necessary to launch the linux kernel with Apple’s EFI.
I’ve only been able to test this on the mid-2011 iMac hardware. However, the late-2012 and late-2013 iMac hardware all report the same EFI version.
There is still an issue with using the SNP network interface with the Apple EFI from iPXE. So, if the network interface in your system is supported by a card specific driver in iPXE, you should be able to use FOG. That’s the case with the mid-2011 iMac we’ve been testing on. Note that even the mid-2011 iMac doesn’t work with the SNP driver.
So, if you’re really hankering to try out imaging on Apple hardware, get the latest version of FOG, build the latest linux kernel, and build the latest iPXE. Configure your DHCP server to talk Apple Netboot, and give it a try with “mps” or “mpa” style captures. GPT and HFS support have been in FOG for a while now.
If you’re a little more cautious, give us a little more time to get FOG polished and tested on several Apple hardware versions.
Status update: Since my last post, we’ve been getting a lot of help from the iPXE developers. iPXE will now switch the Apple EFI to text mode, so that you can see something when the menus show up.
The error that Tom S posted above could have been scraped off of my screen, dozens of times. 
There was an error in the Linux kernel that caused the launching of the kernel from iPXE fail. There are patches for it in the kernel for 3.16-rc6+, that fix this problem.
Then, there is another error/unspecified behavior in the difference between EFI 1.10 (Apple EFI) and the latest UEFI (2.4). We’ve found the assumption, and made a hacked solution, that allows me to actually boot the new linux kernel and load the fog initrd. Expect a patch into the mainstream iPXE within a couple of days that has a non-hacked solution.
I’ll followup in this thread when there’s more concrete news.
I’m curious if Tom S is imaging OS X only disks, or if BootCamp/Windows is involved on the image?
FWIW, I have been able to run ipxe on the intel macs, using the updates noted in that post, if loaded from the hard drive or USB drive (via rEFIt, or rEFind). However, I haven’t been able to get ipxe to run after downloading to the mac via Netboot. (Netboot is working fine.)
I’ve been able to make grub download via Netboot and run the FOG kernel and initrd. But, we need to do some work to create grub config files from the web service like we do for ipxe. Then, we’re very hopeful that mac imaging will work.
If anyone has been able to get ipxe to run after being downloaded via Netboot, I’d love to here about it. It would save us a bit of work.
[quote=“Buddy, post: 29092, member: 225”]Tom,
I got rid of the “Operation not Supported” message on a Dell 390 today by using the “e0478-DEFAULT-TEST” ipxe.pxe . Though that version did not work on the Dell 990’s. I went through all of the most current files you have posted and here is what I have found.
e0478-DEFAULT-TEST
undionly.kkpxe - - reboot loop on dell 990 operation not supported
ipxe.pxe - - - - operation not supported then freezes
undionly.kpxe - - - operation not supported then freezes
undionly.pxe - - - - assumming it errors but goes way to fast to read error then reboots
ipxe.kpxe - - - operation not supported then freezes
ipxe.kkpxe - - - operation not supported then freezes
d6300-DEFAULT-GOOD
ipxe.pxe - - - operation not supported then freezes
undionly.kpxe - – operation not supported then freezes
undionly.pxe - - - - assumming it errors but goes way to fast to read error then reboots
ipxe.kpxe - - - operation not supported then freezes
ipxe.kkpxe - - - operation not supported then freezes
undionly.kkpxe - - - - operation not supported then reboots[/quote]
For what it’s worth, our Dell 990s work on the out of the box PXE configuration.
This could be a useful generic feature. It seems that it would take quite a bit of work though.
I’d be willing to take a stab at the upload script, but haven’t spent any time in the other parts of the system, so I doubt I’d be effective there right now.
I’ve submitted scripts that improve the grub2 deployment:
[url]http://fogproject.org/forum/threads/improved-grub2-solution-proposal.10674/[/url]
Updated versions of fog.download, fog.upload and funcs.sh to improve grub2 support.
Short description: These changes capture the full “embedding area” (the space before the first partition), instead of just the first 63 sectors. It turns out that grub2 may use more than the 62 sectors, if they are available. With Windows 7, the first partition is usually at 2048, not 64.
These scripts have been tested at least one full cycle of upload/download using a dual-boot (windows 7 & ubuntu 14.04) system, using grub2 and extended partitions for the ubuntu system.
I tried to make it so that you can just replace the old files with these. I think I even got the tabs right.
Let me know if you have any questions.
Thanks!
[url=“/_imported_xf_attachments/0/869_funcs.sh-grub2.txt?:”]funcs.sh-grub2.txt[/url][url=“/_imported_xf_attachments/0/870_fog.upload-grub2.txt?:”]fog.upload-grub2.txt[/url][url=“/_imported_xf_attachments/0/871_fog.download-grub2.txt?:”]fog.download-grub2.txt[/url]
Thanks Tom. I appreciate your persistence in getting this integrated. It’ll save a lot of hassles for first time dual-boot users.
PS. Coming soon: patch to make capture of GRUB2 work in more cases.
raumin.
Are you still having grub2 problems? I just found some more information that could cause grub2 imaging to fail in some common cases. I’m working on a patch now that appears to be promising.
I checked out the latest from SVN and tried to use these updates and they didn’t work. I noticed a few things were changed when you integrated the extended partitions into the scripts. I’d like to submit another set of changes to make things work again, but I have a few questions first.
The variable ${imgPath} isn’t a magic variable I’m unaware of is it?
Is there a reason we don’t want to try to save the extended partitions (and GRUB/MBR) on other than the primary disk? It doesn’t hurt anything does it?
When sgdisk is used to save the MBR on multi-disk systems, wouldn’t we want to save the MBR per disk, and not from the first disk only?
Again, thanks.
raumin,
Check the /images/YOURIMAGE directory. If there is a d1.partitions file, then the partitions were saved during the upload. If not, did you pull from svn, or download the tar.gz file to update?
Thanks.