Mac support
-
I believe there’s a developer already working on a method to get Mac supported, right now it’s using a grub4dos passage to get into the fog system, and they’re using a custom kernel from ubuntu rather than the default kernel FOG currently has. I don’t know what’s needed on the kernel side to allow native Mac support. I do know Mac’s use UEFI and require an EFI file. I’m just waiting for stable support of the undionly/ipxe efi files before I will begin testing. I’m hoping I don’t need to do much in regards to getting good support of this as it will open up a ton of possibilities I believe.
-
-
Cheak out this post.
-
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.
-
Hey everyone. So I have been looking to expand Fog to support Macs. I have made a few minor changes to fog.upload,fog.download and fog.checkin to support Macs. I also added the “OS X” OS type to the fog database. The imaging works great!! Both single deployment and multicast
As most people realize, you can boot an iPXE cd and get the whole thing working. But who wants to carry around dozens of cds or usb drives? So I decided to go through offering up a efi to the macbooks through isc dhcp. That works great too!! I first started with Grub2 efi and got that booting through netboot. I moved away from grub because it seemed only possible to work if I included the kernel and ram disk into the efi binary itself…not very scalable or compatible with fogs current logical flow. Then I realized that ipxe updated their site @ [url]https://rom-o-matic.eu[/url].
Here I selected the advanced settings and created both 32 and 64 bit efis. They both boot their perspective macs into iPxe and proceed to get the boot menu from fog. All seems great right? Almost. When iPXE loads the init.xz and bzimage we receive the ok message. Linux starts to boot and displays the followinf errors:
i8042: No controller found (web points to ps/2 keyboard driver…but this error is not on cd version of ipxe)
kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Kernel offset: 0x0 from 0xffffffff8100000 (relocation range: …continues on
–[ end kernel panic - not syncing: VFS Unable to mount root on unknown-block91,0)]none of these errors occur from the cd boot of iPxe. I tried removing root=/dev/ram0 from the boot arguments but alas, no prevail.
I have tried this on both 32 and 64 bit efi macs and the same error occurs. So to sum up this long and winded post: Mac support is very close but it looks like some tweaking to the kernel or ipx.efi is in order.
Tom Elliot you seem to be the maintainer of this post so I ask to you… is there anything you would like me try or possibly a nudge in the proper direction
Thanks
-TS -
Talk with fractal13 as he’s done almost “EXACTLY” what you’ve done here. We’re working on it and the ipxe dev team have been extremely helpful in trying to get us there.
-
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?
-
[quote=“fractal13, post: 34245, member: 24300”]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?[/quote]
I just started working on my “version” of fog a week ago so I have only tested os x only drives. But I have thousands of macs at work I can test with. So once the ipxe issue is resolved, nice going by the way, I can help test this out on a multitude of macs.
Thanks
TS -
Please don’t forget that I can try and help.
Finally 3.15.7 came out, only a matter of time for 3.16.0!!!
-
Tom S,
Can you post a diff -u of your fog.upload/fog.download? You said you already had it going. What OSID are you comparing it with? I’ve added osid 8 for Apple MAC OS. I just don’t know the best approach for the fog.down/upload files.
-
[quote=“Tom Elliott, post: 34265, member: 7271”]Tom S,
Can you post a diff -u of your fog.upload/fog.download? You said you already had it going. What OSID are you comparing it with? I’ve added osid 8 for Apple MAC OS. I just don’t know the best approach for the fog.down/upload files.[/quote]
Of course Tom… I left my source files at work today…oops. I can get those to you tomorrow.If I might digress for a moment please.
I have been working for school districts in a state where we provide a laptop for every 6, 7 and 8 grade students (State Law). I have seen lots of imaging solutions (ghost,Deploy Studio, JAMF amongst many others) and I really like fog. One thing that does drive me a little bonkers is multicasting. Making/editing groups and etc while you have a thousand devices to image is rather cumbersome. Whereas deploy studio and ghost allow you to just join a session.I recently stumbled across a fog wiki post explaining how to bypass the host registration so that one could join a multicast session by supplying its name ( just like ghost) but it was designed for version 0.32. I reworked the hack to be 1.1.2 compatible. Then I added hfs+ support which was adding 10 lines of code to func.sh and fog.upload. But really fog was setup to do the work it just needed to point partclone to use hfsp rather than imager. MPS disk works great. If finds GPT, creates disk1.mbr, and subsequent
img files. The restoring process is the same old business. So long as you are not changing drives the firmware remembers default boot deviceTo my point: I can send you the diff files but they contain more than just the os x support. I guess my question is, do you want to remove all but the changes needed to get os x support or would you like to see all my changes?
Either way I am extremely happy to be able to help out with this.
As far as the name… I have developer access to apple and I can tell you that the name scheme for Yosemite is OS X 10.10.x and already talks about OS X 10.11 are popping up. I asked one of the Apple Engineers assigned to our states 1 to 1 laptop program and he stated “the name is OS X Mavericks and OS X Yosemite versus just mountain lion, lion or leopard” So your naming of Apple Mac OS (8) is good!!
Thanks
-TS
-
If you know how to adapt the Multicast Session stuff, that’d be interesting and feature I’m sure other’s wouldn’t mind.
I didn’t/don’t have the mental capacity for any level of multicast myself, so I appreciate the work and effort if you’re willing to provide and allow us to use it.
I’m sure others will appreciate that as well. I don’t mind getting the code and I can probably figure out what’s happening to get multicast working for you.
-
And for what it’s worth, SVN 1999 is when I added hfsp, so that means !.2.0 already has the hfsp file format in use.
-
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.
-
Great news!!! I will try out the ipxe source and let you all know!! Once I confirm the patches on my end I will test on macbook from 2007-2010, Mac pro 2009-2012, and macbook airs over WiFi.
I will then pull from git the latest branch and diff my changes to submit to fog (multicast tweaks)
I have most of my scripts ready for renaming and binding to domain as well. Just need to see how fog records those tasks. Then create the service.
I love open source…look at what you have accomplish in such a sort time!!! Great job everyone
Thanks,
TSBTW
Boot camp imaging works on Maverick and Windows XP. I will try 7 this weekend -
fractal13,
I am still getting the VFS syncing error. Are you using the TomElliott.configs? If so are you still using the firmware patch Fog recommends to use when building the kernel?
Thanks,
Tom
-
[quote=“Tom S, post: 34506, member: 25305”]fractal13,
I am still getting the VFS syncing error. Are you using the TomElliott.configs? If so are you still using the firmware patch Fog recommends to use when building the kernel?
Thanks,
Tom[/quote]
The VFS syncing error, how does this come out? Are you using the correct pairing? init.xz and bzImage should both be 64 bit. init_32.xz and bzImage32 should both be 32 bit. If you load 32 bit bzImage with 64 bit init.xz, or 64 bit bzImage with 32 bit init.xz, you will see this error.
-
[quote=“Tom Elliott, post: 34517, member: 7271”]The VFS syncing error, how does this come out? Are you using the correct pairing? init.xz and bzImage should both be 64 bit. init_32.xz and bzImage32 should both be 32 bit. If you load 32 bit bzImage with 64 bit init.xz, or 64 bit bzImage with 32 bit init.xz, you will see this error.[/quote]
Thanks for reply Tom,
No my versions are correct, I have tested with the new files last night. The same pairing also works on cd boot of mac and the 30 Dell pcs I am imaging right now.I believe it has to do with ipxe and the bzImage. I changed the log level to 6 and can see that it sees the macbook devices and board info. It also can see my hard drive. It also talks to dhcp and gets an ip address. I think it just can’t see the /dev/ram0. Fractal13 said this had to do with a patch for the kernel. I have tried numerous variations of the config file for the kernel, adding and removing efi support settings, etc. Currently I am working on kernel 3.10.50.
Thinking that is a memory issue I tried to add the ipxe Mem_map settings but the compiling fails. If at all possible, Fractal13 if you could provide your config files for the kernel and ipxe???
(I should also mention I am testing on MacBook 5,2 and 5,1)
I will continue to tinker…thanks,
TS
-
OK…after hours of researching the efi stubs and the ipxe boot process, I got macbooks 2007-2011 netbooting so far. It maybe common knowledge, but it was news to me.
The VFS syncing error was totally the way iPXE handles memory mapping and the hand off of the init.xz file system.
I was using the syntax to load the image in the boot menu as:
[CODE]:img1
kernel bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=< DNS IP> web=${fog-ip}/fog/ consoleblank=0 loglevel=4 type=down img=<IMAGE NAME> ftp=${fog-ip} imgType=n osid=7 storage=${fog-ip}:/images capone=1 imgFormat=2
imgfetch init.xz
boot || goto MENU[/CODE]But the only way I could get it to work was as follows:
[CODE]:Img1
imgfetch init.xz
kernel bzImage.efi initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=${fog-ip} web=${fog-ip}/fog/ consoleblank=0 loglevel=4 type=down img= ftp=${fog-ip} imgType= osid=99 storage=${fog-ip}:/images mc=yes bypass=1 mSession=“”
boot || goto MENU[/CODE]imgfetch needs to be first so that is add to memory first. Then add the kernel parameter with initrd=. The bzImage.efi is just a renamed bzImage. I think the previous pattern did not supply the name of the init file system. I could see that it was using the room in memory but the kernel just could not grab it…strange
Nonetheless so far, no driver issues, no kernel issues. Current grab from git provides bootable 32 and 64 bit images and ipxe efi(64 bit only,I compiled the 32 Bit needed for 2007 and 2008 macbooks). I feel this is a good start.
Thanks Tom and Fractal13 for getting the new binary up!!
TS
-
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.
