Hey everyone, just wanted to get the news out that I’ve started a new page for anyone who’s interested in running Haiku on the Mac. I’ve currently got a matte black MacBook running Beta 1 (32-bit) and if anyone here also has Mac hardware, you’re welcome to be a part of or follow the page.
In a few days, I’ll be able to change it. Right now, its not letting me do it yet because the page is new. It appears I need to have it up for 7 days.
In any case, though, I’m not going to go crazy because there’s an OS in the name for a bit. Overall, the age old argument over Haiku over Haiku OS has always been odd because even official places everywhere refer to it as both. The logo, project, and Inc. are ‘Haiku’, but the site is haiku-os.org (yes, due to domain squatting over the desired Haiku name, I know), the Twitter handle is @haikuOS and on Facebook, it’s Haiku OS Community and Haiku OS. But I know it is always Haiku and officially Haiku still.
So, other than when I tag @haikuos or #haikuos, I do indeed refer to Haiku as ‘Haiku’. My original intention was to have it say Haiku (OS) so people would know it referred to both Haiku and an OS for visibility and better search results, but it can just be Haiku. So… once I can, it’ll be ‘Haiku on Mac’ if people wish.
Thanks! When I can, I do plan to change the OS bit to just Haiku. My plans for the page otherwise are to accomplish its mission of being a place for anyone using Mac hardware to share their experiences.
At the moment, I’ll be honest and mention that I mainly use the default Mac OS on most of my Macs – but I do have a couple others I can install Haiku on in addition to the matte black MacBook I’ve already converted from Leopard to Haiku Beta 1, so hopefully I can contribute some more to my own effort.
And – if anyone has an Intel powered iMac or Mac Pro they can run Haiku on, that would be very helpful, as all I have for Intel or x86/x64 Macs are notebooks.
Guys, sorry it’s been a while now since I’ve provided any updates, but I realize swapping hard drives between machines to boot Haiku isn’t the most graceful solution in the world to make this work. So, I’m going to try seeing if I can find a way to boot from USB (without the need for rEFInd) and see what results I get that way. When I have something workable, I’ll come back with an update to let you guys know.
I think @Zenja said that booting from a USB2 flash drive works on most Macs now. USB3 flash drives still don’t work, but at least I can reproduce that issue on my main laptop, so when I have time (not likely in the next few months…) I’ll investigate.
Okay, as promised, I have tested a USB 3 stick with Haiku Nightly on several Macs (a few MacBook Pro machines, and my legacy MacBooks) last week, and they are not detected by the startup manager (equivalent to the boot menu on IBM-compatibles).
So, second thing I tried was installing Haiku via kvm, and per what I know from the years of using Debian, I manually created a EFI system data volume (which was formatted FAT32) and copied the EFI folder from the CD image since the Installer did not do so. Of course, Haiku sat in the lower partition, and before anyone asks, yes, I double-checked, including in parted, that the disk was using the GUID partitioning table (GPT). To my knowledge, Haiku is active as well and I set up the boot menu with both the efi and Haiku volumes (or partitions).
The drive was successfully detected by my 2011 MacBook Pro as “EFI boot”, but upon selecting it, it wouldn’t boot any further. The Mac froze; I tried it on the legacy machine, and it didn’t see it at all.
Is something wrong with my setup? I most likely missed something but @PulkoMandy, @waddlesplash, @kallisti5, or anyone who has low-level experience, let me know if you have any advice. I can try falling back to a legacy/BIOS scheme or USB 2 for now, and see what that does (as that did work on my older MacBooks before), but I have the sinking feeling there’s a command (similar to bless on the Mac) or something that I have failed to do to get Haiku on EFI to work (on Mac).
makebootable or other such things aren’t needed for the EFI loader; and the EFI loader is smart enough that if it can’t find a bootable partition, it will just show you the menu and ask you to insert a bootable drive before continuing. So your Mac freezing up upon selecting the “EFI” drive indicates something else is going wrong here; e.g. maybe your Mac does not like our EFI loader.
The earlier MacBook models have 32-bit EFI (this is why Mac OS 10.8 dropped support for them), but the newer ones should have 64-bit EFI on x64 (such as my i7 quad-core MBP). That was actually the first one I tested it on (and it did appear as “EFI boot” on that one but wouldn’t go any further and froze); I had put the stick in the 32-bit machines to see if it was detected at all and nothing appeared. But nothing appearing could be because it was looking for x86 EFI images; thing is, they didn’t see the written images either. They do boot from the hard disk (when swapped out) or from the Beta 1 CD though.
Thanks for the advice about makebootable. I can see if I can rewrite Haiku to it and maybe try a USB 2.0 drive once I get the chance as well. I might also give bless on the Mac OS side a go; I haven’t tried this with a non-Mac system before… but it might be possible that might get the Mac to “see” the disk.
Okay; all my USB sticks have an electric blue fin on the inside of the connector, so I’m going to presume they are all USB 3.0. My Macs do boot using the disk swapping method (annoying, but works), the official Beta 1 disc… but don’t seem to successfully boot from my SanDisk media.
Before I write another stick out, however, I have thought of a main reason behind Haiku’s finicky-ness with my Macs; basically, IBM compatibles accept a PE EFI loader, but if you look at /dev/disk0s1 (or wherever your startup disk is mounted on your Mac) from the Mac OS, (like I have done in macOS High Sierra for the sake of this effort), it is expecting a different format. I’d always taken for granted that the files would be .efi files as I had noticed for diagnostics stored on HP hardware. The firmware that resides in efi/apple is MB71.scap for ‘firmware’ and Firmware.scap in Extensions. Both are listed by file as “data”, and I’ve yet to find any developer documentation that would tell me more about them outside of a ‘Mac OS X Internals’ book (which looks like it may be what I’m looking for) and various articles about it, but not directly into it like what we’d need to get a better idea of it.
So, far as I can see, the alternate way to get a Mac to boot from EFI outside of the native way is to use an alternative boot loader like Grub 2 or the one on Windows XP (on the original Core Duo MacBooks), or Vista and later; the Mac sees both of these in the menu, and curiously can define what it doesn’t know as “Windows” in the startup menu. This may obvious to everyone reading it, but I think reviewing what options may help may reveal a way to set up Haiku so it starts up on Mac. So, outside of falling back to Legacy/MBR booting for Haiku, it would appear that one of these would be the best route we could go with.
I’m going to look at the ‘mac’ edition of Ubuntu’s DVD (yeah, I don’t like Ubuntu either… but it’d be worth the look). Truth is, I find that getting Haiku to boot on Mac without the need to scuffle through rEFInd, etc. is really important to making it more accessible for people with modern Macintosh hardware.
I might also add that Haiku’s EFI loader does not work with the latest VirtualBox or OVMF I’ve tested it with, either. But anyway, I hope my looking into this is helping, you guys…
The scap files are firmware updates, they have nothing to do with booting. They will be copied to the EFI partition during the software updates (only if it contains a firmware update, and only if your computer needs them), and will be flashed at the next system boot.
They should be deleted automatically after the update, good question why you still see them there.
On my 2014 MBP, I can only boot Haiku from USB2 flash disks (tried it on many 8Gb devices), but not from a SanDisk 64Gb 3.0 flash fisk. Once booted, I can install to built in SSD disk, and boot successfully via rEFInd.
Yes, scaps appear to be related to updates as something existing like an archive or an image, or as far as I have been able to discern. And yes, we both know they are extracted during software updates and are queued for updating. So right on with both of those. I have been learning what I can about them from links around the Web, like this guy’s question here (not mine): https://apple.stackexchange.com/questions/279038/what-is-firmware-scap-in-the-efi-partition
Most of that sounds right, but this last part is where we disagree.
First, I doubt they all self-delete themselves. On the Macs I’ve looked at so far, at least one scap is visible in the mounted EFI volume. My best guess would be the Mac OS retains these extracted files as a fallback (maybe in case the next f/w update fails).
Second, I do believe these ‘scaps’ may have to do with booting; to explain my rationale, what I’ve found is that the MacBook FW (the part that makes the x86 PC inside a ‘Mac’) does reside in a flashed firmware image or ROM of sorts, which it uses to start, which I’ve backed up and replaced before (I decided to try out a Libreboot ROM on my MacBook2,1 for fun). I’ve since restored the default one back to it. My point is that I’m thinking it would be helpful to know what is being referenced in these files. The scaps I’m seeing are 4.3 and 15.7 MB, respectively. If I recall correctly, the read back image in the Mac was smaller than the nearly 16 MB scap. I find this curious.
So, my best guess would be one would be a stored copy of a firmware/ROM image. But, is it a pure image or wrapped in something? Again, the scap files mention data. What are they, exactly? I feel someone would need a better tool than file or just articles about them to really know…
My best guess for now, because I really do not know, is that scaps are firmware or archives of firmware, and is why I’ve called them “firmware” throughout my last post. Maybe they’re not entirely an image themselves, but could be similar to a tome an classic Mac installer would read back and extract. But whatever they are, exactly, my guess would be they contain the x86/x64 Mac’s firmware files or an image. Or at least the 4.3 MB one would. Without details, I’m blind. I’m guessing… really guessing. Maybe missing it.
Now, here, I freely admit I sorely messed up in what I wrote. My meaning in this part about “I’d always taken for granted that the files would be .efi files as I noticed for (HP) diagnostics” is in the way that the machines seem to start, which I’ll get to in a minute.
So to fix the confusion I had caused for anyone reading, yes, Macs do use .efi files, but from what I can tell, they don’t behave in the same fashion that an HP, etc. does. I was thinking about the mysterious scaps I’d found in /dev/disk0s1 (as it was the first time I’d encountered them) in my original post, then eagerly jumped straight into talking about those, and see where I was off. I read my post back to myself, and feel stupid. Scaps != EFI. But my best guess is that they are firmware or firmware-related. My apologies.
Okay, so back to solving the problem at hand. We know the Mac uses EFI, but far as I can tell as I’m delving into this, they think about it differently, which is where speculation over firmware/scaps came had come into “the picture”, but I realize now that wasting time in the Mac’s firmware would be the worst way to understand this (if we could even see inside these; Libreboot has working ROMs for 1,1 and 2,1, but we’re talking starting Haiku on at least most Intel Macs). Sure, figuring them out would be getting right to the root of the problem, but again, that’s if someone could. So, as a popular saying goes here in the US, “I’m barking up the wrong tree” or focusing on the wrong thing. I think the less arduous way of solving this would be to go back to examining EFI on its own.
So, back to EFI.
As I had mentioned in the thread before, it would appear IBM compatible PCs use PE based EFI images, as I can verify below with file for bootx64.efi from a Windows 8 DVD:
/Volumes/IR3_CCSA_X64FRE_EN-US_DV9/efi/boot/bootx64.efi: PE32+ executable (DLL) (EFI application) x86-64, for MS Windows
We can also look at a Haiku DVD (from inside Haiku, also using file):
/boot/home/Desktop/mntpoint/EFI/BOOT/BOOTX64.EFI: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
Now, what’s interesting is that the Mac will also mention ‘stripped to external PDB’ as well:
boot.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
So, if the EFI files are all the right format (PE/PE32+), what’s the problem then? I think it has to do with something else; where boot.efi apparently sits on the Mac. This part is why I had mentioned EFI works differently than a regular PC. On a standard PC with Gnu/Linux, etc., we would simply expect that the EFI files we need could simply be placed inside of a partition, mark the volume as active, and voila. But as far as I can tell, the Mac has boot.efi residing inside /System/Library/CoreServices on my startup disk and inside of com.apple.recovery.boot on the “Recovery HD”. I’ve confirmed this not just with my main Mac running 10.13 and 14, but on other Macs as well. I had mentioned the possibility of using the bless command from Mac OS to “bless” the Haiku EFI files so that they would become visible to the startup manager, but the problem with this (and now hopefully people can see why I’m writing this post in the first place) is because of an interesting find:
Sure, the startup manager on the Mac will see and boot from the Haiku DVD (it sees the disc as “Windows”) as I have a blurry shot of below:
But, though the Mac can boot from the Haiku DVD, Mac OS itself doesn’t recognize it. If I run diskutil, I see this (sorry if the spaces don’t show up right):
/dev/disk1 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *1.2 GB disk1 1: 0xEB 1.1 GB disk1s1
The good news, however, is that from inside a VM client on the same Mac (since the VM grabs and reads the disc itself), Haiku sees its own partitions fine. In DriveSetup for the Haiku Nightly disc (/dev/disk/scsi/0/1/0/raw; 608.81 MiB), one will see (commas added by me for clarity):
And this is where I’m at now. And to conclude my post, I see there is work that needs to be done to get the Mac to properly read Haiku. I need to experiment with seeing if I can bless the EFI application successfully and have the Mac recognize it. My belief from everything I’ve been finding is that I cannot treat Haiku on the Mac like I would a Pavilion, for example (and I readily and fully confess I had made the initial mistake of doing so; I’d forgotten just how EFI on the Mac worked). In order to solve the startup problem with an EFI equipped Haiku on the Mac, I will need to make a custom disk image that will be set up in a way that the Mac can understand. I haven’t taken a look at Ubuntu’s image yet, btw, but plan to do so for reference.
Awesome to know! I was beginning to wonder if switching to USB 2 would work or not. As far as the 64GB SanDisk, that’s what I’m finding as well. My MacBooks won’t boot for me when I use a similar USB 3 SanDisk flash drive either. I’ll try to find a USB 2.0 disk somewhere, write Haiku to it, and test it to see if it helps.
Anyway, everyone, I will be back sometime soon with (hopefully good news) and updates on how my ‘Haiku on Mac’ adventures are going…